Agile for Executives

I have been working more and more with Executives recently both from within IT and external to IT; CIOs, Executive Directors, Directors, and Senior Managers.

In these sessions curiosity about agile has been piqued, which has led to wanting to learn more.

In these information sessions I have found both the Agile Manifesto and the Declaration of Interdependence do not resonate.

In the main this has been due to their focus on software and delivery, not to say these aren’t good focal points, but that they do not seem to resonate with those at the top of the organisation, and certainly not with those outside of IT.

Inspired by the work of David Anderson, I have used (in addition to the manifesto and declaration) a new set of principles that provoke executive thought.

On the left side I state the principle, on the right pose alternative questions if we choose to keep the status quo.

I’m not suggesting we need “yet another manifesto” or more dogma, but I have found this resonates with executives, challenges them and gets them thinking.

The Case Against Value Stream Mapping

My blog is called Systems Thinking, Lean and Kanban. With the word Lean in the title, and being an active part of the Lean and Kanban community, what am I doing posting an article called The Case Against Value Stream Mapping? Has my recent 22 hour flight to Australia had an affect on my brain?

I have been trained in VSM, have used it, and have found it of value. Its a wonderful tool for helping teams in setting up their Kanban boards; mapping their current Value Stream onto the columns on a board. Alan Shalloway has a great animation of this in action. I also encourage Kanban software tool vendors to have a VSM view in their tool, which will show average delay and process times for a Kanban workflow. In addition when I present at conferences, I reference the usage and results of using VSM in one of my case studies at Lonely Planet. So why this post?

Well, its all to do with how the Value Stream Map is used once it has been created. Lets explore how we learn and how to create change.

Action Science

Chris Argyris, an American business theorist, developed a way of explaining behaviour called Action Science.

In Action Science he describes two simultaneous mental models that make it difficult to create change. The first is our Espoused Theory, which describes the model we say we use to describe how we act (or how we would like others to think we act). The second is our Theory in Use, which is the one we actually use to make decisions.
Mental Models are a way to describe a person’s intuitive perception of the world around them. How we act on that world, our decision rules, are based on our mental models. People always behave consistently with their mental models (theory-in-use) even though they often do not act in accordance with what they say (espoused theory). Within the workplace, we hold generalized beliefs about “what is valued in this organization” and “how things get done around here”. We also hold more specific beliefs about events and people. These beliefs are important because they influence and constrain what we do and don’t do in the workplace.

Single Loop vs Double Loop Learning

Argyris also describes two types of learning. Single-loop learning describes how people learn to adjust their actions in response to natural feedback on the success of those actions in achieving a desired result. They liken this style of learning to a thermostat that adjusts the degree of heating or cooling depending on the temperature of the room. In single loop learning, we may change our decisions, but we leave our underlying mental models and decision rules unchanged. This type of learning solves problems but ignores the question of why the problem arose in the first place (using the previous thermostat example; why is the temperature in the room changing?).

In double-loop learning, we change our underlying mental models and decision rules, which in turn produces new results. Double loop learning uses feedback from past actions to question assumptions underlying current views. Double-loop learning requires not only adjusting one’s actions, but also surfacing, challenging and adjusting the governing variables that are usually taken for granted i.e. our beliefs or “mental maps of reality”.

Double-loop learning adds a powerful dimension to previous experiential learning cycles. In previous models, learning was achieved through reflection on the success (or failure) of your actions. However, in the double-loop model, learning is realized through reflection on the validity and usefulness of your beliefs.

Model I-Inhibiting Double Loop Learning

Argyris tells us that when human beings deal with issues that are embarrassing or threatening, their reasoning and actions conform to a model called Model I. Model I behaviour results in defensive behaviours that block exploring underlying mental models and the resulting maturity that arises. Trying to make change in Model I is difficult because you are dealing with their Espoused Theory. It is neither rewarding nor safe for a person to explore or actually change their mental models and decision rules, so there is a wide gap between their Espoused Theory and their Theory in Use.

Model II-Encouraging Double Loop Learning

Argyris describes a much more productive model that he calls Model II. In Model II,  it is safe and rewarding to explore underlying mental models and decision rules. The significant features of Model II include the ability to call upon good quality data and to make inferences. It looks to include the views and experiences of participants rather than seeking to impose a view upon the situation. Theories should be made explicit and tested, positions should be reasoned and open to exploration by others.

The Problem with Value Stream Mapping

With the above in mind, what level of learning will a leader experience when shown a Value Stream Map? Its unlikely they will experience double loop learning. Its more likely that when presented with the map, containing various delay times and process times, that may prove embarrassing or threatening, they will use their current mental models i.e. model 1, and look to blame the workers or blame their managers.

If you have ever watched the ‘Back to the floor’ type TV programmes you will know the problem these kinds of things create, i.e. The boss hears something shocking, goes back into the management factory and issues edicts that make things worse not better. The problem, as always, is two fold. Firstly the boss lacks perspective to understand that a systemic change is required (“This problem has been created by me!”) and secondly is let down by the methods they have learned about how to act.

Top management issuing orders, memos and directives alone is insufficient to change employees’ behaviour. Single-loop learning often leads to organisational malaise resulting in symptoms such as defensiveness, cynicism, hopelessness, evasion, distancing, blaming, and rivalry.  There is often a large gap between what leaders publicly “espouse” and the real beliefs that guide their actions. In order to effectively come to grips with new situations, the espoused theories need to be aligned with the theories in use.

Double-loop learning techniques help the organisation members learn together and the organisation change. To do this we need to reveal how the work currently works. We need to reveal the thinking behind the current work design. Value Stream Mapping lists each delay and process time in a flow. It identifies current state and future state and plans for implementation. Waste is identified for reduction. But as John Seddon points out

Managers think that cost is in activity, whereas the counter intuitive truth is that cost is in flow.

Process Mapping

An alternative to Value Stream Maps is Process Mapping. We don’t map the process in a room with brown paper and sticky notes. We don’t ask the managers as they are often too removed from the work to know what is actually going on. We don’t send in a Business Analyst from IT, we don’t talk to proxy customers or talk to a spokesperson for an area. We don’t talk to a few token “doers”. Instead we go into where the work is occurring, with a small team comprised of peers of those who do the work. Why peers? workers tend to tell their colleagues the truth about what’s really going on at work. We also take a leader with the team going into the work to perform the mapping.

As John Seddon states

Studying work as systems reveals counter intuitive truths, challenges to convention, that are more easily understood and accepted if someone sees them for themselves, not if they are told. People need to unlearn and relearn.

Mapping is important because it helps staff to change their perspective on the work.
Firstly it helps them to unlearn what they think is going on in the work. Secondly it helps them to relearn how the work should be designed from the customers’ point of view.
In this regard, process mapping is not simply a means to an end. It is part of the change process.

I will post the mechanics of Process Mapping in a future post, but in conclusion, I suggest it would be more likely for effective change to occur if we go into the work to get knowledge of what is really happening in the work, together with a leader who will experience the same learning as a team and will have the authority to make changes to improve. How we document the process, say in a VSM, is less relevant than the learning acquired.

Reading Recommendations

Below I have posted some recommended reading material for those interested in learning more about Systems Thinking. My current mission in the IT world is to elevate ourselves beyond building something in the right way; Agile, to building the right thing at the right time; Systems Thinking.

Booklist and links below

Out of the Crisis – W. Edwards Deming

Workplace Management – Taiichi Ohno

Freedom From Command and Control – John Seddon

Moon Shots For Management – Gary Hemel

Discussing the Undiscussable – William R Noonan

One More Time: How Do You Motivate Employees – Fredrick Herzberg

Drive: The Surprising Truth About What Motivates Us – Dan Pink

Understanding Variation: The Key to Managing Chaos – Donald Wheeler

Leading Lean Software Development – Mary and Tom Poppendieck

The Four Steps to the Epiphany – Steve Blank

The Leaders Handbook – Peter R Scholtes

Brickell Key award

Today I received the Brickell Key award at LSSC10 for Outstanding Achievement and Community Contribution. Due to the volcanic ash flight problems I was unable to attend in person so Jason Yip kindly picked up the award on my behalf. David Anderson asked for a few words from me, to which I mailed the below.

David Anderson and John Seddon inspired me to try something different at the BBC at a time when our various different Agile initiatives and Scrum projects were faltering. Kanban and Systems Thinking were a breath of fresh air for me, and having seen for myself the results these can bring, it has inspired me to spread the word and help others in achieving better service for their customers.

Via the various talks and presentations I have given, blog posts, show-rounds of the implementations at the BBC, and the academic paper co-authored with Dr Peter Middleton I hope to similarly inspire others.

Im deeply honoured to receive this award from a community of like minded people who want to advance our industry and push boundaries.

Agile Yorkshire and NHS ITC Feedback

Late last year I presented an overview and experience report on Kanban at Agile Yorkshire and spent the following day at the Leeds NHS ITC talking Lean, Kanban and Systems Thinking.

I recently received the following feedback

#kanban uptake following @dpjoyce talk. “like the Pistols Manchester gig when many of those who were there were inspired to form a band”

I’d like to thank you for your recent visit to the NHS Information Centre and for the introduction of the Kanban process to our team. It was surprising how quickly the team took to the idea and how well it worked from the outset. We have obviously had a few teething troubles but these were more to do with standardising the cards’ colours and the information written on them than about the process itself.

Even more surprising is that other areas of the business such as our programme management office and some of the data management areas are also looking at how they can implement Kanban for their workloads.

Your visit has certainly made a difference here and we are most grateful.

Nick Porthouse
IT Development Manager
The NHS Information Centre

Journey to Systemic Improvement – Tweets

Its always interesting when presenting to get instant feedback from those in the audience using twitter. Here is a selection of the tweets.

worldofchris @dpjoyce Red Bead Exp. was great as was your preso. #leankanbanx

christianralph “over 50% of work is from failure demand (rework, bugs, complaints) – Vanguard” @dpjoyce #leankanbanx

lunivore “If current work uses IT then leave it, work with it or treat it as a constraint.” @dpjoyce #leankanbanx

skirk @dpjoyce mentions failure demand at #leankanbanx, after @agilemanager talking about “failure modes”. There’s clearly something in the water.

lunivore “Understand, improve, then ask if IT can further improve. Large gains from > thinking around design & mgt of work.” @dpjoyce #leankanbanx

christianralph “understand and improve, then ask if IT can improve further. ” @dpjoyce #leankanbanx

skirk From @dpjoyce at #leankanbanx “Since IT can, should it?” – good question!

lunivore “Outside-in: Sales, Mkting, Finance, HR, IT” – interesting use of the BDD term from @dpjoyce #leankanbanx

lunivore Results from @dpjoyce‘s #kanban available here: http://is.gd/58UkV Also really like @agilemanager‘s feedback on same page. #leankanbanx

Jazzatola This is what I was getting at. You need “…a team willing to reflect, adapt and improve.” @dpjoyce #leankanbanx

marcjohnson RT @lunivore: “<Change> based on a set of principles – better practice, not best practice.” @dpjoyce #leankanbanx

christianralph “BBC introduced a kaizen board, to collect improvements that can be played during downtime” @dpjoyce #leankanbanx

lunivore “Phase 1, no limited WIP but bugs, blockers, anything which stops you hitting the deadline visible.” @dpjoyce #leankanbanx

lunivore “Standups – 20 people in < 15 mins – they’re enumerating the work, not the people.” @dpjoyce #leankanbanx

scottcowan “chargeable and non-chargeable queues, where you need a minimum number of chargeable cards in progress” @dpjoyce #leankanbanx

lunivore “The kanban ‘flu’ soon spreads to other teams.” @dpjoyce #leankanbanx

christianralph “BBC upgraded blockers to 1st class citizens on the kanban board” @dpjoyce #leankanbanx

worldofchris “Stop Starting, Start Finishing” @dpjoyce #leankanbanx

christianralph “planning sessions act like a handbrake to teams momentum and end of each iteration” @dpjoyce #leankanbanx

benjaminm “Iterations were like pulling a handbrake on the team every fortnight” fighting talk on iterations by @dpjoyce #leankanbanx

joakimsunden Time for @dpjoyce “A Journey to Systemic Improvement”. #leankanbanx


Journey to Systemic Improvement – Lean eXchange presentation

Today I gave a talk at the UK Lean eXchange entitled Journey to Systemic Improvement.

My slides can be found here.

Note it is a media rich presentation so the PDF is almost 50MB!!!

A video recording of the presentation and our second running of the Red Bead Experiment will soon be available.

Kanban Results – Part 3 – From Scrum to Kanban

I have previously blogged results from our largest Kanban team.

Now its the turn of another team who had been using Scrum up until April 2009. They were recording data (Lead Time, Engineering Time, Development Time, Live Defects) during their time with Scrum and then from their time using Kanban. Its interesting to see the difference in stats since the switch, which the SPC charts below depict. The charts are split between pre and post April 2009.

The major changes in process the team went through during the transition from Scrum to Kanban were:

  • Whilst using Scrum the team were carrying a hefty Product Backlog, with lots of time spent defining acceptance criteria and estimation (in points) up front, only for these work items to sit in the backlog for long periods of time. When using Kanban the team moved to a just in time model, which resulted in the team being able to spend more time on development, and less time in upfront analysis and less time in planning and estimation sessions.
  • Items were batched (during sprints) for testing when using Scrum, the first week and a half the team would focus on development with items batching in QA. Work would be branched into a release candidate towards the end of a sprint, then tested, and in process bugs fixed. Releases were also batched. After moving to Kanban the team moved to a develop, test and release on demand model. Significant efforts were made to reduce and automate the release process once the sprint shackles were freed, in addition a suite of automated regression tests were written to add confidence in a release on demand model. This added agility to respond to customer demand. The QA became more involved througout rather than just towards the end of the sprint, with the developers on the team also testing work items to alleviate bottlenecks in QA due to their upstream development stations becoming blocked.
  • Lengthy planning and estimation sessions (every 2 weeks) were dropped. Instead planning and estimation happened on demand.
  • 2 weekly retrospectives were kept but with the addition of the team talking about Lead Times and Cycle Times using SPC charts from data being captured.
  • Blockers were elevated to first class items. Unfortunately the number of blockers and their length were not recorded by this team.
  • Rigid 2 weekly Sprint demos were dropped, instead demos were completed on demand.
  • Work in process was limited. As per my last post, once again Little’s law came into affect which can be seen in the Development Time SPC chart below.
  • Focus became on finishing work in progress rather than starting new work. Following the mantra; Stop starting and start finishing!
  • Stories were grouped under MMFs, with the number of MMFs in progress at one time also limited. MMFs in progress were made visible on the board.
  • The Kanban board went through several evolutions to make both the work and the workflow visible.
  • The team started using the board during standups, discussing the work, rather than standing in a circle near the board doing the normal what I did yesterday, doing today, round robin.
  • The team felt they no longer were tied to arbitrary deadlines, which reduced stress and the feeling of shoehorning the last remaining items in before the sprint completed.

Its also worth noting that this team have lost 3 developers since March 2009 (who left the company). The product consists of a large code base with much of the front end considered difficult to change. Yet the performance of the team shown below shows a consistent improvement. In addition this team is one of the few in our organisation who has integrated both UI creative/design and development into their process. Both of these require specialisms which were mapped on to the board, with hand offs between each.

Lead Time

Lead time has reduced from a mean of 25 working days to 14 working days over the past year. There is a large drop in the spread of variation, with the upper control limit dropping from 82 to 36, over a 50% drop in spread. There is a consistent downward trend with the majority of the most recent items under the mean.

6 of the outliers in 2008 were technical debt items with a lower class of service, the rest were waiting a long time in the Product Backlog. In 2009 3 of the outliers were technical debt items with a lower class of service, the others were items batched (at the request of the customer) into one significant release.

Lead Time Oct 09

Engineering Time

Engineering time has reduced from a mean of 10 days to 4 days over the past year. There is a large drop in the spread of variation, with the upper control limit dropping from 33 to 12, over a 60% drop in spread. There is a consistent downward trend with the majority of the most recent items under the mean.

The majority of outliers in 2008 were technical debt items with a lower class of service or items that were de-prioritised. In 2009 4 of the outliers were technical debt items with a lower class of service, the others required root cause analysis.

Engineering Time Oct 09

Development Time

Development time has reduced from a mean of 5 days to 2 days over the past year. There is a large drop in the spread of variation, with the upper control limit dropping from 16 to 7, once again over a 50% drop in spread. This portion of the value stream was directly under the team’s control and not subject to delays from 3rd parties or upstream or downstream parties. The major factor in reducing development time has been to limit work in process.

The majority of outliers in 2008 were technical debt items with a lower class of service or items that were de-prioritised. In 2009 4 of the outliers were technical debt items with a lower class of service, the others required root cause analysis of which 2 were found to be special cause.

Dev Time Oct 09

Live defects per week

We need to ensure that the reduction in lead and cycle times are not at the expense of quality. The chart below shows that the number of live bugs is within statistical control, and since April we are actually seeing a reduction. A large factor in this was due to investing in automated testing and paying down technical debt.

Live defects oct 09

Kanban Results – Part 2

Following on from my recent Kanban results post more information is provided below in regards to the teams focus on handling blockers, which is a vital part of improving flow.

In Scrum we are taught to keep an impediment list:

Anything around a Scrum project that impedes its productivity and quality is an impediment. It is the responsibility of the ScrumMaster to remove any impediment that is stopping the team from producing production quality code. The impediment list is simply a set of tasks that the ScrumMaster uses to track the impediments that need to be solved.

David Anderson however has another take:

Another aspect of Agile methods we can look at is how they handle impediments or blocking issues. The early Agile literature didn’t have a lot to say on this but pointed out that impediments should be raised at a morning standup meeting, or scrum. Very few teams treat impediments or issues as first class work items. They do not focus on tracking of the issue behind the block or for any escalation path to be implemented or tracked. Agile teams encountering an impediment would generally mark an item as blocked and go on to another one.

This is not the behavior you would expect on a Kanban team truly limiting WIP. Because the WIP limit will have been reached, an impediment causes idle time. The only course of action available to maintain flow is to pursue the impediment, track down its cause and resolve it. In a truly WIP limited process impediment removal is paramount.

As I mentioned in the previous post, the team changed their daily standup to talk about blockers first, and actively assigned, tracked, escalated and removed these blockers. Evidence of this is shown below, once again in statistical process control charts.

Number of working days blocked

The number of working days items were blocked has reduced from a mean of 26 days to 5 days over the past year. There is a consistent downward trend with the majority of the most recent items under the mean. The outlier in 2008 was a result of waiting for a 3rd party to complete their work (a special cause), powerful data to use when discussing performance with those 3rd parties in our quarterly meetings. As in the previous post the periods on the charts have been split from 2008 until our financial year end (April 2009), and from July 2009 until October 2009.

Days blocked Oct 09

Blockers per week

The chart below shows that the number of blockers is within statistical control. We are in fact observing an increase in the number of blockers raised, however as the chart above shows these are being removed at a faster rate by the team.

Blockers per week Oct 09

Once again this data was used in our retrospectives and quarterly reviews. Reoccurring blockers were investigated and route cause analysis performed. Outliers were discussed as were those the team deemed worthy of discussion.