BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Kickstart Agile the Kanban Way

Kickstart Agile the Kanban Way

This item in japanese

Bookmarks

Successful adoption of agile is related to the approach that is used to introduce changes in the organization. Organization can do a top down “mandated” implementation or use a different approach as described in alternative approaches for implementing agile. Kanban can be used as a way to kick start agile, allowing teams to opt-in to agile practices when they feel ready for it to create a sustainable new way of working .

Yuval Yeret will talk about good and bad ways to kick start agile the Kanban way at the Lean Kanban France 2014 conference. InfoQ will cover this conference.

InfoQ did an interview with Yuval about kickstarting agile with Kanban, dealing with skeptics in agile adoption and comparing Kanban with alternative approaches for introducing agile in organizations.

InfoQ: What in your opinion are the main causes why organizations experience difficulties when adopting agile?

Yuval: One of the more typical scenarios is when organizations adopt agile without alignment on WHY they want to pursue this direction. This can either be due to agile being fashionable these days so many organizations feel left behind if they're not doing it, or when the organization actually HAS a good reason but when you talk to people in the trenches they are not aware of it or the dissatisfactions that prompted this move.

The classic "mandated large scale rollout" is especially prone to this dysfunction. When you give the marching orders and people need to go agile in order to be compliant the "user story" around why we are doing it typically gets lost in the communication.

Assuming effective communication of the dissatisfactions/pains and why agile might be a good direction we encounter the second major difficulty which happens when we push/shove agile practices/structures/roles down people's throats. All with good intention but without a "fair process" and collaborative decision making regarding what do to and at which pace. This robs people of their autonomy and reduces the chance of healthy engagement in helping the change succeed.

InfoQ: Can you explain what you mean with the Kanban way to kick start agile?

Yuval: We are talking about a couple of different themes/aspects here. The first is the Kanban Method created by David J Anderson. This method takes the stance of first understanding the system and the dissatisfactions from it. Then, without dramatic changes and with a lot of respect to how things are currently done and especially the people and their roles, you use visualization of the way things work together with a focus on managing the flow of work to start improving the way things work.

This improvement comes both due to the direct benefit of flow and smaller batches as well as due to the information and learning from watching the system using "lean/kanban goggles" and applying different diagnostic frames that can guide your improvement efforts.

On top of the Kanban Method one can use the "Start with Managers Kanban" approach which talks about choosing the value streams you use kanban with in a way that involves managers as much as possible early on - in order to get as fast as possible to a point where they understand the thinking and practices and are able to lead the way or alternatively to learn very early whether this direction is viable for the organization or requires adaptation.

This is quite the opposite to the typical agile rollout which focused on teams first and only scales to the "program" level later on. I'm talking about either starting at the "program" level kanban or choosing a key value stream and doing hands on kanban there but with heavy involvement of leaders instead of relegating them to be chickens/outsiders that automatically become skeptics/cynics.

By the way, If you look at the way SAFe implementations work you can find it is based on a similar line of thinking by the way.  "Leading SAFe" workshop for leaders as well as kickstarting Agile Release Trains together rather than first establishing working teams and later on scaling serves the same goal of assuring leadership engagement. But I'm digressing...

Another theme I've seen work well is "Pull-based change". In a big organization with several different groups this means looking at the organization as a market for your change initiative be it agile or whatever. And in this market you can leverage marketing strategies like "Crossing the chasm" which talks about evolving your product/change initiative to fit the current phase in the market - for example you will need to behave differently when you are working with innovators vs when you reach early adopters and you will definitely need to work on some aspects of the change when you reach the early/late majority.

But the most important implication is that your role as the enterprise change agent / management team is to market the change rather than force the change. You then need to enable groups to pull the change when they are ready for it. And when they want to go for it ideally they should be able to "configure their change" - what they want to do, at what pace, etc. I've seen this work well and it is very aligned with the Kanban concept of "Pull" obviously.

InfoQ: You are proposing that teams should decide when they are ready to adopt agile practice. How can we be sure that this will actually happen?

Yuval: We cannot be sure obviously. But we can try to maximize the chances they will "pull". This can be an interesting "Impact Mapping" exercise. The impact we want to have is "teams pull agile practices at the right time and don't procrastinate too much". There are different stakeholders that can help this happen - The senior leaders, coaches, peers, etc. And there are different actions that can help - success stories, measuring/celebrating/rewarding the right outcomes that will drive people towards a more agile behavior, exposure to the options/benefits, highlighting the dissatisfactions, etc.

Actually there is another challenge here. Depending on your context it might be quite problematic to do partial adoption of agile practices and especially agile roles. Here Kanban is quite helpful in that even when you start using it you start with what you have so you don't rush to create a chasm between the teams choosing to go for it and the teams choosing to go more slowly.

I find that the holistic inclusive nature of Kanban also lends itself quite well to the hybrid situations that will happen when some teams move faster than others. The fact that you don't necessarily change the roles and structure at least not initially gives the organization time to work through the change without a dependency on a wider structural change.

InfoQ: What can be done if a team decides that they aren't ready for Agile?

Yuval: If this team is standalone - meaning not part of a value stream / delivery network - then they can choose to continue to do what they are doing. Assuming the organization adopted an agile governance perspective this team will have a hard time shining and it might drive them to adopt some agile aspects.

This is the essence of "Pull based change". It is their option to pull. They are accountable to their results and they should adopt agile if it helps them deliver better results when the timing is right for them. And the organization should accept this and understand that teams move at their own pace.

If this team is part of a delivery network then it is more difficult to stay behind. This is especially true for teams that serve other teams e.g. by maintaining a service that many others rely upon. In this situation when the delivery network desires to improve their agility it will create significant pressure for this team to come along. which is ok.

If in spite of this driving force the team still thinks there are serious impediments to agility then it would be a very interesting area for intervening and figuring out what are the impediments standing in their way and focusing energy of the delivery network/organization on resolving them. I want to stress that this situation is different than forcing all teams to become agile. the rationale here is driven by business need rather than a mandate from above.

InfoQ: How do you suggest to deal with the skeptics, the people that are opposing to Agile?

Yuval: Using "cross the chasm" thinking I would say let the skeptic groups stay behind and join later when agile is proven and has become the defacto way of doing things. The skeptic people within groups that have decided to change should draw more of your attention. And the way to deal with them is probably to focus on understanding the source of the opposition.  Is it due to being too comfortable with the status quo? perceiving agile as the wrong approach to solving a real problem? The right approach but with real challenges that they believe the organization is not willing to tackle?

One of the key activities we (AgileSparks) focus on when we start to work with a new group/organization is a Management Workshop where we tackle the questions of why we are changing, what are our options, what will be the challenges. The skeptics have an important place as part of the discussion and help bring the reality into the room. We also see that having this discussion disarms some of the skeptics.

Those that remain need to be constantly reminded why the organization is choosing to change and what are the specific facets of agile that the organization/group believes would help them deal better with reality. I'd say this is classic change management work.

InfoQ: What are the benefits of using Kanban when organizations are adopting agile?

Yuval: I would say the main benefit of Kanban, Pull-based change and Starting with Managers is easing into the new world of Agile the right way. With healthy choice to join the journey, healthy sustainable pace of change with people pulling.

I've seen multiple cases where using Kanban helped organizations grow the capability to drive deeper and deeper changes. Some of them will then dive deeper into Kanban, some of them would adopt some of the more disruptive practices/structure changes like moving to a cross-functional team/org structure, breaking the release cadence and moving towards continuous delivery etc.

A specific mega organization comes to mind. They successfully leveraged Kanban at the program level cutting across 600 people in the past two years to break the waterfall, improve cycle times, identify and elevate constraints, and very importantly understand the "glass ceiling" their current structure posed and the potential improvement by breaking this ceiling. They are now moving towards cross-functional Scrum teams and groups, inverting their matrix, and adding a sprint cadence.

One could wonder why they couldn't start with that change 2 years ago. If you ask their VP she would tell you that they weren't even in a form/confidence to go and do such a change. It would have been an impossible highly risky leap of faith that they couldn't take. Now it is still risky to break the glass ceiling but it seems within reach. And they are starting from a shared mindset/understanding of seeing lean/agile concepts/practices work AND seeing the flow impediments and their impact so a big part of the change management/skepticism you would expect in such an organization is not such a big issue anymore.

InfoQ: How does Kanban compares to alternatives for organizations looking to adopt agile?

Yuval: These days these big enterprises looking to go agile have another option to consider, which I guess is worth discussing. I'm talking about the scaled agile frameworks - SAFe appears to be the most popular one these days. If you look at the agile/lean theory underlying SAFe and Kanban you will find similar inspiration - including Donald Reinertsen's Principles of Product Development Flow.

In both a SAFe program & a Kanban system you will find large batches and queues and other forms of waste. Both approaches talk about inspecting and adapting to minimize waste and maximize flow over time with Kanban probably emphasizing this a bit more. The main difference is the approach towards change management and the level of guidance/prescription provided. SAFe is much more prescriptive. The upside is the appeal and confidence this structure provides the mainstream/late majority organizations going agile these days. The downside of this prescription and structure is the perception it creates of being "closed" and "final" together with the fact that some of the practices/patterns in SAFe represent low maturity agility in order to make it accessible for the typical legacy enterprise.

Many in the lean/agile community especially those associated with complexity thinking are worried that organizations will adopt SAFe and stop there - leaving them doing a watered down version of agile.  There is certainly that danger because we know organizations are prone to do a change, stabilize it, and then fall in love with the new status quo. In AgileSparks we call it the "recharge" phase. And in many cases it is quite a long phase that can be measured in long months or even years. But to be honest, Kanban is not exempt from this problem. With Kanban the "recharge" phase still frequently happens, leaving organizations with another variant of "watered down" agility.

I guess many people are trying to decide what is the right approach for them. I'm afraid there isn't a clear-cut answer, at least not in my perspective. I mention in my talk the tourist metaphor. Some people like to take guided tours when they arrive at a new city. Some people like to read some books and check out some community sites. Others just wonder about and figure it out on their own. I'm not sure we can say one way is better than the other...

Rate this Article

Adoption
Style

BT