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 van der Aalst is Dutch and studied chemistry, mathematics, physics and biology. However, he switched over to IT almost thirty years ago. After having gone through the classic IT path - from programmer to program manager - he became a specialist in the testing area, in which he held functions such as test manager, test advisor, research & development manager, line manager and agile coach. Leo applied his knowledge and experience in the project- and test management field during a number of international projects and consultancy trajectories (in USA, Germany, Denmark and Austria). He also likes to share his knowledge with other people by writing books and articles, and giving presentations en workshops. Leo is co-author of TMap NEXT® for result-driven testing, TMap NEXT® Business Driven Test Management, TMap® Human Driven and TMap NEXT® in scrum books. He has written many articles (e.g. ‘Software Testing as a Service - STaaS’), which can be found through his website (http://leovanderaalst.nl). Leo is past professor Software Quality at Fontys University Eindhoven in the Netherlands, a much sought-after teacher of test training and a regular speaker at national and international conferences. Leo is an accredited trainer for courses as Certified Agile Tester (CAT), ISTQB Agile-Tester and TMap Suite Test Engineer and Test Master. Besides all this, Leo is development lead of the ISTQB Foundation and Advanced Agile-Tester Syllabi - which are chaired by Rex -, member of the programme committee of the (Dutch) National Software Quality Conference, fellow of SogetiLabs and member of Capgemini Expert Connect.
More on Leo van der Aalst.