Category Archives: Uncategorized

How to “restart” your Improvement Journey – A facilitation guide

Estimated Reading Time: 6 minutes

Previously on “The Agile Journey”…

So some time ago – maybe months or years – you decided to go for Lean/Agile. You went ahead and started to use Scrum/Kanban to break the waterfall and achieve a more agile operation. These were exciting times. First, that time of making sure you understand what you are trying to achieve, checking out all the options, building the plan. Maybe forming new teams, maybe not. Maybe you went for an evolutionary change or a big revolution. Then, training people and helping them start doing things differently. You probably had some help from consultants along the way or maybe you had enough experienced/process-curious people on staff to get through this on your own. You spent some months stabilizing things – taking care of all the impediments that surfaced to us the “Scrum speak”.

And then, after all this excitement, it seemed like things were actually working. Everyone felt that. It seemed like the journey was finally over. Maybe you even took a look at the goals you set to yourself and saw you achieved at least a major improvement. Maybe things just felt ok. Slowly (in some cases not so slowly…) everyone’s focus moved elsewhere. The retrospectives started to feel routine. The stabilization board started to grow rust. You reached a new plateau of performance. And it was ok.

(As external consultants we used to be frustrated by this plateau. It felt like there was a lot of value we could still provide the organization and nobody was listening. I talked about it back in 2012 in both the Scrum Gathering in Atlanta and the LSSC12 Lean/Kanban conference in Boston. When we defined our AgileSparks way we called this the “Recharge” phase – it comes after you finish “Stabilizing”. Naming it helped us deal with it – starting with the understanding it is natural)

At some point, you decided you want to get back to the journey. (Yes, you might notice there is a big question here of what are the triggers to get back to the journey and can we do anything as internal/external change agents to help organizations decide to get back to the journey at the right time – not too early but not stay stuck in this plateau too long? maybe in another post…). And you are wondering what are some effective ways to do that.

How to move from Recharge to Improve

(First, there are probably countless ways to do this. I’ve done it several ways over the years, I’m sure you have too. If you have a way you would like to share or already shared, please let me know in the comments, I’m really looking for practices people find useful for this stage of the journey. I just decided to share one of my favorites I’ve been using frequently lately)

ReStart with Why

One important step before doing anything is making sure you understand why you are doing it and what you are trying to achieve. This is especially important in the case of moving from recharge to improve because you are trying to nudge a system that is stable so you must understand the importance of moving it. A classic short movie that makes sense to see in this context is “Overcoming Resistance to Change – Isn’t it Obvious” (This is based on Dr. Eli Goldratt’s work in Isn’t it Obvious). You can show the movie to your team and follow it up by a discussion of how it applies to your current context. This is VERY similar to running a SWOT (Strengths Weaknesses Opportunities Threats) exercise, so you can do that instead.

An even more structured way I found useful in the lean/agile context is to give people concrete options for the Strengths – Reasons not to change/Weaknesses – Pains of not changing quadrants in the SWOT/resistance to change analysis. These options are based on the “Starting with Why – Goals for Lean/Agile Journeys” slide deck which we often use at AgileSparks.

Starting with why – goals for Lean/Agile from Yuval Yeret

If you are co-located you can do this by showing the slide and asking people to dot-vote on 2-3 goals they would like to focus on. If you have more time, start with scoring on all of the aspects to set a baseline for the future. If you used this to kickoff your agile journey you have the benefit of continuing the same language and getting the benefit of seeing the differences from the baseline you took when starting the journey. Even if you didn’t, setting a baseline now can be a good idea – you can get back to it a couple of months into your Improve journey and check where you are and what you should focus on next. In any case, the point is to look at where you are and choose areas you want to focus on improving – at the level of
Goals, not Means (That is important! As a facilitation tip – try to keep the discussion at the level of purpose/goal rather than means at this point.)

If you are distributed or want people to prepare beforehand you can do this with the facilitator marking colored circles on a powerpoint slide (as can be seen above), work together on a google spreadsheet, use an online survey like the one here (I made the google spreadsheet used to generate this publicly available here) to get people to think about it either online during the session or beforehand, or use your favorite collaboration tool/approach.

In any case, at this point you should have 2-3 clear goals to focus on. Maybe these are the goals you originally decided to start your lean/agile journey for. Maybe they are different. The group from the first example above started the journey to improve flexibility, reached a good enough level and then moved to other goals.

Assess where you are (with regards to the fitness Goals you chose)

The next step is to assess your current reality and gaps that affect your performance in the aspects you chose to focus on. One way to do that is to simply run a focused retrospective with that goal as the theme. You can do it as a “World Cafe” (or your favorite subgroup based meeting design method) – in essence working in subgroups on the different goals and sharing notes and outcomes. If you are distributed or want to do this part as preparation to meeting face-to-face you can run this as well online as surveys using something like http://www.perfectiongame.org/ asking what is our current level, what are we doing well, what can improve our performance.

Another more structured way to handle this phase is to run a depth assessment. I like to use our own Lean/Agile Depth Assessment but feel free to use whatever you like.

Lean/Agile Depth Assessment Checklist A3 from Yuval Yeret

Here you see a group that took our assessment. You can see their scores in each of the aspects of the assessment. After taking the assessment people understand more what each of the assessment areas mean and are able to map how relevant they are to the improvement goals they chose. In this case you can see for example that the “Empowered Teams and Individuals” assessment area was mapped to the “Engaged People” and “Sustainability” goals. After this mapping they could now choose assessment areas to focus on. We can see here “Empowered Teams and Individuals” was one of these areas. (You can ask “Isn’t this something they should have started with?” and my answer is that it depends. In many cases people don’t really understand what it really means when they start the journey so even if they try to do something they don’t get far. And others focus on goals that are lower in “Maslow’s hierarchy of needs” and then realize this is an area that they need to work on more. )

Now, within each assessment areas, look at the specific gaps you have and choose a few that are the most relevant for the goal you are trying to work towards. Take these gaps and add them to your improvement backlog.

Another approach is to look at something like the AgileSparks Way which has a catalog of options for the improvement stage and choose options that you feel as a team are most relevant to your choice of goals. This can be things like running the assessment, examining team formation, going on a WIP diet, going on a frequent releases exercise regime, etc.

From here on it is a matter of executing improvement/change. But you have strong forces on your side. You engaged people as part of this fair process (maybe it was your management team, maybe everyone). You started with why. You set concrete improvement goals that are mapped to concrete action items.

One last thing you might want to do is to run a vote of confidence with everyone who participated in the process to see whether they think the plan makes sense and is worth pursuing. And if not, iterate and fine-tune until it does.

As an interactive session I would recommend setting aside about half a day to a day for this activity. Ideally offsite as an opportunity to open your mind and think creatively. “Doing Food” never hurts as well.

References

An Agile Change Journey Blueprint – The AgileSparks Way from Yuval Yeret

Do Craig Larman’s Laws of Organizational Behavior really mean we always need to start with a structural change? What do they say about starting with Kanban?

0 Comments

Estimated Reading Time: 2 minutes

I’ve been following Craig Larman’s work for a while now. I find the books he wrote with Bas Vodde on scaling agile to be very insightful and actionable.

I recently discovered Craig’s “Laws of Organizational Behavior”:
1. Organizations are implicitly optimized to avoid changing the status quo middle- and first-level manager and “specialist” positions & power structures.
2. As a corollary to (1), any change initiative will be reduced to redefining or overloading the new terminology to mean basically the same as status quo.
3. As a corollary to (1), any change initiative will be derided as “purist”, “theoretical”, and “needing pragmatic customization for local concerns” — which deflects from addressing weaknesses and manager/specialist status quo.
4. Culture follows structure.

And as a practical advice Craig adds:
i.e., if you want to really change culture, you have to start with changing structure, because culture does not really change otherwise. and that’s why deep systems of thought such as organizational learning are not very sticky or impactful by themselves, and why systems such as scrum (that have a strong focus on structural change at the start) tend to more quickly impact culture. i discovered that john seddon also observed this: “Attempting to change an organization’s culture is a folly, it always fails. Peoples’ behavior (the culture) is a product of the system; when you change the system peoples’ behavior changes.” “

So do these Laws mean we always need to start with structural change? With a move to Feature teams for example like Scrum prescribes?
I find the laws provide an interesting perspective about a typical challenge I see at my big enterprise clients. The structure is definitely providing a glass ceiling to improved performance. Sometimes the performance is at that glass ceiling but in many cases it is way below it.

At this point we have two choices (at least) – one is to do what Craig suggests and start with a structural change. In the cases where the organization is ripe for change that would typically be the right move. In many cases though the understanding of the need for a big change is missing. There is mistrust that the new language/approach/structure of agile/flow/feature teams will work and will address problems the organization cares about.

An alternative is to use an understanding-focused tool such as the Kanban Method to both improve the performance w/ the current structure but also to show its limits/glass ceiling. At some point the organization will have to decide whether the performance gains it got within the current structure is enough and whether it is stable/sticky within the current structure. If not, the leaders will now need to change the structure to break the glass ceiling and enable the next jump in performance.

I see this pattern a lot in the field in various sizes of organizations – Kanban used to show the way towards a real structural change towards an Agile structure of real feature teams. It typically drives a healthy leader-led change that eventually sticks.

Bootstrapping Agile (by yourself) using Kanban – My Agile Israel 2013 talk

0 Comments

Estimated Reading Time: 3 minutes

Agile Israel 2013 took place yesterday. This year was they year of “Hands on”. Around 600 attendees came to get practical hands on advice on multiple aspects of the agile world. My talk was about running your agile journey on your own.

This talk was aimed at people looking into agile or exploring ways to go agile for “group level” and above. I presented a mind map I recently created based on work I’ve been doing in the field the last 2 years and some experiences of other coaches on the AgileSparks team. I also mentioned some aspects of the recent and excellent Kanban Kick-Start Field Guide.

I also experimented with a hybrid delivery approach for this session. I started with an Ignite/Pecha-Kucha style run through the 37 frames Prezi using 20 second auto-advance. Together with a short intro to what I’m going to do took about 10 minutes. Then I allowed serious time (something like 20 minutes) to deep dive of areas the session participants found especially interesting or unclear. This felt quite good as a speaker, and I got some good feedback from people in the audience, as well as some people who didn’t really like the session (red dots – no explanation why…)

The first question was about where how to choose which teams to start with, how to deal with different approaches for different teams, which was a good chance to explain my “Starting with Managers Kanban” approach in more depth – basically starting with value streams rather than component teams, then explore real value-stream/feature teams, then scale to more and more value-stream/feature teams as you grow your maturity, understanding. I think it is especially useful when exploring agile on your own, as it ensures the leads/managers are into it before you go into deep painful changes that are beyond your pain/skill threshold.

Second came up another one of my favorite challenges – how to make sure improvement happens. I took this opportunity to explore this area of the mind map in a bit more depth, basically addressing 3 key areas:

The need for purpose/urgency (connecting the drivers for agility with relevant metrics)
The need for clear actionable steps beyond just “improving” and “retrospecting” (here I described the concept of “boosts” to use the term coined by the Sandvik people in their great Lean Kanban Central Europe 2011 talk as well as gave some examples like Maturity/Depth assessment, Learning about variability, Learning about bottlenecks and Theory of Constraints, Learning about Rightshifting and how to use it to energize further mindset shift.
The lack of progress on identified improvement actions. Here I talked about Personal Kanban for leaders and management teams as a way to create discipline of execution and Improvement Kanban Board to make sure improvement actions are first-class citizens in your execution routine

BTW, readers interested in this topic are welcome to look at my Lean Systems and Software Conference 2012 talk – The Improvement Journey.

The last question we had time for was about my favorite visualizations. Kanban boards obviously. But I also talked about the Talent Matrix and how to use it to grow versatility in a way that is collaborative and inclusive. I also mentioned dependency boards and hierarchical kanbans that can be useful when applicable.

One of the questions people are asking me is obviously do I really believe people can bootstrap agile on their own with Kanban? My answer is that it obviously depends. If you have a great leadership team, the need and motivation for agility is clear, there is the ability to invest in learning on their own, the time to spare for experimenting and taking time to recover from wrong turns, then probably you can make it on your own, at least most of the time. Having someone who knows what they’re doing around can reduce risks, help recover faster from wrong turns, avoid some unnecessary mistakes. This provides some “risk management” as well as acceleration of the bootstrapping and improvement process. Note that even if a coach is involved I believe great coaching still leaves most of the work at the hands of the managers/leaders of the organization and still requires experimentation and evolution by people on the ground.

While obviously attending a 30 minutes session is not enough to make this happen (dear attendees, don’t expect a Certified Kanban Boostrapper title…) I believe we can help change agents use this approach to bootstrap agile in their organizations. If you want to learn more about this approach, we are considering a “deep dive” workshop that will get you to that level – including Kanban, the Implementation approach, the different Boosts and Models mentioned, and other tips and tricks we use at AgileSparks to help organizations improve. Leave me a comment here or at AgileSparks if that is something that interests you.

Implementing the Kanban Method using Scrum (a.k.a Scrum with a Kanban spirit)

0 Comments

Estimated Reading Time: 9 minutes

Warning:

If my last postrattled your cage, let’s see how you like this one… This post is a thought experiment. This hasn’t been tried in the field, and might be the worst idea in the world. But at a minimum it might be a way to understand better Scrum and Kanban. Let me know what you think.

The Context

Let’s assume a client or stakeholder in the organization wants to go agile and Scrum has been dictated to us – something like “Hey – I heard Scrum is a good thing. I want one of that please. I don’t care about other kinds of approaches. I want Agile. Agile==Scrum. Give me Scrum. Scrum. Scrum. Scrum.” (only SLIGHT exaggeration of real life…) Let’s also say we like the Kanban Method of evolutionary change management towards Lean/Agile and we actually believe it is a better approach to change management in the discussed context. So basically it might be a nice idea to give the organization what it wants – Scrum, while giving the organization what it needs – an evolutionary approach to change management. Is that possible? Let’s try to use the Kanban Method thinking and principles while implementing them using Scrum practices and building blocks. Here we go, enjoy the ride…

Foundational Principles:

Start with what you do now

Well, Kanban says to start with your current way of doing things. Scrum is perceived as a revolution, so let’s see along the way whether we are able to minimize the changes to the current way of doing things.

Agree to pursue incremental, evolutionary change

This is actually quite easy to live with since Scrum is also an Inspect and Adapt framework that seeks to look for incremental evolutionary change using Scrum as a baseline.

Initially, respect current roles, responsibilities & job titles

Here comes a tough one. Scrum comes with roles, responsibilities and some might say even job titles. Let’s see how we deal with those. One way is to say forget it. I know you’ve read about Scrum Masters, Product Owners and the Scrum Team. But we believe there is no need to change roles & responsibilities up front not to say define new job titles in the organizational structure. This might work and is a reasonable approach but is quite a “cop out”. Lets try to go a bit deeper …

Scrum Team

At least the Scrum Team is quite core to how scrum works so we can probably say that we will define Scrum Teams that will not make any change to existing organizational structure. If we want to play strictly to “start with what you have” we can map Scrum Teams to the current functional teams whatever size they currently are and whatever skills (or lack of cross-functional skills) they currently have. A major alternative here is to start with “Managers Scrum”. See “Managers Kanban”for the general idea. Applied to Scrum this means leaving the individuals/actual teams alone for the moment. Just create a “Scrum Team” that is comprised of the managers of the relevant functional teams. These managers will run Scrum together for a while until they learn the ropes and are able to go sell and deploy Scrum with their teams, or alternatively decide that different teams might be needed before deploying Scrum fully… I will probably elaborate on this approach in a separate post. Let me know if it interests you to push it up the priority rank…

Product Owner

I would ask the organization who decides priorities or align priorities amongst multiple stakeholders at the moment, teach the “Product Owner” role and responsibilities and start with the people currently involved in the prioritization and backlog grooming activities wearing the “Product Ownership” hat. If needed, they will do it as a team. It is far from being the strong Product Owner that Scrum advocates, but we will evolve in a direction that deals with product ownership issues if we see that there’s a problem and that the Product Owner is the right solution. Some in the Kanban community have a strong case against the Scrum Product Owner. I have to say I’m on the fence on that one.

Scrum Master

Oh the Scrum Master… Well recently even in pure Scrum implementations we (AgileSparks) talk about the Scrum Master being a management style that should be undertaken by the individual leading the team (yes yes we believe that even self-organizing teams should have a leader that enables this self-organization). So I find it quite plausible here to talk about Scrum Master being a very good description of the coaching style of management that teams need in order to gel and perform better and better over time. And then I say we don’t need to define any specific role like that but the people leading the teams should be inspired. For sure we don’t define Scrum Masters as a position in the HR system. What we might do is find a great coach/practitioner candidate and ask him to play the “Scrum Master”/”Kanban Practitioner” role for the organizational unit (several teams)

Encourage acts of leadership at all levels

This is quite orthogonal to the actual flow framework we are using. But since Scrum is notoriously exclusive of managers (at least the perception is that it is…) lets make sure that managers understand they need to lead their teams to better and better performance, better and better alignment with what users/customers value. Of course Scrum Teams should show leadership by self-organizing to perform better and better. Those leading teams should show leadership by investing energy in team building and performance, decentralizing control while ensuring alignment with the organizational initiatives and values.

Visualize Work

First actual step is decide which teams comprise the flow of work and visualize the work flowing in and out of those teams using Kanban Boards and work in the teams using the same Kanban Boards or Scrum Task Boards if someone finds a very good reason to do that. Note in this step there aren’t any sprints or ceremonies yet.

We will use a Product Backlog with Product Backlog Items to visualize the “incoming”/”future” work. A Release Backlog can be used to visualize the subset of that work that is targeted for the current release. Work already in progress or done in this release will also be in the Release Backlog but with a status indication of the work state. Based on this information we can understand how far along in the Release Backlog we are and how the Release is doing. A Release level Cumulative Flow Diagram or Burnup can also help us visualize Project/Release state and help us feel safe and aware of what is going on.

Manage Flow

Now that we have the flow visualized we need to manage the work with the concept of flow. Here Scrum gives us some clear guidance that is helpful.

Iterations

We will work in Iterations of 1-4w (Also called Sprints although that is a horrible name. Sprinting should mean short-term acceleration to deal with a special situation. Iteration pace should be sustainable). Let’s assume a cadence of 2w here as that is a reasonable iteration length that many times use successfully and also allows a good frequency of flow management activities. So every 2w we will have a “Business Day” in which we hold :

Iteration Demo – review the completed work of the last iteration and get product-level feedback on it with relevant stakeholders. The completed iteration should be available as an increment of Potentially Shippable Product which means all items completed are working tested software and the relevant build is a candidate for shipping after no more than a short (few days) hardening.
Iteration Retrospective – review and adjust our processes based on the last iteration
Iteration Planning – based on what’s next on the product backlog, product-level feedback from the Demo and process-level feedback and decisions from the Retrospective, We pull backlog items into the next Iteration. Pull = We take in the right amount of items to have an effective iteration. Not too few to avoid being bored. Not too many to avoid too much multi-tasking and context switches and the danger of not completing anything. Another meaning of Pull is that the team working on the iteration does this planning and makes those decisions. It is important to have a couple of more product backlog items queued up in case we are able to accomplish more than the amount we pulled. The purpose of the planning to is to establish this focused “Iteration Backlog”/Forecast and verify everyone on the team and in product ownership on the same page regarding what the relevant product backlog items mean, the priorities between them, how they will be demonstrated in the Demo, and the level of quality/functionality expected to say they are done (Definition of Done / Acceptance Criteria).

Every day of the iteration we will hold a short (10-15min) “Daily Scrum” standup meeting in which we manage the flow within the Iteration. In this meeting the Team and Product Ownership meet in front of their visibility board (Kanban / Taskboard). They talk about flow since last meeting (What I did last day, what cards I moved), expected flow until the next meeting (What I intend to work on today, cards I’m about to Pull/Complete) and mainly impediments. Impediments can be work item specific or flow problems (bored waiting for devs to deliver something, seeing too many defects in what was delivered feeling uneffective, etc.) Impediments can be solved quickly in this meeting or taken offline by identifying an owner that will deal with them until the next meeting. Items with impediments/blockers can be marked using a special indication on the visibility board. Systemic Flow impediments can also be marked (e.g. mark the interface lane between Dev & Test with a red post-it saying “Nothing ready for testing 23/9”.

Implement Feedback Loops

Note that since we implemented Scrum ceremonies we are already deep into Kanban Method’s “Implement Feedback Loops”. The Iteration ceremonies provide feedback loops about Product and Process. The “Daily Scrum” provides a tactical feedback loop. Some teams learn to use the “Daily Scrum” to have a tight light-weight process feedback loop as well and add “Kaizen Moments” as necessary when dealing with what appear to be systemic impediments.

Make process policies explicit

We also made some of the process policies explicit by setting the “Definition of Done” of items to be declared Done at the end of the iteration.

Now’s the time to make more of our current policies explicit. Use your current de-facto ways of operating. You will have a chance to change/improve them in your process adaptation feedback loops:

What is the level of readiness of a product backlog item before the team is ready to pull it?
Any definitions for the interfaces between roles in the team?
Any other clear policies governing the work of the team, relations to product ownership, etc.? Estimation policies? Defect Fixing? Release Criteria?

The Iteration ceremonies we defined are also explicit process policies. They answer questions like how do we replenish the system, how do we deliver, etc.

Limit Work in Progress

Now after we have a flow system working, it is time to apply the real pressure. We need to constrain the system to guide it towards better flow. In Kanban we do this by limiting Work in Progress. Applied to Scrum this translates to constraining ourselves to work just on items pulled into the Iteration. We will not start working on any other item unless the Iteration is safely done. This sounds trivial, but when there are several people with different specialties on the team it is not trivial at all. It drives people to collaborate. It drives different pains/inefficiencies to the surface and requires us to deal with them.

Note that the Iteration focus is not the ideal way to limit WIP. It is not that clear and explicit and it is harder to go on a diet that tightens the WIP limit from iteration to iteration since the Iteration focus is based on velocity which might not improve so fast even if our focus is improving. Also note that in order for the Iteration Forecast/Backlog to be effective WIP limits we need to plan carefully our capacity and capabilities for the whole iteration to avoid taking on too much (and not challenging ourselves to focus) or too little (and straining our focus to an unrealistic and unhelpful level).

We can always later apply classic Kanban per-lane WIP limits of course. And since many people that want Scrum don’t really understand that the Sprint Forecast/Backlog is a way to constrain and guide improvement we can just skip to the easier and clearer approach of per-lane WIP limits. This will also make it easier to get across the end of sprint inefficiency.

Improve Collaboratively using Models

A remaining but important feedback loop is the Ops Review which is a data-driven feedback mechanism that increases accountability to improvement results and accelerates improvement activity. We will add this routine later on typically. There is nothing like that in Scrum but there is nothing saying it shouldn’t be done. Just add it on top of Scrum when the organization is mature enough for it. (I would say after a few months of managing flow and limiting WIP so the systems are stable, clear problems have been solved using Retrospectives, and it is time to seek more pervasive improvement opportunities. )

At this point we try to decentralize the improvement activity to the teams/people. We give them different models to use like Variability / Positive Deviants / Queuing Theory / Principles of Flow / etc. and expect them to suggest and execute improvement experiments and share successful conclusions for reuse by other teams.

Conclusions

I hope this article conveys the message that the Kanban Method can be applied using Scrum as the process framework. This can be useful in case Scrum is chosen by the organization due to various reasons but we believe an evolutionary guided change approach is a good fit for the context or we would like to complement Scrum with the useful change management ideas in the Kanban Method.

I’ve yet to try this in the field but the biggest risk I see in this approach is that Scrum IS focused on flow at the team level and there’s the danger of localized focus when using it as the main process framework. I also have an hypothesis that starting with “Manager’s Scrum” looking at the end to end flow rather than work at the team level this might be overcome.

I’d love to hear what others think. Does this makes sense? What would you do differently?

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

0 Comments

Estimated Reading Time: 11 minutes

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