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 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.
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.
In 2001 I was laid off from Lucent Corporation in Raleigh, NC. At the time, I was a software development director leading a group of developers and testers implementing optical networking devices. It was incredibly complex work and the teams were dedicated to doing great things.
This was just post the 9/11 attack and the Telecom bubble burst so to speak. So, all of the large Telecomm companies were impacted.
I was placed on the building close-out crew, so I had a long period of time “managing” the reduction. At that time, I began to write a book. I completed it in 2002 and it was finally published in December 2004. I remember at the time being incredibly impatient as the publisher, Dorset House, took its sweet time in the editorial and printing processes.
At the end of 2016, Josh and I had published 106 posts on our Meta-Cast agile podcast that we started in January of 2010. So, we've been LIVE for 7 years now.
In that time, we've published on virtually any agile topic you can think of. I thought I'd share our Top 3 podcasts from 2016.
In this segment, we actually review one of our early podcasts that focused on agile testing and then shared some of our updated thoughts and reactions to the topic. It turns out that much remained the same, but there were difference (shifts) in our thinking.
In this segment, we explored the "movement" that is implying that agile is DEAD. We look at the forces behind it, the why if you will. But we also weigh-in on our own thoughts. And if it's not dead, where IS agile now and where is it GOING.
What's interesting in this segment is that Josh shares his direct experience at The Dude implementing agile methods. His focus has been on Scrum, Spotify, and a bit of SAFe. He characterizes it as The Agile Donut. Listen in.
The Meta-Cast is into it's 8'th year. We hope you continue to follow us and that we continue to provide value to the community.
Stay agile our friends!
Bob.
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:
Last year I scheduled a Product Ownership class that was entitled: Scrum Product Ownership 2.0. The description alluded to more advanced topics and I worked hard to weave them into the course materials and my plans.
Folks seemed to be interested in more advanced topics and I was trying to fill that need in the agile market – beyond the pervasive basic certification courses.
But something interesting happened when I delivered the class. I had three primary discoveries:
- Everyone in the class was clearly struggling with more basic skills and tactics;
- As I tried to convey more advanced topics, I realized that they really weren’t. Instead, they were based on doing the basics…well;
- And finally, the class was looking for silver bullets. That is, they wanted advanced topics that would solve all of their challenges.
I subscribe to Mike Cohn’s newsletter. As you would expect the value is always high and his posts usually make me think a bit about my own coaching experience and ongoing advice.
In a recent newsletter Mike adopted a position on a manager serving as a ScrumMaster that goes contrary to my experience. Here’s what he had to say:
When I first started doing Scrum, I was what we'd call today the team's ScrumMaster and product owner. But we didn't have those terms back then. And without terms or any clarity on the roles, it was easy for me to make the mistake of being both.
I also did some programming. Oh, and I was also the vice president of the software department, so my team reported to me.
I want to address that last role because common advice in the Scrum community is that a team should never, ever report to their ScrumMaster. That is, I could have been the ScrumMaster or the VP -- but I should not have been both at the same time to the same team.
I once worked as a coach at a large financial firm that had been “going Agile” for quite awhile. They were one of the worlds largest firms, so the teams and the projects were often distributed.
They had invested in a relationship with a Ukrainian firm to outsource a significant part of their software. This had been going on for a while, so there was integration between internal and outsourced agile team members.
I was pulled in to help the outsourced teams with their understanding of agile practices. You see, even though they “said” they were agile, their behaviors were really suspect and more indicated cowboy and self-centered development.
