Categories: Agile
Agile is popular more than ever before. Is it a magic pill? My experience of using Agile at more than 50 teams forced me to say NO. What can be a reason for being Agile restricted? What is the first thing we should start with to use it relevant and wisely? I want you to meet two simple questions that can help you to define when Agile can help you to be more effective in building your product.
When Agile is good?
Answer 1: No detailed requirements, only vision is enabled
It is quite typical to have only an uncertain customer-level requirement like “An app which can help you with your housekeeping routines”. Nobody knows how exactly a final product has to look, nor anybody understands what is a certain way to create it. Therefore, one of the key activity types will be iteratively defining requirements for the most profitable way to provide clients with the best user experience. Agile is good when what you’re doing is breaking new ground.
Answer 2: Researching via checking hypotheses as an iterational development process
This point is the consequence of the previous one. Still it is more about the process, not the result. We all know that the best way to create the best product is in continuously improving. As you can read in any agile-oriented book this methodology is about letting us maneuver. So the most powerful and effective way to improve a product via maneuver: checking hypotheses. Every hypothesis brings us closer to the final product within every single iteration of creating it.
Answer 3: The proper environment and outer services are provided
The agile team must be focused on the product. Period. Everything that isn't related to creating the product to be outside the product backlog. For example, supplying, contracting, HR, IT support, security, legal support should be organized as services: Highly predictable, transparent and even almost invisible services for the product team. Every team member must be assured that everything necessary will be provided on demand. This is the first thing that would help to keep the focus on the product and to minimize any distractions.
Answer 4: You have a really crossfuntional team to create a product
The very first thing you have to accept about crossfuntional teams is that every team member is not a swiss knife man. In real life it is almost impossible to collect a group of people who will be experts in all areas that the product development process requires. That’s why you should concentrate on forming a team of experts in specific areas: programmers, testers, designers etc. And yes, it is costly. However, there is always a price for everything. I don’t recommend you to consider different ways to become more cost-effective trying to optimize idle time as it will influence the focus factor. As you can see in the previous point, focusing on the product is what we fight for, so please stay coherent.
When Agile is not a best idea?
Answer 1: You know precisely what you want
The key difference between Agile and Waterfall is related to a degree of requirement changeability. It is a well established fact that Agile is preferred if requirements tend to change. So if you have defined and stable product requirements at the beginning, the best way is to choose Waterfall. You don’t have to reinvent the classical management approach if your entire project can be planned before it starts.
Answer 2: Your project is surrounded by external dependencies
If the product development process is strongly dependent on the results provided outhouse you would better choose a non-Agile methodology. Agile is mostly about having all you need to develop a product in your team so if your project is surrounded by a number of different services, works, resources, it isn’t a good idea to use agile managing.
Answer 3: You have a strict deadline
Long term planning is not Agile's strong point. It is OK to have a sprint plan but sometimes it is necessary to have the plan for all the sprints, and we can find no effective procedures to deal with it. But if you have a classical basic plan and an effective instrument for controlling (like earned value) you will have more chances for success. Agile approach is more about endlessly tuning something small than creating something big to a certain date.
Answer 4: Team members are not trained to work with Agile specificity
What do you think of soldiers who cannot shoot? Are there big chances for them to win or even to stay alive? I don’t think so. Agile is not just a frame of vision. It is a group of skills: collaboration, common responsibility, team playing, taking part in ceremonies etc. Remember that all the skills must be like a good rifle: be clean and ready to use. So when your team is not ready to be Agile you have to train them first.
Instead of a conclusion
Bruce Lee said

To be water is to be as flexible as the environment requires. In the dark forest of uncertainty you should be an agile stream. In something clear like the open and bright space of the Niagara river basin you should become a waterfall. When the depth of risks is variable you can even spin into a spiral whirlpool. There is no something more effective than water taking its form due to barriers and other circumstances, therefore choose your way to work with any methodology as if it is like being water.



