These days more and more organizations think they are Agile
A couple of years ago when you talked to people about agile a common response “why should we”, “it won’t work here”, or “so this is the new fad? What will come next?”
Times have changed. And a sign of the fact that agile is becoming more mainstream is that it being diluted and a common response these days is “but we are already agile!”. I want to share a couple of questions to see if you are indeed agile.
What does it mean to be Lean/Agile
At a very high level what does it mean to be agile ? At a first level agile is an approach to development that embraces the complexity and uncertainty in both demand, specification and implementation implications by working in short cycles on small batches of work, constantly seeking fast feedback, and empowering people to work together focused on clear business goals, at a sustainable pace.
A second level of lean/agile is about embracing the complexity of the systems/processes used to take software from idea to realized value and using an inspect and adapt approach to let better approaches emerge. This is a much more pervasive aspect of lean/agile. Organizations fail to realize the real power and improvements are as a result of multiple iterations thru process experiments, always aiming to achieve goals of better delivery capabilities.
Are you delivering in an Agile way?
When you hear someone talking about being agile ask them:
Do your users/business stakeholders consider your delivery cycle fast enough?
Are you developing the Right things? Do you use your agility to drive small features to production to validate the value of a certain direction and then continue to deliver a pipeline of more small features while constantly evaluating feedback?
Are you doing things the right way? How much rework is there in your work? How much of the demand is generated by not doing things right the first time?
Are you improving in a Lean/Agile way?
And then ask some more questions that will dive deeper into the improvement aspects of lean/agile:
How often do you stop to reflect on our performance/capabilities?
Do you have a capabilities goal/condition you are striving for? How many people are aware of it?
How do u know your current state compared to that goal?
Do you run process experiments aimed at improvement towards a target condition we are focusing on?
How many of these process experiments do you try in a month?
What is the cycle time from deciding to work on a process improvement to finishing an iteration of the experiment on it?
What are the current main obstacles to improving towards your goal? How long have you known about them?
What it means
You might find that you have an “agile” organization that is not so agile when considering the service provided to the business.
In many of those cases when you dive deeper you will find a weak, unfocused or even nonexistent improvement engine/culture and a static process/system.
Doing scrum sprints, user stories, or kanban boards is just the starting point of the agile journey.
The main event is improving. Practices such us limiting work in process or focusing on a single sprint help with that.
There is a whole set of approaches beyond that – A3, five whys, retrospectives, operation reviews, statistical process control, the Toyota improvement kata, solutions focus, theory of constraints and many more – all used to improve.
Are you ready for the real world of lean/agile?
You might find this recent prezi useful to look at these multiple layers of improvement and the various approaches used.
Followers of the blog might recall an early new year resolution to get more value from I read. Well the new year is with us, but this post is about returning debt from 2011. Toyota Kata is MY 2011 book of the year. It started me on a lot of thinking streaks and opened a lot of threads for how to effectively do my job as a Lean/Agile consultant. I have to say that many threads are still open. But I recently reread some sections of the book, and it’s about time to talk about it a bit, especially since I keep recommending it to people.
As a practitioner of Agile and Kanban in software/product development environments, I love this focus on what REALLY makes Toyota tick. There’s certainly a lot of bad mouthing of Lean and Toyota’s approach to production out there, calling it tool-focused and mechanistic/unfocused. The Kata is book is very aligned with our view of Lean as Kanban practitioners – the key being the thinking about improvement rather than the actual tools.
Let me try to review it by trying to apply it to the context of a Kanban team.
The Kata starts with understanding the direction. Let’s say we bought the Kanban / Lean Startup cool-aid and are aiming at the direction of faster end to end feedback and effectiveness through having dramatically shorter Cycle Times.
Then we grasp the current condition. This is similar to the “Visualize the work” step in Kanban.
Establish the Next Target Condition can mean – ok now that we understand our mean cycle time is 8 weeks and it is unstable – ranging 4-12 weeks and the direction is towards a stable cycle time of days not weeks, lets aim at stable 8 weeks meaning to reduce the variability from 4 weeks in each direction to 1 week in each direction. Sounds like a reasonable next target condition to me.
Now we try to make that happen and encounter obstacles. We would need to overcome them.
The Improvement Kata talks about a daily cycle of looking at the current actual condition, in light of the current target condition, understanding the obstacles explaining the gaps between the actual and the target, and urging us to choose one of the obstacles and work to address it in small experimentation steps using the PDCA cycle (Plan Do Check Act). On top of this approach sits the Coaching Kata with Five Questions that are aimed at coaching people on using the Improvement Kata. The aim is for managers to coach their people in their improvement work.
This is great stuff. Really great. The key point here is the focus on the job of people to always improve in a focused way, and the job of management to work on improvement themselves but also work to improve the improvement capabilities of their people. Use this as a repeating building block, tie it to the value system
and objectives of people throughout the organization and you stand a real chance for improvement work to become part of your DNA.
I’m just not clear on how to implement this in Product Development/Knowledge Work. Our processing cycles are orders of magnitude slower than in production. Which means we either do coaching/improvement cycles without the ability to see samples of finished work – which invalidates the scientific nature of the experimentation cycles, or we have to suffice with much slower improvement cycles, which makes improvement part of the outer-loop cadence (e.g. retrospectives, operation reviews) rather than the inner-loop cadence (e.g. Daily Syncs). Which is a real shame because it seems Mike associates a lot of the power of the Kata with the fact it is done very often.
At the moment I’m planning to use the Improvement Kata / Coaching Kata for outer-loop cadence, but am still trying to find a way to run it for the inner-loop. If you have some idea or experience with this, help me out…
A possible direction is to do the improvement/coaching kata for local internal processes e.g. Dev/Test in the inner-loop. If a developer is using TDD then we can apply the Kata for his TDD cycles. For a tester we can do it for his exploratory testing sessions or for his test cases.
Having a reason to avoid relaxing processes
Toyota plant manager would likely say something like this to the assembly manager: “You are correct that the extra paperwork and first-piece inspection requirements are obstacles to achieving a smaller lot size. Thank you for pointing that out. However, the fact that we want to reduce lot sizes is not optional nor open for discussion, because it moves us closer to our vision of a one-by-one flow. Rather than losing time discussing whether or not we should reduce the lot size, please turn your attention to those two obstacles standing in the way of our progress. Please go observe the current paperwork and inspection processes and report back what you learn. After that I will ask you to make a proposal for how we can move to a one day lot size without increasing our cost.”
Think about the scrum team talking about the overhead of weekly sprints and asking to use longer 2-week or 3-week sprints. Or the kanban team complaining about low WIP limits. Or testers complaining about the overhead of Small Batches. I love this quote highlighting the use of a vision to act as a decision filter for such policy discussions. We are using 1-week sprints because it is bringing us closer to cycle times measured in days. We are using low WIP / small batches thru testing for the same reason. Now instead of trying to revert to longer sprints/higher WIP/larger batches, let’s observe what are the overheads that make sprints/WIP/small batches painful and let’s see a proposal for how we can be more effective using them. I actually started to use this approach in the last couple of months. An exercise I frequently run in management workshops is trying to think what would enforcing a WIP limit entail for an organization. What would be the obstacles. It helps with change management to have a chance to vent some obstacles and understand how other companies deal with them and how this group can deal with them, even without starting to actually enforce a WIP limit.
The important point is that without the overarching direction / north star, it is hard to remember the rationale for many of the lean/agile practices/tools. If we don’t remember we believe shorter cycles lead to faster feedback leading to higher efficiency, it is easy to fall into the trap of regression to easier more comfortable ways of the past.
Ability to work according to Sequence is an indication of maturity
Sequence attainment is a tighter process metric, which means if the assembly process has to deviate from the intended leveling sequence, then even if shipments are still made on time, you do not have sequence attainment for that day
In product development this is similar to pulling cards out of order from your input queue / Product Backlog. Skipping cards in the backlog is a good indication of a capability problem. A target condition can be “we always pull from the top of our input queue/backlog so that we achieve alignment with the value priorities of the business”. A typical obstacle for this target condition is a sparse skills/talent matrix. And a next step can be knowledge transfer or training.
The difference between a Target Condition and a Target
The Improvement Kata talks about setting Target Conditions, which are Process Conditions, which in turn enable reaching a Target Bottom Line result. It says that having outcome targets is important, but the means for getting to those outcomes should be the real focus of management work. This is quite different from how many managers see the world, especially in the era of Management By Objectives. We have a lot of work to do to teach managers to think about managing by Means in order to reach Outcomes.
For example Sprint Velocity is important, but more important is managing the means towards improving the velocity. So discuss the target condition you need in order to have a high velocity and manage the obstacles towards that. It can be “READY” policies, smaller stories, healthy Continuous Integration system, TDD or whatever you feel enables a higher velocity.
Vague Target Conditions
It is important to understand that specifying a target condition doesn’t mean we define the solution up front. We define the required condition up front, and let the solution emerge through experimentation cycles. We do have a desired behavior of the process we are improving at the black box level and we tweak the process towards the required behavior through probe-sense-respond cycles as defined in Cynefin for example. Bottom line in my understanding the Toyota Improvement Kata is compatible with Complexity Thinking.
Be hard on the Process – Be soft on the operators
What a great quote to start a retrospective with…
It means that if there are problems most chances are they are process related. The process needs to help people succeed. (individual and interactions over processes and tools?)
It is similar to deming saying 95% of what affects performance is the system. Rest 5% is people.
Or five whys striving to policy/system impediments/obstacles underlying people errors.
My view is that the role of people is to adapt the system/process so they affect more than 5% at the end of the day. That is the importance of the improvement kata and continuous improvement in general
There are currently no autonomous, self-directed teams at Toyota
Actually, Toyota even considers expecting people to autonomously own improvements “Disrespectful of People”. While operators and teams do participate in voluntary improvement activities, improvement is part of the job function of team leaders, supervisors/managers and engineers.
Applied to our typical agile team, what this would mean is that the main ownership for improvement lies in the hands of leaders/managers rather than the teams/engineers. Certainly interesting thinking. I do agree that managers/leaders need to lead the improvement efforts. I do think that using fair process and involving team members makes more sense in knowledge work environments such as product development.
Mike does talk about operators participating in improvement work – but mainly as improving their understanding of Kaizen and to help understand whether they are candidates for promotion.
A good take away is to let someone tackle a tough process/obstacle to consider whether they are ready for promotion. Maybe a better alternative than let them own a certain delivery objective?
To develop your own capability, the effort will have to be internally led, from the top. If the top does not change behavior and lead, then the organization will not change either
Managers should lead the improvement effort. Loud and clear… This actually means running improvement kata at a process and coaching their people in their improvement katas. Not a trivial request from managers. Think about the VP R&D overseeing the improvement kata at a testing process or coaching his Director of QA in his improvement kata for an automation challenge. Part of this problem is a Catch-22. In order for the organization to know how to do this they need to try it hands on. In order to have internal leadership managers need to try it first.
Part of the approach Mike suggests is having an Advance Team experimenting with the improvement kata hands on, before rolling it out throughout the organization. I actually like the implications, at least in theory. As a Kanban example, have senior leadership involved in using Kanban to improve a process, so they are proficient enough in the improvement process and its effects when Kanban becomes an improvement approach used more and more within the organization. How can we ask them to coach their people otherwise… This certainly helps with stickiness of the change/improvement effort, although it might slow it down or even block it from taking off in the first place in places which are not ready for it (That is a “Fail Fast” scenario which is probably preferable. We’ve all seen the stalled change initiative – it’s not a pretty picture, not for the organization and neither for the consultants)
coach only one target condition at a time, which generally means one mentee at a time
We typically use forums to coach people towards improvement. Mike’s recommendation to coach one on one is an interesting and challenging one. Need to think about it some more.
(1) a restatement of the overall theme (for example, “To develop improvement kata behavior in the organization”), and (2) a reiteration of “why we experiment,”
Another great quote to start a retrospective with… the current focus of improvement and the reason for experimentation, to facilitate open healthy focused retrospection.
I hope I sparked your interest in this great book. There is still lots of work to be done mapping the Improvement/Coaching Katas to Knowledge Work, but even at raw unmapped form there are great insights in this book. Highly Recommended.