When Scrum doesn’t seem to work

I consider myself an Agile prophet. By this, I just mean that I preach about the benefits of doing Agile software over old standards like Waterfall. There are various Agile implementations, and my favorite is Scrum. Granted, I haven’t tried any other Agile implementations in-depth other than Scrum, but I’ve had Scrum transform my life from misery to a blessing.

I’ve been at my current job for a year, doing Scrum, and the team has kicked ass. The software has a high quality. It gets out on time. Best thing of all? Both of those are accomplished without any significant overtime! Ideally, you’d have no overtime, but what I’m referring to here is maybe 20 hours of overtime over the past year. I know many devs who work that much overtime every week, and few devs who don’t put in that much overtime in a month. So, a process that gets predictability down to that close within a typical 40 hour work week is just amazing.

However, the past month have seen some changes to the team, and the work we’re doing. And we’re wrapping up our second sprint in a row where we’re going to have to pull stories (not counting those that are road-blocked by external forces). The gut initial reaction is “Oh man Scrum doesn’t work in this case, see!” but further introspection shows that we’ve lost sight of how to handle things. So I’m going to list out some things that can cause a high-performing Scrum team to go off track suddenly, as well as some other things I’ve noticed other places that have stopped Scrum from being successful.

 

You have to have top-to-bottom buy in

This is, by far, the reason I’ve seen most Scrum attempts fail. The company I’m at has top-to-bottom buy in. The developers, QA, SCM, managers, product owners, executive team – EVERYONE is on board. If you do not have complete and total buy in, your Scrum attempt is severely at risk. A big part of Agile is getting the client (whether that’s the actual client, or an internal product owner) involved into the software process. That visibility into the software process is crucial to bring understanding to all members involved in the software’s creation with the realities of what it takes to deliver software. If your managers want to back-into dates, instead of them being derived from release buckets consisting of prioritized features, you’re at risk of being driven off track, to cut corners on quality, and to work overtime. If your client wants to give you a big 500 page document of barely-thought-out requirements, then not talk to you for six months, you’re at risk of giving them garbage, or, more than likely, not really having a clue of the true needed requirements, yet you’ve agreed to a due date already.

Simply put – everyone involved in the software has to be part, and to stick to it.

 

You have to keep asking questions until you can’t ask more questions (don’t make assumptions)

Our team changed from working on a well-known area, to something new. Having high confidence from the work we’ve been doing the previous year, combined with excitement of something new, unfortunately lead us to all take assumptions. The end result? We point sized based on how something similar would have ran in the previous area. Granted – you use past experience to point size (obviously). That’s part of it. But we could’ve done a more in-depth analysis of the new work. Not doing that extra analysis lead to constant discovery of new “uh oh”s throughout the story work.

So ask questions. If you can’t get answers? Don’t point-size. If you need to do more of your own analysis first? Don’t point-size. There’s a happy balance here – you can’t spend a solid week investigating a story, when you could’ve implemented it in that time. Each story will have to be considered on a case-by-case basis, and if it’s truly unknown, create a Spike for it.

The easiest way for me to accomplish this, is to pretend that I’m starting on the story right then. Where would I start? What would I do first? Then what would I do? Chances are, you’ll find yourself with questions pretty soon. And don’t trust assumptions! Ask your product owner. After all, he/she is right there in the grooming session with you.

The goal here is to drive out as much unknown that is reasonable from a story before starting work on it. If your point size of a story is based more on unknown than on amount of work, then that story becomes a high-risk ticking time bomb, ready to explode on you mid-sprint. And when you pull in two or three like this? Then you’re really in trouble. You can’t give your product owner reliability/predictability, at which point your reputation goes down.

 

Break the story down. Then break it down again. Then? Yet again!

Our previous team and work had become a well oiled machine. We could take in a couple of 8s and a 13 in one sprint and knock it out. But those higher point sizes were driven from work to do – not unknown. Now we have new team members, doing new work – you have to get a new baseline to determine velocity. Large stories do not help you deliver a reliable velocity. If you pull an 8 point story, chances are you had 3-5 points worth of work done. You’ll finish it next sprint, sure – but now you have a large discrepancy between sprint 1 and sprint 2’s velocity. Yes, it’ll wash-out in the end, but it makes for a rougher start.

So, break down stories. It’ll feel mind-numbing. It’ll feel tedious. But high confidence and the ability to work larger stories reliably comes as a reward for doing things more in-depth earlier. If you can find a clear vertical slice to break it down more, then you should do so. Make it simpler. Drive out unknown/risk from the story. The smaller you have to implement to succeed, the higher your chance of success is. You’ll get the 3 or 5 points of what was once a bigger story done, even if you have another 3-5 in it’s “sister” story that gets pulled. But you’ve delivered more to your product owner. You have less to think about next sprint. And, you’re closer to honing in to your team’s velocity.

 

tl;dr

Upon review, all this stuff is so basic. But you get used to things flowing well, and sometimes you loose sight of the bigger picture. So, in summary:

  • Everyone must be involved and committed to the process
  • Drive out requirements as thoroughly as is reasonable
  • Break down stories into small pieces – 1-3 pointers are optimal, some 5s are okay. Stay away from 8s and 13s.

1 comments:

Angelina ray said...

This is such an informative article on SCRUMand very clearly written. Every single thought and idea is direct to the point. Perfectly laid out. Thank you for taking your time sharing this to you readers. -

Designed by Posicionamiento Web | Bloggerized by GosuBlogger