An Alternative To Dogma: Disciplined Teams Making Effective Decisions

This morning, the #kanban and #scrum Twittersphere was buzzing over a guest blog by Jim Cope on Jeff Sutherland's Scrum Blog; "An Alternative to Kanban: One-Piece Continuous Flow"

This is a gross oversimplification but in essence, Cope is asserting that, 'we don't need no stinking Kanban'.  While my experience as an Agile Coach is inconsistent with some of his conclusions (i.e. that Kanban " take[s] away the sense of teamwork and "positive pressure") he does make some good points.  For example, he points out that, "Kanban is properly applied as a selective, detailed fix to a specific problem. It is not a philosophy of development." and he's exactly right.  Kanban is a tool not a philosophy. It's a tip of the iceberg thing. Sort of like 'daily scrums', burn-down charts, retrospectives, and Sprints. 

Cope states, "We see teams adopting this form of kanban, as a tool or methodology in its own right rather than as a worldview, without first having built foundations and disciplines of one-piece flow."  I agree with that wholeheartedly but the irony is that you could just as easily substitute the word "Scrum" for "kanban" and the statement would be no less true.  The wide spread practice of, 'Scrum-But' is sufficient proof of this.

The problem of teams applying frameworks and tools without a grasp of the underlying worldview and principles isn't isolated to the use of Kanban; Ceremony rich cargo cult adoptions of Scrum are hardly a rarity and a CSM course provides no guarantee that good teamwork will naturally follow nor that the decisions made by a team will be effective. Single piece flow requires a lot of discipline.

Kanban, like elements of Scrum, is essentially one tool in the Agile arsenal to augment the decisions made by a team to achieve single piece flow. If the team achieves that flow using Kanban without sacrificing other objectives (i.e. teamwork, high motivation, etc.) then the tool is effective. If the same results can be achieved with lower ceremony and overhead, all the better.

Without the application of the underlying disciplines, BOTH Scrum and Kanban are likely to flounder.

I think the real takeaway here is that blind application of any tool, be it Kanban or Scrum, does not confer automatic benefits. Ultimately, it gets down to individuals interacting as a disciplined team guided by principles (such as the dynamics that give rise to single piece flow) to make effective decisions.

Fantastic results conducting my first Agile Decsion Flow workshop

There's nothing like a deadline to boost ones Agility. As we approach the event horizon of a deadline, our focus on the goal becomes laser like and decisions we would otherwise have delayed get made. At least, that was my experience today as I put the finishing touches on my first Agile 2.0 workshop. I added content, reordered information, and refined the telling until the first head poked through the doorway of B1-157, configured to seat 50 members of the product management area.

Frankly, the odds were stacked against me; It was a Friday, siesta time, and few of the participants who had responded to the request to attend knew what to expect. Actually, it turns out they did expect something. Since the subject line for the meeting contained the word "Agile" - these business people came prepared with laptops locked and loaded to weather a lecture around processes they felt little passion for.

Business people don't tend to get terribly excited by process. They're usually very bottom line results oriented.

That's exactly what I wanted. I wasn't there to talk about process. I was there to talk about something far more fundamental; agility in the truest sense of the word.

That's one of the reasons I targeted the product strategy members of our organization to deliver my first presentation on what I've been coming to think of as Agile 2.0 (Yes.. I'm mindfully guilty of great hubris in presuming any advancement at all in the art of Agile, let alone a step function breakthrough - but virtually all the feedback I'm getting suggests I'm right. It does need a proper name of some kind).

I wasn't there to talk about process. I was there to talk about Agility in the truest sense of the word.

I confess I felt a great deal of trepidation. I've presented bits and pieces of what's starting to gel as a whole new approach to Agile development to a few people and while the feedback so far has been terrific, I had no idea how a room full of business people would respond to stuff that's not only new but fairly radical. I felt there were two equally likely outcomes; 1) I'd confuse and lose most of them completely, 2) they'd get it and see the potential almost as much as I do (well.... maybe not that much, but at least they'd be intrigued).

My experience was the latter. The overwhelming response was positive. Even though the concepts and thinking tools I presented were new to virtually everyone in the room and the exercise time to try them brief - I could tell that a lot of it stuck.

Not bad for an alpha run. I learned a bunch (I always do when I teach), generated a wealth of useful data from the exercises, and identified quite a few gaps that need to be filled before I can really roll with this.

I wasn't seeking buy-in from everyone but that wasn't my goal. My goal was to get people talking and curious about Agile Decision flow and entice innovators and early adopters to put the principles to work in practical applications in their areas.

Based on the responses I've received so far and the tone of the room, I was successful on both counts.

It just reinforces my belief that I'm on the right track here and will be able to start delivering some real breakthroughs in organizational agility far faster than would have been possible before.

Oh.. one of the workshop participants suggested I name whatever it is I've pulled together as "Agile On Rails" and I rather liked that. Now that I'm bringing more brains on line to help me with this, I'm sure a better name will emerge.

I'll keep you posted.

Cheers!
J.