English | EN Agile series: The misconceptions
Feb 2, 2015
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 the author
