Twas the night before code drop and all through the land
Not a person was coding, not even one hand

The code was all tested and checked in with care
Even the documentation was completed and there

The PMO Director & VP of Dev were nestled all warm and snug in their beds
While visions of bonuses danced in their heads

Joe closed his laptop and Sue hit the sack
Knowing morning was near and they needed the nap

When from my pocket there arose such a clatter
I reached for my iPhone to see what was the matter

To the office I flew like a Senior VP
Tore open my briefcase and fired up the PC

When what in my unsettled eyes might appear
But an incomplete test case as I trembled in fear

I regained my senses and checked out the code
Reviewed the regression and distributed the load

It passed all the tests now, my mind was at ease
Knowing that many would certainly be pleased

That I put forth such effort on a cold chilly night
To re-sync our code and ensure all was right

Soon morning approached and I knew not to worry
As none of the testing was crammed in a hurry

It makes my heart filled with holiday cheer
To know Agile methods make everything clear

As the holidays are with us and our hearts fill with joy
Help us all to remember the framework we enjoy

On XP, on Scrum, On Kanban & Lean,
On DSDM, On AgileUP, On Crystal Extreme

To the ends of the project, no greater joy shall we call
Than celebrate, celebrate, celebrate all

As we conclude the current project and realign our sites
Happy Holidays to all and succeed with Agile Might!

Okay... time to wrap this thing up. If you missed any of the first three 'Noodling on Kanban' posts... I included links at the bottom of this one... just to make it easy on you guys ;-) There is clearly much more to this topic than I wanted to try and address in this tiny little series. We could talk about how Kanban drives culture... how it gives managers a role... how it is more inclusive. Karl Scotland and I debated over Drum-Buffer-Rope and how it applied to Goldratt's Boy Scout story over drinks at Agile 2009. We agreed we were splitting hairs. I tried to get David Anderson to admit that Kanban was just a visual way of managing and elevating constraints... he didn't agree. There is lots more to say... but for the general agilist or newbie... this should be enough to start. For this post we'll wrap with some of my thoughts on what situations a Kanban might be particularly useful and what I see for Kanban outside the team. To me that is the much more interesting problem. Time to Use Kanban? My personal take is that Kanban... even Kanban with a capital 'K'... is not a development methodology. It is not a replacement for Scrum or XP or AUP or DSDM. I do think that Kanban is a powerful tool that can be used when some of our more common agile practices stop making sense. Consider these examples: Have you ever tried to talk about planning in two week iterations with a team that is responsible for production support? The idea that you can't add anything to the sprint once it is started is going to fail... we'd probably abort every sprint. How about a mature product team that is iterating an existing product? Does it necessarily make sense to stop every two weeks for a few hours to plan... to retrospect? If requirements are generally understood... the team talks over lunch... and they just know how to get things done... probably not. How about a team that suffers from late delivery in the sprint? A Kanban board can keep them focused on continuously delivering value... even if they don't do away with the iteration boundaries. What about a new team that isn't ready to self-organize or self-manage? A Kanban can give the manager a tool to help the team learn how to self-organize and self-manage. We can use Kanban as a replacement for stuff we don't need or as an addition when we need a little bit more control. Something to consider, huh? Kanban in the Enterprise Personally, I find most problems at the team level pretty uninteresting. It's not that team level practices aren't important... they are incredibly important... it's just that most of the teams I work with have environmental problems. If the organization would just create the team... leave the team together... let them stabilize... let them establish a pattern of delivery... most of the coaching stuff we do could work itself out. Coaches could focus on helping competent teams become excellent. Similarly... at the team level... Scrum... Kanban... who really cares... let the team decide what works for them and go for it. For me... Kanban gets really interesting at the portfolio level and across the enterprise value stream. Most organizations really struggle to get value flowing in a predicable way out of their enterprise project portfolios. What if we could have an enterprise Kanban... a portfolio Kanban... a project Kanban... and a team Kanban. As you go deeper into the organizational hierarchy... the work in process limits at the enterprise level force value from the portfolio... portfolio limits force value from the projects... and projects force value from the teams. Imagine a system with enterprise cycle time all the way down to team level cycle time. Thinking about the enterprise as a series of capabilities... capabilities that together form a system... a system that can be managed and subordinated to the constraint... now that is exciting. Now we can focus our enterprise agile adoption dollars at the constrained teams and resource groups to get maximum value from our investment dollars. That is where I'd like to see us to start talking about Kanban. Hope you enjoyed this series of posts. Make sure to comment if you think I've got this all wrong... I am open to your feedback. Oh... and here are the links for your reference: Noodling on Kanban... Part 1 Noodling on Kanban... Part 2 Noodling on Kanban... Part 3

I don't want to be a Scrum guy. I don't want to be an XP guy. I don't want to be a Lean guy... or a Kanban guy... or a DSDM guy... or a RUP guy... or a PMI guy. For that matter... I don't even want to be an Agile guy.

As my experience has broadened over the past few years... as I have worked with more and more teams... it seems that most any process can be successful... even Waterfall... with a great team of engaged human beings... passionate... and working toward a common goal.

It seems that most of the time... when we start comparing one way of doing things with another... we tend to compare our best process implementation with the other side's worst. My last waterfall project came in exactly on time... within one percent of budget... with all the scope originally asked for.

And yes... the product was very successful in the marketplace.

Can I please just be a 'get things done' guy? To the extent I can use Scrum or XP or Lean or Kanban or DSDM or RUP or PMI to be a 'get things done' guy... that's what I really want do. To the extent that these labels... or even the processes themselves... get in the way of delivery... we'll figure something else out.

The bigger the tent... the more tools we have at our disposal... the better chance we have to be successful. At the end of the day... it's about delivery.

Tags: Agile Scrum, Agile XP, DSDM, Kanban Software Development