Agile series: The pitfalls

Image Courtesy: Andy Painter Image Courtesy: Andy Painter

Let’s say that you, as an IT specialist, have been working with a proven and well-functioning software development program. Then, on a particular day, the management decides that from now on Agile is the way to go and the “well-functioning approach” will no longer be used. The act of throwing existing software development processes overboard is a common pitfall. Just think… does the Agile manifesto or the scrum approach state anything about how you need to develop software? Or, about how you have to set up and prepare requirements, functional specifications such as user stories or use cases, technical specifications, data modeling, system and software architecture, software and tests? It doesn’t… right? So, it seems wise not to pour out the kid along with the bathwater; and continue using well-working segments of the software development and test approaches or adapt these as such to fit the Agile situation.

Most of the methods / processes are well thought-out and work just fine, if they are used as intended (for example: SDM, JSD, RUP, or PRINCE2). With the implementation of an Agile approach, such as scrum, we often see a partial adaptation. This can be a conscious as well as an unconscious decision. Even a consciously made decision, using the process called “cherry picking,” will in most cases lead to a, considerably, lower rate of success than a complete adaptation. The famous saying “being in between thoughts” certainly applies here and represents a notorious pitfall.

Programming to the last minute….who isn’t familiar with that concept? This is a deep pitfall, which means that,
as per definition, no working software will be provided at the end of the iteration. All Agile approaches state, in somewhat different formulations, that a product is only complete (‘done’) once it has been tested and accepted (‘demo has been provided’) by the stakeholders. In doing this, the short-term thinking will entail test and technical debt risks. And, the act of providing ‘something’ (maybe because the ‘product owner’ wants it), in a ‘quick’ and ‘dirty’ way by the end of the iteration, might lead to inconsistencies related to code, architecture and testing that would get exposed in the following iterations. This in turn could lead to major, expensive and time-consuming repair activities.

Consider another situation where, all of the sudden, you are no longer dealing with a traditional development project, but are in a scrum team, thinking: “Now, let’s just hope that the other team members know how to handle this.” This is a very typical pitfall. Everything changes, except …………. me! A common human trait is to consider oneself more capable than the others, and believe that the rest will struggle in a challenging scenario. However, with scrum it is important that you also change along with the situation /setup and flow. This doesn’t just happen, you really have to make an effort.

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 ( 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.

Related Posts

Your email address will not be published. Required fields are marked *

7 + 9 =