Scrum Is OK

I’ve been reading the scrum guide recently in order to tear it apart. Turns out: it’s actually alright

8/26/2022 processagile

A lot is being written about agile and scrum recently. I myself have written a post entitled "The Case for Dropping Agile". And whilst I stand by what I said, we have to realise that Agile and Scrum aren't the issue. As with pretty much all the world's problems: famine, war, disease; it's us humans that are to blame for messing it up.

I've wanted to write an article for a while now shredding scrum to pieces. Having been a part of a few scrum teams now they all seem to end up in the same cycle: bringing too much work in, spending too much time planning technical minutia upfront, delaying scope instead of having the autonomy to affect it, and working on overly specific tickets.

So I opened my iPad, wrote my title and decided to go back to basics: read the scrum guide, and dissect it line by line.

Except the funniest thing happened: I realised that Scrum is fine. It could do with a little tweaking, but ultimately it makes sense. As ever: it's the humans that use it that are the problem.

The scrum guide can be a little daunting but ultimately: A team of developers, agree on a set amount of value to add in a set amount of time.

That's it. There's a planning session, a review, a retro and daily stand ups to discuss progress and adjust their plan. Ultimately it's the simplest thing. So where did we go wrong?

A scrum team consists of a Scrum Master, a Product Owner and Developers. But here's the secret: developers aren't just engineers. Developers are designers, UX experts, and testers. Anyone responsible for developing the product. It's so easy to forget the "cross-functional" aspect of agile teams because we see "developers" and think "engineers" or QAs. We are wrong.

The number of times you hear about "syncing" the design team's sprints with the engineering team's. It just doesn't sound very cross-functional does it?

The result is scrum teams that only have software engineers and testers, with designs and low-level requirements being fed into the sprint. At this point the team either loses all autonomy to adjust their plan, or the designs have to be changed and updated constantly to meet the sprint goal. The former reduces the team to "doers" that are always trying to catch up, whereas the latter introduces a lot of waste for the designers and friction between the two professions.

Story points are the single worst thing to happen to software development ever. No doubt.

Because of story points, scrum teams have a mythical velocity to chase, something that is impossible.

"But how we will know when we're going to be done?" I hear you ask. You don't, you never will, it's software development. Get over it. The scrum guide does not mention story points or estimation at all.

The closest that the scrum guide comes is to say “the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts”. A simple “well a similar feature took us a week so this should be about the same” should suffice for the “past performance” element of this.

Remember: the goal is to estimate, to forecast. The goal is not to predict a done date.

A further issue is a belief that a product backlog item must be a User Story with Acceptance Criteria etc.

Must it? A product backlog is defined as:

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

"But how do we know if it's doable in 2 weeks?" I can see is your question this time. You don't. But if you were to decide that you can and should deliver this in 2 weeks, you can then create features to meet the deadline knowing you can iterate and make them more complex in later sprints (if need be).

By doing this you force yourself into an MVP and iterate mentality. The alternative is cutting up big features into 2-week chunks that may or may not make sense after each iteration.

Not all iterations are born equal. Picking up a PBI and deciding that is the most important thing to work on next doesn't mean you then have to fill two weeks' worth of work and create a "sprint goal" something akin to "Provide value X and also Y".

My suggestion: pick a single PBI off the backlog, something like "Provide value X" or "Solve problem Y", this would come with a rough idea of how long the team should spend solving the issue (something called an "appetite", which is a concept I'm a big fan of) the team would decide on a solution that should be achievable in the time, design it, develop it and deliver it. If that's 2 weeks then good, if it's 1 week even better, if it's 3 then that's still OK. It's that simple.

"But our projects can't work that way, they need designing upfront". OK, then you can't do scrum or Agile. At this point: waterfall is your friend.

My conclusion to all this: scrum is fine. It's not the best way of working (in my opinion) but it's fine if you choose to work that way. Just please don't bastardise it with ways of working that belong in a waterfall world.

Scrum does not require all your designs upfront. Scrum is not a way to break up a 6-month waterfall project into predictable chunks. It isn't designed to do that. Scrum doesn’t require you to sit and argue over planning poker for 5 hours. You can implement scrum successfully without needing these things