Here are some things I have learned from Scrum.
- Cross functional teams are good. Just having them achieves a three to tenfold improvement over a group of people working on several projects at once. And they improve innovation by the team.
- Time-boxing increases discipline, visibility and the ability to pivot.
- Small batches are good and breaking work down into small pieces is essential.
- Smaller release cycles improve most everything.
- It is useful to have a team coach.
- Do not expect people to figure out what they need to do just because you have put them in a framework.
- Focus on learning the practices of a framework makes learning what you actually need to accomplish (flow) harder.
- People like to be given a set of practices to use.
- Defining a simple set of practices to use can lead to rigid dogma.
- Take an approach that transitions you to the behaviors you need.
- Approaches that work well in one context may not work well in another even though people them everywhere without noticing this.
- And, just because you can put whatever you want into a framework, that doesn’t mean the framework is not prescriptive. In itself, the framework has things you must do.
Continue reading “What I have Learned from Scrum”
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.
For more information on the guardrails, go here.
To see guardrails tailored for leadership and management, go here.
This blog is an excerpt from my upcoming book –Achieving Business Agility at All Scales
This is an excerpt from a chapter my new book Achieving Business Agility at Small to Mid-Scale.
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”