I was inspired for this article by the same titled blog post from Simon Nadav Cohen that you can find here: https://labs.spotify.com/2016/05/13/to-coach-or-not-to-coach/
In the article, Simon speaks to his experience of overusing the “coaching stance” in his agile coaching interactions and showing that more nuance is often required. I wanted to explore it even more from an additional context – that of leadership coaching. But let me start out here…
The 5 Why’s
Are you aware of the 5 Why’s tool? It’s a lean technique for getting to the root cause of a problem or challenge. You keep asking why, five times in fact, in order to “peel the onion” of a problem and get to the root.
I was reading an online HBR article the other day about leadership communication. Here’s the HBR article –
https://hbr.org/2016/03/two-thirds-of-managers-are-uncomfortable-communicating-with-employees
I thought this might be a nice way to RE-explore leadership communication challenges. And a new twist might be some ideas on HOW to improve it.
I submitted a talk to the North America Scrum Gathering this year that made me a bit nervous. It was entitled – Why the World Needs More Prescriptive Agile Coaches. And I was intentional with the title.
I’ve felt for quite a long time that agile coaching can be too soft, at least in the beginning with Shu-level (beginning) agile teams. Coaches are taught to never TELL teams what to do or be forceful in any way. At best, they might “hint” at a tactic or solution, but the real learning and evolution is “up to the team”.
Consider this the default coaching stance for the majority of agile coaches.
And while I understand it, I wanted to get the audience thinking differently in this session. And yes, see what the outcome might be. Does it resonate well OR do I get some tomatoes thrown at me was the question.
I came upon a wonderful post entitled The Illusion of Managing People at Nucleus Insights. You can find it here: http://nucleusinsights.com/blog/?p=224
The focus of the article was away from “managing” and more towards “leading, inspiring, and focusing”.
There were three key points made:
- Nurture the culture, can the controls;
- Paint the big picture, skip the little instructions;
- Always ask, never tell.
They wrapped up the article with the following quote:
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.
