Lean Bag Packing at Agile2011

Once again, I helped out with the volunteer bag packing at the Agile2011 conference, and as usual we had great fun and broke records. This year we completed 1600 bags in just under 4 hours packing time, with an hour preparation/breakfast and an hour for lunch.  Christopher Avery took some video footage and interviews, which I hope to be able to link to here soon.

For the retrospective, run by Eric Willeke, we asked participants for things that they had learned which were relevant to software development. Here’s the list:

  • Focus on quality
  • Communication is essential
  • Let go
  • People and process
  • Experience is useful
  • Being prepared
  • Its important to know why
  • Improve through collaboration
  • Practice makes perfect
  • People are responsible
  • Ask & listen – don’t assume
  • Redistribute work
  • Power of whole team
  • Lots of communication
  • Simple visual metrics
  • Integration is hard
  • Don’t be attached to your process
  • Knowing good enough
  • Allowing for variance
  • Be engaged
  • Do it – inspect and adapt
  • Variety is motivating
  • Understanding impact of change
  • Change is disruptive
  • Shut up!
  • Dress appropriately
  • Common purpose
  • Relentless improvement
  • Communication without words
  • Reacting to reality
  • Be lean – JIT happens
  • Building relationships
  • Rhythm is fun
  • Visualising progress
  • Visualising WIP
  • Adaptability in context
  • People – not resources
  • Cross functional to eliminate bottlenecks
  • Single point of failure
  • Self organising team
  • Focus on the work
  • Good communication
  • People self-organising

Update: Eric has written his own post of the experience

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Crystallising Kanban with Properties, Strategies and Techniques

On the flight out to the Kanban Leadership retreat in Iceland last month, Katherine Kirk and I were chatting about Kanban failure modes that we’ve seen out in the field (e.g. quirky command and control interpretations by people who had not had experience in Agile first), and played with the idea of combining Kanban with Crystal (kind of in the same way that ScrumBan combines Kanban with Scrum). We jokingly referred to this as CrystalBan.

The reasoning behind our discussion was that Crystal and Kanban are both adaptable, context driven approaches. Crystal concentrates a lot on working with the ‘human’ side of the methodology equation – highlighting good, tried and tested Agile properties, strategies, and techniques – and Kanban is focussed on incremental improvement at a pace which respects people’s ability to absorb change. We discussed how, as an Agile/Lean community, we sometimes take it as given that Kanban for software and systems was pioneered by people from the Agile world, and therefore we often don’t explicitly state what to use from Agile to get the best out of Kanban. Maybe we should?

It was a fairly light-hearted conversation, so we didn’t pursue it in Reykjavik, but the idea didn’t die either as both of us kept coming back to it. We held an Open Space session at the UK Agile Coaches Gathering a few weeks ago which didn’t produce anything really concrete, but did get some murmurs of interest, so Katherine and I sat down this week to thrash it out.

Why Bother?

Kanban failure modes was a topic twice covered in sessions in the Kanban Leadership Retreat and, interestingly, difficulties with ‘humans interacting with humans’ were pinpointed as one of the common causes of Kanban failure modes. Crystal’s main properties, strategies and techniques deal a lot with the people side of the equation from the Agile perspective…. which opens up the idea that it might be a nice possible blend with Kanban.

So, are they compatible? Can they work together?

In his book Crystal Clear,Alistair Cockburn describes Crystal as “a family of methodologies with a common genetic code, one that emphasises frequent delivery, close communication and reflective improvement…” and he points out that, as it is context driven, that “…there is no one Crystal methodology”. As a result he admits that some groups can “have trouble with Crystal because it is too empty to start with.”

In his book Kanban, David Anderson describe Kanban as “an approach that drives change by optimizing your existing process”.  This makes Kanban relatively easy to start with because the “essence of starting with Kanban is to change as little as possible”.

Given that Crystal gives guidance on what a successful process will look like, based on a strong Agile foundation, and that Kanban gives guidance on how to improve an existing process, drawing from Lean, it seems that they are a natural fit to realise the benefits of both while avoiding the risks. A win-win.

Crystal Properties

Crystal describes seven properties of a successful project, the first three of which are core:

  • Frequent Delivery – e.g. “the single most important property of any project, large or small, agile or not, is that of delivering running, tested code to real users every few months”.
  • Reflective Improvement – e.g. “a project can reverse its fortunes from catastrophic failure to success if the team will get together, list what both is and isn’t working, discuss what might work better and make those changes in the next iteration”.
  • Close Communication – e.g. “information flows into the background hearing of member of the team, so that they pick up relevant information as though by osmosis”. (Referring specifically to Osmotic Communication in Crystal Clear)
  • Personal Safety – e.g. “being able to speak when something is bothering you, without fear of reprisal”.
  • Focus – e.g. “first knowing what to work on, and then having time and peace of mind to work on it”.
  • Easy Access to Expert Users – e.g. providing the team with “a place to deploy and test the frequent deliveries”, “rapid feedback on the quality of their finished product”, “rapid feedback on their design decisions”, and “up-to-date requirements”.
  • Technical Environment with Automated Tests, Configuration Management, and Frequent Integration – “such well established core elements that it is embarrassing to have to mention them at all”.

In order to achieve these properties, different strategies and techniques can be employed. This is where we see that Kanban comes into play.

Kanban Strategies and Techniques

One source of Kanban strategies is David Anderson’s Recipe for Success:

  • Focus on Quality
  • Reduce Work In Progress
  • Deliver Often
  • Balance Demand against Throughput
  • Prioritise
  • Attack Sources of Variability to Improve Predictability

What David calls “five core properties to create an emergent set of Lean behaviours” could also be thought of as techniques in Crystal ‘dialect’. David’s five core properties are:

  • Visualise Workflow
  • Limit Work-In-Progress
  • Measure and Manage Flow
  • Make Process Policies Explicit
  • Use Models to Recognise Improvement Opportunities

I have a different model I use which maps onto strategies and techniques. The strategies are:

  • Study the System
  • Envisage the System
  • Limit the System
  • Sense the System
  • Learn about the System

with the associated techniques:

  • Value Stream Mapping
  • Visual Management Board
  • Work In Progress Limits
  • Cadence and Measures
  • Quantitative Experiments

So What?

Katherine and I both observed that the Kanban strategies and techniques do achieve the top three Crystal properties of Frequent Delivery, Reflective Improvement and Close Communication, as well as help towards some of the others. However, because Kanban for software and systems in the most part has its origins in the Agile world, perhaps its time, as a community, to start to examine whether we should be a bit more explicit about all the good Agile resources that already exists – as Kanban starts to expand further into ‘non Agile’ territory.

People new to Kanban, and without Agile experience and knowledge, may easily miss the benefits from some of the other properties, as listed in Crystal Clear, which have been tried and tested by the Agile community for many years. In the same way that Alistair made the Technical Environment property explicit, despite it being so well established, we shouldn’t forget all the existing established strategies and techniques which can enable the other properties.

Further, this approach helps us understand how other strategies and techniques from outside of Agile can help towards successful implementations. For example the work of Chris Argyris, as promoted by Benjamin Mitchell, can help towards Personal Safety.

 


 

I’d like to thank Katherine for her time, energy and passion in helping form this and collaborate on writing it up.

 

VN:F [1.9.22_1171]
Rating: 5.0/5 (6 votes cast)

Presenting at Agile2011

I’ll be at Agile2011 again this year presenting a couple of sessions. Here are the details if you’d like to come along and take part.

Flow Games

Designing a Kanban System for the Enterprise

Note that while the program page for “Flow Games” suggests that we will play a selection of games, the final time constraint of 1 hour means that Eric and I will probably only be able to play one game, which will be the Ball Flow Game. Fortunately, there is another similar session (Lean Fundamentals with Michael Sahota) which will run the other games we had in mind, so we encourage you to go along to that if you want more!

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)

Running the Ball Flow Game

I previously wrote about the Ball Flow Game I ran at the Scrum Gathering in Amsterdam. I’ve updated the game quite a bit since then and its stabilised into something I’m finding very useful when I work with Kanban teams to help them understand some of the concepts behind Kanban Thinking. I hope this write-up enables others to use and run the game.

To recap, the Ball Flow Game is based on the Ball Point Game, with the following rules:

  • Participants play as a whole team
  • Balls must have air time between people
  • No passing to a direct neighbour
  • The start person must be the end person

The aim is to complete 20 balls (as opposed to complete as many in 2 minutes). Thanks to Rally colleague Eric Willeke I now add some fun context as well. I tell the team that they are producing magic balls. Magic is added to a ball only when everyone has touched it. If two people touch a ball at the same time, the magic is dispersed. Further, magnetic fields mean that passing a ball to a direct neighbour also stops magic being added. The start/end person is the customer wanting magic to be added to the balls. Its silly, but it adds an extra element of fun, and reinforces that the rules are constraints in the context that can’t be changed.

I use a spreadsheet to help automatically capture data about the performance of the team. (Download the template). It works using four macros, which are assigned to buttons and hot-keys:

  • Begin (Ctl-B). Begins a round by starting a timer.
  • In (Ctl-I). Captures the time a ball is added into the system.
  • Out (Ctl-O). Captures the time a ball come out of the system.
  • End (Ctl-E). Ends a round by calculating the metrics.

Once the metrics are calculated, three charts on the worksheet will populate themselves.

  • Lead Time. The time each ball took to work its way through the team (assuming balls enter and exit in the same order). The dotted line is the average.
  • Throughput. The number of balls the team completes every 10 seconds
  • Cumulative Flow Diagram. The number of balls either not started, in progress or done every 10 seconds

Upper and Lower Control Limits can also be calculated and displayed for Lead Time. They are currently commented out in the macro code because I found that they weren’t necessary for the core learning objectives. You may also need to tweak some of the macro functions for different versions of Excel (I use Windows Excel 2010). The template has worksheets for 5 rounds. For additional sheets, simply one of the existing rounds.

One of the things I’ve noticed is how the dynamics of the conversations are different from when I run the traditional Ball Point Game with teams. In particular, the team I was working with today really understood the idea of scientific management and made very small, quick and focussed changes each round as experiments, hypothesising on how the metrics would change. With the Ball Point Game I find teams want to debate in depth all the options in their attempts to get an improvement.

Note that as I said in a post of Balanced Software Development, “scientific management is still relevant for knowledge work, when the workers are the scientists.”

Here are the results. (Apparently we started with only 19 balls due to a facilitator error!)

Round 1

In this round, the customer ‘pushed’ balls into the system when he could. You can see the lead time increase as the WIP increases in the CFD, up to a point when a natural system limit is reached. Towards the end the customer stops adding more balls to let the system flush itself out a bit, which shows as the step in the CFD at about 60 seconds, the drop in lead time, and the spike in throughput. The final two balls went through when the system was virtually empty. Notice the short lead times again!

image

Round 2

In this round the team decided to limit the WIP to 6 – one per person. However, interestingly (to me at least) they decided to batch them, by getting all 6 through before they started the next 6. Lead time is much more stable this time. The spike is because the customer forgot to receive the last ball of the 1st batch before starting the 2nd batch, so it got stuck! Throughput is wildly variable though because nothing comes out for a while, and then all 6 come at once. You can see the batching in the ‘steps’ in the CFD.

image

Round 3

In this round the team wanted to experiment with an low extreme WIP limit of 1. Lead time is significantly better, but throughput is low because there is too much slack in the system now. Notice the smooth flow in the CDF. The patches where WIP drops to zero are because the customer’s process between receiving a ball out, and adding a ball in, added a noticeable delay.

image

Round 4

In this round the team increased the limit to 3, but continued to process those 3 in batches. Lead time remains the same, but with improved throughput. The CFD still shows signs of the batching with the customer delay between batches, but is much steeper due to the improved throughput.

image

Round 5

Finally, the team decided to remove the batches and solve the customer’s delay issue by re-organising themselves. This time the customer added 3 balls into the system, and then only added another when one came out. Lead time is slightly increased, probably due to the fact that there were always 3 balls in process which added some complexity. Throughput is improved again though, and the CFD is looking very smooth.

image

As you can see, the team made significant improvements over the five rounds by making small changes informed by the data they had about their flow and capability.

VN:F [1.9.22_1171]
Rating: 3.3/5 (10 votes cast)

Kanban and Quad Biking

I’ve recently been using a newer language to describe the model I apply when introducing Kanban to teams, which has been generally working well. I now talk about:

  • Studying – understanding the current system structure
  • Envisioning – creating a common mental model of the system
  • Limiting – bringing the system under control
  • Sensing – having an awareness of the system’s performance
  • Learning – improving the system’s capability

imageAt the Kanban Leadership Retreat in Reykjavik this week, I talked about sensing and was teased by Daniel Vacanti about how fluffy it sounded. (To be fair, I was giving as good as I got). Later that evening in the bar, I was chatting with Katherine Kirk, and I realised why it sounds fluffy. It’s because sensing is not just about the mechanics of measuring the process the capability of a system. Its also about the human aspects of a system, which are too easily forgotten. So for now I’m going to stick with it.

And that brings me to quad biking.

The day after the Leadership Retreat, a small group of us went quad biking over the Icelandic landscape. Its an amazing way to see the country and highly recommended. While I was driving over the rocky ground, I realised it was a great metaphor for sensing.

To begin with, it takes a bit of time to get used to driving the bike. More control is needed while learning the basics. When driving at speeds up to 70kph, however, you’re never actually in full control. The more firmly you try to gain control, the more likely you are to lose control. I soon realised that by gripping and steering too tightly, I was getting thrown about too much when I hit a large hole or rock. By holding more loosely, relaxing, leaning back and going with the flow, I could sense how the bike was behaving and move accordingly. By doing so, I learned that when going round tight corners, pushing the steering to force the bike round was hard work and ineffective, but leaning back and pulling the steering was a lot easier and more effective.

This is why I like sensing as a word to describe the way I work with kanban systems. While establishing a cadence and measuring are key ways that we can understand capability, sensing describes a more instinctive awareness of how a kanban system is performing, and conveys the way teams are able to adapt, anticipate and experiment as they explore the limits of the system.

Katherine Kirk has also taught me about equanimity, “a state of mental or emotional stability or composure arising from a deep awareness and acceptance of the present moment.” Sensing a kanban system involves having equanimity when  dancing with the system.

VN:F [1.9.22_1171]
Rating: 4.6/5 (5 votes cast)

The LeanSSC European Conference Series 2011

This year the LeanSSC are running a series of conferences which have been created to give local audiences more convenient access to similar and related content without the need to travel extensively. While each event will have its own unique flavour and presenters, the similarity in timing allows for some overlap, and we are encouraging people to choose the event most convenient for them. The LeanSSC is not differentiating between the events in priority or preference and does not view one as superior to another.

Here are the details of the conferences. If you are in Europe, or fancy a trip, please consider submitting or registering. I hope to see you there.

Lean & Kanban 2011 Benelux

Call for Papers

  • Closed

Speakers

  • Including Don Reinersten, David Anderson, Alan Shalloway, John Seddon, Dave Snowden, Michael Kennedy

Registration

Prices exclusive of VAT

  • 2 Day Conference Pass: 700 Eur until Aug 15 (then 800 Eur)
  • 2 Day Conference Pass + Dinner: 750 Eur until Aug 15 (then 850 Eur)
  • 2 Day Conference Pass + Dinner + Hotel (3 nights): 1150 Eur (then 1250 Eur)

Lean & Kanban 2011 Central Europe

Call for Papers

  • Currently open. Closes June 28th.

Speakers

  • Including David Anderson, Kent Beck, Jim Benson, David Joyce and John Seddon

Registration

Prices exclusive of VAT

Individuals:

  • One day, Regular 520 EUR until Aug 17 (then 580 EUR)
  • Both days, Regular 985 EUR until Aug 17 (then 1095 EUR)

Two or more colleagues from the same company:

  • One day, Regular 465 EUR until Aug 17 (then 520 EUR)
  • Both days, Regular 885 EUR until Aug 17 (then 985 EUR)

LESS2011

Call for Papers

  • Currently open. Closes July 18th.

Tracks

  • Lean & Agile Product Development, Complexity & Systems Thinking, Beyond Budgeting, Transforming Organisations

Keynotes

  • Peter Middleton, Jim Sutton, Steve Denning, Bjarte Bogsnes

Tutorials

  • Alan Shalloway, Jean Tabaka, Benjamin Mitchell

Registration

Prices exclusive of VAT

  • Early registration EUR 595 until July 31
  • Regular registration EUR 695 until October 29
  • On-site registration EUR 795
VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Kanban and Tragedy of the Commons

After Limits to Success and Shifting the Burden, we now come to Tragedy of the Commons.

I live in the seaside town of Brighton in the UK. On the rare weekends when we have hot weather it is popular to go down to the beach. Everyone gets in their cars and drives into Brighton expecting a quiet, relaxing day on the coast. What they actually get is a noisy, crowded area full of lots of other people who have had the same idea. This is an example of the “Tragedy of the Commons” archetype. The beach (and the roads to it), are the commons – a shared resource. Individually, each person expects to gain some pleasure from the beach. However, when too many people visit, nobody gets any pleasure from the beach, because it has limited capacity and quickly becomes over-crowded.

clip_image002

Individually, A and B’s activity give themselves separate net gains so that they each benefit through a reinforcing loop. However, their activities combine to create a total activity which, after some delay, eventually consumes a common resource beyond its limit. At that point, A and B’s activity begins to reduce those separate net gains through a balancing loop.

The “Tragedy of the Commons” archetype often manifests itself through “Shared Services”, when a small number of people with specific skills, work across different teams. Each team in isolation gets benefit from the Shared Service, but when demand for the service exceeds its capacity, then nobody benefits. At a smaller scale, a team with a low “bus factor”, or a hero, can also suffer from a tragedy of the commons, when too much work is dependent on a single person.

Often, a Tragedy of the Commons occurs as a result of Shifting the Burden to the commons. By setting up the system to deal with the Shifting of the Burden, the likelihood of the Tragedy of the Commons can be reduced.

Similarly, the commons becoming overloaded is a specific case of Limits to Success, and setting explicit limits for the commons will avoid this. Further, creating a buffer before the commons will ensure that there is always work when the capacity is available. In Theory of Constraints terms, this is exploiting the constraint.

image

A kanban system also helps with a Tragedy of the Commons by helping visualize the total activity, so that everyone is aware of the demand on the limited resource. Further, each party can limit their own activity to avoid the total activity becoming too great. Swim-lanes are one approach to visualising this.

image

Finally, Classes of Service can then ensure that the limited resource is being used effectively for the most appropriate work. Swim-lanes, or colour-coding, can create clarity of which work is more important, based on its Cost of Delay. This clarity can also help keep an appropriate balance of different types of work in order to manage the risk of the commons unnecessarily delaying urgent work.

image

What other examples of Tragedy of the Commons have you experienced, and what other techniques have you used to visualise them?

VN:F [1.9.22_1171]
Rating: 3.4/5 (5 votes cast)

Kanban and Shifting the Burden

Following on from a look at the Limits to Success system archetype, lets now look at the Shifting the Burden archetype.

I like my coffee in the morning. In fact I usually need a good cup of coffee before I start to feel human. Some days I like a coffee to start the afternoon as well, and occasionally I’ll have a few more in-between to keep me going. This is an example of ‘Shifting the Burden’ archetype. I feel low, so drink coffee to pick me up. However this is just a short term fix and I eventually need more caffeine to maintain my energy. The real problem is why I have low energy; late nights, a poor diet and little exercise. Rather than getting more sleep, eating a healthier diet, and exercising, I am shifting the burden to the caffeine. If I were to shift the burden to a stronger (and less legal) drug, then it is likely that my need for the drug itself would become the problem, rather than my lack of energy. At this point, the archetype has moved from Shifting the Burden to Addiction.

clip_image002

Shifting The Burden begins with a Problem Symptom. The quick or easy answer to this problem is the Symptomatic Solution which creates a balancing loop. However, there is also another answer – the Fundamental Solution – which can create an alternative balancing loop. The Symptomatic Solution only eases the symptom though, and doesn’t resolve the underlying problem, so the symptom consistently returns. The Fundamental Solution does address the root cause, but has a delay though, which means that it is more of a long term answer than a quick fix. The more the Symptomatic Solution is applied, the more a Side Effect takes place, which over time with delays reinforces the need for the Fundamental Solution, while at the same time making it less feasible. When the Side Effect becomes more of a problem than the initial Problem Symptom, is when the Shifting the Burden archetype becomes one of Addiction.

clip_image002[4]

Recognizing the archetype leads us to examine our solutions to problems and to question whether they are Symptomatic or Fundamental. When problems re-occur over time, then using Root Cause Analysis techniques may lead to finding alternative Fundamental Solutions. Continually depending on technical specialists or coaches may be a Symptomatic Solution, whereas investing in training on knowledge sharing may be a better Fundamental Solution. As the well-known Chines proverb says, “give a man a fish and he will eat for a day, teach him how to fish and he will eat for a lifetime”

A Kanban System can help cope with Shifting the Burden, once a problem symptom has been identified, in the following ways:

  • Signalling occurrences of the identified problem symptoms so that they are transparent and appropriate focus can be made on the fundamental rather than symptomatic solution. A brightly coloured tag or shape can achieve this.

image

  • Visualizing what problems symptoms are being addressed by various symptomatic or fundamental solutions. The Concern, Containment, Countermeasure pattern can be useful here where problem symptom is defined and stated as a Concern. The Containment action is the symptomatic solution taken to resolve the problem quickly. Then, after root cause analysis, the Countermeasure action is the fundamental solution to prevent repeated recurrence. (Thanks to Jason Yip for pointing me to this pattern)

image

  • Allocating capacity and limiting work in process for work related to fundamental solutions using a dedicated swim-lane and WIP limits. This treats the improvement efforts as first class work types, with equal visibility to the rest of the work.

image

What other examples of Shifting the Burden have you experienced, and what other techniques have you used to visualise them?

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)

Starting An Agile Transition With Why

In March this year I gave this keynote at the Rally Agile Success Tour in London. This is a video of the talk, followed by a write-up. The slides can be downloaded from here.

People don’t buy WHAT you do, they buy WHY you do it. Simon Sinek says that this is the fundamental reasoning behind what he refers to as the Golden Circle, which he describes as a natural law occurring in many forms, in the same way as the Golden Ratio. He cites example of the Golden Circle including Martin Luther King, who said “I have a dream” not “I have a plan” and the Wright brothers, who succeeded first with manned flight despite having less money, education, connections and publicity as competitors. The Golden Circle suggests that we should start with WHY, before determining HOW, and finally WHAT, rather than starting with WHAT.

image

Starting an Agile transformation with WHY involves knowing why you want to use an Agile approach, and the goals you are aiming for, rather than becoming Agile just because it seems popular or a good idea. Therefore, begin by defining your WHY, deciding where you want to go and creating a vision of the future that you hope Agile will help create. Then Agile will be a means to an end, rather than an end in itself. Your WHY is your destination, and Agile can help with HOW you get there, and guide WHAT you do to get there.

WHY

A WHY is what motivates people to take action. It is a purpose, a cause or a belief. It is a reason to care and want to get out of bed in the morning. A WHY is not to make money. Money is a necessary precondition for business, in the same way that breathing is a necessary precondition to living although our purpose in life is not to breathe. Making money may also be a desirable result, but it is not a WHY.

WHY is the equivalent of the System Thinking premise of purpose. Complex Systems have a purpose which influences behaviour, the product of the system’s elements and interactions. Dave Snowden uses the Magic Roundabout in Swindon as an example of a complex system whose purpose is to enable a high throughput of cars with a low accident rate. Reports show that it achieves this purpose, despite also being generally regarded as one of the scariest roundabouts in existence. By starting with WHY, the roundabouts designers created an effective, safe and resilient WHAT. Starting with WHAT leads to the less scary but more common design.

image

WHY is always going to be context specific, but one simple generalisation would be that it is to satisfy customer demand. Demand analysis can help understanding of what work adds value, and helps us towards our WHY, and what work doesn’t add value. John Seddon describes failure demand is work that results from not doing something right, or not doing something at all. That is not to suggest that we should strive for perfection and be right first time with up front analysis and design. Value can still be added in small, incremental and iterative steps. Think of it like a ticket machine at your local deli. When a customer first takes a ticket then the request can be considered value demand. Subsequent tickets for the exactly same request can be considered failure demand. However, further tickets could be for similar, related requests because the customer comes back for more of the same, as opposed to exactly the same.

Simon Sinek argues that our brain is wired to start with WHY. Our first brain, the Limbic System is what deals with emotions, unconscious thought, instinct, and governs our behaviour. Our thinking brain, the Cerebral Cortex, is what deals with rationality, conscious thought, intellect, and governs our language. Thus, our natural behaviour is to make decisions emotionally, unconsciously, and instinctively. We then justify those decisions rationally, consciously and intellectually with facts. I have just bought a new car (well, new for me) and spent a not insignificant amount of money in a totally impulsive purchase. I had no intention of buying a car when I entered the garage, but fell in love with the car and ended up talking myself into deciding it was an opportunity I would regret if I missed it. Similarly, both times I have bought a house, which is both an important decision and major investment, the decision was because the house “felt right”. The size, condition, location, price etc. came second.

How

HOW describes the way that a WHY will be realised. It can be thought of as a set of guiding principles that help map a WHY to a WHAT. A HOW can also be a specific outcome that is to be accomplished without detailing the activity and output required to complete it. Additionally, HOWs are often ways of differentiating approaches and describing them in comparison to competitors.

One way of describing HOW an Agile approach enables a WHY is with the metaphor of a Recipe for Success. David Anderson popularised this idea with the following recipe:

  • Focus on Quality
  • Reduce WIP
  • Balance Capacity against Demand
  • Prioritise

Similarly, my colleague Ken Clyne at Rally talks about the fundamentals of Agile as:

  • Focus on customer value
  • Deliver early and often
  • Reduce batch size
  • Pull quality forward
  • Inspect and adapt
  • Create a collaborative culture

These recipes are a guide to HOW to achieve Agility in order to achieve a WHY. However, they are not specific enough to describe WHAT to do.

A common explanation for WHY organisations want to become Agile is “Better, Faster, Cheaper”. These are at best HOWs, and not WHYs. In fact, I would suggest that cheaper isn’t even a HOW. To paraphrase John Seddon, focussing on cost will usually result in cost going up.

Another approach to describing HOW to become Agile is through a transformation strategy or roadmap. Options for which path to take include beginning slowly with a single, fully Agile pilot project from which to learn, diving in and moving all project to an Agile approach in one go for clarity of message, only beginning new projects or initiatives as Agile to avoid risking current work, or incrementally solve specific challenges with certain practices for a more evolutionary transition.

Working Agreements can also be considered as a description of HOW. Explicit policies for how work is done can be created by recognising how value is created, how that creation is visualised and made transparent, how the work in process is limited, what cadences are used for synchronisation and co-ordination, and how continuous learning and improvement happens.

My personal take on HOW to be Agile is in terms of flow, value, capability. Achieving flow involves eliminating delays and focussing on reducing the lead time from concept to consumption. Delivering value involves making sure that the right things are being worked on and the right problems are being solved rather than “doing the wrong things righter”. Building capability involves developing people and their skills working as teams aligned to the organisation strategy.

What

WHAT is done proves that a WHY really is believed. It consists of tangible ways with which a WHY is realised and provides clear data points that actions are according to a WHY.

Agile practices are WHAT teams do in order to enable them to realise their WHY. Further, practices can be associated with HOW agility is demonstrated, in terms of flow, value and capability. The following is one interpretation of some practices. I’m sure there are many others.

Flow

User Stories are a technique to break down functionality into small pieces of demonstrable functionality which can create single piece flow. Time-boxing and kanban-style limits are both ways of managing WIP and enabling a focus on finishing rather than starting to keep work flowing. Visualisation approaches help teams see all the work so that they can focus their energy in the right places to keep flow. Strong teamwork and collaboration minimises the need for queues and batches which cause delays. Test Driven Development, with its emphasis on automated unit testing and refactoring, keeps designs clean and quality high so that new work can progress quickly. Continuous integration and deployment help works flow right through to the customer without lengthy release processes causing delays.

Value

Product Backlogs, User Stories, Minimal Marketable Features and other value-focussed forms of requirements are intended to help teams ensure they are delivering maximum benefit. Similarly, the On-Site Customer, or Product Owner roles are intended to maximise collaboration with people who are determining and receiving the value. Iteration demos and reviews are a means of gaining early and continuous feedback and validation that the product is delivering the intended value. Frequent and continuous delivery means that the value can be realised as soon as possible. Acceptance Test Driven Development and Behaviour Driven Development provide techniques for delivering value through quality and clarity of functionality.

Capability

Dedicated, cross-functional, value focussed teams mean that learning and knowledge is kept, shared and built upon to develop capability. Various collaborative practices, such as Pair Programming, Collective Code Ownership, Group Design, Team Estimation and Planning Poker similarly share knowledge around a team. Regular demos and reviews provide a cadence with which feedback and learning can build product capability, while regular retrospectives provide a cadence with which feedback and learning can build team capability. Visualisation of work, and the way value is created, gives visibility of bottlenecks and constraints and other issues such that they can be resolved to improve capability. Slack ensures that teams have spare capacity to both address these issues, and spend time on other forms of capability development which will improve future productivity and performance.

Conclusion

When embarking on a change initiative using Agile approaches, always “Start with WHY”. Use the WHY as a True North with which to guide the Agile transformation and steer decisions on which Agile practices to use for what reasons. Understand HOW agility is going to help progress towards the WHY, and WHAT Agile practices will provide the means to get there.

A clear WHY, that people are motivated by, will make it more likely that they will want to use Agile. However, Thomas Edison said that “vision without execution is hallucination”, so don’t stop with WHY, but make sure that the Agile HOW is also well known and the Agile practices that form the WHAT are clearly understood to ensure that the goal is successfully reached.

VN:F [1.9.22_1171]
Rating: 5.0/5 (2 votes cast)

Agile Israel and LSSC11 Conferences

Some info about a couple of conferences coming up I’m particularly looking forward to. At both, I’m going to be talking about Visualising System Archetypes, which will build upon my recent posts about Systems Thinking and Systems Archetypes to explore how visualisation patterns can show, understand and deal with different patterns of system behaviour. Here’s the abstract:

Many organisational challenges are a result of systemic issues, where cause and effect are not directly connected, but are separated by time and involve feedback loops and delays. Given that Kanban is a method for designing a software and systems development system, and systems thinking includes the idea of system archetypes which describe common patterns of behaviour, we can use system archetypes to guide our visualisations and help us identify opportunities for improvement. This session will introduce how to understand system archetypes, describe a number of common and relevant archetypes, and discuss patterns which can visualise and thus help break those archetypes.

Agile Israel

As the adoption of Agile concepts becomes more and more mainstream, it’s time to climb to the next level!

Agile Israel 2011 is your chance to hear about next level ideas and practices such as Agile Testing, Kanban, Lean Product Management, Agile Project Management, Scaling Agile into the Enterprise level, Metrics and Dashboards, and more, and to meet practitioners from the Israeli Agile community and learn from experience reports and experts.

Agile Israel 2011 is the 4th annual Agile event in Israel, starting at 2008, and as always will include the presence of prominent speakers alongside experts from Israel and case studies from Israeli companies (view photos and lectures from Agile Israel 2010).

This year Henrik Kniberg will be the keynote speaker. Among the other international lecturers and guests will be Jurgen Appelo, Hillel Glazer, and the ScrumAlliance MD Donna Farmer.

The event will take place on April 11th 2011 and Avenue congress centre near Tel Aviv.

Register today http://agileisrael2011-ral.eventbrite.com. An early bird of 20% is currently available until March 15, and I have 5 speaker discount codes giving 5%. Ask me for details.

LSSC11

This year’s Lean Software and Systems Consortium conference (Long Beach, California, May 3-6) is bigger with many more tracks and world-class speakers. In addition, the Software Engineering Institute (SEI) is part of the conference cooperation with the Lean Software and Systems Consortium.

This year’s theme is the synthesis of other models, going beyond lean: LSSC11 will show how vertical markets are embracing lean, how it is applied in large-scale initiatives, and how it is succeeding around the world. 

Anyone considering lean methods like Kanban will want to be at LSSC11 to build on their knowledge and connect with like-minded business people.  Companies represented include Lonely Planet, Goodyear Tires, JP Morgan Chase, Hewlett Packard, Deloitte, GoDaddy, Microsoft and many other organizations worldwide that are actively using lean software and systems thinking to succeed.

Do not miss the excitement, the learning, the networking, and the once-in-a-lifetime moments at LSSC11. Enjoy extended early bird pricing until midnight on March 13, 2011. Ask me about speaker discount codes as well for further discount. Register today at http://lssc11.leanssc.org.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)