Search Results : waterfall » The Cutting Ledge

Feb 062014
Ed Sumerfield and Chris Nelson of Gaslight Sof...

Ed Sumerfield and Chris Nelson of Gaslight Software presenting “Why Agile Fails” (Photo credit: RubyNuby)

How the fuck is this coming around again?

George Westwater on Waterfall

Every so often, someone will put forth the idea that agile practices are great and all, but they fail at certain things like providing an up-front budget, a well-researched scope before work begins, a full project timeline with milestones, etc.  These sorts of things are such staples to the way most orgs approach their projects that there’s a certain tension to make agile practices better at providing them, and the path of least resistance to trying to supply these is to use the practices that used to provide them – typically some type of phase-gate approach like Waterfall.  You hear things like this:

  • We complete all the requirements and design up front, but then we do our development in an agile way.
  • We do agile, but in a way that can be managed with Microsoft Project.
  • We’re agile, except we do our testing at the end, but at least we release every six months.

And so on.  The basic idea is that doing a project without these traditional Waterfall additions is somehow inherently more risky or will fail to provide a company what it needs to make intelligent project decisions.

I’ve already spent a lot of electronic ink on this blog talking about how the benefits Waterfall purports to offer are largely illusory (kind of like the illusion of security offered by being employed at a large company) and how various agile methods can actually do a better job at providing intelligence to the business, so I don’t want to rehash all that.

However, the point I want to make here is that Waterfall and Agile arose from very different systems and operate off very different assumptions about the work.  For instance:

Waterfall’s Assumptions

  • The work to be done is mostly static.  Changes are rare and always occasion for re-examination.
  • Business needs / the market is not volatile; our priorities and methodologies today will be very similar three years from now.
  • The work is extremely similar to work that we have done before.  Almost everything is a known quantity.

Agile’s Assumptions

  • The work to be done changes often and progressively as more clarity is gained or needs evolve.
  • Business needs and the market is volatile.  The thing on the front burner today might be on the back burner in three months.  Our methodologies are evolving.
  • The work is to develop something new.  Similar technologies and methods might be used, but the business problems we’re solving technically have not been solved before.  Otherwise, we’d be using that.

The problems with Waterfall are not necessarily inherent to Waterfall as a methodology.  On paper, it looks all right.  The problem is that the set of circumstances under which it operates best is pretty rare in software development.  Are there software development projects where the domain is pretty static, changes are rare, and the business changes very little?  Sure, those do exist, and Waterfall would work just fine.  In fact, it or something similar might be the best choice for those kinds of projects.

However, a lot of organizations believe Waterfall’s assumptions to be true of their situation, and they are not at all.  Most real organizations have work that looks more like that list of Agile Assumptions, and in that context, agile methods will probably fare much better.

The issue with combining the methodologies isn’t a religious one; it’s that you’re trying to combine two things that are appropriate in two very different contexts.  You’ll end up crippling Agile by trying to make it more Waterfallish because you’re trying to drag in a context that doesn’t apply.  It’s like adding a sail to your car.  Sails are pretty good in their context, but they’re not objectively good for all contexts.

The fact is, becoming agile will challenge a lot of illusions and assumptions we make about our work that are not accurate.  If you’re hearing something like, “Agile makes it difficult to budget for the whole project up front,” that’s your cue to examine if budgeting a whole project up front is really the smartest thing to do as opposed to paying for value as you go.  If you’re hearing, “Agile makes it hard to set project milestones,” that’s a good opportunity ask yourself why you feel you need project milestones, what value they offer, and could you get that value in better ways?  Agile is meant to change your understanding, your values, and ultimately your practices at an organizational level.  It is not designed to accommodate them.

So, before you decide to add a sail to your car, just give driving the car a shot.  You might find that it doesn’t need that sort of improvement.



Enhanced by Zemanta
Dec 032012
5GW Waterfall Model

5GW Waterfall Model (Photo credit: Dreaming 5GW)

If you get into any kind of open forum discussion regarding the benefits of more agile or more lean approaches to traditional software development, it’s not uncommon for someone to say that the problems organizations experience with Waterfall are largely because they aren’t doing Waterfall right (incidentally, this is also what most of the Scrum folks say when organizations experience problems doing Scrum, but I digress). The idea is that, if organizations were disciplined and knowledgeable enough to implement Waterfall properly, the way it was designed, that most or all of the high risk issues in Waterfall wouldn’t be issues.

It reminds me of martial arts forums. Someone will post twenty videos of Bad Won Do practitioners getting their tails kicked, and someone will comment that what they’re doing isn’t “real” Bad Won Do.  “Real” Bad Won Do is actually quite effective (and apparently undocumented) and, if they’d just do the real stuff right, they’d be powerhouses.

But here’s the thing. Even if you did Waterfall with 100% perfect execution, it remains an extremely high risk, high fail project delivery methodology.

1. Testing Comes Too Late in the Process

Winston Royce, the man who brought a lot of visibility and popularity to phase-gate approaches to software development (and accidentally contributed to the success of Waterfall) wrote this in “Managing the Development of Large Software Systems:”

The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code will not fix these kinds of difficulties. The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a l00-percent overrun in schedule.

In other words, since you’re testing the whole system at the end, you run a very high risk of major rewrites to fix issues.  This is Waterfall done right.

2. Value delivery comes at the end.

You release at the end of the project. Nobody gets any value out of your work until everything is done. This is a huge risk for a number of reasons.

First of all, the project might not get done. In fact, many projects meet this fate. Funding runs out. Priorities change. Dissatisfaction with the vendor. When this happens, the business is often left with nothing. They just eat the cost of a ton of work that got them nothing but stacks of documentation and some half-baked code. Since value wasn’t delivered incrementally, they have nothing.

Second, there is an enormous risk that what was valuable nine months ago is no longer valuable, either due to changes in the business or just the fact that the value of requests expires over time. It would have been useful when it was requested, but not nearly as useful now.

Third, the funder of the project has no real option but 100% success or 100% failure. You either get everything, or you get nothing, and this leads to some very unhealthy decisions like sticking with a vendor who isn’t performing or continuing to pump funding into a project that should have been abandoned or thoroughly revised months ago.

This is Waterfall done right.

3. Waterfall is predicated on a faulty premise.

Waterfall assumes that I can fairly accurately predict timelines and resource needs for a project that will involve several people extending over a large amount of time.  The entire notion of a phase-gate approach like Waterfall is the idea that I can get all the requirements, lock those down, do all my design, etc. And all the trappings of my project management revolve around this presupposition.

And this might have a glimmer of hope to it if software requirements were cookie-cutter kinds of things that all required the same resources, same effort, same complexity, same outcomes. But as we know, software development is way, way more variable than that.

Can you imagine a general making a battle plan for a year long campaign and sticking to that plan the entire year? It doesn’t happen. Yes, having a plan is important, but the plan has to be intrinsically adaptable because conditions on the ground are changing. Some are predictable, some aren’t – the variables in war are endless.

I’m not saying software development is as volatile as war (most of the time), but the principle is very similar. I mean, what if I asked you to plan down to the hour your work days for the next year.  Could you do it?  What about the next month?  Next week?  I think you’d find this challenging, because each day of work brings up new variables, emergencies, challenges, etc.  So, I ask you, if you couldn’t even plan the hours of your work week in advance, how realistic is it to assume that you can do that for several people, departments, and resources over the course of six months to a year and expect the outcome to still be relevant to all stakeholders?

This is Waterfall done right, and this factor is, I believe the most problematic, because it gives an illusion of certainty that does not actually exist.

Enhanced by Zemanta
Sep 302011
BRADENTON, FL - FEBRUARY 28:  A napkin holder ...

Image by Getty Images via @daylife

Diner 1: Hey, do either of you have an extra napkin?

Waterfall Guy 1: I have made detailed plans and estimates on exactly how many napkins I will need for this meal.  Therefore, no.  If I finish the meal and have overestimated my napkin needs, that’s a very good thing, and I’ll be happy to give you my extra napkins.  Historically, I tend to underestimate these needs, which will lead to either a request for more napkins or drawn out sessions where I use the same napkins I have until they dissolve into component particles.  Either way, I won’t know until I’m done, but I wouldn’t hold my breath.

Agile Guy 1: Any napkin I’m not using right now is an extra napkin.  Take as many as you like.

May 242011
Example of an American grocery store aisle. 

Image via Wikipedia

Cast: Bill and Ted – roommates

Bill: Hey, Ted.  I just noticed that we’re getting kind of low on groceries.  Do you think you could run out to the store?

Ted: No problem.

Bill: Great.  How long will that take?

Ted: What?

Bill: How long will that take you?  I need to plan my day.

Ted: Well, I don’t know.  I don’t know how many groceries we need, and even if I did, I don’t know what traffic will be like or how busy the store will be, or even if I’ll have to go to two stores because they’ll be out of something.

Bill: Look, you’ve gone to to grocery store every week for two years since I’ve known you.  How can you not know how long this is going to take?  Please give me a number so I can plan my day.  Also tell me how much the bill will be.

Ted: I have no idea!

Bill: Come on, Ted.  You’ve done this a hundred times, and you don’t know about how much it’ll cost?  How am I supposed to budget without knowing how much you’re going to spend?

Ted: Ok, it’ll take an hour and I’ll spend $200.

Bill: That seems like an awfully long time.


Bill: Wow.  You have real communication issues.  Anyway, do you think you could get it done in half an hour?

Ted: Sure.

Bill: Great.  You’re committed to half an hour with a budget of $200.

Ted: Fine.  Ok, now, what groceries do we need?

Bill: Whoa!  Hold on there, sport.  You can’t just go charging in to that sort of thing.  We need to figure out what car you’re going to take, how much gas you’re going to use and how much that will cost, and what the optimal route is to the store.  Then we need to make a list of our ideal grocery stock and compare it to all the items we currently have on hand to create a list of deltas.  Then we need…

One week later…

Ted: All right.  We’ve mapped out the route I’m going to take, made all the logistical decisions, and attached a timeline and dollar figure to each item.  I now have a plan where every detail has been accounted for, and I am ready to begin the process.

Bill: Well, the problem is we’ve eaten more groceries since you’ve started that process, so your list is wrong.

Ted: That’s a real shame, because our entire plan hinges around it being correct.  If you want to make changes this late in the game, we’re going to have to do some more requirements gathering and figure out the impact to our times and budget, and just that process alone will have impact to the time and budget, so maybe we should vote on whether or not we even want to…

Bill: All right, all right.  Nevermind.  Just get the groceries we planned on, I guess, and we’ll just live with it.

Ted goes to the store…

Ted: (singing) Implementation phase, implementation phase, oh how I love the implementation phase.   (stops singing) Wow, traffic sure is terrible.

At the store…

Ted: I didn’t know today was National Broccoli Day.  This place is packed.  It’s taking forever just to get down one aisle.  Crap, they’re out of Baco-Bits.

Back at home…

Bill: Ted, your trip to the store took 50 minutes – almost twice what you estimated.  Also, you spent more on gas with your trip to another store to get Baco-Bits, which put you over budget.  Furthermore, what you did get fell far short of the groceries we actually needed by that time.  Our plan that you, yourself, helped to create spelled everything out, so I can only assume that you’re a bad grocery shopper who can’t even follow simple directions.  You’re fired.

Ted: Thank you.

Oct 082013
organizational culture

organizational culture (Photo credit: nchenga)

In survey after survey, the #1 reason agile practitioners cite for the failure of an agile effort is that the company culture didn’t support it.

That’s probably true, but I think we might be letting ourselves off the hook, here.  For an agile consultant to say the failure of the initiative was due to the company culture is sort of like saying that a patient’s cancer treatments would have been effective if it weren’t for that cancer.  Or making a PSA to announce that death is the #1 killer in America and we should all take steps to avoid it.

In the interest of transparency, I have been guilty of this more than once.  I’d go to a place, get an uncharacteristic amount of resistance (it’s a weird phenomenon that organizations will sometimes pay for consultants and then ignore them), and after a certain period of time, decide that agile just wouldn’t work there because of the culture.  If I’d been really honest with myself, the truth would have probably been closer to, “I’m not wise and experienced enough to know how to handle this situation,” or maybe even, “I don’t want to put in the amount of effort and longsuffering it will take to weather this situation.”

A dysfunctional culture is exactly one of the things greater agility is supposed to challenge and gradually alleviate.  The kinds of things you do to empower people to turn from victims to self-improvers are the kinds of things that begin to dissolve cultural problems.  Command and control cultures begin to thaw when they see the gains that a high level of self-direction gives.  Trust and cooperation begin to build among traditionally hostile departments when teams become more dependable and transparent.  On and on.  This isn’t just me waxing hypothetical, either.  I have personally seen this cultural transformation several times at the hands of a burgeoning agility.

Only trying agile initiatives at companies who have the culture for it is like testing your hangover remedy with teetotalers.  A company culture that’s ideal for agile is inevitably going to be agile all by themselves.  You might still add value in helping them optimize here and there, but you won’t have substantially improved that organization.

It is the entrenched waterfall, hierarchy out the wazoo, big planning up front, command and control, whirlwind priorities, siloed organizations that need the gentle erosion of improvement, agility, and optimization the most.

Enhanced by Zemanta
Apr 152013
Illustration of the event horizon (Schwarzschi...

Illustration of the event horizon (Schwarzschild radius) (Photo credit: Wikipedia)

The idea of an event horizon comes from general relativity, but if you’ve ever heard of an event horizon, you probably know it either from black holes or from that weird Laurence Fishburne movie.  With black holes, the event horizon is that boundary around a black hole that marks the transition from “you could conceivably still get away with enough force” to “you’d better tell your friends you’ll be late to the bar.”  Black holes are always pulling at the things around them, but the event horizon defines the difference between having to deal with a black hole and actually being inside one.  Interestingly, from the outside, objects that pass the event horizon seem to disappear completely.

Event horizons are the ultimate black box.  They are the universe’s embodiment of that fight or flight moment.  You can get in, or you can stay out, but you can’t stay there.  In fact, the force required to stay in an event horizon increases to infinity.  The longer you try to remain neutral, the harder it becomes until it’s impossible.

When an organization decides to increase their agility, this effort also has an event horizon.  Generally, these efforts either originate in management and spread out, or they originate in an implementation team and spread out.  The latter is far more common.  Management might mandate the agile effort, but the actual transformation begins in an implementation team.

Regardless of where it starts, this effort has a boundary that attempts to suck in everything else around it.  Agile transformation efforts are not static.  You can’t just take, say, a team of software developers, get them all agiled up, and expect this to have no ramifications for the rest of your organization.  What you have done is created a singularity that, given enough time, will draw in the entire organization.

This is actually what you want.  This is one of the benefits of truly agile efforts; they can’t stay in their little box.  That event horizon is defined by the boundaries of contact between your “agile teams” and the rest of the organization.

Does your project management have distinct, Waterfallish phases?  The event horizon will eventually touch that.  Do you budget your projects on a cost-based approach where you have to allocate all the money up front?  The event horizon will touch that.  Are you constantly changing priorities at the top?  The event horizon will touch that.  Do you have tons of processes solely designed to protect the company from itself?  The event horizon will touch that.

In ways you never even intended, the singularity will try to draw all aspects of your company into it, and the event horizon marks that boundary of change.  Objects pass into it, and that’s where you have the critical moment of decision: do you allow accounting, management, project management, the executive team, and sales to pass through the event horizon, or do you expend force to keep them outside of it?

The answer to that question says a lot about the ultimate success or failure of an organization trying to be agile.

Enhanced by Zemanta
Mar 072013
Muteki Kanban Musume s original soundtrack

Muteki Kanban Musume s original soundtrack (Photo credit: Wikipedia)

It’s that time of year, again.  Spring is on the way, and in the spring, a young geek’s fancy turns to thoughts of conferences.

I commend to you the Kansas City Developer Conference this year – a two-day thrill ride for developers and the people who manage them that’s the most fun you can have at a conference without wearing a costume.  This year’s product has the following features:

  • Keynote by Dan Vacanti – key player in the development of Kanban (Kanban is Japanese for “the world’s best software development workflow management philosophy ever”) who also once saved Brooklyn from a power outage by connecting their power grid directly to his brain.  Also known for telepathic powers and training the X-Men.
  • Other keynote by Pete Thomas – co-founder and CTO of Pollenware, which has automated the distribution of several metric tons of pollen to flowers throughout the KC area.
  • A session by yours truly on how to use metrics from Lean to project timelines, measure quality, and ultimately improve your team. Also includes a short pre-session on tarot, bone divination, and 5-minute colonoscopies for Waterfall teams who need estimates.
  • Jon Mills will personally give a chair massage to every attendee who wants one.  You have to bring your own chair, though. Also, the chair will need to sign a waiver before Jon massages it.
  • Lee Brandt will host a live show of “Lee Brandt’s Wild World of Animals.” This episode will feature the short, brutal game of cobra polo.
  • Ian Joyce will be leading a drumming circle and talking about your Developer Self-Esteem (DSE). Specifically, he’ll be lowering it.
  • Holy crap, it’s James Kovacs. How the hell did he get in there? He probably thinks he’s coming to speak at DevLink or something. If he asks you about it, be cool. Don’t screw this up for us, guys.
  • Michael Sarchet will be singing his hits “Baby” and “As Long as You Love Me.”
  • Troy Tuttle will be running sessions of the very educational GetKanban game as well as leading a seminar on how to utterly destroy someone’s worldview with calmly worded questions.

Not convinced by the awesome lineup? How about these killer events?

  • The AdventureTech Fly Guys
  • DEG – Sogeti “Ridin’ Nerdy” Rap Battle
  • Exlcusive meeting of the Fred Durst Society for Humanities and the Arts
  • A performance by Taylor Swift somewhere in the world

Reserve your seat, today, but you’ll only need the edge!

Enhanced by Zemanta
Nov 052012
EI-DHH (Boeing 737-8AS), short final to RWY 30...

EI-DHH (Boeing 737-8AS), short final to RWY 30, València-Manises (LEVC). (Photo credit: Wikipedia)

Here’s the context. Some guy with a smidge of pull in the Ruby on Rails community made a post about testing when coding. I was actually surprised to see a somewhat immature perspective on testing and what makes it valuable. His conclusions make perfect sense if the primary value of testing is bug detection and prevention, so I’m not saying he’s stupid or anything (he’s not). However, I was surprised to see that testing, for him, pretty much has bug detection and prevention as its primary value. That tends to be the ground floor understanding of unit testing that gets people in the door, but nobody stays there.

There have been a great number of responses to the article in comments, other blog posts, etc., and there’s not really a need for me to rehash what they’ve said or what I’ve said in the past on this issue over and over again.

Instead, I thought I’d interact with the view in more of a Q&A format, using questions and objections that people have actually shared with me when discussing this issue.

Q: How do you justify the extra time writing tests takes? Don’t your clients pay you to write code, not write tests?

A: My clients do not pay me to write code. My clients pay me to deliver valuable, high-quality software, and it is the most moral thing in the world to do what I can to make sure what I deliver is what they want and working properly. Can you imagine Boeing saying something like, “We get paid to build planes, not create mathematically sound blueprints, run stress tests, and do safety inspections?” Nobody wants a plane that can’t fly or accomodate passengers or will likely kill them, and you are pretty much to blame if that’s the plane you sell them.

Tests make sure that we are delivering what the client is asking for as well as only writing code that makes those requests into reality as opposed to unnecessary layers of abstraction, features we don’t need, features that deeply misunderstand the client’s expectations, etc. I don’t think of it as the amount of time necessary to write tests taking away from coding; I think of it as all the time I’m not wasting writing code that’s useless or will need rework.

Q: Do you think you should have 100% test coverage?

A: In the sense that all the code I write is in response to a test that captures a specification, yes.

Q: So you’d write a test for the getters and setters of every property?

A: See, that’s question begging. I don’t write code then write tests to “cover” that code. I write tests, then I write the code I need to pass those tests. If I write a property with a getter and setter, it’s because I needed that property to make an existing test pass. So, no, I wouldn’t write a unit test around a getter and setter of a property, because that doesn’t make any sense. Where did that property come from to begin with? If not from a test, then why is that property there?

Q: But what about writing tests around code that already exists?

A: Very different ballgame, because at that point, you’re writing tests primarily to catch and prevent defects, and then DHH’s points have a lot more value to them. But it also depends. If I’m writing tests for the purpose of rewriting that code or decoupling it or what have you, then my tests serve more of a design purpose, and we begin to shift back to writing tests around the expected behaviors first, then refactoring the code to those tests. But, yeah, if it’s just a matter of some class sitting out there and someone wants regression tests around it, then I’d probably triage my tests along lines similar to what DHH recommends. But that isn’t an ideal situation and shouldn’t be typical, either.

Q: Isn’t using Cucumber for tests the result of a drug-fueled vision of a magical land where non-programmers write your tests for you?

A: That’s what DHH said, but once again, it reflects a reasonably immature view of development and testing. I do find that, in the Ruby community, a lot of the development seems to be done by one person or two to four man teams who are trying to build a workable product as fast as possible and get it out the door. In that context, some of the views make more sense. You’re not collaborating with lines of business, federal compliance officers, third party vendors, mainframes, volatile APIs, and all the other things that go into many line of business applications when you’re trying to build Coderizer or Snufflehumpr or whatever and get it out the door that weekend, so the considerations are somewhat different.

Also, if you have a relatively Waterfallish view of software development where the business sits in Silo A and produces an artifact that is carried over to the developers in Silo B to build, then the views make a little more sense as well. If you tried to introduce Cucumber (or Gherkin, in my case) across the process in a phased-gate approach, the only real question left is which Silo will devolve into the Lord of the Flies first.

However, when you are working on decently-sized line of business applications in a more (ugh) agile manner, you find yourself collaborating together with said business people as well as QA people. When you have a business representative, a developer, and a QA person sitting down at a table together to talk about features, requirements, and expectations, Cucumber is an amazing tool to help bridge the language gap. And if Cucumber is still too techy, you can at least come up with acceptance criteria a grammatical step up from Cucumber that can easily become Cucumber scenarios.

Enhanced by Zemanta
Oct 312012

Today is Halloween, and it is also the anniversary of Martin Luther hanging his 95 Theses to the Wittenberg Door. These are two themes that are really hard to combine in terms of costumes and parties. You can only dress as a zombified Martin Luther so many years in a row before it loses its zing. There’s no point in branching out to other Reformers because, despite their various differences in life, theologians draw few distinctions between Zombie Martin Luther and Zombie John Calvin.

But I’m not here to tell you all about my personal problems; I’m here to tell you a spooky story that actually happened to me.

I graduated from Covenant College, which is situated at the top of Lookout Mountain, Georgia. The Chattanooga-facing side of the mountain is primarily populated with old money – fancy homes, country clubs, etc. The other side of the mountain exists beyond some time curtain where dense forests give way to tiny, rural communities centered around the local snake handling churches (I attended one of those services there, by the way, but that’s another story) and townships of less than ten families that didn’t formally rejoin the Union until the seventies. Sort of a Texas Chainsaw Massacre waiting to happen.

Twice a year, Covenant College had a Day of Prayer where classes were suspended for the ostensible purpose of giving students a day to rest and pray. I tend to think of Sunday as a good day for that, but I wasn’t one to turn down an extra day off, and neither was the rest of the student body. Day of Prayer was often shorthand for Day of Dollar Movies or Day of Smoking Cloves in the Woods. On this particular Day of Prayer, I decided to go hiking alone through the woods on the back side of the mountain, mostly because I am precisely the kind of idiot that horror movies rely on to be feasible, but also because I wanted to find a waterfall that was supposed to be near the base of the mountain.

I set out at 9am in my ill-fitting flannel shirt and possessed of no supplies whatsoever because, once again, horror movie idiot. I followed what appeared to be truck trails until they ran out.  After about three hours of heading deep into the woods on the loosely inhabited side of the mountain, I was good and lost. No waterfall in sight.

I was not alone, however.

Out of nowhere, a cacophony of loud barking erupted behind me. I’d heard no dogs prior to that time, but I turned around, and barreling through the trees at me were two, black Rottweilers. Slaver literally flung from their jowls. There was a man about fifteen feet behind them, partially obscured by some trees. I didn’t get a detailed look, however, as my reptile brain kicked in and I tore off running.

The dogs were faster than I, of course, but they had more trouble with the underbrush and, shortly, I came to this broken ridge on the mountain that was about a foot and a half wide, and I clung to the face of the mountain and stepped out on it, walking sideways. It was way too much for the dogs to navigate, and they just stood there and barked. No sign of the man, but I made my way around that ridge and down the other side.

So, now, not only was I lost, but I had paid absolutely zero attention to where I was going. I picked a direction and started walking. I didn’t know it at the time, but I was actually now circumnavigating the mountain near the base.

Eventually, I came to this odd area where the woods opened up into a wide valley of tall sunflowers. The sunflowers were like cornstalks – virtually a forest of their own. It was pretty amazing, really. The woods continued on the other side, but for that transitory strip, it was sunflowers as far as the eye could see, both horizontally and vertically. I began to make my way through those sunflowers.

It is important, dear reader, to understand that, at this point, I was dead smack in the middle of nowhere. Even later, once I could figure out where I had been, I was nowhere near any towns, settlements, or even roads. I was in the middle of a sea of sunflowers in the middle of the woods in an area of a mountain that, by rights, should have been virtually untouched by man.

So, you can imagine my surprise when, about ten feet in front of me, emerged a girl.

The girl appeared to be in her mid to late teens. Her skin was pale, her eyes and hair were dark, and her clothes were frilly, black, and neo-Victorian. It was like she was the archetype of the Goth ideal. It wasn’t really her looks that struck me, though, it was the fact that there was actually a second human being right there, making her way through the sunflowers opposite me.

“Hey,” I said in greeting, and she glared at me with the most awful, hateful gaze. I have had people angry with me before, but the sheer loathing in that gaze is something I’ll never forget, and it was truly shocking to me. If her hands hadn’t been in plain view, I might have worried about a knife or something. I kept my distance, and we stared at each other the entire time as I walked around her. That awful, awful gaze, like I was an invader.

At about 3pm, I emerged from the woods near Ruby Falls and walked the rest of the way back up the mountain on the main highway – dehydrated, tired, shaken, but grateful to be in familiar environs.

A month later, I was talking with one of my friends, and he was telling me that he and a friend of his (also named Phil) hiked on the back side of the mountain one summer. I told him I’d done that on Day of Prayer. He then proceeded to tell me about the house.

In the middle of a field out in the middle of nowhere, he and Phil had come across a two room house. Nobody was home. They went up and looked in the screen door and, according to Pete, saw that the house was decorated with small, hanging bones and sigils. They did not get to make a careful examination of the place, though, because out of nowhere, from around the side of the house, emerged two, black Rottweilers who chased them away.

Enhanced by Zemanta
Sep 272012
English: Photograph of Steve Denning

English: Photograph of Steve Denning (Photo credit: Wikipedia)

This is a question addressed in Steve Denning’s article that uses it in the title.  I have already talked about why one should appreciate Denning for what he does, but also take him with a grain of salt.  I want to take a look at the actual article content.

First, it’s notable that these points aren’t actually Denning’s.  Everything he says about kanban comes from an e-book by Michael Sahota.  Michael Sahota is a Scrum coach who, to his credit, also has some experience with kanban.  This means he escapes the critique of 99.999999% of the Scrum dudes who critique kanban – that being that they have no experience with it.

But it’s interesting to note that Denning’s actual arguments essentially boil down to, “This other guy said these things about kanban, and that sounds probably right to me.”  This is what I mean about the grain of salt.  Agile coaches, consultants, and commentators will have made astounding progress when they stop proclaiming religiously what someone else has said and actually observed it for themselves.  If there was ever a field where it was necessary to become your own authority figure, it’s consulting, and there is no other initiation into that level than trial, tribulation, and victory.

If someone has been leading their company through Waterfall and has been kicking ass, I can’t argue with her.  Why?  Because she’s actually kicking ass.  I honestly can’t imagine this actually happening with Waterfall, but you see my point.  I see far too many agile “authorities” boldly proclaiming what does and does not work, what companies should and should not be doing, and what the agile community should and shouldn’t be doing, and it’s just ridiculous to me because I know they have no clue.

The crux of Sahota’s/Denning’s argument is that kanban can work with existing practices and, unlike Scrum, does not challenge an organization’s culture.  Sahota qua Denning points out that kanban can address cultural change, but it doesn’t intrinsically require it the way Scrum does.  He then goes on to discuss kanban’s usefulness as a sort of slow “gateway drug” to more rigorous agile practices, such as Scrum.

The first problem with this is a confusion between rate of change and lack of change.  An organization that moves to kanban will have to change – culture, practices, values – everything.  However, kanban does not require bulldozing everything an organization is currently doing.  Rather than crushing the rock like another rock, it erodes the rock like water – pointing out the sharp edges that need smoothing and, organically and over time, carving out the Grand Canyon.  It challenges a company’s practices and culture slowly and incrementally, but it does challenge them.  You can’t do kanban and refuse to deliver incrementally.  You can’t do kanban and measure success by conformity to up front estimates and requirements documents.  But we don’t uproot everything at once.

Scrum, by contrast, requires a pretty big displacement of practices.  You can’t really incrementally Scrumify, and this is generally discouraged.  The irony is that you can’t change culture overnight.  The idea that forcing an organization to adopt Scrum is going to instantly transform an organization’s culture is not only ridiculous but a key factor in many difficulties people have adopting Scrum.  They do all the Scrum stuff, but the culture hasn’t had time to change, difficulties ensue and… guess what, Scrum doesn’t work!  No, it does work.  It’s just that you tried to take people from 0 to agile in thirty seconds.

The second problem is that Sahota/Denning confuse leaving a value stream unchanged with leaving an organization’s culture/values unchanged.  This is ironic, given that one of the thrusts of the overall article is that a set of practices are not the same as a culture.  Kanban begins by mapping what an organization currently does to produce value.  It doesn’t recommend changes right off the bat; it just makes the value stream visible.

Have you ever noticed that almost no organizations have done this prior to kanban?  Have you ever noticed that it is rare for an organization to have a visual map of what their inputs are, what their customers want, and how they produce value?  Do you know why this is so rare?

Wait for it.

Because thinking critically about how you deliver value to a customer and all the things that hinder that is NOT USUALLY PRESENT IN THE CULTURE.

Mapping the value stream is a challenge to the culture.  Making work incremental is a challenge to the culture.  Identifying bottlenecks and constraints is a challenge to the culture.  Allowing work “phases” some slack and having them go idle if the downstream is full is a challenge to the culture.  If you don’t think so, walk on up to your manager and say, “Hey, I’m not going to develop any new features, today, because QA has their plate full.  I’m going to help QA, instead, to get that moving,” and see how that goes.  It’s a challenge to the culture!  Folks, I have been at this a while at a pretty good number of companies, and I can promise you that the kinds of questions and activities kanban raises are not ones that allow cultures to go unchanged.  Just because you begin by mapping the current process does not mean you will change nothing.

Finally, there is the idea that kanban is suitable for organizations that aren’t ready for a “real agile” methodology like Scrum.  It might be a lightweight gateway into them, however.

I have to admit that I find this completely puzzling in light of what actually happens in the industry.  Not only have I been at this a while, many of my friends and colleagues have as well.  I also actively read books, blogs, and interact regularly with agile coaches not just in America, but in other countries.  All that to say that, while there’s tons going on that I don’t know, I feel like I have a high level idea of what the trends are in our industry.  And I have never, not even once, heard someone say anything like, “Yeah, we mastered kanban, and once we were rockin’ along on that, then we knew we were finally ready for Scrum.”  No one does that, and if your organization has, they would have burned you as witches in Salem because of your freakish abnormalities.

By contrast, the stories of organizations moving from Scrum to kanban are legion.  That isn’t to say there are more orgs doing kanban than Scrum.  That’s not at all true.  Scrum is way more common and popular.  But when you hear about orgs switching from one to the other, it is virtually always people going from Scrum to kanban, not the other way around.  And as a CSM, I can tell you that doing kanban well is every bit as rigorous and challenging as doing Scrum well.

Is kanban agile?

Well, if agility means delivering valuable software more quickly, then yes.  If agility means incremental delivery of the most valuable items, then yes.  If agility means challenging the culture to value learning, observation, and adjustment to change over guesses, contracts, and trying to eliminate variation, then yes.  If agility means uprooting everything an organization is currently doing, then no.