Tag Archives: kanban

The synergies of Kanban & DevOps

Estimated Reading Time: 1 minute

I believe Kanban and REAL DevOps are a match made in heaven. I really do. I know I’m not the only one. Leading into Agile India 2015 InfoQ interviewed me about this. This was also one of the main themes of my talk in the conference and the DevOps Flow workshop I gave before the conference. (Contact me if you’re interested to hear about the next opportunity to participate in such a workshop).

While we’re waiting for the video from my talk to be processed, here’s a trailer…

 

And an older variant of this talk from DevOpsDays Israel:

 

How to limit WIP when you cannot block arriving work requests?

Estimated Reading Time: 2 minutes

A concern that comes up frequently when you start talking about applying a WIP limit is:

“So, what I understand from you is that at some point you will block incoming work requests if the WIP limit is reached, yes? Well, we cannot do that. We cannot tell people we will not work on their items. That will not fly around here”.

I think that is a reasonable concern. In Don Reinertsen’s Lean Product Development workshop this week in Paris (highly recommended btw…) he frequently used the Emergency Room (ER) metaphor. So let’s borrow it.

In my view both the waiting hall and the treatment area are WIP since they both affect the overall service time.

You can apply a limit in at least two ways. The first can be to apply a limit to the overall WIP. Once this limit is reached you will indeed turn away patients. Fans of ER themed TV series will recall episodes where the ER closes shop and turns ambulances and walk-ins to other hospitals. This happens very infrequently though. Their WIP is set to a high level and it is understood that the waiting area might have a very high occupancy leading to very long service times before the situation is so dire that you start blocking people. (A client that attended Don’s workshop with me commented that you might want to invest in stronger security if this happens often as it typically leads to some violence towards staff…)

The second way is to limit “Treatments in Process” to make sure that once patients are in treatment they go through as fast as possible and staff don’t multi-task too much and the treatment area is not too crowded. You will notice this style of WIP limit DOESN’T turn away patients. It accepts them and queues them. Yes the service time might be high if there is a long waiting queue but you will still be serviced. I don’t know what ERs actually do since my personal experience with them is quite limited but I think they either explicitly or implicitly do a mix of both.

To return to our knowledge work environment I advocate using this approach as well.

Yes you should have some WIP limit on your incoming queue. That WIP limit might be high if you want to minimize blocking and prefer to provide long service times. That is probably what the evolutionary resistance-minimizing approach would be.

More importantly I would start with a limit on the actual work in processing. This will achieve a more sustainable and effective processing both for the work as well as for the people doing it. This will also have the effect of reducing the average waiting times and overall service level of your system.

Now, in your environment you might also have a better chance of shaping demand and occasionally blocking work in a way that is acceptable to your clients. But that is a higher maturity level of Kanban. (Klaus would call it a higher flight level) Don’t give up on starting with WIP limits just because you cannot do it early on in your journey or if you think you will not be able to do it even later on.

 

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.