Scrum Is Killing Me...
Lets start with facts I sometimes wonder if people know:
- Scrum has been defined and maintained by Ken Schwaber and Jeff Sutherland who are 2 distinguished gentlemen.
- Scrum is documented as a whole in "The Definitive Guide to Scrum: The Rules of the Game" that is available under CC BY-SA that is an OpenSource License. There is no other reference document.
- Scrum is an "empirical approach to project management". It relies on good ideas like "artifact transparency". It also relies on good intends like valuing "commitment, courage, focus, openness and respect".
- Scrum books and training should only address "How to implement Scrum". They should not contradict neither create variations of it.
- Ken Schwaber and Jeff Sutherland have both participated to the writing of the Agile Manifesto. However Scrum does not define the "Agile Manifesto".
The Definitive Guide to Scrum, "Implementing only parts of Scrum is
possible, the result is not Scrum". I would suggest we do not
experiment that on our projects by the way. Even if that is not the subject of this
blog, I would say that "
Fake-Scrum" or "
S***-Scrum" is probably way worse than Scrum itself
- The fact something is backed by some good ideas or good intends does not remove issues. That's not because Scrum was meant to "fix" the waterfall downsides that it does not have its own downsides. It is called the cobra effect...
Issues from ScrumAmong the issues, I've faced at several customers that were doing Scrum, the most frequent ones are the following:
are failing and it is frustrating everyone. People should focus
on writing software, not on sprint success. You may argue that it is
because, the game is not well played. In my experience, the 2 most
important reasons for Sprint to fail are the time-box and close-box
nature of the Scrum Sprint; it is not people:
- You cannot predict what needs to be done on Software even for the shortest 2-to-4 week periods. If you have 5 developers and an hard-to-fix, urgent bug comes out, you cannot ignore it! This alone can remove 20% of your ability to deliver and can make everyone fail.
- The problem you are solving always fails estimations. Despite the "one sprint goal" you always get some "Not Done" tasks in your backlog at the end of the sprint. This means you don't deliver the content of your Sprint, or worse, I've seen a 2-week sprint delivered in 2 days because of some clever guy that did basically the work of a whole team.
- The time-box as well as low-level descriptions of tasks necessary to estimate time have 2 additional drawbacks:
- People rapidly become "micro-managed" by the tracking system and by the group. As a result and despite what Scrum intends to do, people who are working with Scrum often feel "Subtle Control" and do not get the ability to take a step back to fix their issue correctly
- You get "Done" features and not "Well Done" features. This only generates a lot of waste in your Software. It is also killing people that are working like washing-machines without actually being "efficient". If the "fail-fast" nature of software is a quality you need to keep in mind that people should succeed at their work and Scrum basically prevents this from happening too many times.
- Last but not least, the weight of Scrum is unbearable for many teams that are losing their common sense. That is due to:
- The number of roles : product owner, developers, scrum master
- The number of meetings : daily, planning, review and retrospective. Their high frequencies and the number of people involved
Issues with ScrumThe previous section is referring to issues due to Scrum, per se . Its nature usually involves more problems. I'm sure you've experienced many others if you've been working with Scrum, even a few days, like:
- A shift between what people really wants and what the product features are. Thank to "certified PO" that do not understand needs
- The lack of intrinsic product qualities like performance, operational costs, observability or simply ability to easily develop with
- A Certified Scrum Master managing the team instead of enabling the team
- A focus on features instead of value and user experience
- Poorly organized teams due to constraints, like bad tools, people shared across teams, lack of skills or distant work
- So on and so forth...
Inspirational talksThose are inspirational talks that are deconstructing "Agile" and "proposing alternate models", you might actually like some of them:
- Agile is Dead, Dave Thomas
- Managing Manager‐less Processes, Fred George
- Principles of Technology Leadership, Bryan Cantrill
- Leadership Without Management: Scaling Organizations by Scaling Engineers, Bryan Cantrill
- Artisanal Retro-Futurism Team-Scale Anarcho-Syndicalism, Brian Marick (see arxta)
- One Hacker Way, Erik Meijer
- Implementing Programmer Anarchy, Fred George
- The Future of Programming, Robert Martin
- Frankenbuilds; if Agile is so good, why are our Products so bad? Gabrielle Benefield