Discussion about this post

User's avatar
Claus's avatar

My impression and experience working in many "classically" or Scrum-driven projects: you either have a team that works, or you don't. Teams mostly work because people communicate well, respect each other, have the necessary skills required for their job and form a unit with a shared sense of goals. Of course, this list is not exhaustive and external factors are important as well, but I'll leave those out of the equation. On the other hand, there are teams that don't work well together, because they're missing one or more of these crucial ingredients. But, and that's my key learning, Scrum needs all these qualities as well, else it will fail. If a project is lucky enough to have a very good Scrum master and product owner(s), they might be able to help a team form through various means.

So... you have this "mythical", but totally incomplete methodology that almost totally depends on factors it can't create itself: what's its purpose then?

There's another crucial factor: is a team really allowed to go all-in on Scrum, meaning it has the support of the rest of the company to provide them with what they need in time and quality? More often than not, deadlines and budget are still fixed (which, from a company's point of view, is perfectly valid), but this removes one of the most important pillars Scrum is based on.

What was the reason for Scrum's success then? Well, I'd argue that it was driven by management, because they learned what happens if you let a team go "black box", missing dead lines, quality, etc., so they got totally excited by the promise of constant, visible delivery. Fair enough. Also, it's a nice, fashionable way of controlling and tracking people, that veils itself as transparency. We don't need leadership, it all falls into place by itself by some democratic process. Many people don't work that way, that's a reality, whether we like it or not. But, and this is one of my most crucial reasons to resent the Scrum hoax: pressure of constant delivery plus chunking tasks into bite-size tasks strongly disadvantages complex, foundational and cross-concern work. Error handling or security (just to name two topics)? Nah, we don't need it now, let's get stuff done! Except: this is all needed! I like to compare it with building a house: nobody would start working on the cosy bed room on the second floor before the foundation is done. Can't build a bathroom without pipes being installed before. How did we think we could build software this way? Of course, all of this can work with Scrum, as it does not prevent good work from happening. But: you need the right people in the right setting. And then you're back to square one, see above.

One last thing: people are not stupid. Once they realize that they're not in a real Scrum setting, they learn how to cope with the situation. Rituals degenerate into meaningless bla bla, story points are not story points anymore, velocity tracking is not perceived as a chance to improve, but surveillance, etc.

For me, the quality of a software product is more determined by people than by tools or methodologies, always was, always will be.

Expand full comment
Mike Watson's avatar

I've only been on the side of rocky scrum situations for my entire career. I have yet to come across a single person that was like, "Mike. Scrum following all the rules is the best!" Many of us have adjusted (aka lowered to rock bottom) our expectations with it.

Expand full comment
5 more comments...

No posts