Scrum Is Killing Me...

Software is eating the world and it is a lot of fun. A lot of fun to work on products that are shaping our future or, at least, to hope and fight for it. It is a lot of fun to work with smart people, enthusiastic people, committed people. It is a hard work too. We do not want to compromise. We fail a lot. We need to stay right-in-time: not early, not late either. We need skilled people, talented people. We need diversity. We need to be part of teams. We need to be involved with a team; remain positive, accept ideas from others, be passionate and tolerant. So it is fun and it is hard! Well, it is especially hard since Scrum is killing me... again!

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".
  • From 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...
I will keep my points short and will separate "issues from Scrum" and "issues with Scrum". If you are not convinced, check for yourself "The Definitive Guide to Scrum: The Rules of the Game". It is well written and simple! Still not convinced? Watch the great video talks from people that point other ways to manage developers with success. Those include talks from Robert C. Martin, Dave Thomas and Brian Marick who also participated to the writing of the Agile Manifesto back then.

Issues from Scrum

Among the issues, I've faced at several customers that were doing Scrum, the most frequent ones are the following:
  • Sprints 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 Scrum

The 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...
For those who think that is an IT project curse, plese note that: "Most people that are working with computer science are actually clever, skilled, not to say eager to succeed". If you are doing Scrum and are not yet convinced there are better ways, I suggest you watch the set of videos below...

Inspirational talks

Those are inspirational talks that are deconstructing "Agile" and "proposing alternate models", you might actually like some of them:


Popular posts from this blog

Installing Oracle Database 12.1 in Command Line and "Silent Mode"

Querying an Oracle VM Server Xenstore from a Linux Guest

Introduction to Oracle Linux 7 Network