Category Archives: Management

Who would have thought Personal Kanban would end up being the counter-measure to stalled Kaizen / Continuous Improvement?

Estimated Reading Time: 5 minutes

Paying attention to Management attention

I’ve been talking recently about the challenges of keeping sustainable sticky Continuous Improvement programs. An aspect I’ve mentioned but not emphasized enough is the lack of management attention. In this blog post I will focus on why management attention is so important in improvement programs, why is it lacking and what might we do about it.

Why we need management attention

Basically to change the system of work you need the attention of people that are in charge of it and can change it. If they don’t have enough capacity to work on the system you will end up stuck. You might find yourself focusing on local optimizations, you might even make progress in things that affect the overall system, but changing things like management decision filters, approach to targets (or lack of them…), relations between silos and the like will be difficult.

You might rightly ask: “Aren’t we supposed to trust the people working in the system and empower them to take charge of the system design and improvement?”. Yes we should! But getting to such a system typically requires significant change/transformation of how the system of “changing the system” works. You need attention of the people in charge of that system to change it. We’re back at square one aren’t we.

You might make a case for Guerilla warfare – working with people on the ground to change the system of work without showing up on the organization’s radar or at least without requiring formal support. That might work for initial “scouting” and establishing a case for new ways of working. I haven’t seen or heard of cases where the guerilla warfare was able to scale the change in a persistent healthy way throughout the organization.

So basically, can we agree that at least at some point of changing the system of work or system of improvement we need the people managing the system to start investing attention/capacity cycles in studying and improving?

For my inspiration on this term of “Management Attention” and it being the constraint of our systems you should watch Exploiting the Constraint: Management Attention by Eli Goldratt.


Why are we lacking Management Attention to Improvement work

Many managers don’t pay as much PERSONAL attention as we’d like to studying and improving the system of work or in the capabilities of their organization. Why is that?

Some managers thrive on urgency and opportunities for heroism. One can probably inquire about the ecosystem in which those managers thrive and who is responsible for changing that system. Basically as long as the organization cherishes and commends this kind of management rather than quiet steady capabilities-focused management we shouldn’t be surprised. The counter-measure? Seek to change this “policy” constraint which typically is driven from way up… This can be hard, but if you don’t deal with it don’t expect much traction.

Other managers DO care about improving the capabilities of their organization. They DO care about the system. They just don’t have the capacity / cycles to invest in it.

Let’s pause for a second and reflect on this issue from a different perspective. We’re all familiar with the team that is so busy delivering value that doesn’t have time to retrospect let alone take action towards improvement. What can such teams do? They can start by bringing their system of work under control using approaches like Kanban or Scrum. Then they can start allocating capacity to improvement. Scrum forces team to spend at least the “Retrospective” ceremony time for improvement but still many teams don’t take action based on the retrospective. Allocating capacity towards “Improving the system”/”Housekeeping”/”Engineering Improvements” or however you want to call it is key to getting actual results and feeling that the time spent in Retrospectives or Kaizen events is well spent. This allocation of capacity can be achieved in Kanban by always having one experiment in progress for example. Or one experiment in every Sprint Backlog if Scrum is more your cup of tea. So what can we learn from our advice to teams?

Personal Agility for Managers – Exploiting the constraint

A manager can start to bring his work under control by using an approach like Personal Kanban. Once under control he can start allocating capacity and attention towards improving. Improving his personal system of work, so he can free more and more capacity to strategic themes in his system of work. What might those be? For example driving and supporting improvement agendas of the organization he’s in charge of.

If managers are a key leverage point for improvement programs, we can also see them as bottlenecks/constraints for the “System of Improvement”. What we are suggesting here is to focus on this constraint and ensure managers achieve the best results they can with the time they have.

Decentralized Control – Subordinating to the Constraint

The next step is to subordinate to this constraint. Subordinating means to look at the system and finding opportunities to divert work from the constraint elsewhere, or do work in a way that makes the work of the constraint easier/faster. One way to achieve that is to Decentralize Control. If more and more work can be decentralized, we can free management attention/time. This can be “work” decisions such as what to pull, how to deal with conflicts etc. It can also be “improvement” work. They key though is to do it right. Not just decentralize but give good guidance as to the Intent of what we are trying to achieve. For a great talk on this subject watch Donald Reinertsen’s LSSC12 Talk.

 Takeaways for Lean/Agile Journeys

My current thinking is that helping managers improve their personal agility using approaches like “Personal Kanban” should be a key building block of successful improvement program. I started nudging managers I’m working with to consider this when I’ve seen them become the constraint for the “Improvement Journey”.

It shouldn’t come as a surprise that many of AgileSparks‘s current clients are exploring “Personal Kanban” in parallel to improving their wider systems. We are also working to help them pro-actively. AgileSparks coaches such as Danny Kovatch have been working on Personal Agility programs and approaches for a while now, Jim Benson exposed many people in israel to Personal Kanban in his Agile Israel 2012 talk as well as a workshop he ran when he was here.

A great side effect of working on something like “Personal Kanban” while running or preparing for a “Kanban Method” journey is that a key group of stakeholders for the journey are experiencing it first hand and leading by example. If they can “Limit WIP” and show to people they are doing it, there’s a higher chance that “Stop Starting Start Finishing” will stick on the team kanban board. Or on the portfolio board. It might be an interesting approach to start with Personal Kanban as preparation ground, even before management attention surfaces as the constraint. OTOH we might be working on a non-issue. If managers are not the constraint in a specific situation, should we still start with their personal agility? I can go either way on this, and would love to hear what other Kanban practitioners/consultants think.

Bottom line

There’s a good chance management attention is the constraint of your system. Identify if that is the case. Exploit it by offering managers “Personal Kanban” as an approach that can help them free scarce capacity. Subordinate to this constraint by Decentralizing Control intelligently while aligning using strong Intent. Leverage the cool side effect of having managers use similar approaches to take control of their work that their group is using to take control of its work.

TODO in a future post: How can we reliably identify if management attention IS the constraint? I have several thoughts on this, but will leave them to a future post.

Your turn

What do you think? Is management attention a typical system constraint? Is personal agility a good way to deal with it? Have you found other ways that worked for you?

The Scrum Sprint Commitment/Forecast as an Expectation

Estimated Reading Time: 3 minutes

Disclaimer –  I’m a well-known Scrum Sprint Commitment basher. But in the last few weeks especially while processing the Lean Conference Boston Keynote by Steven Spear I have a fresh perspective I wanted to share.

There is no improvement without learning

One of Spear’s key points was that there is no improvement without learning. There is no learning without surprises. There are no surprises without setting expectations. Specifically challenging expectations that will be missed occasionally. See a quote from one of his Harvard Business Review articles about how Toyota really learns:

We argued that Toyota’s much-noted commitment to standardization is not for the purpose of control or even for capturing a best practice, per se. Rather, standardization—or more precisely, the explicit specification of how work is going to be done before it is performed—is coupled with testing work as it is being done. The end result is that gaps between what is expected and what actually occurs become immediately evident. Not only are problems contained, prevented from propagating and compromising someone else’s work, but the gaps between expectations and reality are investigated; a deeper understanding of the product, process, and people is gained; and that understanding is incorporated into a new specification, which becomes a temporary “best practice” until a new problem is discovered.

I got a copy of Spear’s book the High Velocity Edge at LSSC12 and I intend to read it in the upcoming months to try and get more insights into this concept of Expectation-driven learning.

Expectation-driven Learning applied to Scrum

So one way to see the Sprint Forecast is as setting an expectation of how much work is going to be done before it is performed and committing to try working as effectively as we can to try and meet that forecast. Sometimes there will be a gap between our forecast and the real amount of work done, which is an invitation to learn about our real capabilities, our processes and our people and drive new experiments for how to deliver at a higher level. I see this as a healthy use of commitment.

This again explains why a team that meets its forecast each and every time might be a predictable team but not necessarily a hyper-productive team and for sure not a learning team. For learning you need hypothesize that you can stretch yourself a little beyond your current capabilities supported by an experiment for how to achieve that stretch. But hypothesis and experiments have this nature of sometimes succeeding and sometimes failing. So you would expect to sometimes miss your forecast and have to learn something from it. Again, no learning without surprises.

This frame of thinking by the way brings Scrum and Kanban even closer in my perspective. It re-emphasizes how working in a pull system driven by commitment to either WIP Limits or Sprint Forecast are very similar concepts of constraints and expectations – explicit process policies that drive learning. This learning is not less important than the ability to predict delivery outcomes that comes together with working in this pull system.

What can we do different tomorrow morning

Scrum Team? Make sure you set challenging sprint forecast, supported by clear hypothesis and experiments of how  you will reach that forecast while still in sustainable pace. Commit to try. Even more importantly commit to learn if the experiment fails. Remember this is a safe-to-fail experiment.

Working with Kanban? Make sure you set challenging WIP limits, supported by clear hypothesis and experiments of how you will sustain this WIP limit while still delivering. Commit to trying. Even more importantly commit to learn if you need to exceed WIP limits. Remember this is a safe-to-fail experiment.

Note the similarity between the two environments! same phrases chosen on purpose.

Manager? Give your teams permission to experiment. Expect them to experiment. Expect them to commit to trying and learning. DON’T expect them to always meet the forecast/WIP limit or you will slow down learning. Expect them not to ignore their commitments. Expect them to come to you with requests for assistance and ideas how to achieve lower WIP limits or higher sprint forecasts. Expect them to try some of those ideas on their own without any help. Finally and probably first thing to do – Teach them that there is no hyper-productivity without improvement. There is no improvement without learning. There is no learning without surprises. And there are no surprises when there are no expectations.



How does the performance objectives process change in a Lean/Agile world?

Estimated Reading Time: 2 minutes

Seems like every January I get questions from HR leaders in organizations I’m working with that go something like this – “We are working on the yearly performance objectives process, and we were wondering whether it needs to change in an agile environment?”

The main evolution I see in the Performance management process is leaning towards measuring up and across as well as focusing on capabilities improvement rather than a set of concrete product deliverables specified up front.

Measuring up will motivate individuals to become better team players in their teams, as well as be better connected to their business objectives.

I personally preferred capabilities improvement over concrete deliverables for many years even before I’ve been exposed to agile, but of course it makes more sense. There are many situations where you cannot specify deliverables up front these days. You CAN aim for a certain capability or improvement trend.

Another trend I’m seeing and think is useful is to give teams shared goals on top of individual goals. These are again capability-driven goals as well as business objective goals.

A couple of years ago I compiled a list of examples that some HR leaders found useful. Maybe you will find them useful as well. Below are some references I used to build this list and I think are a good place to start for HR professionals interested in the performance/professional development aspects of agile. They are a bit dated I admit, and those following my writing and twitter presence will find more stuff.

UPDATE: HR people are really excited about the AgileSparks Agile Leadership development program called LAST (Leading Agile Software Teams)

Individual and team goals

View more documents from Yuval Yeret

References - about how to measure/compensate in a group accountability environment
From my own blog – try to think about what something like the Toyota Improvement/Coaching Kata would mean for individual goal setting…
What resources do you find useful for HR in an agile environment?

“We are already Lean/Agile” – Really?

Estimated Reading Time: 3 minutes

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.


The Toyota Kata – Book Review and Thoughts

Estimated Reading Time: 8 minutes

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.

What is the Toyota Kata?

If you haven’t heard of the Toyota Kata book, you can head over to Mike Rother’s Toyota Kata Homepage where you can find good presentations about the key topics as well as a good synopsis of the book, which I won’t repeat here. At a very very high level this book is about the Toyota approach to management – which is to have a focused approach to improvement (The Improvement Kata) and a focused approach to teaching people how to focus on improvement (The Coaching Kata).

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 Improvement Kata

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.

The Five Toyota Kata Questions - Mike Rother

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.

One last note – if you are interested in this topic, you will probably find Henrik Kniberg’s Tokyo Scrum Gathering Keynote about Change interesting as well…