Decisions and continuous flow

I’ll start with introducing my first bit of information.

Yesterday I sat in on a class my friend Alistair taught at a local college. Alistair was speaking specifically about process efficiency and applying lean manufacturing principles to it. Well, designing and building software isn’t exactly the same as building a product in a production line… but, Alistair (and others) assert that it’s similar. The “parts” that move from station to station in our software production line aren’t car-doors, or engine parts, but decisions that people make. In “knowledge work,” decisions are the parts that eventually end up in our finished software. And, we don’t get real value out of that software until that software – the product of those decisions – is put into use.

Alistair uses this chart to show decisions flowing from people or groups of people in different roles in software development:

Alistair describes this stuff in detail in the freshly released second edition of Agile Software Development.

Decisions or Requirements?

I suspect some of you have heard me rant about the word “requirement.” I hate it for reasons I’ll note down at another time. It’s important here because when a business person makes a decision about what they want and describes that decision to a business analyst, it be called a “captured requirement.” That decisions/requirement might be further elaborated by a BA and then forwarded to development. The developer could consider those his or her “requirements.” Decisions made by one station become the consumable parts used at the next station to allow the process to go further.

Decision Gluts

Alistair went on to make the point that if we pile up lots of decisions the forward them to the next station in big chunks, that next station is going to take a long time to work through those. He pointed out the idea that working code is sort of a decision made by developers. If we wait months before handing working code off to QA, we’re handing them a big glut of work – or decisions to validate/consume on their end. Predictably it’ll take QA a long time to get through this “glut” of code. The net result is the time for work to get all the way through the process increases as a result of handing of work in these big “gluts.”

In lean manufacturing the idea is to work towards “continuous flow.” This means every station gets a steady stream of incoming parts that they can process at a smooth, continuous rate. Keeping a station waiting, or sending them a big pile of decisions all at once disrupts continuous flow.

What about our end users?

Alistair’s model got me to thinking a bit further out. What about the end-users who receive the new release of the software we’re working on? What if we carried this model out to them?

Users who receive a new product release receive from us really receive the results of a bunch of decisions made in design and development. Users who rely on the product in their daily workpractice then need to look at the changes made in the software, and how those changes will affect the way they use the software. They may need to change their workpractice as a result.

It’s considered conventional wisdom that we don’t want to change the users experience much from release to release – that we need to work harder to get it right because users are intolerant of change. Users who are direct consumers may choose not to use the product. Users who’s use of the software is mandated by their jobs may suffer decreases in productivity. This thinking often leads us to lots of hand-wringing about the UI design, and often the reduction of release frequency because “user’s just won’t tolerate a high rate of change.”

But, if users are our last workstation in our process flow – and arguable the most important – then why would we want to drop a glut of change into their workstation to contend with?

Is it possible users hate new releases because they’re often inflicted with big releases, and lots of change all at once? Have they been burned too often?

Is it possible users cringe at the idea of more frequent release because the thought of dealing with that sort of pain more frequently makes them cringe?

Is the idea within organizations that we should release less frequently to end users based on some of that past bad experiences with big releases?

Assuming these preconceived notions are nonsense, and that people who rely on our software would like to see continuous improvement to that software, how do we design and build software in order to release that improvement on more of continuous flow manner?

Life moves in lots of continuous little changes

In the real world things seem to change slowly and continuously. My kids grow up slowly changing a little every day. I learn slowly – learning a little more every day. The world around me changes slowly – new buildings are built, new stores and restaurants open, new movies are released. All those things equate to little changes in my life. It’s the big changes – the big speed bumps in life that demand my attention that concern me most. There’s good big changes – like winning a lottery, and bad big changes – like wrecking my car.

What’s my point here? I think we’re all used to some continuous change – and the changes we pay the most attention to are the big ones.

Software with lots of little changes

I suspect you know what version of Microsoft Office you use. If you rely on Office, changing to a new version may be an exciting event, or a frightening event – or a bit of both. (I’ve already installed and backed off the Office 2007 beta. I just couldn’t cope with the disruption) Products like Office change versions infrequently and with BIG gluts of change. We have to brace ourselves for new versions. We have to set aside time to install, and familiarize ourselves with the new version. It’s an event that will eventually fall into the good or bad category – and we’ll approach it apprehensively.

What version is Google maps on?

What version is eBay?

What version is CraigsList, Flickr, YouTube?

I’ll assume these products have changed since they were first released. I know they have since every once in a while I’ll remark to myself “that’s new.” when I use a feature. Have these organizations figured out how to deal with change differently?

Visit the Wayback Machine to see how popular websites have changed over time.

Notice in this screenshot from the Wayback Machine that the ”*” next to the date marks when the site was updated. That’s a lot of updates.

I’ll repeat an anecdotal story about eBay’s design changes who’s source I can’t recall – so I may have made it up. 😉 When eBay wants to make what looks like a large user experience design change, they’ll plot several interim design changes that gradually move the UI to that new design – sort of like in-betweens in an animation sequence. This way the day to day user is never hit with some jarring amount of change – just little bits over time. You could see this sort of strategy as wasteful in that you’d design, build, and release versions of a feature or product with the intent of throwing them away in a short while. But, considering Alistair’s model above, aren’t we actually being more sensitive to the “continuous flow” we desire at our users’ change consuming workstation?

What would a design and development process look like that encouraged frequent small change to user experience?

I don’t have any proven answers, but I suspect people at your favorite big commercial website do.

What about other types of products ? commercial shrink wrapped products? large enterprise class products? software built for in house use? What might a design and development process that kept continuous flow all the way to the product?s end user look like for those classes of products?

I don?t know exactly ? but I have some ideas.

What do you think?