Why Agile Always Feels Wrong (But Is Actually Right) for Tech-Enabled Service Companies

A few years ago, the CEO of a tech-enabled services company asked me why our product team wasn't gathering all the requirements for a big piece of functionality and why we didn't already have a detailed plan for building everything.

The typical answer is, "Because we are agile, doing it all upfront is wasteful and can delay our time to market. So instead, we gathered just enough requirements to understand how we could build this for our customers while still getting something to market quickly so that we can provide value and learn.". However, this answer frequently falls flat because Agile doesn't intuitively make sense.

If you are in a tech-enabled services company and struggle with this, then this is for you.

For most people, it can be challenging to understand the nuances of Agile, especially without experiencing it yourself. For you, without a technical background or time in the trenches, it seems counterintuitive to not have a comprehensive plan upfront.

Like building a house, don't you need to get all your requirements upfront?

We naturally think using a step-by-step methodology, and most of our world functions like this.

Imagine if you went into surgery and the doctor told you she would "figure it out" along the way. You probably would want another doctor.

Agile can feel like that to you.

It is hard for you to see how something as natural as gathering all requirements is a bad idea AND why it will delay your time to market and stifle your ability to adapt to new insights and feedback.

You want to understand and trust the team but this Agile stuff feels "wrong".

If this resonates, then I'd like to start with why Agile is better.

Understanding Agile: More Than Just a Buzzword

Agile development has revolutionized how software is built and delivered. It emphasizes iterative progress, collaboration, and flexibility. Compare this to traditional project management that follows a sequence of steps, each dependent on the completion of the previous one. Agile turns this notion on its head.

In Agile, planning, execution, and delivery happen almost simultaneously. Teams work in sprints, delivering small, incremental updates and adjusting based on continuous feedback. This non-linear approach can be challenging to grasp if you've never experienced real-world product development.

And I don't MEAN watching it happen, I MEAN participating and having a front-row seat. It requires a shift in mindset from seeing progress as a straight line to understanding it as a series of mini-cycles, each bringing the product closer to its final form.

More like a painter that is creating something new and constantly is changing what they are painting as it evolves.

The Communication Gap

One of the biggest hurdles you will face is bridging the communication gap between technical and non-technical team members. Technical jargon, complex architectures, and abstract concepts can make it difficult for non-technical leaders to thoroughly grasp a product's current state and needs. This can lead to misaligned expectations, missed deadlines, and frustration.

Effective communication is crucial, and face-to-face communication is preferred. You should strive to understand the basics of software development and create an environment where technical experts can clearly explain their work in layman's terms. Regular check-ins, transparent reporting, and fostering a culture of mutual respect and understanding can help bridge this gap.

The Trap of Faux Agile

A common pitfall you will face is the misconception that your teams are practicing Agile when, in reality, they are implementing a modified version of Waterfall with smaller increments. This "faux agile" approach can be hazardous. It involves breaking down projects into smaller phases, much like Agile, but still follows a linear, step-by-step progression without true iterative feedback loops or flexibility. Granted, this is faster than the traditional Waterfall of months between releases, but it still is wasteful.

Side note: I said "project" instead of "product". Oftentimes, you may think about the work as "projects" and treat them as fixed scope, time, and budget. They are NOT!

This pseudo-agile method fails to capture the core essence of Agile development, which is to embrace change, continuously improve, and deliver value incrementally. Instead, it retains the rigidity and sequential nature of Waterfall, which can lead to bottlenecks, delayed feedback, and a false sense of progress. Teams may appear to be high performers on the surface (e.g., lots of outputs, status updates, etc.), but without the underlying principles of responsiveness and adaptability, they always fall short of delivering value compared to real agile teams.

Tail Wagging the Dog - Governance is rarely the answer

Another common pitfall is putting project managers over your product development teams. This sucks and is wasteful because it leads to a focus on timelines and deliverables over customer value and product quality. Project managers emphasize predefined plans and meeting deadlines, stifling Agile development's flexibility and iterative nature. This misalignment results in failed products that don't meet user needs, hindering innovation and reducing market impact.

While it feels natural to lean on project managers to navigate the inherent chaos of product management, especially during the early stages or when turning around an underperforming team. The messiness of this process can be intimidating, and project managers provide a sense of order and control. However, this can overemphasize structure and deadlines when team's most need flexibility and responsiveness.

The challenge for you is to balance your organization with the dynamic nature of product development. Embracing the messiness, fostering experimentation, and trusting the product team's expertise is essential to ensure the focus remains on delivering actual customer value rather than merely adhering to schedules and checklists.

Scary, isn't it?

This isn't to say that you shouldn't see progress/reports. It is even more critical that regular design and product demos are conducted and that you can see the results. But I often see vanity metrics and status updates become the norm. Ask the product team what you would like to see and how often. Tell them why and what value it provides. They may not always be able to provide it, and you should expect that they will push back if they don't understand the value, but it is critical to have that conversation.

Navigating Uncertainty and Change

The dynamic nature of agile development means that change is constant. Requirements evolve, priorities shift, and unforeseen challenges emerge. For you, this can be unsettling. The desire for certainty and clear milestones is at odds with the fluid nature of software development.

Embracing this uncertainty is key. You need to learn to trust the process and system, encourage experimentation, and view setbacks as opportunities for learning rather than failures. This requires a significant shift in perspective from controlling every aspect of a "project" to empowering teams to make decisions and adapt as needed along the dynamic journey to build a "product".

Building Trust and Empowering Teams

Trust is the cornerstone of any successful agile team and is a two-way street. You will need to build trust with your product/technical teams by demonstrating a willingness to learn, listening to their concerns, and valuing their expertise.? This trust fosters a sense of ownership and accountability within the team, driving them to deliver their best work.

Empowering teams also means giving them the autonomy to solve problems. Again... Scary stuff!

Just remember that micromanagement stifles creativity and innovation. Instead, you should focus on setting clear objectives goals, providing the necessary resources, and then stepping back to let the team take the lead.

Learning from Experience

The most challenging aspect for you is the steep learning curve. There's no substitute for experience. Leading a tech-enabled company requires a deep understanding of both the technical and human aspects of software development. While it's possible to learn the basics through training and self-study, there's no replacement for the real-world experience of building and launching products.

However, there are some short-cuts. This is where mentorship can be invaluable. You should seek out mentors or advisors who have successfully navigated these challenges. Learning from their experiences can provide valuable insights and help avoid common pitfalls.

Conclusion

By embracing agile principles, fostering open communication, navigating uncertainty, building trust, and continuously learning, you can effectively guide your teams to success. Avoiding the trap of faux agile and truly understanding and implementing Agile methodologies are critical. The journey may be complex and filled with obstacles, but the rewards of seeing a product come to life and deliver value to your customers are well worth the effort.