You must must must watch Malcolm Gladwell tell his little story about a friendship that went wrong. It's only 15 minutes long and it's funny and tragic, but more funny than tragic. [via presentation zen]
Clarke Ching's Rocks and Snowballs Blog
Please forgive all the spelling and grammatical mistakes below, and the general half-arsedness of the writing, but I figured I should share this (currently overlong) chapter from the 4th quarter of my book. It's the bit where my characters - the hero, Steve, and the guru, Craig - discuss Craig's incompletely-formed theory of when and why software development went wrong.
Just one thought before you read it: my hero isn't a software guy and he's not really a guru in his own mind, he just reads a lot and worked in manufacturing for years.
Craig (the guru) said, 'Guess what, Steve.'
I played along. 'What?'
He stopped, turned to me and held his hands up. 'When I started working with your software developer colleagues in Wyx-health, I soon discovered that your software gurus - the folk who, I guess, formalised the way you work, way back - were heavily influenced by the western quality gurus. What surprised me, though, was how badly they screwed up.'
'You now how, in the 1970s and 80s, everyone in business wanted to emulate the Japanese way of manufacturering? TQM, Just in Time, Kaizen. And so on.'
'Well, how do you think most western manufacturers learned what the Japanese did differently?'
That was easy. 'From consultants. Or books.'
'Exactly. Now, my guess is that your computer gurus - being inquistive people - read those books too, recognised the books tackled the same symptoms they were trying to prevent - namely too much expensve rework at the end of their processes - so they took the quality techniques from the books and applied them to software development. Rather clever, but so, so wrong. Do you have any idea why?'
I shook my head.
'You, software development people don't do manufacturing. You do development - the stuff that happens before manufacturing starts. The hint is in the name - you do software "development", not software "manufacturing". Right?'
'Umm … '
He frowned. 'I'm going too fast. I'll slow down.'
He pointed towards the cafeteria's kitchen. 'In the kitchen, they have big binders full of recipes. Someone developed those recipes - I'm guessing they took well known domestic recipes then adapted them for use in large scale commercial kitchens. This might sound strange, at first, but a recipe is a description of a manufacturing process. The recipe starts with a list of raw materials - the inputs - and follows with the steps to tranform those materials into a final product. With me?'
'Input-Processing-Output? Gotchya.' Those words described a generic algorithm and were words familiar to any developer.
'Now, put yourself in the shoes of the people who developed those recipes. Do you think they just write the recipe down then publish it, without testing it first?'
I shook my head. That would be daft.
'Of course they don't. What they'd do is write version 1 of the recipe down, cook it, then taste the product. If it doesn't taste good then they'll tweak the recipe, write it down, cook it, then taste it, and so on. They'll keep coming up with new versions of the product - tasting them and testing them against other criteria - until they're happy. Do you know what that kind of process is called, Steve?'
I frowned, thought a moment. 'Is it Iterative?'
'Yes, it's iterative and empirical, in that it's based on evidence - like when they taste the cake - rather than just pure theory. You might also say it is incremental as they produce version 1, then version 2, then version 3, and so on. They key word here, for me, though is iterative. Does that make sense?'
'I guess'. I then played back his words, to check I understood. 'They iterate, testing their output until they get it right?
I thought a moment. The output of a recipe development process is the recipe, which, itself, defines the new the manufacturing process. And the output of the manufacturing process was the product itself. The development process created the lasagne recipe, the manufacturing process follows that recpie to coook the lasagne.
I said, 'I'd never thought of it that way before.'
'Nor had the folk at Wyx-Health.' He leant forward. 'Now, put yourself in the shoes of the team which develops new cake recipes. Would you expect iterating like that - with, lets face it, loads of failure - to be expensive? '
I instinctively shook my head, 'No. They'd work in a test kitchen where the marginal cost of throwing away food is some lost time and some raw ingrediants. They need to fail to learn and it'd be much ceaper to fail in the test kitchen than in, say, the canteen's kitchen.'
'Precisely. Now tell me: you do development so what's your industry's equivalent of the test kitchen, Steve?'
'Our developers work in what we call a development environment. When we've finished our development work, we move our code into what we call our production environments. They're the big computers where our real customer data lives.'
'So, your production environments are the equivalent of the factory, or the canteen's kitchen?'
'What, then, is your equivalent of the recipe?
I blanked. I really didn't know how to answer him because I didn't really understand his question. I shook my head. 'I have no idea.'
'Nor did I, at at first. But your Wyx-health colleagues soon figured it out. They concluded that the recipes you create are the programming code your developers write - both are, after all, the instructions for transforming inputs into outputs.
'Algorthms', I said.
He nodded. 'Does that sound crazy to you?'
I considered his question for a moment then screwed my face up, awkwardly. 'Actually, yeah, it does.'
His face fell. 'I thought it might. But, let's pretend your code are recipes and see where it takes us. Your programmers write recipes in their development environments. Your testers taste the recipes. And when the recipes are good enough, they're tranferred to the production environments where they are run with real inputs, producing real outputs. You still with me?'
I frowned. His theory sounded plausible, but I'd never heard anything like it before and I was skeptical. It wasn't so crazy that I didn't want to hear his conclusion, and I didn't want to be rude, so I said, 'Just …'.
'Okay. Here's the bit that puzzled me. Development teams in other industries start iterating - and therefore testing, since testing is an intrinsic part of iterating - very early in their development processes. They cook version 1 of the cake, test it, tweak the recipe, then cook version 2, and so on. They test throughout the entire development process, but you computer people don't start testing - or iterating - until mid way through a project. Why is that?'
Again, I couldn't think of an answer. I shrugged. 'That's just how we've always built software.'
'Let me tell you what I think', Craig said. 'Like I said earlier, I think your gurus borrowed the quality thinking from the books about quality in manufacturing because that was all that was avaialbe. If there had been books on quality in product development then your current processes would have been iterative, incremental, and empiracle. They would have assumed you start with an incorrect recipe then iteratively and cheaply improve it over time. They would have assumed the output was a recipe fit to run in your production environments. But they didn't, instead they took the processes applicable to manufacturing which assumes the recipe is right before it starts and, since the recipe is meant to be correct, there's no need to iterate.'
I put my hand up, requesting a moment to think. 'But, since we're doing product development in a manufaucturing environment, you still iterate but not until we start testing in the last half of the project. That's when change requests happen- at the last half of the project, when they're expensive to do. Is that it?'
He said, 'Yeah. It's something like that.'
A couple of months ago Rachel Davies, an Agile friend, wrote a blog post called "The Folly of Scaling Agile". It was, as you'd expect from Rachel, very well written and very well thought out. Only problem, for me, is that I disagree with her conclusion. I thought I'd share my comment here, since Scaling Agile is not only possible, but vital.
I agree with a lot of your thoughts, but I have a different conclusion and - I suspect - a slightly different view of what Agile is. I don't think scaling Agile is folly, I think it's HARDER because of all the things you've described but I think (I know, actually) it can be done. Agile in big organisations is different to Agile in smaller teams. I think (know) it's worth trying to do it though because it makes the working lives of people who work in software development businesses happier (though not necessarily easier).
The starting point for me is that scaling Agile usually involves teaching all sorts of people in all sorts of roles who are unfamiliar with - and often very hostile to - Agile to work in what is a very counterintuitive, to them, way. Small-scale Agile, with a team of converts is easier for all the reasons you've described.
So, part of the solution, is to adopt agile in a way which doesn't cause push-back from the adoptees.
I do use some new Agile words, but I try to use old words as much as I can.
I start at the high-level and try to get the customers and project management to chop 1 big project - how they'd normally do it - as, say, 2 or 3 or 4 smaller releases. I trick - in a nice way - the teams into collaborating, by getting the testers to sit down with the developers and analysts before any code is written and discuss what and how and when they're going to test it. I get the analysts to work with the developers and testers and PMs to slice and dice the functionality and then think about how they can build those slices up bit by bit. A get vendors to ship their work in, say, 4 or 5 drops, rather than 1 big drop, and I ensure we test the arse off each of those drops as we go.
When I work this way I try real hard to ensure that I'm always removing pain for people - but sometimes I have to let them realize they are feeling pain first.
We've launched a brand-new product this way (with a team of about 80) in the last 2 years and also a brand new business. If you look at the way the teams work with your XP eyes you'll see tonnes of things the teams could do differently, but for me it's a step by step process which takes considerable time, but it's worth it.
You might not know this (or may have forgotten!) but for the last decade I’ve been writing (& rewriting & rewriting) my business novel, Rolling Rocks Downhill. The book is my answer to the question: what would we do differently in commercial software development if our job was not to just build software but to make our businesses more profitable and our workplaces happier?
I’m rather happy this morning because last night I completed 9 months worth of hard slog where I removed 15,000 words from the first 3/4s of the book. That’s hard! I chopped it down from 90,000 to 75,000 words. I restructured the book a good bit, I rewrote and rewrote bits of it so they’re easier and faster to read, and I added more description to the text so it's more visual to read. I killed a few darlings along the way too - ouch.
Next up? I’m about start stitching the last quarter back onto the end of book. Most of that material is already written, but it needs thinning out, speeding up, and some needs to be completely rewritten.
And then? Not quite sure …
If you're frustrated coz you've got lots of good ideas and others just don't get them, then read on. My sucky experiences, and my response to them, might help.
Ten years ago I learned about KAI theory, a simple model for thinking about how people like to change, which enormously influenced how I role out Agile and TOC.
I was in the worst job ever, at the time, and the problem was me.
I was an innovative type, naturally preferring radical change, working in a large organisation with a preference for little or slow or incremental change. I thought the problem was "them" but after learning about Kirton's Adaptor Innovator theory (KAI) during my MBA I realised the problem was "me". I didn't fit and, like the human body rejects virus, the organisation eventually evicted me and my grand ideas.
The essence of KAI is that some people prefer small, slow, incremental change and others prefer bigger, more radical innovative change. Kirton has a test which places individuals on a continuum with Adaptors at one end and Innovators at the other.
There are two important bits:
- People who score near each other on the continuum understand each other but they think everyone else is a bit nuts (innovators think adaptors are boring, change averse cow-ards; adaptors think innovators are dangerous, risky cow-boys), and
- Just as birds of a feather tend to flock together, organisations tend to cluster around the same part the continuum, and they evict people and ideas that don't fit.
If you imagine a 12-inch ruler, I was working in an innovative organisation where most people sat at the 2 inch mark, but I preferred the 9 inch mark. It took me 4 years to escape and find an environment which fit my style. The alternatives were that I either changed all of THEM to fit my style or I changed myself.
Nowadays I work in an organisation which sits (I'd guess) at the 3 or 4 inch mark, but I'm still a 9. I deliberately chose this situation because I think it's wrong for incremental to miss out on Agile, and most of the 9's already know what I know and can do it better than I can.
How do I cope? I be innovative (i.e. play to my style) by innovatively figuring out how to dress my fancy ideas up so they're more easily consumed by people who prefer incremental change.
One key way I do this is deliberately dressing new ideas up in old clothes (Skeuomorphism) which is surprisingly easy since little of Agile is all that new. Another is that I take a TOC approach to improvement which, because improvements are focused on the system's bottleneck or constraint, limits the amount of change that happens at once. Another is that I focus on the essential part of Agile (delivering small chunks of value, often) rather than the prescriptive practices and then I help the people I work with figure out what practices they need themselves.
I call my approach to implementing Agile & TOC, SLOW and quiet Agile. The SLOW bit, I find, is really important because it means stuff sticks ... so, really, it's faster.
Want to read more?
Then read this: http://www.kaicentre.com/initiatives.htm.
I like this, Bruce Springsteen’s preamble to “I’m going Down” during his first 2014 NZ concert. It kinda sums up life, though I’d maybe put a more positive spin and say things are crap then they get better”.
It goes like this.
Everything is alright. And then … it’s not.
Everything is alright. And then … it’s not.
Has anybody experienced that?
One minute everything is fine … and then … it’s not.
Why does that happen?
Now generally the answer I get is: one minute I’m alright … and then I’m not.
<stop quote, start singing>