Introduction
This article has been floating around my head for quite a while. It will encompass several themes. The first being, how do we “account for” the time and focus within our agile teams? Second is, how granular do we plan for and monitor the focus of our agile teams? And finally, when planning and forecasting, should we plan at the individual level?
The “we” in these is a bit broad. I would include managers, directors, VP’s, C-level folks, the PMO and Project Managers. Virtually anyone who is tasked with “caring about” a technical team and what, how, and when they do what they do.
The Dinosaur Age
Well in this case, it’s not that long ago, but the analogy feels right to me. In this Dinosaur Age, project managers and “all management” for that matter, cared about people and their time. What are some of the aspects of that?
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 remember my first reading of the DAD – Disciplined Agile Framework by Scott Ambler that one of the areas he emphasized was governance.
When I first read it I had two immediate reactions:
- What did he mean by “governance”?
- And why care about it within agility; wasn’t that something agile intended to minimize or eliminate with transparency?
So to say that I was less than impressed by DAD initially was an understatement. But over time, I’ve kept up with Scott’s writings and explanations of his intentions with DAD. And to be honest, I like what I’m hearing of late.
Scrum is all about rhythms. Teams that are successful with Scrum establish a sustainable cadence for collaborating with each other. Each of the sprint ceremonies help us move toward our goal, and remind us what’s coming next.
Scrum is pretty straightforward about how to establish the right rhythms for the team, but organizing your work as a product owner is a little murkier. You know that sprint planning happens every two weeks, but what do you need to do to prepare? Your team does backlog refinement for an hour every week, but how far in advance do you need to start working on stories to make that meeting worthwhile?
In this article, I’ll share the rhythms that have worked well for me as a product owner. The Scrum ceremonies act as a trigger – a reminder that there’s something I need to do. I’ll organize this article by those triggers, and we’ll work our way backward to see what we need to do to prepare.
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.
For years and years, I’ve been talking about the importance of Sprint Goals in the fabric of Scrum team execution. They:
- Help to guide the focus and conversations at the daily standup and the team’s daily activity;
- Help to focus the team’s sprint planning towards an outcome;
- Help to identify the purpose and focus of the sprint demo;
- Help the Product Owner and the team in making sprint content trade-offs if the run into difficulties;
- Ultimately help the team define what “success looks like” for each and every sprint.
Given that definition, my clients usually start looking at Sprint Goals in a different way. I see them as being very powerful mechanisms for focusing the team’s efforts and I hope you start to as well.
I stumbled on a blog by someone I hadn’t heard before. His name is Tanner Wortham and the blog is Spikes & Stories.
Here’s the link to the post: http://www.spikesandstories.com/qualities-of-great-agile-coaches/
In it Tanner explores qualities of great agile coaches with a theme of their biases:
- Bias towards learning
- Bias towards action
- Bias towards innocence
- Bias towards honesty
- Bias towards silence
- Bias towards the team
I loved the premise of the post and feel inspired to extend it a bit. So adding a few additional biases to the mix.
When I first started my agile journey, there was a small set of certifications. The Scrum Alliance was the “lead dog” in the effort. Around 2003-2004, there was only the CSM, CSPO, and CST certifications. Life was quite simple then.
Over the years, I believe folks started to get the sense that there was “money to be made” in this area. Lots of money. So certifications began to “pop up” more and more.
Much of this certification frenzy bothers me because it flies in the face of most of the agile principles. In fact, I’ve found that the money can corrupt even the best of agile trainers and coaches. But that’s not the point of this post.
My curiosity got the better of me and I wanted to see just how many certifications I could find. So here it goes...
Until they realize that:
They have to sometimes say NO to some stakeholders;
They have to make decisions; short term vs. long term; tactical vs. strategic; now vs. later;
They have to peer into the future and anticipate customer needs;
They have to aggregate opinions from multiple, sometimes very powerful and unique, voices;
They have to trust their teams;
I was in a Backlog Refinement meeting the other day and you would have thought I was in divorce court where the parties were negotiating (fighting for) everything.
Each time the team asked clarifying questions around a user story, the Product Owner would begrudgingly answer. It felt like they thought they were wasting time trying to explore the story.
It was clear that what he really wanted was…an estimate.
So the team felt the pressure and stopped asking question. Instead they went immediately into Planning Poker for each story. And as you might expect, the estimates were sort of…all over the place.
