Tag Archives: Change Management

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

Estimated Reading Time: 4 minutes

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.

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

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.