Kanban

In contrast to Jim’s guest post the other day, here is a tale about my grass-roots attempts at implementing lean thinking with my teams within the domain of my control.

Some interest in surrounding teams has cropped up, but it’s my view that a true lean system/project requires very strong executive management support.

If you don’t have that (yet) then sometimes sub-optimization (within a team or two) is a way to flex your lean muscles and provide some gains.

At least, that’s the approach I’ve been taking.

Kanban Implementation Question

Josh,
My top goals are to get better at what I do and to formalize and align my PM skills with PMP standards. I’ve been internalizing your skillful nudges and instructions that you have shared to this point (PMStudent Blogs, Kanban, and this email).

Which brings me to a question – if Kanban is where you regulate your tasks to eliminate “multitasking” (which I applaud), where do keep the master list of tasks which drive you to your project deliverables? It would seem that you would be moving those tasks from the master list into your Kanban board and then out again to the master list as they were achieved. No?

Keep up the great insights

Sphere of Influence/Control

Great question. Working for a large federal program, we have EVM in play and I have to work within a waterfall framework. I’m convinced that end-to-end lean thinking would dramatically increase the effectiveness and efficiency of any project or program, but I’m not in a position to enact an agency-wide change. Because this is a joint project, both the USGS and NASA would have to buy in for us to start lean thinking across the whole value stream.

Translations

So I do translations between what my team does with Kanban and traditional project schedules. We still have the WBS for deliverables, and those are turned into work packages that get scheduled in the traditional way. When those hit my teams’ Kanban boards, they will get decomposed further usually, and on the fly as items come from the pull queue into active work. I roll up schedule status for work charged and completed items as the translation from Kanban back to the traditional waterfall schedules.

Especially when there are interfaces and dependencies all over the place (as is the case with my project teams) you still have to have representation on some schedule or tool that has everyone on it. So in my case the traditional element schedules that roll up into an IMS (Integrated Master Schedule) are in play so the various pieces across contractors and agencies (USGS and NASA both) can be lined up and ready when they are needed for integration.

“The most difficult situation, however, occurs when agile teams are dependent on teams that have much longer planning timeframes. Dissonance between teams with different planning horizons is common and can be difficult to resolve.” - Poppendieck’s in Leading Lean Software Development

Your Thoughts

So what do you think about all this? Is there a better way for me to approach this?

Is it better to do a Scrum-but or Lean-but if the full end-to-end implementation isn’t feasible?

{ 0 comments }