English | EN Agile series: The pitfalls
Feb 3, 2015
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.
About the author
