The Agile Manifesto ignores management – not mentioning it once. Management has slowly been acknowledged by Agilists as being important – but almost always with the phrase “servant leader.”
This is only partially accurate. Servant implies someone is being served and this is often understood to mean their teams. But managers are not really serving their teams directly. They are serving the business. Their job is to make sure their teams have the right environment to get their job done, to help grow their teams and to give them acknowledgement.
I think a good metaphor for Lean management is curling. Curling is the sport where a person pushes a ‘stone’ with a handle on it trying to get to a specific spot. Two sweepers go in front of the stone to both clear the path and slightly melt the ice with their brooms. Think of these as the managers. Continue reading “A Metaphor for Lean Management”
I’m often hearing how Agile is failing because leadership and management won’t adopt Agile values & principles. I would much rather they just keep some basic agreements:
Let’s stop for a minute and ask ourselves, do we want them to ‘be’ Agile or to do the following:
1-create clarity on what the most important work to do is
2-define these as a sequence of small increments for which we can realize value. Have each of these increments include technology &any other groups needed to realize value
3-provide technology clear acceptance criteria on these items
4-provide guidance across business units as to which are most important based on cost of delay
5-allow technology to self-organize & pull the work to be done in the sequence of greatest importance when technology has capacity
6-have an agreement with technology on how to handle emergencies
7-provide feedback when needed
We have come up with the following agreements we call the guardrails:
* Focus on realizing value
* Collaborate with each other in order to maximize the realization of value
* Make all work visible
* Sustain or increase predictability.
* Keep the work within capacitythroughout the value stream
* Encourage everyone to strive for continuous improvement.
Scrum.Org defines “ScrumBut” as meaning “that Scrum has exposed a dysfunction that is contributing to the problem, but is too hard to fix. A ScrumBut retains the problem while modifying Scrum to make it invisible so that the dysfunction is no longer a thorn in the side of the team.”
But ironically, Scrum limits the options of how to fix this dysfunction by requiring its immutable roles, rules, artifacts and events be followed. If one fixes the dysfunction by dropping a Scrum practice while adding a non-Scrum practices the team is still doing “Scrumbut” even though they’ve eliminated the dysfunction. But now, by not doing Scrum they are in unfamiliar territory since Scrum does not provide insights on the intention of each of its practices. This tends to have new teams in particular, that don’t understand the intentions of the Scrum practices, have to stick to Scrum or go outside of the range of Scrum.
If people just abandon practices without adopting a new one to fulfill its intent ScrumBut is likely a bad thing. Substituting practices requires understanding the intention of the practice being substituted &a set of alternatives to choose from.
This is an excerpt from Lean-Agile at the Team: A Lean Approach to Scrum &Kanban. See 1st comment for url
Writing a page on “How to Adopt Scrum” reminded me that the CSM course started around ’02 because Ken wanted to help those of us who already knew Scrum to be better coaches. It was a great experience and helped my coaching ability. But it didn’t teach me scrum. I already knew Scrum & reading Ken’s book was a prerequisite for the course. Continue reading “Piano tops and Agile”