Solving a Bad Scrum (TM)

In the programming world, Scrum is known as a development process technique – a way of organizing how work is done! There are plenty of articles out there, but here’s something of my own perspective on things.

I’ve been a Certified Scrum Master by cPrime since 2015. I’ve worked for multiple scrum teams in different companies. Here are the common pitfalls I’ve seen in my experience, and how to avoid them.

Let’s kick off with a…

Too long of a daily stand up

Problem: Some folks like to run daily stand up meetings that last far too long – sometimes more than an hour. It happens, believe me, I’ve seen it. People get caught up in problem solving, doing a little bit of design discussions, a little bit of project planning, few debates about favorite coding environments and so on. Poof! One hour gone. That’s, on an 8 person team, about one engineer worth of time lost every day. Well, truth be told, some of these discussions can be productive, still, is the trade-off right?

Solution: First of all, analyze what’s causing it – what is the reason behind the long stand up. Is it the lack of awareness in the team that stand-ups are more productive if kept quick? Is it the Scrum Master, Product Owner or the Manager who likes to keep tabs on everything? Is it that there is a lot going on and people need to discuss a lot of things that are on their minds? Once you’ve done that, work with the team to show how much that reason is costing them – in time and efficiency. Offer to run a different kind of a stand up – one where (as suggested by pretty much everyone) people quickly just acknowledge each other on three things – what has been done last day, what is being worked on today, and are there any blockers. One minute per person, tops! Break up after the quick meeting and discuss anything you have with individuals, if needed. Congratulations, you’ve just saved your team tons of productivity.

No stand up

Problem: Some folks run “Scrum”, but without a daily stand up. Perhaps they don’t have stand ups at all, or they run a weekly stand up, or something else. This is far better than the previous problem, of having too long of a stand up, but is it good? Stand-ups are like brushing your teeth – it’s a morning routine, good for your team’s health. Now, I don’t have any data to back this up, so you will excuse my “proof-by-common-sense” here I hope, but, having a stand up is a great way to make your team feel like a team. People make eye contact, everyone gets a chance to speak up, everyone gets heard, positive energy is exchanged, camaraderie is built etc. That’s what a good daily stand up does for your team. It’s a useful, affordable routine, when done properly – quickly and consistently.

Solution: What is the reason behind not having a stand up? Does the team feel negatively toward meeting every day? Do they feel there aren’t enough many updates to be shared every day? Is it that everyone is working on a separate track? Perhaps you don’t need it after all? If you think otherwise, and would like to fix this problem, try offering to your manager to talk to everyone on the team and find out about their sentiment on daily stand ups. Figure out where you’re at. Address the concerns using some of the values mentioned above and propose a solution to your team. Offer to run a daily stand up for one week, and see whether the team’s sentiment changes.

Next we have…

Humongous product backlog

Problem: Your team’s backlog has several hundred stories in it, nobody knows what lurks in there and it just keeps growing (i.e. new stories are added faster than old stories are being closed). It’s not prioritized ranked (because it’s impossible to do), half of the items are deprecated since last year and the rest is so poorly documented nobody understands what they are all about any more. Its purpose has come down to serving purely as an excuse of a backlog, something where you put stories and hopefully never have to look at them, ever.

Solution: Start fresh, unfortunately, is your best bet. With your next, fresh backlog, use the following recipe to make it end up not-like-your-old-backlog.

1. Rename your existing backlog to Unplanned. That’s your graveyard of stories anyway, things that aren’t on your roadmap and who knows if they ever will.
2. Create two additional folders for your stories: Planned (this is where you will build your fresh backlog) and New (this is where people add stories which are not refined yet).
3. Keep your Planned backlog ranked, not prioritized, i.e. do not have “High”, “Medium” and “Low” stories. Rather, have them numbered, e.g. from 1 to N (the number of stories in the backlog).
4. Limit it to ~50 stories, so that anyone, especially the Product Owner, can have at least some idea about what’s in there.
5. Start by polling the stories you think you will be working on in the next 3 months, but no further than that. Sift through your old backlog, check with the team, managers etc. Put them into the New folder.
6. Schedule a backlog grooming meeting. In this meeting, go over the New folder and make sure all stories are:
   1. Estimated – for example using Fibonacci’s complexity points. I prefer using 1 for anything that’s easy (relatively a day or less), don’t go more granular than that. The 1, 2 and 3 are “small” stories – workable by a single engineer in a single sprint – anything bigger than that either needs to be broken down (as the time comes for you to work on it), or it needs more than one engineer to work on it during the sprint. This is just an example of how to do this estimation, pick your poison.
   2. Formatted – the story beings with a customer in mind – As a <who?>, I want <what?> so that <why?>.
   3. Detailed – the story has acceptance criteria – basically think of it as a break down of requirements. Sometimes, it’s like objectives and key results. E.g. if the customer wants a new car, the acceptance criteria might contain that it must be fuel efficient, or that it must be black, etc. Don’t go overboard with this.
   4. Ranked – compared with the rest of the stories in your Planned backlog (which is initially empty), assign a number to it, from 1 to N. Fractions are okay when you are okay during the grooming meeting, but at the end of it, you should reorder all stories back from 1 to N (e.g. 1, 1.5, 2 becomes 1, 2, 3).
   5. Repeat and rinse weekly.
7. Sprint planning? Pick your top stories from the backlog (more or less, things oftentimes changed since the last grooming meeting) and run back to work!

No backlog whatsoever

Problem: Some folks like to keep it informal. This is, again, not as much of a problem as keeping a bogus backlog around. Less overhead. Still, you are probably missing out on a good technique to keep everyone focused. You can’t answer things easily such as “when will this get done?” (assuming you are not going to do it right now), “what’s on your roadmap?” etc.

Solution: Figure out what’s the reason behind this. Lots of people have never seen a functioning backlog (check the previous situation and the award winning recipe). Perhaps people are “too busy”. Etc. Offer to create a backlog for the team and manage it for some time, and see whether it works.

Finally, with so many meetings (grooming, planning, daily, retrospective, demo), there’s one common problem of…

People are bored to death by your Scrum

Problem: Lots of people love to run meetings, and I can’t blame them for it (I’m one of them). It can be a fun, dynamic, fulfilling, and as one meme said, “excellent alternative to doing actual work”. Your hold your Scrum meetings, but you notice your team is on their phones, laptops, nobody is paying attention, everyone hates it, yada-yada-yada.

Solution: Fix yourself! The team is not at fault! Understand why do people prefer the alternative to listening to your meeting. Are you engaging with the audience enough? Do you ask questions, even rhetorical ones? Do you change your intonation when you speak? Is your meeting too long? Did you ever ask the team what they think? Does this meeting produce any value? Whatever you do – don’t keep your meetings longer than 45 minutes. Keep the last 15 for Q/A, or let folks off the hook early – everyone loves that. If you are in the position of leading these meetings – make it a priority that everyone else gets an equal chance to participate.

Thanks for reading thus far, please do share what other problems & solutions you’ve seen in Scrum teams and lastly, if you and your team really can’t stand doing Scrum, but you are doing it because everyone else does – the quick tip is – you don’t have to do Scrum – at all. And you are not alone in this. One of the people I admire the most in this world would agree with you – Erik Meijer: