Generally I am a supporter of agile methologies, because it 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 methologies 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 invided to share additional experiences while introducing some of the agile methology, like Scrum, Kanban, ASAP, XP, ...
The team focus on the current sprint, the product owner makes the long time planning?
All agile methologies 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.
There is no need for a specification, the features arise while working on the projec?
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 someting 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. Builing 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
"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 frontend 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 sayed yes. Nowadays I would respond: Why not, If you are the person which knows most of the module why should you not be responsable for it?
- In agile teams you work closer together, but there is nothing wrong about divided responsibilties.
"Scrum seems good, but lets make an adapted version of it which fits best to us"
Thats 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 methology 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
"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 methology needs well separeted function in form of User stories and the availabilty 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 methology has to be done in the whole project. The development team, the consulters, the managment and finally the ustomer (or internal representative of the customer) have to adapt the methology.
"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 completly right. Agile methologies show 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 struggeling 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 furhter away from the project the greener it seems.
When you stick to deliver each few weeks a bunch of the whole project the possiblity of the bad surprise at the end of the project decreases dramatically.
- Agile methologies do not resolve your problems but they show them in an early phase when you have more possibilites to react on them.
As it is a bit late :-) 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.