A Minimally Valuable Agile Mindset (a.k.a Agile Mindset is more than one thing…)

Stickiness comes with Mindset

Today in our morning call the AgileSparks coaching team discussed what are some indications that a company/group has reached a stable level that they will continue to at least sustain and ideally improve from (which means we can sleep well at night knowing our mutual efforts are not going down the drain)

One of the indicators raised by my fellows was that everybody in the organization and especially the leaders are not just operating mechanically but also have an agile mindset and their de-facto decisions/actions show it. Examples that came up included “Letting Go/Stepping Back”, “Trusting the Team to pull”.

An Iterative/agile approach towards an Agile Mindset – It is NOT All or nothing

This brought up a discussion where I played the Devil’s advocate (Oh well, I didn’t play it) – saying it was a problematic indicator. Why? Isn’t agile mindset great? Yes it is. And examples such as the ones raised as well as “Fail Fast”, “Inspect and Adapt”, “Iterate”, “Accept incomplete information”, “Stop Starting Start Finishing”, “Treat inventory as waste”, “We can improve/grow” (a.k.a the agile/growth mindset) can all drive great decisions/actions. Continue reading “A Minimally Valuable Agile Mindset (a.k.a Agile Mindset is more than one thing…)”

Making Agile Teams work in real life – The quest for Stable Feature Teams?

Context

This post is inspired by ongoing discussions in the AgileSparks team based on our experience trying to help organizations make agile teams work in real life. It is heavily inspired or can even be called a revision of a post from a couple of years ago on the Lean/Kanban approach to teams.

If you look at the Agile Manifesto, you can find “The best architectures, requirements, and designs emerge from self-organizing teams”

Scrum, the most popular framework for implementing agile is quite clear about the topic (Quoting the Scrum Guide 2011)

“Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.”

The scaled agile frameworks popular today (SAFe, LeSS) also put high value on Scrum Feature Teams. All of this is with good reason.  As Al Shalloway writes Cross functional teams eliminate waste and manifest lean. I fully agree. So where’s the problem?

One of the big problems with cross-functional teams is that they require structure changes. Let’s assume though that we overcame this challenge. We get to the another big issue. As teams spend time together they gel and mature and get a chance to achieve higher performance levels (assuming we are doing the right things to nurture this performance and not kill it, but many have written about it before so let’s leave it aside for now). See for example Tuckman’s stages of group development model.

This is why Scrum recommends stable cross-functional teams. So, again, what’s the problem?

Well, if we have very high staff versatility meaning everyone on the team can do everything and all teams can deal with whatever is on the organizational backlog, we don’t have any problem. We can create stable cross-functional teams and they will just deal with whatever we throw their way (or whatever there is to pull from the backlog when they have capacity for it, if you want to look at it that way…). Very high staff versatility is a great idea. Extreme Programming calls it collective ownership. Others call it “Full Stack developers”. For some reason, I rarely see it in the trenches though. Maybe it is just the contexts I’m working with but the variety of technologies and specializations is such that there are very few “full stack developers” around. And as a networking/kernel specialist in my background I’m not sure I would have liked to spend lots of time coding mobile application UIs or SQL statements for that matter. So the reality we encounter is that of at least some variance of skills.

We can deal with this variability, right? We can simply build the teams in a balanced way that is tuned to what’s coming our way. Each team will take features of a certain “work mix”. Essentially this means we will have a product backlog for each “work mix”. The problem with that is that now we are dictating priorities based on the team structure. Let’s say we built a team that is Server-heavy (3 server guys 1 client) and a team that is Client-heavy (3 client guys 1 server). Both are cross-functional able to deliver end to end features but of a different nature. This constraints our capacity allocation to be 50% Server-heavy features and 50% Client-heavy features. Now what happens if we suddenly need to deal with a big need for features who require same amount of work in client and server? Yes we can force-feed teams this work and expect server guys to work on the client side and client guys to work on the server side, on both teams. Yes, this will be a good investment towards Collective Ownership and versatility. Hopefully it is something these guys will find interesting and useful individually. Hopefully they will feel it is a worthy cause. Hopefully the ramp-up time will not be too long. This picture becomes more complex the more skills we need to work on improving. This leads to many people finding it hard to create stable Scrum teams. They find it creates wastes.

Now, let’s pause for a second. In many cases this is just a symptom of fear of change. The difference between Stable Scrum Teams and Dynamic Scrum Teams can be dramatic from the perspective of management (especially those team/line managers managing people directly). In Dynamic Scrum Teams and surely when continuing to work without Scrum/Feature teams altogether people these team/line managers continue to “control” what is going on. They continue to “own” the people and move them around. They can continue to live in the illusion that their old style of management is the right style of management. The move to Stable Scrum Teams, even if it doesn’t change the formal organizational structure, leaves no room for doubt. The team/line managers are not in the loop of day to day work the same way anymore. They have to do things differently. They need to focus more on attending to the bigger picture, to the capabilities of their professional teams/lines (What Spotify call chapters/guilds and others call Community of Practice/Professionals). So one shouldn’t be surprised that they rationalize however they can the downsides of Stable Scrum Teams. (Thank you Chris Matts for sharing some thoughts about this topic of Staff Liquidity during our Feature Injection chat today).

With this in mind, maybe you are saying, the hell with it, let’s do this change. It is all political change resistance. We need to strongly communicate the need for it, manage the change correctly, sell people on being “full stack developers” and have the patience to deal with the lower productivity while we are investing in our liquidity/versatility. And in many cases this will be the right approach.

Maybe you are talking the “Start with what you have” approach of starting with dynamic cross-functional teams that are created and dissolved on demand with the rationale that it is a smaller change but is still a step in the right direction. And in many cases this will be the right approach as well. A word of caution though – Remember your goal in the long haul though – make sure that you are investing in improving versatility along the way and building the capability for improving the stability of teams without reducing the business flexibility. Invest in management skills and style that is more and more oriented around the “Community of Practice” and “Capability Building” so that managers don’t associate that strongly the “daily allocation” responsibility with their identity as a manager.

And one more thing – Regardless of whether you go to Stable or Dynamic teams but especially if you go for Dynamic – let people finish something before they start something else. Don’t put people on too many teams. Ideally a person should work on one team. There are exceptions. But if you find people are working on too many teams they should either work as a “shared services” team and not as members of all these teams or you need to stop some projects/features and wait until people actually have the attention for them. The fact that the Capacity Allocation Excel can find a way to squeeze that project in with fragments of a Full-time-equivalent to be there supporting it just in the weeks they are needed is a surefire recipe for overloading the system and affecting motivation, quality, velocity and cycle times. Jim Benson’s new book “Why Limit WIP” has a great section (Eldred’s story from chapter 7 onwards if I’m not mistaken) about this BTW. I loved the introduction of Learned Helpness as a result of this situation.

 

PS Sorry for not providing a clear-cut best practice. But hopefully I gave you some ideas about how to choose the right approach to start with in your context…

 

 

 

 

Sensing and increasing manager engagement during an agile change initiative – guest post by Yaki Koren

Earlier this week I published a guest post about how managers need to change if they want agile to succeed by Yaki Koren. Some blog/twitter followers asked for elaboration and Yaki was gracious enough to comply. I suspect the fact that this is a really hot topic for him this week helped. Without further a due, here is Yaki with some explanations of what the coaching team in his organization does to sense and increase manager engagement in order to improve agile change depth and stickiness… (Note Yaki doesn’t emphasize it but we are talking about a Kanban Method style of change initiative here which affects the kind of activities going on).
I was asked after the earlier post how do we engage managers and making sure they captain the ship. Here is a try to explain what we do (or at least what think we should be doing and when we do it, it works well).

As we are internal consultants it is quite easy to engage us – there are almost no bureaucratic barriers. We have developed a few techniques to protect managers from harming themselves by going down a dangerous path (for them).

As mentioned above we realized that a key success factor for agile implementation is a manager’s willingness to captain the ship. So the first thing we make sure is that the manager contacts us and not the other way around. We may do marketing, we may do an elevator pitch but the manager should call us, the manager should set the meeting. It’s a “call us, we don’t call you” thing. At the meeting we let the manager run it, state their need etc.

We keep doing this all through our engagement with the manager. We are making sure someone is pulling us and no pushing is done. When they stop pulling we, again, may do marketing and may encourage them but they need to take the action. If it’s not important enough for them they won’t do the action.

So, many times there are initial calls that die off and there may be a session or two and then it dies. It better die early when not too much damage was done.

Our main problem are cases where for some reason the process did start to actually run and the group moved to Kanban and then they stop pulling. These are sad cases with bad public relations, though I must say that even then it usually works better than the alternative.

Another thing we do when starting is asking the manager to budget us. We didn’t do this initially (we got the budget from top management) and when you don’t pay you sometimes don’t care. So now we’re asking for some budget, usually higher than what we actually need – and this proves to be a good test for the manager, another sanity check for their willingness to invest in the change.

When they lead it and agree to budget us we make sure they understand what are the big challenges they are going to face:

· Progress monitoring is quite different than what they’re used to – we tell them they will feel a loss of control at the beginning

· They need to invest more in day to day management – less status reviews and more execution (some managers don’t understand it: for them the change is easy)

· The process of work will keep changing. There is no winning formula we can give them – They will start with something and need to constantly adapt. It’s not a one-time bang thing. I should write a post on this aspect.

Since our organization is big sometimes we are not contacted by the person we believe is the one who should actually lead the change. Sometimes it may be a subordinate, their manager or even a peer. So they may set the meeting, they may even budget us but still we need the person who should lead this to actually show they’re serious.

This is more tricky.

You may find yourself in a room with a person whose manager asked him to do the change and the manager is not there at all. If they are not interested you are trapped. Suddenly it is you that wants this and you may find yourself pushing instead of being pulled.

What we do (or more accurately “try to do, really want to do, plan to do and sometimes it actually works”) is again to make sure this person wants it. We sit there, quietly. Many times they will expect us to lead this – however this is not ours to lead, right? So we may ask politely how can we help. You will get a deep frown doing this. And, by the way, it is fine if they tell you they’re there because their boss told them to. Then you need to understand together what is it they’re boss wants them to do. If they don’t understand why they’re there they need to get back to whoever arranged this to understand the reason.

Many times we have sessions with the project team. I like being in the center of things, giving a great performance, but it seems to be much more effective if the manager does this. I need to fight my ego and then do a good preparation with the manager (after explaining why they should do it) for the session. The more the managers lead the more effective it will be.

When we start the process we sometimes find we are becoming part of the operation. To avoid this we make sure we don’t attend all project meetings on purpose, we make sure nothing is dependent on us. This is the team’s thing, not ours. We are there to help, not do some of the job. Again, it is very tempting to do it – create the excel, lead the session, build the board – but every time we do this we skip a learning opportunity for the project team and increase their dependency on us. It is a matter of empowerment.

I believe there is more stuff but these are our main techniques for making sure only managers who are apt for the move to agile actually do it and when they do it to make it their thing, not ours.

The downsides of agile – guest post by Yaki Koren

This is a guest post by Yaki Koren who is the lead coach in one of AgileSparks’s clients – Amdocs Delivery who are going through a very interesting transformation leveraging the Kanban Method, crossing the chasm techniques as well as several key agile practices. It is also where I spend a considerable slice of my time the last year trying to help make this happen. And now – here is Yaki…

 

Last May I gave a talk at Agile Israel about the implementation we did in my company. At the end of the talk a guy from the audience asked what is the down side to agile. I must admit I never thought of it as it looked quite perfect to me. Eventually I answered that managers who like to micro manage will find the move to agile difficult.

 

Now after more than a year of implementation I think I have a better answer to this question.

 

We are doing the transformation to agile in many projects. Some succeed more and some less. In small projects (around 10-50 person months of development) it seems to go well most of the time.

The problem starts with the big projects. Here you see great differences. You come to the daily meeting and you think you are in a different company.

 

In some projects (where it goes well) you see the project manager leading the meeting, setting priorities, making sure all are working together. In other projects the project manager couldn’t make it to the meeting so some other person from the project management team is facilitating the meeting (less of a lead and more of a facilitator). In these projects the various parties of the project take the agile spirit to the direction of the wild west, including show downs when the sun is high in the sky.

 

The down side of agile is that managers actually need to manage. It is a down side to some and an upside to others.

 

It is not a simple task moving from playing the commitment game to constantly navigating the ship through the stormy seas of software development. Some managers get a new spark in their eyes when introduced to agile, feeling revitalized with new zest and vigor. Some try to play the old game under the new dress and there things go awry and frustration follows.

 

When we start an implementation we ask the managers why do they want to go through this. Now we are starting to tell the managers what is the expectation from them. What will be the change in their day to day. We believe this will help us better align expectations with the managers and to make sure we have better results with the implementation.

Starting with Managers Kanban (also called Product Stream Representative Kanban)

The short version

Based on experience helping organizations go agile in the last few years, an emerging attractor for healthier more sustainable results seems to be the “Starting with Managers” pattern. This is a “training wheels” pattern which seeks fastest learning of the managers in the organization what going towards an agile flow feels like and entails as well as the fastest learning as to whether that is an approach the organization wants to commit to and deploy. Basically all elements of Kanban – Visualization, Flow Management, Explicit Policies, Improvement Feedback Loops etc. are implemented with Managers. People are aware that it is happening but not expected to directly change their behavior at first. They might get different “directions” from their managers due to different flow decisions but they are not “pulling work” on their own. This pattern is a change management pattern that seems to generate more buy-in and support at the managers level, which manifests as faster “stop starting start finishing” thinking, lower resistance and viral distribution of kanban systems in the organization.

For more details, see below…

The Context

Let’s say we are talking about a group with about 50 people. This group works on several products or projects at the same time, with a functional team structure mapped to the technology stack e.g. GUI, Business Logic, Database, Infrastructure, etc. Each of those functional teams has a team lead/manager, there is also a QA group which is mapped functionally as well (though sometimes QA is already a bit more tuned to the product side). This can be either the whole R&D group of a small-medium product company, the IT unit of a medium organization, or a product unit at a bigger enterprise product company or one IT department in a bigger IT unit. The majority of engagements we run at AgileSparks are comprised of those atomic units, sometimes standalone and sometimes as part of a bigger enterprise engagement.

The Typical Approach

What we did until recently wouldn’t be a big surprise to anyone. We went in and implemented Scrum or Kanban at the team level combined with an end to end flow system typically using Kanban. You’d see the typical buzz and hassle of launching a couple of teams, training dozens of people, preparing backlogs and boards, and running iteration ceremonies for a couple of times until there is a stable agile framework running in the organization. Even when using Kanban it is still a big change to create all the teams, their kanban systems, teach them the ropes of how to manage flow, and work with each of the teams to start improving using WIP limits etc.

This approach has definitely been successful many times at bringing an organization to a “steady as she goes” agile delivery process. But I felt with so much energy invested into it it is a shame we cannot get even better results. We want to reach a “Continuously Improving” organization. And on top of that I always felt a certain friction/unnecessary tension while leading these engagements. In a combination of methodically looking to experiment with how we do things together with a string of “different style” organizations that wanted a different less “gang-ho” approach an alternative emerged.

“Managers are the biggest impediment”

The center of my exploration has been the role of managers in the success or stagnation of agile change programs. Looking back at previous engagements, in “Bright spots” I was typically able to create a stronger more involved management layer that drove agility forward. In cases where the focus was on teams and I couldn’t get managers to engage the results were mediocre. Every Agile survey you read says something about managers being the biggest impediment. They don’t support agile, they don’t enable agile, they don’t trust the teams, they are not patient, etc. I have a slightly different take on this.

I believe “Managers understanding is the biggest impediment”. They don’t understand enough about why agile and flow works. What is the role of constraints in driving improvement. What pull mode actually means. Many of them show a lot of good will and ask “What do you need for me” and get confusing answers. And we shouldn’t be surprised. We spend most of our energies and time on showing teams how to work in agile, why would the managers understand? Maybe it is my Israeli upbringing but as a Manager going on a new endeavor with my people I want to be first. I want to understand the deepest what it will entail. I want to be in front, not in the back. And so far we’ve been asking managers to take the back seat in agile change management programs.

So is the solution management training? Discussion of “Agile Thinking/Values” ? management offsite? These can be part of the solution, but if they end and then all the actual agile experience is at the team level with managers back doing their own things, I think it wouldn’t work. We are talking about changing the way the organization thinks and it’s de-facto mode of operation (Schein even calls this Organizational Culture). I believe in order to achieve that, managers need to run in front, be the first to try different ways of behavior, understand what they mean for the organization, and if they see it is a good way that should be repeated lead their people by example.

Start Small, Managers First

With this in mind, the concept of “Managers Kanban” emerged. This happened at around 3-4 clients around the same time with varying results but all of them quite encouraging ranging from stable and improving in a very difficult environment to another case with viral spread of kanban systems in an organization which is known to be very careful and measured in its approach to trying new things.

The concept is quite simple. Familiar with the Kanban Method? Great. Now choose an end to end Value-driven flow like a Product line or Project. Look at all the functional/technical teams involved as well as other stakeholders. Create a Kanban System that focuses on the interaction between those people. Typically the task-level work done by individuals engineers in the functional teams will be abstracted out a bit but in any case this system is like a chess board. Managers move their pieces and take action that they then translate to marching orders for their teams. When an event comes up at the team level the Manager is the one reporting about it at the end to end Kanban system. How do they manage their own team/people? I don’t care at the moment. Wait, I actually do care. I recommend they continue with what they did so far, at least for a short while.

One thing to note about this Kanban system is that it is a multi-level one. It starts with Features, moves to Minimally Marketable Features which flow end to end. When in development those MMFs are broken into User Stories. Each such story while in development can be in different states in multiple functional teams. These so-called “Team Stories” are visualized here in using different vertical lane per team, where each user story takes up one horizontal lane/position with a box in each of the team lanes to mark the involvement of that team in this story. The state of the work on this “Team Story” involvement is visualized by marking the box as empty=TODO, half-full=WIP (or even indication of % complete feeling e.g. 1/4 complete, 3/4 complete etc.), full=DONE (and waiting for the other Team Stories to be completed for the full User Story to move to DONE). This was a nice emerging visualization we came up with along the way. When they moved to an electronic tool (LeanKit Kanban) they started to use Avatars to just track involvement (It is very easy to track flow of Team Stories using the card taskboard capability though). A different company is using a somewhat involved swimming lane structure in Digite Swift-Kanban to visualize the same information. 

To manage/lead this Kanban team comprised of Managers we typically assign a higher seniority manager. His role is to design the kanban system with the team, manage the flow, manage the improvement work. The side effect is that we get the management chain involved, leading. In the best cases even the VP of the group was involved in the system design and flow management/retrospective meetings. Nobody is excluded. When you start hearing the VP saying “Is this inline with Stop Starting? Do we think that so many things currently in WIP is healthy? What do we need to do in order to reduce it?” you know that there is something healthy going on. In some cases the “Project Manager” was assigned to lead this Kanban team. The benefit is that we instill lean/agile thinking into the Project Managers very quickly this way. The downside is that we don’t get the same traction with the core R&D managers this way. I don’t believe this is a core problem with the approach, just something to fine-tune. The important point is to make sure senior managers of the functions do a lot of “Go See”/”Gemba” – come from time to time to flow meetings that happen several times a week, pay a visit to a retrospective, etc. Ideally each senior manager should be the sponsor of one of these “Managers Kanban” and be accountable to achieving good flow and learning.

A great side-effect of this is that as the coach (internal/external you get much more face-time with the managers to gauge and influence their thinking and behavior.

Another way to look at this pattern is to see it as an answer to the question “What is the minimum viable change we can try to show us whether managers can really start thinking and behaving agile/”Stop Starting Start Finishing”? On the way we of course also let them learn how real agile thinking/behavior looks like so if they are convinced they want it they are well-positioned to take the next step and deploy it more widely through the organization

 

Viral Spread

When things go right, managers indeed “get it”. They “get it” so clearly that they go out and experiment with Kanban systems at their teams without the organization even suggesting it. All they need is permission to experiment and boards start popping up on the walls or in the electronic kanban system. In one example we seeded two “Manager’s Kanban” product-stream level systems and after a month or so we saw about 5-6 team-level kanbans in both R&D and QA popping up. The Product Managers that were lucky enough to be involved in the “Manager’s Kanban” experiment talked to their friends who grew jealous and wanted a Kanban system for their Product-Stream as well. Before long the constraint became wall-space and time to help nurture those self-emerging kanban systems. This doesn’t always happen though. I’m still not sure what are the key factors for virality here. I tend to think it is related to organizational openness and the amount of leadership by example and commitment to the “Manager’s Kanban” shown by the core R&D leadership, but it is certainly an important area to do some research/experimentation on.

Results

 

When I look across the different case studies I see different depths of implementation after around 9-12 months. But the common factors are reduction in the observed pains that led to looking at lean/agile as well as stable system of flow management – Visualization, Manage work according to Flow, Have explicit policies governing flow. There is typically quite a shallow shaky discipline around WIP limits at this point (which is quite typical in general for this stage whether it is Scrum or Kanban style of WIP limits being used) but there is the understanding and awareness that it is shaky and should be improved. There is also a shallow improvement practice/culture. Retrospectives and Kaizen moments but no model-driven improvement and no operation reviews, just initial sparks of looking at metrics and using them to drive ideas for improvement.


 

There are strong encouraging signs that the organization is looking to stabilize the flow and improve it. I’ve observed steps towards Continuous Integration, Feature Teams, ATDD, Continuous Stabilization (get rid of the stabilization lane and include it in the definition of done of testing) all driven from seeing flow (or lack of it…). There is also a lot of fine-tuning around the structure of the kanban system itself. The board, the meetings/ceremonies supporting it, who’s involved, etc. There is a slow but sure trend of people from the teams becoming the representatives in the end to end kanban system, on the way to a full kanban system without the need for “representative democracy”.

Another interesting area of experimentation is what kinds of extra team boards to maintain beyond the end to end boards. At the start these were (quite naturally) standalone boards e.g. Infra Team and Infra QA Team on different boards). Over time we are seeing more and more integrated boards being experimented with as a way to reduce the synchronization overhead that comes with a complex network of kanban systems.

Why I think it works

My hypothesis is that this pattern ensures the most important parties and the “usual skeptics” are on-board before going further with the change, using a practical experience rather than conference room convincing. It creates a very natural demand for full pull systems that decentralize control rather than having that dictated by the change framework. To me it sounds a very natural consequence of Kanban Method thinking which is I guess why I found myself doing this before I deliberately thought of the pattern.

Challenges/Impediments

This is far from a perfect solution. There are many challenges here. Some of you might have guessed them already. The main one is that this is not a scalable way to manage an organization. If all work is managed using “Manager’s Kanban” then managers continue to be a coordination bottleneck. There is a limit to the amount of kanban systems a manager can take part of and since lean/agile means working with smaller batches/work items the coordination costs will actually grow higher. For example the Infra Team R&D manager needs to monitor needs from his team across almost all product stream kanbans, synchronize that with his own team kanban system, sync with the QA lead, etc. This is a serious headache and cannot continue forever especially if the organization wants to scale to more activities more people without growing the management ranks significantly.

This is why “Managers Kanban” is just a temporary “Training” pattern on the way to full flow pull mode. You can consider it a kind of “Concierge MVP” – the goal here is learning about what works and is viable as a flow model. It is not a viable long-term model of managing the work. It considers the main risk of going lean/agile being the ability of the managers to think lean/agile, think flow, act according to lean/agile decision filters. When this risk is off the table, it is time to go to the next stage which is sustainable lean/agile involving the individuals with managers supporting but not necessarily involved day-to-day in the flow of work throughout the organization. The classic next step is to create stable Product Stream/Project/Feature teams that will be able to work together with Product Management on a specific value stream. These can be cross-functional, functional teams or a mix depending on the kind of work the organization is facing. Read more about those teaming options in an earlier blog post of mine.

Where Next

It really depends on a case by case basis but there are some lines of similarity in the next steps decided on by the different organizations I’ve worked with. 

All of them are re-energizing their discipline and attention to Limited-WIP/Pull discipline. This includes monitoring WIP levels, trying to look deeper into reasons for WIP level exceptions, and providing the slack capacity to do something about the constraints leading to those high levels of WIP. In many cases this touches on the tough spot of Versatility of individuals and Collaboration between different managers and teams. All senior managers I talked with feel the pain of lack of collaboration between silos. And by now they all understand that implementing WIP limits effectively is a good way to drive towards collaboration, even without changing the organizational structure.

The other front is deepening the improvement routine. Retrospectives and chance kaizen moments are fine for the first steps of creating a stable system since the pains are very clear. But in order to sustain guided improvement the next step is to adopt something like the Toyota Improvement Kata as an organizational routine. This entails revisiting the goals/pains, setting up metrics that align with those goals and running a routine of improvement and coaching towards improvement, with Operational Reviews being a key part of continued engagement and accountability of the managers towards improvement.

Summary

I hope the initial shock of keeping the individuals out of the picture initially is wearing out by now… I would love to hear what you think about this pattern. Would it have helped you deal better with situations you encountered in the past? Would you consider using it? How would you improve it?

One question I’m playing with is how much of this is Kanban-specific and how much can be leveraged in a Scrum context. I tend to think one can create a “Managers Scrum” system but it is probably a bit more involved than search & replace kanban with scrum in this article… Expect a future blog post about this…

This is the topic of my upcoming session in Lean Kanban Central Europe 2012 in Vienna by the way. If you are around and interested, come and participate. I will try to make this an interactive session with room for opinions and ideas.

 

 

updated: Added “Why I think it works” section