Agile is the answer to everything; or at least, better than a traditional software development approach, they say. Sadly, this is not the case in practice. Each organization, even at project level, must evaluate and consider which approach to go with. This could be an Agile approach, but in environments with a lot of hierarchical and fixed / defined procedures and processes, or any type of certifications (such as aviation, security, etc.), Agile would seem less suitable than a traditional approach. In nearly 50% of the Agile projects, people are not happy with the results.
Agile lacks processes; in Agile, one doesn’t plan; and Agile also lacks discipline! These are very commonly expressed misconceptions. Just like traditional approaches, Agile approaches most certainly have processes. Maybe light-weight processes, but processes nonetheless, which are applied by the Agile team as they deem necessary. People say: everyone does as they please, without planning and discipline. It is rather the opposite, actually! Go ahead and find out how you can, for example, deliver working software through an iteration of two weeks without planning and discipline? Indeed… not possible! Release and iteration planning is a fixed segment of Agile approaches, where scrum- or kanban boards, burn-down charts and the daily scrum are used to align the activities and make them transparent. All these aspects support the planning process to achieve the desired result. In fact, instead of a lack of discipline, we rather see and demand a rock-solid sense of discipline from the Agile team members to achieve this result as a team, through the iteration process.
A stubborn fifth misconception is that apparently Agile does not document. In general, the Agile team
only documents what is really necessary, to be able to perform the required work as per
the requirements of the Agile team or the stakeholders. In some cases, this is indeed
minimal, because our team members know precisely what they need to do and what they can expect
from each other. In other cases, this could be more elaborate, because probably certain requirements
have been set to … for example, maintainability or transferability of products. It could also be due to certain laws
or legislations, which require additional documentation as compared to what the team would need in
order to create the product.
About Leo van der Aalst
Leo has over thirty years of IT- experience in waterfall, hybrid and agile environments, especially in environments such as agile, scrum (since 2005), DevOps, SAFe and Spotify. As an agile coach, Leo has provided training and workshops to more than 350 agile teams in the Netherlands and abroad and as a change manager he has guided organizations in the transition to working agile. In addition, he is a much sought-after speaker and trainer, and co-author of five books on software quality.
More on Leo van der Aalst.