My Scrum knowledge was out-of-date. The new Scrum guidance is streamlined to essentials and I like that.
Last Friday I was privileged to serve as a guinea pig for my colleague Martin‘s Professional Scrum Master course. The afternoon prior, he asked me and my colleague/classmate James to read the Scrum Guide and take the Scrum Open Assessment, specifying that we should score at least 75% on the assessment to show our readiness for the level of the course. James did exactly as asked, posted a fine passing score, and thoughtfully generated this blog post which instantly became the most-viewed in Northwest Cadence blogging history. Meanwhile, I flunked the assessment and wrote a blog post about how my new USB adapter has googly eyes.
Not the best student, me.
On Friday it was time to double down, literally. As a practice run, Martin condensed the two-day course into one long day. With only the three of us, we had lots of opportunity for discussion and debate as we worked through the PSM material. Martin’s insights, having used this stuff in the real world, are invaluable too.
Mid-morning, our new social media guru Laura asked us to live-Tweet or Facebook our thoughts about the course… a request she may swiftly have come to regret, as we were feeling feisty and immediately began Tweeting helpful suggestions such as marketing “WWKD?” beaded bracelets. (Hmm… chicken & pig Bandz! Calling patent office…)
At the end of the day, we took me up on my (frankly self-defensive) suggestion to use our prior scores as a baseline and take the Open Assessment again to see how Martin’s teaching had helped us to improve. Both of us had higher scores, but if mine is to be believed, Martin’s definitely the best Scrum instructor out there:
Didn't just ace it... did so in 4 minutes, 49 seconds
No, I didn’t cheat. Yes, I’m kind of one of those annoying good-test-takers. (Which, as with SAT and the like, should not be confused with “knows the subject matter any better than a non-test-taker”.)
But let’s get serious for a moment. The questions that tripped me up the first time were, in fact, meaty and interesting. Scrum has evolved and simplified in recent years. Before joining Northwest Cadence, I spent nearly three years on a reasonably effective Scrum-but team (which I guess really does make me a Scrum-but Master), and as I spent the day learning new insights about the Product Owner role and its responsibilities, the Scrum Master role and its limitations, I recognized so many nifty little practices – some we used, some I wish we’d used – that either solved or might have solved real issues we faced in the wild.
My favorite part, by far, is the way in which well-defined roles in Scrum empower the development team. Martin recently posted about the Rolled Up Newspaper Method of bringing developers around to Scrum. I understand it makes me a filthy tree-hugging hippie, but I don’t believe in the rolled-up newspaper for dogs or developers.
As it happens, I train my dog at Ahimsa in Seattle, an amazing place with fantastic results, run by a rock star genius mathematician who left academia to train dogs and their owners to get great results using positive methods that empower the dog. Hmm!
(Those who know how much I adore my dog, and how much I adore my former development team, won’t blink at the comparison of developers to dogs. Also, Martin started it.)
Dogs, like developers, can be trained to pee outside using exclusively positive methods.
For at least the last three years, I’ve said that if developers understood how much Agile, and specifically Scrum, helps them with problems they care about, they’d demand it. That’s exactly what I did, although I understand that as a “developer” I’m a bit of an odd duck. (Odd pig?)
Anyway, here are a couple of specifics I find intriguing:
- I like the way the Product Owner has absolute control over the Product Backlog and its sequencing. I like how “prioritization” has been changed to “ordering” to emphasize that it isn’t just the stakeholders’ priority or preference that drives the sequence: any number of other criteria may be used, and the Development Team is free to negotiate with the Product Owner on this matter. The Product Owner is accountable to the stakeholders for satisfactory results, let’s say for delivering value, but the stakeholders don’t control the details of how this is accomplished. I like how this gives the Development Team opportunities, e.g., to propose knocking out valuable low-hanging fruit, or to request re-sequencing to smooth out architectural or infrastructure dependencies. A strong, positive relationship between the Product Owner and the Development Team (and the stakeholders) will yield great results and a better quality of life for developers.
- I like how the Scrum Master’s job is to get the hell out of the Development Team’s way. I like the emphasis on Servant Leadership in this role. Over and over again, Scrum training questions and scenarios beat this point into the student’s head: the Scrum Master doesn’t solve problems or make decisions. The Scrum Master only preserves the Development Team’s autonomy and provides them with any structural assistance needed for them to solve the problems or make the decisions themselves. This is exactly what we devs say we want – hire us to write great code, then leave us alone while we do it.
On my former team, I was simultaneously Scrum-but Master and Technical Lead. This was ill-advised for at least two reasons: Dev Team members shouldn’t have titles, and my combo-role seems like a conflict of interest. But looking back on it, I can see the beginnings of some really nice practices: as Lead, I had the opportunity to participate directly in Product Backlog grooming throughout each Sprint, giving the team’s technical feedback on complexity, dependencies, and quick wins. Two successive Product Owners were great to work with and did a great job of synthesizing technical recommendations with our stakeholders’ priorities – no small feat, considering how stakeholders proliferate and conflict with each other in higher ed. Even struggling with Scrum-but, we did some amazing things as a team and delivered some really cool software in the federal compliance space.
- I like the way Scrum is a framework, within which the Scrum Team has total freedom to write PBIs, decompose requirements, and develop, test and deliver software in whatever way works for them. It doesn’t prescribe the SDLC: it fosters an environment in which an SDLC can happen reliably, because they can adapt and grow one that works well for them. In this sense I’m seeing similarities to Kanban but with a lot more structure. I don’t mind structure and neither do developers generally, if it’s a good one!
I came to Northwest Cadence expecting to be a defender of Scrum-but, which might yet occur, but for the moment I’m really fascinated by the framework itself, straight up. I’m excited to dig in and put my public-sector experience to work with a more diverse clientele. I have some cool things I can teach already, but test scores notwithstanding, I also have a lot to learn.
Look for me to test and grow these Scrummy ideas in our upcoming public events! I haven’t heard back yet on my idea for a bracelet giveaway…
Does that answer your question? 
In defense of the metaphorical “Rolled Up Newspaper Method” I do not encourage it to be used to help facilitate a process (Scrum / Kanban / other) as that requires informed consent, but to help train/teach particularly resistant developers to use source control (or any tool) properly.
As in: “No don’t branch like that…” smack!
And with the reality that you can’t actually, and usual legal (well, maybe in the east it is considered OK), do it encourages managers / leads to think of better ways to encourage team members to improve their skills… neither the stick or the carrot works in reality….
Or did I just dig a bigger metaphorical hole?
p.s. There is nothing wrong with being a “filthy tree-hugging hippie”
Very good post. Thanks for this.
You hit on two things that I found to be incredibly important in our scrum-but implementation.
1) “Scrum Master” is a bit of an overbearing title – it should be understood that this role is a facilitator, a servant leader as you say – in fact our Scrum Master prefers Facilitator as her title (which is awesome).
2) Scrum should be presented as a framework – there seems to be a lot of lingering emotion and assumption in our industry that when you talk about software process, you are talking about *taking away* freedom. With Scrum, you’re adding the structure necessary to *create freedom*. Anarchy is *not* freedom – some might say this is counter-intuitive, especially when you combine it with the existing preconceptions about process, but it’s true none-the-less.
Great feedback – thank you! I like the “Facilitator” title. On the other hand, Scrum “Master” may help as a reminder that this person is the one expected to be most knowledgeable about the rules of Scrum.
Check out the new Scrum Guide to see how much it’s now aligned with the “framework” idea. In the past, Scrum prescribed a longer list of practices and worked its way into everyday developer practice to a greater degree. Now that various practices are no longer mandated, I think devs can feel a little less pushed-around by a Scrum adoption. (If they’re smart, they’ll still gravitate toward most of the recommended practices IMO, but it may help for them to do it in their own time and think it was their own idea.)