Why we say Agile when you want to say chaos "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs March 03 2021 True Agile, Agile Development, Guest Post, Mind the Product Mind the Product Ltd 1274 Why we say Agile when you want to say chaos Product Management 5.096

Why we say Agile when you want to say chaos


Most people working in a tech environment have experience working with Agile methodologies. However, it’s very common to see that Agile principles and philosophy are not correctly interpreted and implemented. Some companies fall into the “Agile = speed increase” trap. They focus on how the technical team performs or delivers, but not on what matters: their Product and Product strategy.

In this post, I’ll elaborate on some common Agile´s pitfalls, how to avoid them, and the crucial role of the Product Manager in Agile environments.

Embracing Agile

When talking to other product managers and working in product roles, there is a common topic in the Agile implementation process. Many companies seem to embrace the Agile philosophy to justify constant changes, or skip basic due diligence in decision making as if working in Agile meant working without a defined plan.

Companies should embrace Agile as an investment, part of their long term vision and with clear goals and expectations on why they are adopting this mentality. Implementing Agile is an investment as the process to adjust to it can be hard. Companies might not realise the benefits immediately.  It must be part of the company’s long term vision, as Agile is based on continuous learning and adjustments. It needs to be tied to the company’s objectives.

Companies that invest in Agile, following rules and principles will see more motivated and productive product development teams. They will also see faster product time to market, higher product quality, better stakeholder satisfaction, and more transparent and open communications processes between teams. But this will only happen with a clear purpose and strategy behind it.

When referring to change in the context of Agile, it’s key to remember that Agile encourages change, but change based on evidence and clear objectives, Moreover, the market and customer requirements change. You need solid metrics and analysis to identify changes and opportunities.

There are millions of ideas and changes that you can make to your product. However, you need to ask yourself the following questions:
  • What problem are you trying to solve?
  • Why do you think that making that change is a good idea?
  • How are you going to identify when you implement a change in your product that the problem has been solved?

If you can’t answer these questions before jumping into solutions, you already have, or are about to have a problem.

Creating agile solutions

When the word Agile gets used by operational areas or teams that haven’t been trained in Agile, it can get “corrupted” easily. For the untrained user, Agile can be interpreted as working at high speed, delivering “things” quickly. Often people believe that the speed in delivery was the only challenge to solve in a product development process. They forget about the lack of strategy behind what those “things” are or should be. They focus on solutions when they should be focusing first on what problems they are trying to fix.

During my career, I have heard many times “we have to build a scooter” (following Henrik Kniberg’s popular illustration) as the product solution to all business challenges. It’s a great motto and supports the principle “you should try to simplify and build something fast and “dirty” to get your users’ feedback as quickly as possible and validate your idea,”

But using the scooter principle has some implications. You need to accommodate the following points:
  • A clear understanding of what problem you’re trying to solve and the goals that you’re trying to achieve.
  • Identification of how you´ll track and identify whether the solution solves the problem.
  • Time and mechanisms in place to capture and analyse users’ feedback.
  • Implementation of good metrics to assess the result.
  • Time and readiness to improve, change, or discard the scooter, if that’s what’s required following the agreed goals.

Without an overarching Product Strategy, the scooter philosophy can result in rigid and complex products with a bad user experience. Teams keep delivering and making changes to their products while adding complexity to their platforms and users. They think they’re running but they’re not making any significant progress. The real progress lies in the value delivered, and how can value be delivered if you don’t have processes in place to measure and identify it?

Understanding the Agile methodology

The Agile philosophy is dangerous when it’s not understood correctly by everyone within a company. A philosophy that encourages the delivery of improvements progressively encourages a user-centric focus, relies on data, and can soon be converted into the opposite way of working.

“If we can build a scooter to solve a problem that allows us to deliver many things quickly. We can then cut corners and avoid time-heavy analysis exercises. Why would we waste all that time if we are experts in our market? With our intuition, we can focus on delivering,”

The above statement is fictional but it reflects real business mindsets and product development processes in companies. Performing user research, analysing competitors, defining clear goals, and brainstorming different solutions, are interpreted as unnecessary steps that delay the real goal — delivery of the product.

Using Agile to build effective product teams

For Agile to work effectively in a company, the first thing that needs to be interiorised is a solid product strategy. The processes required to build a solid product is a must-have investment and not a useless expense. Agile or not, you can’t skip identifying and stating clearly the problem to solve, the product objectives, challenging yourself with answering why you are making a certain change, understanding and knowing your users, identifying your risks and dependencies and analysing your market.

As per Steve Jobs quote: “People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas.”

Agile, if applied successfully, will improve your time to market, but you´ll need to choose wisely how your time and resources will be invested.

Having a solid product strategy and mentality within a company is crucial for the Agile methodology to succeed.

For a Product focused company to thrive, Product Managers need to be able to:
  • Set Product priorities
  • Challenge requirements
  • Have user and market data available
  • Say no to requests if they aren’t aligned with the company’s and product’s goals

Their positions need to be seen not as the figures that “delay” getting things out of the door, but as the positions that ensure time and resources are invested wisely and only in the development of those product solutions that make sense for the company and support its objectives.

Product Managers are the gatekeepers of the Product and Product development teams. They remove noise, protect the product development teams to focus on the “right things”, they identify what’s required and who should be involved to create good product solutions. Product Managers add value and without them, there won’t be a real implementation of an Agile philosophy in the company.

In conclusion

When integrating Agile, focus on aligning Business, Product, and Technology together. Focus on setting up a common Agile mindset within the whole company, but don´t think that Agile will remove the complexity behind product development processes. Creating products is complex, but with the right mindset, you can make it less painful, avoid falling into chaos, and more importantly, deliver added value to your product and company.

More on Agile