10 Lessons from 20 Years in Agile: Lean Management

This podcast is part of a series, The 10 most important things I have learned from 20 years in Agile (June 3, 2019)

In this series, Al Shalloway shares some of the most important insights he’s had over this time and how they relate to each other.

This episode is about Lean Management. Continue reading “10 Lessons from 20 Years in Agile: Lean Management”

A Metaphor for Lean Management

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”

What I have Learned from Scrum

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”

Let’s stop trying to get leadership/management to ‘be’ Agile

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

 

Rethinking ScrumBut &ScrumAnd

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

Piano tops and Agile

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”