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.
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.
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


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

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

agile adoption fails in a “fixed project situation”

i saw an interesting article on infoq.com.

the term “fixed bid” is used in the article, but this article applies to another “fixed project situation“, too, i.e., where the resources are fixed, and there’s a specified, promised feature scope and a specified, promised delivery date. 

(btw, it isn’t really possible to control all of resources, delivery date, and scope and quality of features at the same time…)

In an agile software team you don’t estimate your work till right
before you begin. And you only estimate, in the case of Scrum, the next
iterations work. So how do you know how long it will take? You don’t.
Furthermore, you really don’t care.
You’ll continue to deliver
functionality every iteration. As soon as product management and QA say
you have a good enough product; it’ll be released as a production
version. You might have a guess, but until the team estimates it….you
really don’t know long it will take.

In a fixed bid situation….your estimation needs to take place up front.
In the 2nd scenario, if I told the team, … “we’re using Scrum”: they’d estimate the work
the next iteration. They would assume their estimates would be taken
seriously and you’d give them time to complete the work as it unfolds
regardless of whether their estimates fit your original project funding
or not. That’s only fair.

alternatively: they would assume they’d get the “time to complete the work with high quality regardless of whether their updated estimates fit your original project plan and delivery date or not”.

[this leads to failure]….at managing the project and therefore…….”this agile thing doesn’t work”.

The mistake was to assume the company’s leadership … was
organizationally committed to … agile principles. The mere fact
that they are asking you to estimate the funding you’ll need to
complete the project tells us otherwise.

alternatively: the fact that they are asking you to commit to a fixed feature set and a fixed delivery date tells us otherwise. 

this isn’t bad, per se, it just isn’t agile.

[the real problem]

  • Agile is often assumed … to be a development process with no impact on budgeting. This is not the case.
  • Development teams assume leadership understands the implications of adopting agile at the budgetary level.

Developers and development teams often have zero visibility into
budgeting so they are unaware of how their agile efforts are being
accounted for in monetary terms. …. Likewise, management is often ignorant of
development and specifically agile development practices. Agile
adoption requires education to ease the clash and misunderstanding of
these two worlds.

So what are some of the consequences of attempting to adopt agile
practices on a fixed bid project
…essentially laying an agile façade
over the waterfall project

Agile does away with the need for a project manager. …. organizing and managing the development effort are more centered on
technical leadership, task and risk management. Timelines and budgets
go out the door.
if you’re in a non-agile situation … then traditional PM practices are … essential

Doing iteration planning in a fixed bid situation will almost certainly
result in confusion, budget variances, and/or loss of functionality.


In fixed bid scenarios the question is not … how much
functionality the team is doing per time period
. It really doesn’t
matter. They need to get all the functionality done

So using … iterations in a fixed bid project sends the wrong signal to the team and your customers.

using iterations in a fixed project situation sends the wrong signal to the team.

you can still visualize workflow, f.ex. with kanban, reduce work in process, do stand up meetings (very short, impediments only), etc.

but in general you should try to get out of a fixed project situation before trying to go agile.

Edit: About that last part… I think there’s a few basic, agile tools you can utilize whatever you’re doing: visualize how you work; get faster feedback; limit the amount of work in progress.

interrupted by an email?

or rather, do you let yourself be interrupted?

then it takes time to get back to what you were doing, and then more time to get back in the flow.

The October issue of Real Simple magazine quotes a Microsoft and University of Illinois at Urbana-Champaign study that claims it takes 17 minutes “for a worker interrupted by e-mail to get back to what she was doing.”

Unclutterer: Recovering from an email interruption

what is quality?

good quality is difficult to quantify, and what is good enough is fluid. it is often easier to point out lack of quality than to specify good quality.

quality is relative

when you think about what is good or bad about a product, criteria may come to mind which are not easy to quantify.  f.ex. “feels good”, “it works”, “good value”, “i just like it”, “luxurious”…

price can lead you to buy one product and not another, even if they otherwise seem to be of equal quality.

your needs and wants change over time.

different situations influence what price is a good price, or what you get from a purchase.

different people have different values and backgrounds, leading to different choices.

however, someone is deciding on quality – you buy something or not, you get to sell something or not…

so maybe the question should be: who decides quality?

the stakeholders decide

some people are more invested in a product, and it’s not only customers, but really anyone who’s affected by or is affecting a product.

customers are necessary for the existence of a product in the commercial market, but it is not sufficient for a product to only meet the customers’ needs.  others must also be satisfied, such as stockholders, employees, and governments.  in the government sector a paying customer might not even be necessary.

who are the stakeholders, anyway?

those affected by or affecting a product, i.e., stakeholders, include:

  • customers – decide to buy or not
  • partners – add value
  • employees – add skill, expect f.ex. meaningful work
  • owners – add capital, expect increased value
  • governments
  • analysts like Gartner, Forrester

sometimes there’s conflicting expectations due to the fact that stakeholders don’t all want the same things… which makes it more difficult to figure out what good quality is.

ISO on quality

you might have an impression of ISO as a bit too formal, but in this case i think they’re onto something.

the ISO 9000 family (the 200x versions) describes quality as the ability to satisfy requirements; from the stakeholders, explicitly expressed, or just implied.

so what is good quality?

it’s about product and process – both what we make and how we make it.

it’s about compromise – conflicting needs means not every stakeholder get everything they want.  if reaching a deadline to make a customer happy means working a lot of overtime making employees unhappy, it might be worse quality all in all than missing the deadline.

it’s about all of the stakeholders. yes, it might be easy to focus a lot on the customer, but you need to keep all the stakeholders happy – or at least happy enough.  e.g., your bank needs to trust that you can pay back a loan, and the government expects you to file your taxes.

it’s about expectations.  a customer might expect certain functionality which is normal among competing products, and get unhappy if it’s not there, but might not think to include it in the requirements in the first place.  even if you’re not a mind reader, this is part of the quality of the product.

it’s not just a point in time – f.ex how the technical quality of software over time sustains (or not) stakeholders’ needs and expectations over time.

you need to recalibrate your understanding of stakeholders from time to time, since time and changing circumstances make stakeholders’ expectations change – and thus change what is good quality.  e.g., owners of a company probably expect more profit after a few years than in the very beginning of the company.

to sum it up: as you can see, in my opinion quality is relative, and is defined by what stakeholders need and expect.

software projects: have your cake and eat it?

would you like to have your cake and eat it, too?

in my opinion you actually can’t; you’re not able to make absolutely sure that a project is on budget (resources), on time (delivery date), and have all the planned features with high quality, all at the same time.  there’s always a risk, and you can only control any 2 out of the 3 factors at the most. If you try to control all 3 factors at once you are most likely sacrificing the quality of the features, and thus you’re not in control over the features anyway.

Scott W. Ambler makes a few interesting points in this article about software development projects – i’ve selected the quotes that’s most interesting (to me) below.

  • “the only true measure of progress on a software development project is the delivery of working software. “
  • “Agile teams choose to produce potentially-shippable software at the end of each iteration, providing concrete and visible feedback to their stakeholders as to their actual progress. “
  • “… the majority of stakeholders prefer this sort of tangible evidence of progress instead of intangible numbers. “
  • “… the majority of our stakeholders aren’t really interested in whether we’re on schedule or on budget.”

“…. In August 2007, Dr. Dobb’s ran a survey exploring how people define IT project success, and we found that 80 percent of people preferred to focus on producing a good return on investment (ROI) than being under budget, and that 62 percent wanted teams to ship their systems when they’re ready to be shipped rather than forcing adherence to a schedule. ”

  • “… the priorities are to spend the money wisely and ship quality systems. “
  • “… shipping high quality software is more important than being on time and on budget”
  • “… instead of measuring progress against your plan, … you should instead be focusing on ensuring ROI and product quality. “

“The agile practices of implementing requirements in priority order and allowing requirements to evolve throughout the lifecycle ensure greater ROI, and agile practices such as test-driven development (TDD) and refactoring promote greater quality.”