Agile software engineering – The pitfalls

Generally I am a supporter of agile methods, because they can contribute a lot to a successful project and rise motivation in a team. But I have also seen a lot of projects and teams fail with adopting methods or sliding into endless discussion what should be done and what not.

Thus I decided to collect some of the common pitfalls which I have seen and everybody of course is invited to share additional experiences while introducing some of the agile methods, like Scrum, Kanban, ASAP, XP, …

Pitfall 1: Not focusing on the entire picture

Misunderstanding: “The team focus on the current sprint, the product owner makes the long time planning”

All agile methods have on in common. One of the highest priorities is to deliver complete features in a short time. Mostly this is done by defining User stories, take some of them and plan them due a fixed date. Nothing wrong about this. But what’s about the Userstories which come after, to they match with the current User stories? Does the Product owner alone has really the ability to make all decisions? Does one person has the time to make the planning in the best way?

In traditional projects, especially when adapting big existing products like SAP, you have for example ABAP programmers which know a lot of details about a specific module or also a submodule. Why omit there valuable input for the longtime planning.

• Its essential that the entire team not only focus on the current sprint but have also a (even though not so detailed) view on the entire project.

Pitfall 2:  Skipping Specification

Misunderstanding: “There is no need for a specification, the features arise while working on the project”

Writing good specifications is a hard task. You do not know at the beginning a lot of the special processes the customer wants and you do not have a lot of time as the engagement team promised a challenging deadline and the development team is ready to start.

Well mostly you have some vague use cases or scenarios and well there is also something written in the contract. So why not start. As the project now is agile, the implemented features can be adapted easy.

Especially at the beginning of the projects defining Userstories is time-consuming and the Product owner has to do a lot of other stuff. Building relations with  the customer, organize infrastructure or explain the customer this “Agile” thing. This leads fast to a lame excuse “focus on the current sprint” – as there is not a lot behind.

• Agile projects can be started faster, but also not without a certain amount of preliminary business analysis with the customer and preparation time

Pitfall 3: Everybody has to know everything

Misunderstanding: “In agile development teams we have collective code ownership so everybody can do everything” 

In nearly every team you have a mixture between highly experienced people and newbies. Should they really share difficult and easy tasks evenly. Does everybody needs to know every detail of all userstories? When I first started with Scrum six years ago we changed also the job definitions. Testing and documenting people become also developers. And database specialists were introduced into GUI programming. After a year or so there were only developers. Then we started to switch back, because of the lack of specialists when special topics arise and of course its rather inefficient if the whole team discusses each single task.

Additionally I once explained Scrum to a small company which wanted to introduce it. At the end a senior developer asked me, well if I understand it right, then I am not the responsible for my product module anymore, right? I said yes. Nowadays I would respond: Why not, If you are the person which knows most of the module why should you not be responsible for it?

• In agile teams you work closer together, but there is nothing wrong about divided responsibilities.

Pitfall 4: No common understanding of agile methods

Misunderstanding:”Scrum seems good, but lets make an adapted version of it which fits best to us”

That’s not a bad idea in the first view. And maybe its working in a little company with a few developers. But if you are introducing an agile framework into a medium or large company, you have as much views on how do to it as much people are involved.

• Stick to a fixed model unless you want endless discussions

Pitfall 5: Agile methods are only for development

“This agile thing sounds good, lets start with the development team”

Throwing a functional specification into the development team and let them develop it agile does not work. Agile methods need well separated function in form of User stories and the availability of the customer on a weekly to monthly basis for accepting the changes. If you develop agile and there is nobody who has the time to test it and give you valuable input, the advantages of bringing the features faster to the customer will not arise

• Agile methods has to be done in the whole project. The development team, the consulters, the management and finally the customer (or internal representative of the customer) have to adapt the methods.

Pitfall 6: Agile methods solves all problems

Misunderstanding: “Let’s develop agile, then we get rid of our problems”

Agile methods do not solve problems. When you introduce it, your problems will rise. Well that’s not completely right. Agile developing shows you rising problems faster and clearer.

There is for example the water melon project reporting (I do not know if it really was defined in literature already but I like it)

Product Manager asks the developer: “In two months we have our deadline, how is it going. All standard cases are implemented and they are mostly working but I am really struggling with the special cases. And documentation, entire testing, and, … there will be not enough time.

Afterwards the product manager communicates to the department manager: Well the standard cases are already implemented but there are some issues with special cases:

Department manager communicates to the CEO: We have still two months and the standard cases are done.

So from the developers view the project status its completely red, from the manager is green. Like a watermelon. The further away from the project the greener it seems.

When you stick to deliver each few weeks a bunch of the whole project the possibility of the bad surprise at the end of the project decreases dramatically.

• Agile methods do not resolve your problems but they show them in an early phase when you have more possibilities to react on them.

I hope you could find already some valuable input and I will continue another day, but feel free to give your valuable input. I am waiting on it.