Thoughts from a Thirsty Bear

As an experienced developer/coach, once in a while you get asked a truly fantastic question by a client who has actually done her homework, and you're absolutely stumped by it. I love it when this happens since it is a fantastic opportunity to not only learn, but also to teach the client how to solve similar questions themselves next time. This particular team had been attempting to implement Scrum for some time, with a degree of success. But one thing was bugging them in particular. How to control stories in-sprint. The advice they had been given (and the way I understand Scrum to work) was that sprints are immutable. During the plannig game, the team sets the sprint backlog, populating it with the subset of backlog stories that the team believe they can fit into the timebox. That's it - only a major event causes that to change, in which case the sprint is terminated, replanned and restarted. So when the Scrum Master asked about the 2016 edition of the Scrum Guide

Aka "Absent Scrum Master Anti-Pattern" There is a question that keeps cropping up when talking to clients. It is  “How many teams can a Scrum Master lead?”.  My answer? Just the one. Let’s take a closer look at why people persist in asking this question, and try to understand better why it is generally a Bad Idea™.  When a team is running well, everyone is happy, and product is being delivered successfully iteration by iteration, feature by feature. There is comparatively little for the Scrum Master to do aside from day to day housekeeping. Everyone knows how the process works, everyone plays their part. The system chugs along and delivers. The SM appears to have a huge amount of slack, which most organisations believe is a Bad Thing - slack means they need to squeeze out more performance (read “ profit ”), in this case by giving the SM something else to do. I.e. another team. And maybe another. And another. Or other random responsibilities. Ignoring the bad

...they've all got it in for me! Excruciating Carry On pun aside, here's the long overdue link to the talk I gave to the Limited WIP Society  way back in March 2010 (my fault for not posting it here - it's been up on the SkillsMatter website for ages). (Sorry, this is just a link. I can't work out how to embed this directly into the blog page - any ideas, anyone?)

Via various convoluted routes: Become a Certified Agile Software Specialist! Update : the link is now cobwebbed, but if you did the original then please get in touch! Update 2: It's back! FTW! Update 3 : the link has disappeared again. Boo!

A recent exchange between me and a non-developer, trying to explain that some Scrum Masters are better than others: Me: "Scrum Mastering is pretty much the same as Team Leading. To find a good one you need to look at their past. They almost need a 'pedigree'." S: "Oh, you mean Pedigree Scrum ?" Me: "Yes. They need to eat their own dogfood....." At that point we had to temporarily abort the conversation. OK, maybe you had to be there....

I stumbled across a blog post about Scrum's origins on Jeff Sutherland 's blog recently. The whole thing is worth a read in order to get a perspective on where the methodology came from, but especially interesting was the following comment: " Few implementations of Scrum achieve the hyperproductive state for which Scrum was designed (5-10 times normal performance). Those that do all implement variations on XP engineering practices... " This fits with my - and others' - experience over the past few years. Scrum, with a few tweaks based on personal experience, provides a good starting point for a lightweight management framework. But that's just it - it's a management framework. You need wrap something to be managed in it. And if that something is a lardy, slow mini-waterfall process then you will simply end up delivering stale garbage more efficiently. XP has the opposite problem. It provides tools and techniques to develop quality software efficiently, bu

Planning Games can be a problem. Especially with large teams where it is difficult to get consensus, and also far too easy to descend into lengthy discussions where different people are in fact violently agreeing with each other (at least in terms of what size something is). What should be a simple one hour maximum meeting to scope out the relative sizing of specific business stories can turn into a Dilbert-esque four hour meeting from hell. Classic Planning Poker rules suggest using a timer to try and avoid these kinds of situations. Anyone can start a two minute timer, and at the end of the time the team must estimate. Limiting the amount of time gives a degree of pressure and focus to the discussions especially when there is disagreement. Also it limits otherwise lengthy discussions where in fact everyone now agrees on the estimate. I the past I have tried using this technique with some teams that had a tendency to get bogged down but with limited success. I have tried using a mobil