Cracking the WIP

In my Top 12 for 2012 I talked about the need to "Reboot IT" and rethink the assumptions, behaviors and processes that have served us well to date but that I believe cannot sustain a modern enterprise in the face of the volume, velocity and value of change required to deliver on the innovation opportunity that Web2.0 and cloud technologies represent.

One of the fundemental tenets of this reboot will be the move to industrialise the delivery of IT. While the fan boys of methodologies such as Lean, Agile and Scrum sometimes get overly heated about the specifics, the general principal that most, if not all, seem to agree with is the reduction, if not elimination, of work-in-progress (WIP) by reducing the size of change and moving toward a more incremental, feature driven, delivery model.

The DevOps movement marries these ideas with others to describe a systems thinking approach to IT delivery that seeks to address the impedance mismatch that inevitably results from development and QA increasing build and release frequency without establishing a cadence (or "drumbeat" in the parlance of Theory of Constraints) across both functions.

One of the most common questions I get asked is "how do I get started"? In his book Kanban author David Anderson describes a pragmatic approach that I've seen work well in that it addresses some of the organisational change management challenges head-on. I find David's views especially refreshing, being that he has a background in large, complex organisations such as Motorola and Microsoft, his understanding of the importance of political as well as technical capital resonates with my own experience both as an employee of and a consultant to large enterprises and high stakes projects.

Briefly, David's sage advice is:

• Start with what you do now
• Agree to pursue incremental, evolutionary change
• Initially, respect current roles, responsibilities & job titles

He then extols the virtues of what he calls his core practices;

1. 1. Visualize the work to understand constraints and any artifacts of process imposed "insanity" (my words)
2. 2. Limit WIP which is the largest determinant of quality and duration of tasks (the more WIP, the later the deliverable)
3. 3. Manage Flow around constraints and resources with the goal of decreasing variability
4. 4. Make Process Policies Explicit as expectations not set are expectations not met
5. 5. Improve Collaboratively (using models/scientific method) as there's no point trying to optimise a system that has high variability

Nothing about this might strike you as particularly revolutionary, but by bringing proven manufacturing processes into IT, David and others like him, have crossed the streams of business and IT to achieve breakthrough results.

What surprises me the most as I've travelled the world talking to senior IT leaders, is how few of them are even aware this thinking exists, let alone championing the adoption (or even thinking about it). Is it because Kanban and the like are seen as "developer's business" and therefor too techie for the CIO or is it because it's so obvious it's not worth thinking about?

While you're thinking about that, Pump it up!