Agile software development: a prototype for all knowledge work?

Last week I reviewed Thinking for a Living, I’d like to pick up one or two points raised in this book and discuss them a little further. These are not points exclusive to Davenports work but having just read the book its a convenient focus for these thoughts.

I’m convinced that software developers (programmers, testers, product managers, etc. etc.) fail to recognise themselves as knowledge workers. Worse still, I think those that manage these people fail to recognise them as knowledge workers. So, we get discussions about “the software factory” and we hear managers describe how they can make their “factory” more efficient - as if the developers were working on a production line.

The metaphor continues, too many people in the business are concerned with “process” the idea - taken from Fredric Taylor and scientific management - that if we (the management) can improve our process then the factory will be more efficient, more productive, higher quality and so on.

What those who buy into this way of thinking and talking miss is that knowledge work is fundamentally different to factory thinking. In fact, modern factory thinking is different to traditional factory thinking. Toyota considers every one of its workers to be a knowledge worker - whether they are designing cars, advertising cars or assembling them.

The problem is, that when software developers and their managers ignore the knowledge worker aspect - either by regarding development as a factory process or as something “special” and “unique” - they miss out on opportunities, research and observations presented by the existing body of knowledge on knowledge work.

Davenport’s book clearly regards software developers as knowledge workers. Personally I’d go further, I think those involved with software development - that is everyone: developers, testers, analysts, product managers, project managers, etc. etc. - are not only knowledge workers but they are in the vanguard of modern knowledge work.

Before we write a line of code we need knowledge work: what is the problem? who does it effect? what is the benefit?

When we write code we need knowledge: language, operating system, problem, business, ....

When we test code we need knowledge.

Every line of software code embodies knowledge. Even the humblest for...loop expresses so much about out understanding of the problem, the solution and the domain it exists in.

Sometimes software people are the shock troops of knowledge work: parachuted into hostile territory to replace aging working systems and practises with shiny new technology - no wonder they don’t have many friends! No wonder you want “geeks” who don’t communicate with people, sometimes you don’t want them talking to the people they are replacing.

OK, that’s a little bit of hyperbole and exaggeration to catch your imagination but you get the message.

Now for the interesting bit.

Software people are on the front line of twenty-first century knowledge work. They don’t make it easy for themselves - ignoring much that existing knowledge on knowledge work, learning and change - but they are making discoveries, they are innovating, they are finding new ways of working.

One of the innovations that is transforming the way we do software is agile development and lean software development - I say one innovation because despite the two names they share much in common.

Davenport touches on this a bit, he spends a couple of pages on Agile methods and he quotes Martin Fowler. But he only hints at the true potential here. If, and its still a big if, Agile/Lean can transform software development maybe these practises can be applied to other areas of knowledge work.

What would it mean for a lawyer to work agile?

How would a financial advisor’s work be changed?

A journalist?

And a doctor? - in fact Womack and Jones are already talking about how Lean can change health care. Their recent book Lean Solutions actually discusses this.

Some ideas can transfer immediately:

• Card-and-board “Kanban” systems to focus work
  
• Daily stand up meetings
  
• Team work: break the one person, one task, as long as it takes model
  
• Pairing: why not have two lawyers write a brief?
  

Behind this a commitment to increase our productivity with a focus on value adding work - eliminate waste!

And, underlying all this, the operating system on which the whole thing runs: Continual learning and improvement - the Learning Organization.

Perhaps the future of all knowledge workers looks a lot more like the current methods being deployed by agile software developers?

Or perhaps, software people are just playing catch up, maybe we’ve cut ourselves off and only now are we catching up.

As usual the truth lies somewhere between the two extremes. For myself, I believe the future of all work will look a lot more like modern software development running on LOOS - Learning Organization Operating System.