After working for a team that used Scrum heavily for over a year, I became increasily aware of some of the shortcomings of Scrum and other agile methods. Note that this is not to dismiss Scrum but to open development teams to the fact that we can evolve beyond these practices and look for better processes that will suit our individual software teams.

I wrote a paper which is really inspired by Andy Hunt’s Grows Method. I will include some excerpts here. The paper was based on the software processes of a hypothetical company called DynamicTech. Any resemblances to a real company are not intended or implied.

Scrum and the failure of Agility

The “basis of an agile approach is to embrace change”. “To be aware of changes to the product under development, the market and the environment” to name just a few[8]. Agile methods encourage adapting to change but we can see that DynamicTech is struggling with process. What is adapting in this case? Can the CTO begin changing this process which has worked well and is now part and parcel of the company’s culture?

So is Scrum really agile when it is very prescriptive of process and provides little room for change. It seems Scrum is in direct contravention of the core tenets of the agile which state “Individuals and interactions over processes and tools” and “responding to change over following a plan”[1]. Scrum has created a rigorous strict framework. Utilizing practices like Kanban doesn’t make it more agile. As long as the core process is maintained. It becomes difficult to change. With good reason, it will be hard for the CTO to change a process he has invested time and effort in. “Agile methods ask practitioners to think when it is far easier to follow the rules and claim you are doing it by the book”[8]. We tend to be comfortable with rules despite their restrictive nature.

Scrum has led to misconceived belief that agile is about product backlogs, standup meetings, burndown charts or team velocity[2]. All these principles while exciting at first quickly develop into dreary routines. This is also not helped by the fact that iterations are described as “sprints” which suggest that you run as fast you can, rinse and repeat.

Software development is really more of an obstacle course because it is impossible to foresee anything that can happen during this process. The process lends its self to adapting and reacting rather than following methodological process.

you can get the PDF directly.