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.
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.
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.
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.
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.
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.
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.
Great feedback below from David Anderson on my recent Kanban results post.
It is really interesting to hear this feedback, as to us in the team these changes have become almost natural and the norm. For example we regularly use SPC chart data in our retrospectives and quarterly reviews, the team often suggest changes to help improve the process, starting new work is often rejected with the focus on completing work in progress first. More recently the team are starting to record touch time to see where they can further improve and drive out waste, and to understand and highlight dependencies between work items.
These improvement have obviously required a team willing to try something different (from Scrum which they were doing before) and want to continuously improve. We also have an experienced BA in the team that works very closely with those upstream and whom has an extremely detailed knowledge of the lines of business that we deliver MMFs to. A focus for improvement has also been with those downstream who release MMFs into the live environment. Finally to complement the improvements in process the team has strived hard in the last year to improve their engineering practices; pairing, Test Driven Development, continuous integration, Automated Acceptance tests, improved configuration management, improvements in coupling and cohesion, to a point where they can release on demand with very low transaction and coordination costs for each release.
There are similar improvements from our other team who are using Kanban, and I will be blogging about these over the next month or so.
A further note is that Dr Peter Middleton is writing an academic paper on our results which will be published shortly.
From David Anderson…
After Lean & Kanban Miami in May, Corey Ladas tweeted that he’d like to see fewer cumulative flow diagrams and more statistical process control charts from teams doing Kanban. At the time, I commented that we had to be patient and that teams would mature to the point where they felt the need for statistically defensible methods such as SPC.
We are beginning to see that maturity develop in the community and it is mostly happening in London. Benjamin Mitchell has been carrying around some SPC charts from his team at BNP Parisbas and showing them to anyone who’ll listen at Ltd WIP Society and XTC meetings. Now David Joyce from BBC Worldwide has blogged results from 12 months of Kanban introduction. He chose to use SPC charts to show the improvements in lead time and defect rates.
I’ve posted this response on my own blog
I did so because I want people to see beyond the basic numbers. While the improvements are definitely worthwhile and I am sure the reduction in lead times, increased number of releases and improved quality is significantly improving business agility and customer satisfaction, David’s data contains a lot more information. It contains further empirical evidence that teams using Kanban achieve high levels of maturity and do so within time frames hitherto unreported in the literature.
I have some thoughts on why this is so. I talked about them at SEPG in San Jose in March. For example, Kanban sets an expectation of quantitative management through its transparency and availability of data. It sets an expectation of kaizen culture (continuous improvement driven from the shop floor) by providing models like bottleneck management, waste reduction and variability reduction that enable teams to visualize and implement improvements. It sets an expectation of flow and the maintenance of flow through swift issue escalation and resolution. And it encourages root cause analysis and resolution to maintain flow and improve predictability.
From the beginning Kanban sets an expectation of high maturity behaviours. Behaviours that appear in levels 4 and 5 of the CMMI. It appears that by doing so from the outset, this really does accelerate improvement and achievement of higher maturity levels.
Our community needs more stories like this. If you have one, please submit it when the call for papers is issued for Lean Software & Systems 2010 in Atlanta April 21-23. We’d love to have you present at the conference.
Meanwhile, a cap doff to David and his team and the remarkable changes that are taking place at the BBC’s commercial arm. 
David
http://www.channelkanban.com/
Over the past year our Kanban teams have been striving to reduce the following:
- Lead Time – the time it takes from a customer request to when it is delivered
- Development time – the time it takes from entering the Ready For Development queue to when it is handed off to QA
- Engineering time – the time it takes from entering the Ready For Engineering queue to when it has passed QA, left Engineering, and is ready for UAT
Through various means; working on the system, talking about blockers first in the standup, actively assigning, escalating and removing blockers, recognising and reducing bottlenecks, retrospectives, improving our process by separating common cause problems from special cause problems, using MMFs and component stories and tasks, implementing Kaizen, implementing classes of service, highlighting items that have been on the board for too long, to name but a few, we have seen improved results which are depicted below in Statistical Process Control charts using data taken from our largest Kanban team.
Note the links in the above paragraph link to other areas of this blog that describe in more detail how each of these have been achieved. You can click on each of the charts below to see a larger version.
Lead Time
Lead time has reduced from a mean of 22 days to 14 days over the past year. There is a consistent downward trend with the majority of the most recent items under the mean. Each of the outliers were proved to be special cause. The periods on the charts have been split from 2008 until our financial year end (April 2009), and from July 2009 until October 2009.
Development Time
Development time has reduced from a mean of 9 days to 3 days over the past year.There is a consistent downward trend. 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 periods on the charts have been split from 2008 until our financial year end (April 2009), and from July 2009 until October 2009.
Engineering Time
Engineering time has reduced from a mean of 11 days to 8 days over the past year. Once again there is a downward trend. However there are more outliers that required investigation. Some of the outliers were proved to be special cause, but the majority were down to waiting for 3rd parties to complete their development and QA, something the team actively worked on to reduce. The periods on the charts have been split from 2008 until our financial year end (April 2009), and from July 2009 until October 2009.
Throughput
We class throughput as the number of items released, and would expect an upward trend as the code base is decoupled, work items broken into MMFs, and cycle time reduces. The chart below shows this upward trend in the number of releases per month. Note that we are subject to release freezes hence the drop from December to February where the release freezes were imposed.
Bugs Per Week
We need to ensure that the reduction in lead and cycle times, and increase in throughput are not at the expense of quality. The chart below shows that the number of live bugs is within statistical control, and since July we are actually seeing a reduction.
There are now several follow on posts from this original post
http://leanandkanban.wordpress.com/2009/10/25/kanban-results-feedback/
http://leanandkanban.wordpress.com/2009/10/26/kanban-results-part-2/
Making Measurement work for you workshop – Jeremy Cox
The final part of the day was a workshop ran by Jeremy Cox who is a Vanguard consultant.
He started of by explaining there are 3 types of waste in a system
Type 1 – you can just stop (if you have the authority) for example appraisals
Type 2 – you need to design out of the flow
Type 3 – you need to do to survive
Vanguard have found that IT Systems that we depend on so much are high wired into current business silo targets (not measures), this then makes removing the targets harder to do (and more costly). One of the audience, an IT Systems Manager mentioned that he has seen targets around page views and impressions for web sites. This resulted in the sites being made more complicated to use, which meant people were clicking around more and the overall stats went up! If simplifications were made to the site they would suffer as their stats had gone down!
In Vanguard’s experience organisations spend a fortune on IT and have no knowledge on how it is affecting performance.
In the Vangaurd literature there is much talk of the “customer”. Jeremy explained there may be more than one customer and if this is the case in your organisation to not try to create a universal customer. The word customer may be wrong in your context too, it could be consumer or patient for example. By taking an outside in approach you may find the “customer” is different per area or touchpoint.
Measures
The key question to be asked is “have you got measures that enable you to learn and improve?” if not then they are arbitrary.
Measures need to be developed with the staff, use this guiding principle; who are your customers and what do they want?
During the session Jeremy used a framework that he has found useful when applying Systems Thinking; Principles, practice, issues.
Measures principle 1 – Purpose -> Measures -> Method
We brainstormed current targets in our organisations. It is usual for them to be set at Method i.e. bottom up. You are told it will be done like x and a measure comes out of it. Other times we start at Measures and come up with a target. Both of these result in a defacto purpose.
The advice is to start with Purpose, this helps you develop measures and liberates method. ALL of your measures should be firmly routed in purpose.
Remember removing targets doesn’t mean “no measures”. We arent suggesting to remove measures, but to create new measures derived from a customers point of view.
Changing measures requires senior management buy in. The suggested practice is to add more useful measures to the existing targets you have to report now, then over time reduce the old targets as people realise they are becoming less and less useful. Its important to note that between the worker and senior management there are various levels of performance managers, they are likely to cling to old targets and become perturbed by the change to measures. They need to experience the normative loop and discover themselves why the new measures are better for the customer and your organisation’s service.
What does good service currently look like in your organisation? When going out into the work ask the following questions “how often are we able to say yes?”
How do you study purpose? Go out into the system and study demand, what matters to your customer. Look at Value Demand vs Failure Demand, go and talk to your customers.
When setting measures you may not get it right first time, review your data regularly, is Failure Demand dropping? are end to end times reducing? are your customers happier?
What do you measure and how do you do it?
By design target based measures prevent learning and improvement. Regularly ask the following question “do the measures that are currently in use lead you to learn and improve?”
A leader should follow this up with the following questions
1. Show me your methods
2. What are the problems you have discovered? What have you learnt?
3. What is your plan to deal with these problems?
4. What help do you need from me?
5. What decisions do people make with the data?
Asking the above will enable you to easily see if the current measures are useful.
What do good measures look like? a good answer to the above questions would be for example “we have studied demand over the last week and have found a new Failure Demand that is predictable and preventable. This is how we plan to reduce it”
Its common when you ask these questions you find there are no measures in place, or there are too many measures, or people are wary and you get a negative reaction as they suspect you might be inspecting them. You should ask both staff and managers, you will more than likely get different answers. Never take people only at their word, they may say something and do something different, watch the work as well to see what is truly happening. You have to roll up your sleeves and go out into where the work is done.
Jeremy advised to stick to the principles but not rigidly to the Vanguard method, you will have to compromise during the journey.
Change Thinking
This is intervention theory, this is the really hard stuff!
You can read, Check, Plan, Do as
- Get Knowledge
- Build the desire and confidence to try an alternative
- Make it normal
The Check stage in the Vanguard method is an “unlearning” process for staff, people will unlearn at different rates, or in some cases be unwilling.
Some managers will jump straight from Check to Do and set new targets. One of the first reactions to seeing true end to end times following Check is for managers to set new targets to reduce them.
Remember, are the measures defined and used in the work? do the people who do the job work with their managers to set measures? They have to be set in conjunction with those that are located in the work.
Measures, work design and job roles are all interlinked, they are mutually enforcing. With any intervention you always change these 3.
One technique that works is to put measures up on a board near the team, they all review regularly, use them to improve, update them and modify the work and the roles accordingly. Use carefully and gain buy in from the team. Dont just put targets on a board and point to them!
Cost/Benefit where are the boundaries
The business case should contain Revenue – Waste costs = Savings. Its important to do Check (at least a pilot) first to help with a business case. You never know the boundaries of your system until you start studying it. You will find that bits of the system will create demand for other bits of the system, so follow the work. Agree a boundary for change with the sponsor.
Don’t spend enormous amounts of time trying to get *exact* Failure demand figures for the business case.
The question that is always asked is “how much are we going to save?” You cant quantify this up front, change is emergent. Engage with the sponsor and agree on what they want out of it and focus on this. A pilot Check will give enough indication to present to a sponsor to see if we should proceed.
A fundamental part of Check is engaging with senior leaders and agreeing scope. Don’t start too large, the faster you go after waste the sooner you will know how long it will be to take it out.
Systems Thinking Experiences – Shona Murray from Aviva Life and Tim Blanch from Coastal Housing
Following John there were 2 experience reports, the first from the private sector and the second from the public sector.
Shona started off by relaying stories of how she used to be target driven, her staff would quake when she queried them as to why they were not making their targets, whenever this happened the following period the targets would be met, it was only when she started delving deeper did she find the ingenuity of her staff to game the system.
For example Aviva Life had targets for calls answered within 3 rings, so the staff devised a mail box so that unanswered calls would be sent there and targets would be met. She was told “the customer loves the mailbox!”.
Another example was given that the staff werent meeting the first line call targets, another Shona bashing, so they drafted in the admin staff to help with the load and meet the targets, sure enough they met the targets. Shona asked what was happening to all the quotes the admin staff had to deal with? the answer was that they were pilling up to be dealt with at a later date, the focus had become the target.
Staff were targeted on customer care, having to ask “is there anything else I can help you with today?” sounds sensible, but plugging in an listening to a customer who has called several times before to complain about not receiving something, to be told they would still have to wait and then asked “is there anything else I can help you with today?”, well you can imagine the response. Imagine your response after being asked this each time you were transferred. The staff had to do it though, or would be penalised for not doing so. When you phone a call centre you are often asked by the IVR to enter your phone number and date of birth using your keypad, then you asked again by the person you get through to, why? because they are targeted to do so.
She then met John and learned Systems Thinking. She found that leaders must be focused on getting knowledge. She now has a Monday morning Failure Demand session, where she examines demand and drills into the causes of the Failure Demand. She has found that handling Failure Demand takes double the amount of time as Value Demand, so with 40% Failure Demand this is using up 80% of her staff’s time, reducing this Failure Demand greatly increases capacity.
Aviva Life are now designing their work against customer demand. They are analysing demand and training the workers against this demand.
She advised to talk to your leaders and say, lets be a piece of work for the day, lets follow it through the flow. So start early in the morning and visit someone at the front end, ask they what they do with this piece of work, they send it on so follow it, ask the next person, then follow it and so on asking the same question. They did this at Aviva for a cancellation, a 20 second piece of work, the senior management found that it took between 5 and 35 days to cancel! They found with their own eyes that costs are in flow.
Aviva Life have seen 70% + improvements in customer service times following implementing Systems Thinking, by removing arbitrary targets and focusing on the flow of work. Their managers have changed their focus, they ask themselves 3 questions:
- What did your customer want?
- What was our response?
- Why was it like that?
They found that 95% of the answers were down to a problem with the system rather than the worker. The managers went into the work with these 3 questions and came out with a lot of actions for improvement! They went and worked on these actions and measured performance. Managers should be available to be pulled by the workers when needed, but they were busy in meetings, so Aviva Life got rid of many of the “standard” meetings to free them up for the workers.
Shona found that functional silos were creating waste. They had outsourced much of their work to India, they had 144 people in their offshore centre, cost per activity looked cheap, but the actual cost of customer valued work flow was high. They have now on-shored this work, with 22 people! Aviva Life no longer focus on costs, they focus on flow, as a result costs have gone down. Their CEO is bought into Systems Thinking and has had senior management gatherings part of which where they are taught Systems Thinking. This has resulted in these senior managers returning to their areas asking why their staff are not applying this.
I have asked Shona for a copy of her slide deck, when I receive this I will update this post.
The key takeaway I got from Tim’s session (as I am in the private sector) was that they stopped doing appraisals. They found no one missed them, turnover didnt increase. They found that managers (and the team themselves) know who needs to improve and where, poor performers were unable to hide.
Part 3 – Making Measurement work for you workshop – Jeremy Cox
First off, WOW! This was my first Network day and boy was it worth it.
Below are the key takeaways that I took from the sessions that I attended.
An irrational belief in targets – John Seddon
First off John reported that we are winning when it comes to applying Systems Thinking in the public sector and changing conventional thinking. He will be writing a column in the LGC every 6 weeks. John sees the next election as a watershed, he is now regularly briefing the Tories – although in his opinion only half of them have understood Systems Thinking so far. He is also talking to the Lib Dems. He jokingly asked if anyone had signed the petition for him to become the Tsar for Public Services, said he did it to draw attention. If he was offered the role he would only do it on his terms and his starting point would be to get rid of the bullies with no knowledge of the work currently in place. He would change the focus of inspectors to ask only one question, what do you measure and how do you do it?
Those working in Wales can now drop arbitrary targets and those in Scotland have begun to cease micro managing. He also reported that proportionally there is more Systems Thinking going on in England than anywhere else. He mentioned the comprehensive area assessment (CAA) process and how it has been termed a “weapon of mass distraction” by Gareth Daniel.
John thinks that Systems Thinking will get there in part. In this current climate of cost cutting he is advising the Tory Fringe Party to spend less on the right thing, than less on the wrong thing; the things they spend money on now. The total place initiative came in for a battering, Vanguard have created an alternative proposal. People tell him that efficiencies cant be achieved, he responds that cost is in flow and not in activity, we havent achieved efficiencies because we have been focused on activity. Finally he reported that Vanguard have been doing their first pieces of work in healthcare recently and that Vanguard have found that improving service has had an unanticipated effect; people take more pride, for example those in housing estates starting taking pride in the estate they live in.
John has asked that anyone getting showered with dumb instructions, please send them to him.
He advised you reject anything and anyone who offers you “best practice”. It should be “better practice” as anything can be improved. Best practice = copying and trying to copy something to your system wont work as your system will be different.
Moving onto targets John commented that command and control targets often relate directly to plans and budgets, as there is a commonly held belief in current management thinking that this is the only way to run an organisation. He commented on the important distinction between targets and milestones. He has a big problem with traditional project management, not with planning and milestones, but with managing by things that are arbitrary such as milestones with dates (people become fixated on the dates, therefore quality goes down, costs go up). Change is emergent, therefore traditional project management is flawed.
There then followed a brainstorm where each table called out why we are so set on targets. He then took each one in turn and talked about his experiences.
We think targets improve performance
They dont! 95% of performance is down to the system and not the worker. A highly motivated, qualified, experienced worker is constrained by the system that they work in. How do we change this? Show the people who set the targets the effects, ask them to stand in the place of work and study what is going on, they will soon see the constraints and the effects targets have had on the worker. Ohno never explained, he told his managers to go and see the work (this is often termed as learning to see). Standardising work also reduces performance, variety and innovation, resulting in costs going up.
Someone from the audience told how their office cleaners have been targeted to clean each meeting room in 2 minutes, you cant clean a phone box in 2 mins! Another talked how a colleague has 50 years experience in VAT queries, despite this, the VAT queries are separated at the front end between easy and hard, he often receives easy ones instead of the hard, he is told what to do, which items to investigate and to do them within a certain time. His expertise has become lost. John also cited several similar examples of front and back office splits that are resulting in us disconnecting knowledge from service.
Within target based regimes they have found that its easy for poor performers to hide, in organisations designed using Systems Thinking those poor performers are easy to spot.
John advised designing roles back from the customer valued work. If you design complementary roles you will get an improvement in performance – cultural change is free.
Appraisals are a waste of time as performance is constrained by the system. This doesnt mean you dont have to stop doing appraisals, but change them
- How are you doing?
- What do you understand?
- How is your work designed?
- Are you trained against customer demand?
- How do you pull help?
More can be found here.
We think targets motivate people
People have learnt to game (cheat!) the targets, especially when they are related to pay increases. John told a sad story where GPs are now paid for every referral they make to a cancer specialist. Therefore far more people are being referred than before, the specialists are targeted to see them within 2 weeks but have become overwhelmed. The real cases are getting lost in the pile of referrals. Targets make costs go up and purpose go down.
If you cant measure it then you cant manage it
Deming realised that the most important things are unknown and unknowable. Why unknown? Because all systems contains variation, no matter how sophisticated the system is, sources of variation will always exist and that prevent us from producing an outcome that is exactly identical with the last outcome. Why unknowable? The optimum system is a goal by which we gear all our effort to achieve. We do not know how to get there nor do we know it when we get there. All we essentially know, is that we need to constantly improve our system if we want to become closer to this goal.
Targets allow for comparibility
We assume the target is a reliable measure, but it isnt. What do you learn from comparison? Each team being compared may have different demand and different variation. Ohno said there is no point in comparing, what you need to improve is in your system to find, go and look, its a signal to look. If you *do* have 2 teams that have the same demand and are performing differently then go and see what the other team is doing, but remember its not best practice, its better practice. This reminded me of a friend who reported that his team was out performing another, he visited the manager of the other team to suggest he look at what the better performing team were doing, he declined, stating that if his team radically improved then it would draw attention and make him look bad that the performance of his team had been poor up to that point.
Targets make good PR
Good PR follows compliance.
Targets make people accountable
Targets drive in massive costs and poor service. People learn to game the targets as described above.
Whats the alternative?
When you talk about removing targets people hear “no measures”. This isnt correct. John stated that we arent suggesting to remove measures, but to create new measures derived from a customers point of view. The next reaction is that doing this will cost a fortune. People tell him that this is a different world, that customers have become more demanding. He thinks this isnt true, people are getting fed up with bad service and their attitudes towards service have changed.
You can still hold people to account by measures that are derived from the purpose of the system. Measures derived this way create method. Inappropriate methods are easier to spot and change in a Systems Thinking designed organisation.
In closing, John asked how many of us are building cars to demand? The answer none. So why the insistence of trying to apply manufacturing examples to Lean implementations? He has become preturbed by the Lean Toolheads and is unhappy at Womack and Jones interpretation of TPS in their Lean writings.
John mentioned that Tescos are forming a banking venture, they have some Systems Thinkers in Tescos who are part of this venture, so it will be interesting to see what the outcome of this new service will be.
Finally he mentioned that people in the work once freed, become motivated, they spot problems and fix them, well before they come to the attention of auditors.
Part 2 – Aviva Experience – Shona Murray and Coastal Housing Experience – Tim Blanch
Part 3 – Making Measurement work for you workshop – Jeremy Cox
Another great paper from Vanguard on Failure demand.
This paper by John Seddon, Brendan O’Donovan and Keivan Zokaei (originally developed for a Warwick University course) explores the development of ‘factory thinking’ in the service management literature, with its emphasis on standardisation and off-shoring in order to achieve economies of scale and reduce unit costs. It argues that the development of the ‘lean’ movement continued this focus on managing cost and activity. As a result, ‘lean’ became synonymous with ‘process efficiency’ and the opportunity for significant performance improvement as exemplified by Toyota was lost. By revisiting the ideas behind Ohno’s Toyota Production System, a systems service management archetype is instead proposed as an alternative.
