More than a year ago I wrote an article about how important “capacity management” was in agile teams. To be clearer the point was really…realistic capacity management.
At the time, I’d just come off a coaching roll where I’d encountered quite a few organizations that were pushing their teams too hard. Not slightly over their capacity, but two, three, four or more times their healthy capacity. And this created some distinct side effects:
- Employee satisfaction and morale was down and attrition was up. And they didn’t just loose their average people, they were losing their best people;
- Product quality was usually in a crisis mode and customer trust was continuously eroding;
Now that I think about it, a “rule” sounds a whole lot more formal than I intend it. Perhaps I should call it a guideline or a heuristic or a thinking tool?
Ah, I don’t know. Let’s get into it and make that determination afterwards.
The Rule
It’s simple really. It revolves around telling your teams what to do. That is providing your directives, strong opinions, and guidance when you’re interacting with your fledgling agile teams.
The premise is that for every 100 opportunities that you are confronted with in your organization to provide prescriptive advice to your teams, you get no more than 5 times to actually tell your teams what to do.
One of the core ideas or principles of agile teams is this notion of a self-directed, self-managed, and self-organized team.
In my experience, it’s one of the hardest things to “get right” in your coaching and team evolution efforts.
Often I see two extremes…either:
the teams use the self-organization, self-directed mantra as a means of having no accountability. It’s essentially the “inmates running the asylum” and they can choose to do whatever they wish, whenever they wish under the banner of – “don’t bother us…we’re being agile”.
Or the other extreme is that:
the management team says that they’re empowering their self-directed teams, but when you look at their behavior, they’re doing what they’ve always done…tell folks what to do.
Book References
Project Retrospectives - A Handbook for Team Reviews by Norm Kerth
Sort of the “Godfather” of the modern day, agile retrospective is Norm Kerth. I always try and mention norm and his work as a means of giving folks a sense of the pre-Agile legacy of retrospectives. Point being, it pre-dates agile approaches.
The other nice thing about Norm’s work is his notion of “safety” in retrospectives and his Prime Directive. I almost always reference the prime directive at one point or another with each of my clients and in my teaching. It epitomizes the “mindset” of a healthy retrospective.
There’s a trend in the agile community of influencing folks away from saying no, instead saying: “Yes, And…” as a means of connecting various conflicting points together. I wanted to use the same mechanism for the title of this article, because I think we need to start looking at the basic Scrum certifications in a different way, perhaps the same way we view Peanut Butter AND Jelly. Let me try and explain.
I’ve seen an incredibly alarming trend over the last 1-2-3+ years in my coaching. It involves whoever is teaching Certified ScrumMaster classes; whether they be from the Scrum Alliance, Scrum.org, or elsewhere.
I encounter quite a few organizations and many teams in my travels. Almost universally they are adopting Scrum and have a few to many CSM’s around to guide the transition.
But I’m finding that the “Scrum” that is being fostered and guided in these organizations leaves a lot to be desired. Often:
I have a good friend and colleague who works in a rather large enterprise. Among others, she’s tasked with bringing “agile” into the organization and “transforming” their work. She’s largely leading the effort, so has a tremendous amount of responsibility for its success.
They’ve chosen Scrum for this effort.
They’ve engaged a rather large agile coaching firm to help them “go Agile”.
So far their strategy has been along the following lines:
- Hire full-time agile coaches
- Do a little training for “Leaders and Managers”, less than a ½ day, usually 60-90 minutes
- Spin-up Scrum teams (a little training), with Technical Leads as ScrumMasters and limited Product Owners (time and skill)
- Start sprinting
- Hire more agile coaches
- Spin up more Scrum teams…start sprinting
- Rinse & repeat…
To-date, there are more than 50+ newly minted Scrum teams who are dutifully sprinting away creating lots and lots of value.
My colleague Josh Anderson and I were chatting on the Meta-Cast the other day about agile team sizes. While there are no prescriptive limits or guidelines to agile team size, there are general guidelines.
From Scrum, the size has always been recommended to b 7 +/- 2 (or 3..9 in the latest Scrum Guide) as the preferred size for teams. But as in all things agile, direct experience is always valuable. So what was ours?
Over the past few months I’ve been coaching my clients who are in the early stages of adopting agile approaches for software. Most of them are adopting Scrum, but a few are adopting Kanban.
Universally, one of their complaints is that their teams aren’t “stepping up” to the
- Empowerment
- Responsibility
- Accountability
- Passion & Energy
- Creativity
That is implied as part of the culture of self-directed, agile teams.
To say that they are disappointed is an understatement. And these comments are coming from all levels of the client leadership teams.
Giving feedback is one of the things I like most about agile methods. There’s this thing about it though. It’s not that easy to give effective feedback. Lately, I’ve been hearing agile team members start their feedback with the following statements:
- I don’t want to rain on your parade, but...
- I don’t mean to be negative, but...
- I don’t mean to criticize, but...
- I don’t mean for you to take this the wrong way, but...
And then there’s the Ricky Bobby quote from the movie Talladega Nights regarding – “With all due respect…”
I get bombarded with different points of view from agile coaching firms all of the time. This one crossed my screen from Mike Cottmeyer just this morning.
http://www.leadingagile.com/2015/03/lets-acknowledge-safe-for-what-it-is-and-move-on/
and here’s a snippet from Mike’s post, just to give you some flavor:
So… I want to say this one more time for emphasis… either you create the conditions to do agile well… or you do something else. SAFe is that something else.
We can say that SAFe is a cop out… or isn’t really agile… or that it’s the second coming of RUP… but don’t underestimate the complexity, the risk, or the cost of totally refactoring an enterprise to be the kind of organization that can really do agile at any kind of scale. Some organizations simply can’t or won’t invest in this. At the end of the day small batches are better than big batches. Iterative and incremental is better than waterfall, even if it isn’t agile.
