Monday, January 23, 2012

Comparing Kanban and Scrum

Is pointless.

Yes everyone has an opinion, and a strong opinion at that.

Including me, especially me.

Everyone has an opinion except the people that really matter. I'm talking about the executives in charge of those multi hundred million dollar IT transformations going on right now. The ones responsible for integrating all those legacy systems to support that latest M and A.

The folks responsible for determining the who, the what, and the how for the technology landscape that will support corporate America (and in my case Canada) into the next century are almost all completely ignorant of what agile is, and what agile means. They still think waterfall is the way to go. They think agile is a toy to be used by post graduates to create cute applications that play on teenagers' iPhones.

I see this every day where I work, and I see a lot of big IT programs here. I have have seen some very large scale IT transformations started recently based entirely on more command and control, more governance, and more standardization.

This is the big killer whale that we all need to face. A prevalence of a mindset that is hostile to agile principles, and sees self organization as a threat.

Yes, the tide is slowly turning, but its also going backwards in lots of places. There is a ton of work for us to do. Best we do it together.


  1. Why do you think the tide is going backwards in lots of places? Do you think it makes a difference whether one takes a team up approach or an holistic view? Perhaps it's not the method that's important but the perspective from which it is used.

  2. It's always struck me CIOs and similar ranking executives make politically safe decisions. They look after themselves and their careers first. They show loyalty to those who can help them and expect it from those they plan to pull up behind them. Loyalty and avoidance of political risk are paramount. Everything else is at best secondary or in their opinion irrelevant.

    Agile is seen as politically risky. Adopting its values may be interpreted as a sign of weakness, a loss of political control or influence or even an act of disloyalty as it shakes up the status quo in the power structure.

    If there a huge single failure of Agile in the past decade plus, it is the failure to recognize this or address it.

    1. From what I've seen. CEOs are not afraid to take risks. At least at a grass roots level. They do want to use agile, scrum, kanban, etc as a buzz word without understanding what it is. Without in the trenches leaders working on transformation, business goes on as usual only with the label "agile".

      I am more of Jeff's opinion that ignorance is the issue. If time is not taken to understand it, that's what happens. They believe that they are agile while they are actively forming QA departments, PMO's, producing the 100 page spec and demanding their teams hit imposed deadlines.

      Easy to do, hard to master never rang out so true as in the executive level for me.

      On the flip side, I have also seen CEO's and CFO's dig in and learn what agile is all about. Modifying how they extrapolate and interpret data for business health measures. Those that understood brought a wealth of knowledge to the table. They were valuable to agile.

  3. I think proponents fighting about which one is better is pointless. But discussing strengths and weaknesses of various approaches for a given situation and system isn't so bad. To me, software projects run into the most trouble when those making decisions don't understand the technology, managing knowledge workers and project management. Which flavor of agile makes less difference I think. Kanban is great in my opinion. I also think lots of different forms of agile can work well. The key is not which method but how well you execute.

    One reason I would lean to kanban is I think it does exactly what Ohno had in mind - make problems visible. So often managers care most about making sure problems stay hidden (fear who will be blamed...). Another is you can get started with kanban fairly easily (in my opinion). The problems getting the people that actually do the work to accept things is somewhat tricky but usually isn't close the biggest problem. It is almost always management not wanting to change, wanting to find the easiest way out of today (and deal with the rest tomorrow) and being afraid to coach and help instead of direct and blame.

  4. Alan,

    The primary reason a common theme I am seeing is a pendulum swinging erratically from complete chaos to very rigid command and control. CIOs don't realize that one begets the other. Rigid command and control processes breed avoidance, they also don't scale with complexity. The eventual result is that many large IT organizations have very working governance in effect. Every so often an exec sweeps in with a mission to set things right, starting the cycle all over again.  The agile middle ground is getting passed every time.


    I agree with that sentiment. Agile is not very market friendly to executives. It also doesn't address the systemic issues that cause execs to stick to safe choices. If we were execs, we would be likely doing similar things. The good thing is that concepts like Lean, Gamification, etc are explaining why agile works, and how to create economic incentives for execs to listen to us.


    Certainly I'm not trying to paint all execs with the same brush. A combination of igorance and (perfectly understandable) self interest combine to make agile a tough sell to execs. There are of course exceptions to the rule. I do have some great experiences, I'd like to see more of them.


    Yes agreed. Healthy debate is important, we need to strengthen our methods. Sometimes I think it does occupy to much mind share within the agile community. I also have a (strong) preference for what methods I like to use. I would like to see more events like stoos, (but more open) where we are we bring together all of the counter command and control folks together to address that big white whale we all need to take on