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:
I attended an agile coach’s gathering about a year or more ago. It was a “coaching the coaches” session and it was very valuable. But an aspect of it has stuck with me ever since. One that I’ve mulled over and over and would like to share.
There were a group of coaches in attendance from the same client engagement, a large, multi-billion-dollar organization that had been going Agile for a couple of years.
When they decided to go agile, one of the first things the client did was reach out to an agile coaching firm for help. On the surface, that sounds like a good thing to do. However, the firm was largely staff augmentation focused, so that was their background and comfort zone.
I’ve been doing more pairing lately. Much more.
I’ve been trying it in my conference workshops and talks. Pairing with Mary Thorn quite a bit on the agile quality and testing side of things. I’m also pairing with Josh Anderson on our Meta-cast and I’ve done a few presentations with him. Very enjoyable.
I’ve also been pairing more in my writing. For years, I’ve been a lone wolf writer. Nobody but myself saw my writing before it entered the light of day. But now, I’m learning the value of having reviewers and editors. Second opinions matter. A second set of eyes matter. And having a partner in your endeavors can be quite a bit of fun.
An example of this is Mary Thorn being my “Chief Story Teller” in my 3-Pillars book. We had a blast writing the book and her stories complimented my own experiences to give readers two sides to many coins.
Tanner Wortham is a ScrumMaster and coach who I’ve quoted on this blog before. He recently wrote a blog post entitled: When Can a ScrumMaster Say No which I read with interest.
I’ve been sharing of late around the notion of more prescriptive coaching stances and, at least in my mind, this seeps into the role of ScrumMaster. So I wanted to hear what Tanner had to say.
Here’s a snippet from the article:
[…] Doing away with the sprint review simply ignores the problem. Help the team experiment with new ways to conduct the review but that align with the intent. Over time, they will find their solution. At no point did we have to say no. In fact, we should avoid it. I believe our responsibility is to understand and to guide. Rarely is it to deny.
Even so, I occasionally encountered two situations where I’ll say no as a Scrum Master:
I’ve been presenting at conferences for years. Over 20 years to more precise.
One of the common occurrences is that someone points out a typo or grammatical error on one of my slides in the comment section of the feedback form. I recently had this happen in a Certified Agile Leadership class. One of the feedback post-it notes on the first day pointed out a few typos. While I appreciate the feedback, I often wonder if there is more feedback than simply minutia…
If you read the feedback on Amazon for my Scrum Product Ownership book, some of the reviewers say the same thing. They talk about copy edit quality and the errors. These folks are right. I should have spent more time and money on the editing process. But if you look at the vast majority of the reviewers, they seemed to have overlooked those mistakes and received great value from the book.
And the detractors really seem to rate the book much lower based on the simple errors, simply overlooking the real value of the book. It’s as if they can’t see the forest for the trees.
As the instructor walked us through the exercise, he made it clear that “it depends” was not an acceptable answer. I asked if we could say “I don’t know”. And that was unacceptable as well.
It seemed that his only view of a viable answer to leadership was to provide a historical, trended data forecast. To give them as specific a timeframe as possible and lightly couch the risks associated with the estimate.
His primary driver for this position seemed to be that:
If we didn’t give them a specific forecast, they would go to someone (another team, another organization, offshore firm, nearshore firm, outsourced, etc.) that would make a more specific commitment.
I.e., that because we’re afraid of losing the “bid”, we have to provide something to win their confidence and win the work. No matter the level of confidence or runway we have in our historical “velocity-based” data.
I was talking with someone at a conference a few weeks ago and he asked the question:
What do you think about the concept of “Elastic Teams”?
To be honest, I’d never heard teams referred to in that manner, so I had to admit that I didn’t know. I asked, what do you mean by an “Elastic” team? He went on to explain.
He said that these are teams who are formed, dissolved, and reformed around business needs and priorities. For example:
If you had 3-5 teams working on a set of products in your portfolio and the overall business priority changed. Then you could possible shrink each of those teams by 3-4 individuals and assign them to another team (or group of teams) for 2-3 months.
If something else shifted, perhaps something smaller. For example, a customer escalation of a performance problem. Then you might shift members amongst teams to address the situation. In this case, it would hopefully be a shorter-term reassignment, and then things could go back to normal.
One of the new capabilities of my agile coaching practice is the ability to deliver the Scrum Alliance, Certified Agile Leadership (CAL1) class. It’s a relatively new certification for the Scrum Alliance and it targets the management and leadership levels within organizations who are planning to or who have already adopted agile approaches to software development.
I’ve been coaching agile transformations (organizations, groups, teams) for over 15 years. During that time, I’ve noticed that there are literally 3-tiers to any transformation:
- Sr. Leadership Tier
- Organizational Leadership & Management Tier
- Team Tier
Most organizations only focus the transformation or adoption towards the team level. But in my experience, success is in effectively guiding all three tiers towards agile principles, tactics, and leaner agile mindset.
In fact, I think the critical tier is in the middle.
I’ve sometimes heard it called the “frozen middle” because it’s where true agile transformation lies, but it’s the tier that often gets the least attention.
Enter – Certified Agile Leadership
The CAL is solely focused towards the middle-tier. And finally, we’re engaging leadership folks with training and coaching of their agile transformational skills.
It dawned on me the other day. I client asked for role-based guidance around ScrumMasters and Product Owners. One of my pointers was to the Meta-cast podcast that Josh Anderson and I do together.
But there are 100+ and counting podcasts there and I realized that it's very hard to cull through them all to get role-specific advice.
So I thought I'd pull together three lists in this post that align with the three Scrum roles: ScrumMaster, Product Owner, and Team. It's not intended to be exhaustive, but I think you'll find value in the discussions.
Every year I try to spend time on my own training. I usually start thinking about two things the year before:
- What are some knowledge gaps that I have that I’d like to fill, and
- What are upcoming trends that will cause me to become obsolete if I don’t get ahead of them?
Then I review the available courses and I’ll try to come up with 2-3 things that I’ll focus on for improvement.
Last year I posted my first "Sharpening the Saw" post in June. That inspired me to do it again for 2017, but closer to the beginning of the year. You'll probably see this become an annual post to remind me (and perhaps you) to plot a journey of continuous learning.
