One of my favorite, old-time rock groups is Emerson Lake and Palmer. And their song From the Beginning seemed appropriate for this article.
One of my new favorite voices in our agile community is Sandy Mamoli out of New Zealand. I’ve read oodles and oodles of her work, but I have yet to see her in person. Fingers crossed, I get that chance soon.
One of the more interesting things that Sandy is focusing on is team self-selection when it comes to how to organize around projects and work. Recently Sandy wrote a piece entitled: Giving Teams the Best Start.
In it she emphasizes the work that Ainsley Nies and Diana Larson have done in their book Liftoff, which just released its second edition.
There’s an Extreme Programming concept, tool, practice that many have forgotten. Sure, we remember user stories, refactoring, TDD, continuous integration, and pair-programming among the more popular XP practices.
But there are some that were quite useful and meaningful that we’ve misplaced. One of them is release planning as described in the Planning Extreme Programming book by Kent Beck and Martin Fowler.
Another is the notion of “Yesterday’s Weather”, which is a much simpler concept. I want to focus on it though as a powerful thinking tool for today’s agile teams.
I saw a picture tweeted by Alex Yakima with this picture of the RTE Canvas and it inspired me to talk about this role more.
You can find the tweet here - https://twitter.com/alexyakyma/status/793491699515273216
In the canvas, he highlights five key responsibility areas for the Release Train Engineer. They are:
- People
- Program Increment
- ART Success Indicators
- Improvement Roadmap
- Coaching & Education
My friend and colleague, Lee Eason, recent wrote a post entitled – Redefining Success in a Post Agile World. In it, he generally shared thoughts around the evolution occurring (and needed) in the agile community towards understanding and delivering on business factors.
First, I want to congratulate Lee on a thoughtful and well-written article. I look forward to those moments when Lee shares his thoughts. While they are infrequent, they are important and timely observations from an agile practitioner in the trenches.
However, I do want to react and add a perspective to Lee’s. One that I think he may have underemphasized or missed altogether.
Here’s a snippet from his closing thoughts:
Introduction
This description is intended to help guide the implementations of Scrum of Scrums at Program / Train level.
It all started with this picture that Mike Cohn published over 10 years ago. In the explanation he briefly mentioned a hierarchical structure where multiple Scrum teams get together when they are working on related projects.
Often I explain it as: team-based Scrum behaviors, just up a level.
https://www.scrumalliance.org/community/articles/2007/may/advice-on-conducting-the-scrum-of-scrums-meeting
In my classes I often liken an aspect of the ScrumMaster role to that of a sheepdog. That an important part of their role is protecting the team. Often the direction of this protection is assumed to be outward, for example, insulating the team from external interruptions.
In a recent newsletter (sent on September 22), Mike Cohn discussed this part of the role in more detail. He spoke to two areas of protection:
- From Management Dysfunction (external), and
- From Team Complacency (internal)
The thing that struck me in Mike’s post is the internal protection perspective, ie., protecting the team from “themselves”. It made me think about areas where a ScrumMaster can really help their teams in this area.
Let’s explore some specifics…
If there were one topic that seems to dominate all others in agile software development, I’d say its estimation.
Every team seems to struggle with it and I’m always being asked for “silver bullet” solutions that might make it easier. And of course, there are none.
I do think there is some guidance I can provide that might help you to improve your estimation understanding, confidence, and results. Or at least that’s my intent. So let’s try…
2-Phased Estimation
The first thing I’d like to make clear is the nature of most agile estimation & planning approaches. I like to think of them as a 2-phased approach versus the 1-phase, plan everything down to the single molecule in advance approaches typically used in waterfall projects.
I think everyone has the sense that the ScrumMaster role is all about:
The team, the team, and the team
and that they spend all of their time working in groups, with…the team. Most of their effort is facilitating meetings, resolving impediments, and generally serving the well being of their team(s).
And all of that is true.
But I think there is a much more subtle persona to great ScrumMaster’s and it doesn’t directly involve the team or group. It’s actually one of the hidden aspects of Scrum Mastery and I want to explore it in this article.
What are you talking about you might be thinking?
I attended the Mile High Agile conference in April. One of the keynotes was Michael Feathers. He did something interesting in the opening moments of his presentation.
https://www.youtube.com/watch?v=3AMzRAjA0-o
First, he asked how many non-coders there were in the audience. And about 80% of the group raised their hands. MHA was very well attended with approximately 850 folks – so that manes about 600 folks raised their hands.
The second thing he did was show us some code on the screen. And he asked how many folks were comfortable with it. For example, showing it (code) in a sprint review. I think there were even more folks that raised their hands.
As an agile coach, it seems one of the areas that teams struggle with the most is in estimation. And by estimation I’m implying some of the following:
- When do you “task out” the story? Who provides estimates for the tasks? And in what units?
- How do you breakdown, estimate, and re-estimate user stories? When are you “done” estimating them?
- Story points are relative and high level – should we convert them to hours or time?
- At scale, let’s say 10-20 teams, the estimates are interconnected across some teams. How do we handle dependencies and integration?
Mishkin Berteig has published a nice overview of 9 estimation techniques. As part of this article, I will review each one from my own perspective. Some I’ve used and others I’ve not. I’ll share my own stories to compliment the techniques.
