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.
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.
By definition, agile development is a team sport. The emphasis is on teams working and delivering together. It’s not measured by how many user stories the development team produces, but by how many completed/done stories the team can produce.
Quality is not something “owned” by the testers, but the responsibility of the entire team. In fact, you don’t try to “test in” quality, but rather “build it in”.
It places collaboration and teamwork above individuals working alone. It values pairing and swarming around work. It values limiting WIP so that team members work together.
One of my favorite movies of all time is A Few Good Men with
Jack Nicholson and Tom Cruise. I can picture that highly charged confrontation
at the end clearly in my mind. You know the one.
Tom Cruise says—I want
the Truth…
And Jack Nicholson
leans forward, with that classic look, and says—
You Can’t Handle the
Truth!
What a climax to the film. I get chills every time I watch
that scene.
I’ve been thinking more and more in my coaching about why
leaders and managers often wait too long to ask for agile coaching help. I
think it’s a general phenomenon in agile (and non-Agile) teams and
organizations, but for the purposes of this article, I want to focus upward—on
“them”.
