Agile: Common Misconceptions You Want to Avoid
When Agile is the right choice, and how to get most of it
A couple of months ago, I was participating in conversations on how to adapt a project for what is comically called WaterGile development. That WaterGile session was an agile adaptation for a project that started as a waterfall and had the specifications and discovery part already done in Waterfall style.
While the conversations were productive and fruitful, I realized that not all people were on the same page about Agile practices. The motivation of this article is to contribute a better understanding of Agile advantages and strengths.
A quite different project philosophy
A common misconception among newcomers in the agile world is that Agile is just a set of project management practices that utilize the same waterfall mindset.
However, Agile requires a radically different philosophy. Agile by itself is a way of thinking, or better said an overarching approach and philosophy to maximize value and mitigate risks during the software development process.
Most companies that intend to apply Agile to new teams or new members need to incorporate training in their onboarding of new members, while they appoint Agile Coaches to educate about the methodology and its philosophy.
Agile is implemented with different tools and practices. By far the most popular Agile practice is Scrum and the second popular is Kanban. Having said that, most organizations follow intermediate approaches when transiting to agile, especially for projects designed for waterfall and executed in an agile way.
To learn more about Agile Practices and Philosophy I recommend you the Google Agile Course on Coursera, which I found out to be a great source of learning.
Flexibility on processes VS Chaos
Agile favors self organizing teams, and up to some degree flexibility on deliverables and delivery dates. This is scary to many organizations with different approaches to organizational structure and delivery planning.
Agile favoritism to self-organizing teams doesn't mean chaos. It is a different way of organizing work and accountabilities, where structure and roles follow a different approach. Since Agile focuses on customer satisfaction, value delivery, and efficiency, the evaluation of the outcome is more result-oriented.
Agile also describes certain rituals as the norm of work, all work is planned around Sprints that are usually 2–3 week work cycles and backlog items, and meetings are conducted on Scrum meetings, Design Sprints, Sprint Planning, and Sprint Retrospectives. While personal contact is encouraged over-elaborate documentation, all detailed documentation and acceptance criteria are written in User Stories.
Agile manifesto merely presents an opinion on what is delivering more value. It favors:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That doesn’t mean we don’t really have plans, documentation, and processes. It is rather a reminder that those are merely tools to ultimately deliver valuable products to customers. So eventually, it is up to the team to decide a balance between delivering functional software VS spending time over the means to support the development process.
Cases where Agile is the right choice
Agile was made to cope with uncertainty and constant change and maximize value delivered. It is especially relevant with product delivery in evolving or fast pacing markets or when frequent release of features is proffered.
Contrary to common consensus, Agile practices are not suitable for all projects. Agile is a better choice in volatile environments (high V.U.C.A. environments). That is when:
- things change very frequently and there is little or no stability between changes (high Volatility).
- you cannot make predictions or there is significant potential for surprises (high Uncertainty).
- the project is very complex. The most common scenarios I have faced are interrelated projects that run in parallel from different teams, and dependent systems that change frequently (high Complexity).
- you are not happy with the progress but you cannot isolate some root problems (high Ambiguity).
Agile is also relevant when customers are not certain about the features they need or how to organize their work around a product or service.
Agile is also suitable for continuous change and continuous delivery. That is when we need to deliver as fast as possible features and learn from customer feedback. It is also ideal to experiment with new concepts or markets and incorporate the learnings in the next product development cycles. In this way, we deliver a product that is more relevant to customer needs and minimize the wasted effort in specification changes.
To learn more about Agile Practices I recommend you the Google Agile Course on Coursera, which I find a great source of learning at the time I took it.
When Agile is not ideal
Waterfall approach is more effective in small projects or fixed environments.
The waterfall is more effective when exact specifications are known and little or no change is expected until the end of the project. It is also preferable when partial delivery of the product can not create value. It favors meeting a deadline on a fixed budget, with the risk of creating features that are not useful and not maximizing the value delivered.
In my experience waterfall is preferred for some projects aiming to meet statutory or regulatory requirements in banks, pharma, or the public sector. It is also more effective when very small feature sets or incremental changes projects. Hardware drivers are a good example in the software industry. It is also preferred in mature industries where the pace of change is slow, like in Mining, Industrial Gas, and Maritime.
Another use case for waterfall is when the required people are not available to work together at the same periods or when a fixed team cannot be assembled. In that case, working in separate teams under waterfall development could be an alternative solution.
It is not about a fixed delivery date
Agile is not meant to guarantee delivery on fixed date with a fixed budget. It is rather a maximization of value delivered with the given resources.
Most people coming from a waterfall background sooner or later will need to face this reality. Agile does not guarantee delivery on specific dates. By design, Agile is about maximizing delivered value and not about meeting a specific date.
On the other hand, Agile supports the frequent delivery of useful features. In that way, you deliver value to customers earlier than the project end date. It also supports prediction on delivery dates with story points methods. That usually means after 2–3 sprints have elapsed so that reliable data are gathered for predictions.
Conclusion
Doing Agile can start overnight, but embracing the true philosophy needs a shift in mindset and management habits, which will always take time and effort. Agile does not guarantee given delivery dates and fixed budget, it does however deliver more value for the given resources each time. Moreover, Agile is not always the best choice and is more suitable for changing and uncertain environments.
For more overviews on technology, coaching and management follow me.
Thanks for reading.
