Category Archives: kanban

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?

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.

Helping with Kanban – Thoughts from reading Helping by Edgar Schein

Estimated Reading Time: 3 minutes

I recently read Helping: How to Offer, Give, and Receive Help by Edgar Schein (actually I listened to it on Audible and then read it again on kindle to better process/digest). I can highly recommend it if you are interested in ways to become a more helpful consultant, manager, person – one who is able to actually help people/organizations rather than just dispense advice/suggestions. I’m not doing a full review of the book here but there are a couple of points I found very interesting in the relation between the Helping approach and the Kanban Method, which I wanted to put out there. I will probably talk more about this in my Lean Kanban North America 2014 Interactive Workshop in San Francisco on May 8.

The key theme in the book is that in order to provide helpful help you need to be build the helping relationship – not jumping to the expert/doctor role of dispensing advise/diagnosing but first listening, understanding, working through what Schein calls Humble Inquiry which starts with Pure inquiry – understanding what is happening without trying to influence the client in any way. Only then moving to Diagnostic Inquiry which directs attention to other aspects in the story and Confrontational Inquiry which asks what-if questions thereby hinting at suggestions (which is close to the Doctor/Expert role).

“This kind of inquiry can best be described as accessing your ignorance and, because it is genuine inquiry, it is appropriate to call it humble. The helper becomes open to what may be learned through observation and careful listening. The helper’s expectations may be incorrect, and it is the helper’s willingness to accept new information that elicits trust and makes the client feel better about having a problem”

If we look at what we are trying to do with Kanban – it is quite similar. We start with understanding the system by visualizing it. Not trying to diagnose/probe too deeply before we understand – actually before the client/clients understand. Accessing our ignorance – we don’t know HOW the system is working, we don’t know how it SHOULD be working. Which is exactly what Schein is trying to do with process consulting – to build the understanding together, not be in a position to understand FOR the client but WITH the client. In Schein’s perspective this not only minimizes the chance we will dispense generic advise based on our experience of similar events but will help to equilibarate the relationship between helper and helped – listening and respecting the situation helps the client/helped gain back “face” that he lost by asking for help. If we don’t “bring the helped up” by doing this there is a chance he will “bring us down” by trying to be very critic and unaccepting of our suggestions by the way.

“Starting out in the process consultant role is the most likely to facilitate status equilibration and to reveal the information necessary to decide on what kind of help is needed and how best to provide it. Only when some level of trust has been established is it possible to get accurate information that allows the shift to the expert or doctor role. As the helping process proceeds, the helper may shift among all three roles many times as the situation demands.”

This humble inquiry approach is also aligned with our approach towards management workshops in AgileSparks. Our instincts over the years pointed us away from diagnosing and presenting solutions and towards a more humble exploration of the system/context in parallel to presenting some useful patterns like Kanban, Scrum, ATDD. I try to emphasize the diagnostic role of these patterns/frameworks and the fact that even when we go out of the room with a decision to do something, it is basically a continuation of this “humble inquiry” (I didn’t use the term until today obviously…). We are obviously shifting roles from process consultant to doctor and expert and one of my main takeaways is to be more conscious about the role I’m playing and whether it is the effective/helpful one at the moment. I’m definitely jumping to the doctor/expert one faster than I should – and I will try to work on that using some tips and tricks from the book.

To summarize – and as I answered Bob (Marshall) yesterday – this book leaves me: startled (discovering new perspectives of how I’m doing things), a bit ashamed (for being more of a Doctor/Expert), alert (to the potential of being more helpful using this approach) , curious (about whether I can actually leverage it and what will happen if I do), rejuvenated (by getting a fresh perspective to something so core to my work). So bottom line the Helping book was quite helpful.

Kanban FAQ: Should I FINISH what I’m working on or help the team READY new work items?

Estimated Reading Time: 3 minutes

Once people start to get “Stop Starting Start Finishing” thinking (Kanban) or the “Focus on the current sprint” thinking (Scrum) a frequent question that comes up is how to deal with people who are required for different activities throughout the work life cycle.

Some example scenarios:

“I’m a tester who both participates in ATDD spec. workshop (upstream) and exploratory testing (downstream). The developers are free to start a new story, should I help them with the ATDD thinking for a new card or focus on finishing the one I’m working on?”

flowtrumpswip

“I’m a developer who both analyzes new stories (you might call it backlog grooming if you’re a scrum team…) and develops them. I see our backlog of ready stories is running low – should I continue to work on my story or should I move to analyze some new ones?”

Stop Starting Start Finishing talks about finishing things and minimizing the waste of inventory. It seems to say always prefer to finish and not starting. Why would we even consider a different approach? And indeed on some rare teams it is reasonable to work in a pure “One piece flow” mode where we focus on one thing, finish it, and then move to the next. But this requires a very high level of collective ownership and collaborative concurrent engineering. This is seldom the starting point and rarely an early achievement of teams trying to set up a more healthy flow of work.

So in the majority of the teams the challenge is that in order to maintain healthy flow people are typically working on different things. And when the work process of these teams is such that it requires different members of the team to take part in the work in separate areas of the life cycle so they have to touch the work, leave it, and return to it, we have an issue. Maintaining healthy flow is now in conflict with Stop Starting Start Finishing because you would typically always have something to finish, so when are you going to move left on your board or go to work on things related to your next sprint?

One concept that might help is the “Lean Decision Filter” (see slide 16 from David J Anderson’s  Lean Kanban 2009 Keynote):

Lean Decision Filter

• Value trumps Flow – Expedite at the expense of flow to maximize value

• Flow trumps Waste Elimination – Increase WIP if required to maintain flow even though it will add waste

• Eliminate waste to improve efficiency – Do not pursue economy of scale 

So based on the filter what we can deduce is that if we need to start something new in order to maintain flow then this is what we should do even if it is a potential waste since we could have focused on finished something.

BTW In a lot of scrum teams this manifests as the heuristic to spend 10% of the team’s capacity on preparing for the next sprint.

A way to decrease the waste of context switching while maintaining flow is to use an ongoing cadence. For example hold specification workshops or backlog grooming sessions at a regular time each week. This minimizes the impact of the context switch since it provides some heads up for people instead of surprising them and pressuring them to move to something else (otherwise the rest of the team will be idle…).

Bottom line – one of the first steps to really getting Kanban/Scrum is to start thinking “Stop Starting Start Finishing”. But the Lean Decision Filter helps us apply the required common sense to real world situations where this seems to be in conflict with effective flow – which is actually what we are striving for.

Do you see this problem in other forms? Did you find other ways to rationalize the right thing to do? Do you have other tips/suggestions to people facing this problem? That’s what the comments are for…

 

Lean Kanban North America is coming to San Francisco but when will I have time to enjoy the city?

Estimated Reading Time: 2 minutes

Lean Kanban North America a.k.a Modern Management Methods conference for 2014 is coming up. This year it will take place in beautiful San Francisco.  I love San Francisco and the conference hotel is smack in the area I love most – the waterfront… But I’m not sure how much time I will have to wander outside…

I’m expecting quite a busy week – As one of the two winners of last year’s Brickell Key award I’m on the selection committee this year. Legends tell of long nights deliberating the merits of the different candidates until white smoke rises. Looking at the strong candidates nominated for this year I don’t see how it will be any different this time… 🙂

Beyond that I have two sessions I’m involved in this year. One is the Amdocs Case Study. Conference series veterans will recall an Amdocs case study Erez Katzav and I presented back in LSSC2010 in Atlanta. Wow, that was a long time ago… Anyhow this year a fine team from another division in Amdocs is coming to talk about how they are using Kanban to improve the agility of a business group encompassing thousands of people. For those of you keeping track of my work and talks – The initiative is based on a lot of the things I talked about in the last years and has been a source for a lot of talks/write-ups as well. It is a very interesting story with ups, downs and new interesting challenges every week or so. For anyone interesting in change management in a large scale global enterprise as well as how to run a large scale operation using kanban flow approaches, don’t miss this session.

And finally, on thursday, I’m running an interactive workshop about Crossing the Chasm and pull-based change. This workshop will be an opportunity to elaborate and go deeper on some of the themes in the Amdocs case study and other talks like Kanban – a SANE way to go agile from LKUK13. I’m still obviously working on the structure for the workshop but am excited to have a more interactive intimate opportunity to talk about these topics, answer questions, hear feedback and ideas as well as stories/experiences from others who are facing similar situations. The Amdocs team will obviously also participate in this workshop so it is a great opportunity to dive deeper into questions that arise from the track session.

And on top of that there’s a very interesting schedule of sessions, keynotes and other interactive workshops I’ll want to see… (Here is my current plan…)

Busy week. Where is the time to go to the wharf and enjoy some clam chowder bread bowl? To catch up with everyone? Oh well.

Having said that, if you are at the conference and want to talk, I’m sure we can find the time… best way would be to contact me on twitter.

See you there!

 

 

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.