Daily Meeting Checklist

Are work boards updated?

– at least regarding your own work
– “No“? let’s take a look

Are there any issues, problems?

– “Yes“? let’s talk about it…

Can you answer “what’s next”?

– (for you)
– at least until next daily meeting
– “No“? let’s take a look…

  • Can you join existing planned, started work?
  • No? Can you help with any bottleneck, problem?
  • No?
    • A bit much work in progress?
      => Do some improvement work
    • Lastly: consider starting new planned work

Remember:

Lean Decision Filter

“What should I work on next?”

Yuval Yeret quotes David Anderson:

  • Value trumps Flow – Expedite at the expense of flow to maximize value
  • Flow trumps Waste Elimination – Increase WIP (work in progress) if required to maintain flow even though it will add waste
  • Eliminate waste to improve efficiency – Do not pursue economy of scale

See also Al Shalloway on Lean thinking about waste in software development – it’s not about optimizing and reducing the use of “resources” (to quote a tweet by @drunkcod).

 

Slack is Unplanned Improvement Work

Full utilization cause delays - http://agileconsulting.blogspot.no/2011/07/explaining-why-limiting-wip-is-so.html
Full utilization is not effective, not efficient, and causes delays

Being busy all the time is bad for you, your team, and your organization.  It is far better to allow for slack, which is not a bad thing, but creates opportunities for improvement without needing to schedule them.

“Recipe” for what to work on next, incorporating slack:

  1. Can you help progress existing planned, started work?
    Work on that.
  2. Can’t do that?
    Find bottleneck and help work to release it.
  3. Can’t do that either?
    Do some (improvement) work which

    • won’t create any work downstream,
    • will improve future throughput, and
    • can be paused as soon as existing kanban related work is available.

A bit more reading related to slack.

Kanban – Core Concepts and Practices

Kanban Core Concepts

  • Visualize work: items, process/ flow, policies
  • Limit work-in-progress (WIP), but don’t be too ambitious at first

Basic Kanban is a lightweight framework for change management.
Starting with the core concepts on top of your present process should meet little resistance, at least when coupled with focus on improving quality.

Btw, I talked at a lokal meetup earlier this year (slides here), mostly on the core concepts – why they work and how to start.

A few Kanban Practices

  • Flow; encourage, cultivate, transform towards
  • Classes of Service (CoS); visualize and track different types of work, with different demands on them
  • Gradually limit WIP to improve flow and to uncover your next improvement opportunity
  • Cadence; regular rythm of things like backlog replenishment and deployment, separate from development
  • Metrics; to manage flow over time
  • Pull; instead of mostly work with deadlines
  • Slack, swarming – doing it consciously

There’s more, but this illustrates the relation between the core concepts and a set of recommended practices.

You’re likely to start with a simple version of some practices, f.ex. the work types (CoS) critical items, work with deadlines, bugs. More practices can be utilized as your organization matures, and more sofisticated use of practices, like setting different target lead times for different CoS, f.ex. 50% of bugs should be fixed within a week.

Update after “conversation” with @pawelbrodzinski:

Buy-in from management and whole organization is preferable, but team buy-in is enough and necessary, in my opinion.

I think it’s important to just get started, improving step by step, and team buy-in and the Core Concepts are enough to do that.

Kanban is Agile Jazz

XP2010 had a banquet including a jazz keynote by a couple of seasoned, Norwegian jazz musicians, Jon Pål Inderberg (sax, vocals, body percussion) and Bjørn Alterhaug (double bass). They performed for us, and talked about improvisation and things like structure, freedom, trust, etc. It was food for thought and a great experience.
I’ve seen other metaphors for software development, such as gardening, cleaning a kitchen, making a film, technical debt, construction, and martial arts. Last week I was inspired by the jazz keynote and by @agilemanager to think about musical performance as a metaphor.

XP2010 had a banquet including a jazz keynote by a couple of seasoned, Norwegian jazz musicians, Jon Pål Inderberg (sax, vocals, body percussion) and Bjørn Alterhaug (double bass). They performed for us, and talked about improvisation and things like structure, freedom, trust, etc.  It was food for thought and a great experience.

I’ve seen other metaphors for software development, such as gardening, cleaning a kitchen, making a film, technical debt, construction, and martial arts.  Last week I was inspired by the jazz keynote and by @agilemanager to think about musical performance as a metaphor.

twitter-challenge.pngPlan, Flexibility

What to play in a concert is decided in advance – for a classical concert well in advance, and in detail.  A jazz band, however, often finalizes the playlist just before the concert, even modifying the playlist as the concert goes on.

The plan for the performance of a single jazz tune is often subject to variation and “planned uncertainty”. For example, the band knows where an improvisation part starts, and knows on what cue to move to the next part, but they don’t know in advance what happens in between or how long the part is going to be.

twitter-agile-audience-s.pngThe adaptive nature of a jazz concert or a song enables an agile response to change. There is focus on flow towards delivering value to the customer (and each other), instead of doing a certain amount of ordered work. Circumstances can be taken into account, like the mood of the audience, interruptions, etc.

Errors, Learning

Mistakes will be made.
twitter-google-fail-fast-s.png
If you trust your fellow musicians and the structure permits it, you might even take greater risks, either gaining greater value or learning valuable lessons from failures.

From the jazz keynote: Embracing Errors as a Source of Learning

A successful jazz concert produces an amount of music that’s never been played before, while a successfull classical concert should vary only in subtle interpretation details. F.ex., it was unusual for Miles Davis to practice with his band; he wanted to hear something new in each concert, and said to them that they were being paid to rehearse on stage.

Whatever type of music, a good musician spends time learning her craft, both practicing by themself and doing music with others.

Collaboration, WIP Limits

Have you noticed that during a drum improvisation the rest of the band dials back, sometimes all the way back?  Some instruments playing less makes more room for others, there’s imitation and learning from each other, and there’s collaboration and conversation going on.

Sometimes a composer (of any kind of music) or a jazz performer impose restrictions in order to foster creativity.   Those limits can be rhythmical, tonal, or on any degree of freedom. (Cue “One Note Samba“…)  Such limits increase throughput of ideas, and give more room for important information that the composer or musician might want to accentuate.
twitter-kanban-jazz-time.png
Instead of everybody doing “their own thing”, a jazz musician can be quiet, listen, and then contribute to what the others are doing.  Slack, i.e., doing nothing and listening, makes room for others and opens you up for creativity.  You can be ready and agile, and then contribute where the song is going.

Kanban is Agile Jazz

Don’t get me wrong: I love lots of classical music, and I think there’s room for various agile tools in a software development toolbox.

However, jazz is one of the most adaptive styles – and kanban is one of the most adaptive tools, with focus on flow, WIP limits, starting with the existing process and continuously improving step by step.

Thumbnail image for twitter-scott-unique.png
twitter-aslak-improvise.png

twitter-answer.png

Lean: Development is not Manufacturing

The conclusions of lean manufacturing theories are not necessarily valid in the domain of (software) product development.

There’s good reasons why it’s so difficult to fix time, budget, and feature scope all at once in a software development project.

I’ve been listening to a talk by Don Reinertsen, and one of his points, although not the main point, is about variability:  if you could reduce variability in the workflow by 10%, or you could reduce capacity utilization by 10%, by far you would prefer to reduce capacity utilization.  That’s where the economic payoff is.

The reason is that increased capacity utilization increases queue size and lead time exponentially.  In other words, if you try to keep all your resources busy all the time, everything takes forever to finish.  This goes for both manufacturing and development.  Variability in workflow, however, is bad in manufacturing, but can’t be avoided in product development, and might even be exploited.

So what else is different about development compared to manufacturing?

Manufacturing Development
Tasks are…. repetitive non-repetitive
Tasks are… predictable unpredictable
Requirements are… a constraint a degree of freedom
Requirements are… fixed evolving
Cost of delay is… homogeneous non-homogeneous
Task durations are… homogeneous non-homogeneous
Variability is… always waste not always waste
Inventory is… physical objects information
Inventory is… visible invisible

Source:
A talk by Don Reinertsen,
Second Generation Lean Product Development: From Cargo Cult to Science