Anti Agile? Moi? I think not!
‘”Doing Scrum” is as meaningless (and impossible) as creating an instance of an abstract class.’
- Tobias Mayer
This is a quote from Tobias Mayer, a certified scrum trainer. I had an opportunity to today to describe exactly what this means. I was accused of using the quote as “anti-scrum” and I think that opinion is so wide of the mark, it’s almost firing backwards.
If you’re actively trying to “do scrum” in your workplace, then I think that you’re missing the point about scrum itself. Scrum is just a framework, a tool you use to help you achieve your goals and the goals of the business for which you excercise your talent and skills. Don’t waste time on trying to “do scrum” – you’re either doing it or not. It’s a simple set of rules that are bolted on top of the agile manifesto.
Even if you’re not doing “scrum”, but you’re doing “scrum-but” (ie: “We do scrum, but …” – thanks Jimi Fosdick!), then don’t sweat it. If you’re delivering potentially shippable software at the end of every sprint, then you’re on track. With any luck (and a bit of judgment and guidance from your Scrum Master) you’ll start to stick closer to the rules as you inspect and adapt and begin to adopt the manifesto through the medium of retrospectives.
It’s all about not breaking the rules. No one wants to play games with people who break the rules, it means there’s nothing tangible, no edges or borders, no boundaries with which to keep the game flowing.
As Tobias says, Scrum is about surfacing organizational dysfunction, instead of bending the rules
Read the entire article entitled, Scrum Doesn’t Do Anything here.
IS EVERYONE AWAKE?
Try this in your standup tomorrow;
Wait until it’s your turn to offer yesterday/today/blockers, the make something up. See if anyone notices. If they do, then you appear to be doing scrum properly as your team are interested in what you have to say. If no-one bats an eyelid, then you’ve got a problem. The standup is an information radiator, some way of telling your team and anyone else who is interested, exactly what it is you’re doing. If what you’re doing is dull, then spice it up a bit. If it’s the same thing as you were doing yesterday and probably the same thing as you’re doing tomorrow, then try and be a bit more detailed – what EXACTLY did you do.
If people are genuinely not interested, then perhaps you’ve structured your team wrong. Really, you should all be working round the same kind of area, so if people aren’t interested because it’s not something they do, or will do, then it sounds like you may not be swarming and your developers are siloed. If that’s the case, then shake things up, because you’re not doing scrum!
CSM Certificate
Some people are like Yay! others are Boo! Me? I’m more meh…
I can understand both sides and, frankly, can’t get behind either. Some say that the CSM course isn’t about learning how to do scrum, but learning how to take scrum to your business. That’s fine. These people, they say “Why do you need a certificate for something that you can prove you know by doing?” Well, you need to find somewhere to do it first, surely? Being a CSM makes it much easier to get a job as a scrum master, and, once you’ve got that foot in the door, you can then start to prove yourself as a CSM by actually doing. Fair enough right?
Others, they say; “OK, so what’s the point in the certificate in the first place?” and I say, well, I concede that point also. Going on the CSM course is enough, as long as you can say you were on the CSM course – how do you do that? With your automatic entry to the Scrum Alliance, you can looked up on the register.
Well, I say meh… If it helps you get a job, then great! If it helps you get a foot in the door, then great. If it helps you pay attention more in the training, then that’s awesome too. Just don’t worry to much about it. At the end of the day, it’s what you DO in the day to day of running your sprints that counts.
Besides, the industry is full of certificates and exams that mean exactly squat. It’s just like university – you prove you can learn and retain enough knowledge to pass a test; although it’s a hell of a lot cheaper!
Grooming a product backlog
How many times do you or your team work with the product owner to groom the backlog? Once or twice a sprint? Once a month? Less? How about trying to do it every other day, or even every day?
Grooming the product backlog is one of the most important things you can do in scrum (besides following the rules and um, delivering). It helps you maintain a healthy outlook on what you’ve got to do, it helps you recognise and deal with dependencies and blockers earlier and it goes a long way toward release planning and estimating a project delivery date (or date range, more likely).
Also, if you groom the backlog daily, it’ll take much less time and be a much less arduous task. I’ve done both. Sitting with the product owner once a week to groom a backlog of many, many stories is a pain in the arse. The most appropriate time is just after the stand-up. You’re all standing around the sprint/product backlog, so take the time to ask for a couple of volunteers to spend 15 minutes examining some stories, grab the product owner as well. I always suggest that anything bigger than a five pointer is probably a good candidate for breaking down a bit further or defining acceptance criteria and anything bigger than a 13 should definitely be broken down further.
Take a big or ill-defined story and ask, can this be broken down? Can we break this into any smaller parts that offer business value? If so, then great, break it up there and then, if not, then ask if it can be broken into smaller parts that don’t provide business value? Sometimes, this is a worthwhile questions as, when you break a story into smaller, non-valuable parts, inherent value sometimes bubbles to the surface, taken out of context, the team might spot a way that smaller stories that don’t deliver value, might actually do so after all.
Then ask the team if the acceptance criteria is accurate enough, does it, in their opinion, describe the “done” state of the story? Obviously, the only party who can actually say when it’s really “done done” is the business, but your team will always have a good idea of what “done” is to them and the product owner should be able to offer more information on what the “done” state is.
Finally, see if you can ascertain some kind of rough priority order, this is especially relevant for technical stories that may not provide value for the business at large, but will often support other stories that do provide value and you should always try and pay off your technical debt wherever possible.
So, if you groom the backlog with the product owner and various members of your team more regularly than you do now, when you get to sprint planning, it’ll be a breeze. You’ll spend much less time discussing what the stories mean than the actual tasks needed to complete them. You’ll know exactly which supporting technical stories you may need and, if you’ve been aggressive at breaking down stories to two, three of five story points, you’ll be able to be fairly accurate with your commitment.
And really, that’s what it’s all about, being slightly more accurate, so the confidence of your team is high that you can complete what you’ve committed too. Your team will love you for making sprint planning less like pulling teeth and your product owner will love you for delivering what you’ve committed to.
Win-Win as they say.
Guessing a velocity
You’re at sprint zero. You’ve got a new team. You’re new to scrum. You’ve never quite managed to stick to the Scrum framework. All reasons why you might not have a velocity. I’m sure there are more, but these are the most common. What do you do? How do you know how much you’re going to be able to fit into a sprint?
You guess.
Yes, I’m serious. If you’ve groomed your product backlog for the first sprint, estimated your stories and refined those estimates and broken down larger stories, then the only thing left to do is guess. Gather your team around and ask them “What do you think you can fit into this sprint?”. Once the team has picked from the highest priority stories and agreed that they think they can fit the work in, ask for their commitment. It’s at this point that you’ll need to help the team decide whether or not they’ve over committed. Most teams almost always start out thinking they can deliver more than they really have the capacity for. It’s not because they’re showing off, or because of any kind of arrogance, they actually do think they can deliver what they’ve said they will. Remind them that, while the stories are well written and the acceptance criteria well defined, they are just the start of a conversation with the business and things could change.
Your team will probably decide to knock of one or two stories and right now, that’s fine as they can always go back into the sprint if you find yourself running out of stories half way through. Once there’s a commitment, add up the story points. That’s your predicted velocity. It may not be accurate and it’s quite probably wrong, but right now, right this very minute it’s the most accurate idea you have of how much you can deliver in your sprint.
Why is this useful? Well, it will give your team a target, they’ll want to actually hit that velocity prediction as they’ve said they would. It’ll also come in useful for release planning and having some kind of vague idea of when your product might be delivered. You know least about how long or how complex a task is right before you start it, but now you’ve got some benchmark. You can add up the rest of the story points on your backlog, divide by the predicted velocity and have a figure which is roughly how many sprints you’ll need before you have delivered your product.
That is something that the product owner will shit himself with excitement about. Assuming he hasn’t asked you to translate that into a gantt chart.
leave a comment