3 More Industry Problems

Today I read an excellent and, as always, emotional journal paper by Tom Gilb — the measure guy of software — entitled “What’s Wrong with Requirements Specifications? An Analysis of the Fundamental Failings of Conventional Thinking about Software Requirements, and Some Suggestions for Getting it Right“. (Download PDF)

It got me thinking (once again) about all that is wrong with the software industry. I now have even more to report. Everywhere I look, I see a mess. It is important to acknowledge that the industry is in its infancy. Acknowledging this, you can confidently and profitably dedicate a lot of time to work on the system, not just in the system. Because the system is broken by default, and will remain so for many decades to come, I believe.

3 Industry Problems

1. Requirements are not well defined. The main problem, as I see it, is that we’re mixing means and ends, as Gilb puts it. We’re talking too much about what we want, and not so much the background for that wish, which is what we should be specifying. If we know why you want something (i.e. business strategy, broken into objectives), we can use our experience to devise better solutions. Gilb proceeds to explain how to quantify and measure requirements. He’s right to say that we should, but he’s just way ahead of us, and we need to fix the way we specify requirements before we can start measuring anything. His point remains valid.

2. Factory organization – Separated and specialized functional units passing work between them in a large, efficient factory organization is doomed to fail (planning & specification, design, coding, QA, bugfixing). Such disregard for tacit knowledge and basic motivational psychology should not exist. Economies of scale in development (and services) is a myth. This has been tested and has failed horribly (think waterfall). It still happens all the time, and in many industries, not just the software industry. Probably also where you are right now. The closest metaphor I can think of is a kindergarden separated into “baby-feeders”, “diaper changers” and “comforters” etc. Think holistically — the real value delivered in in a kindergarden are not merely the practical operations. By contrast it is the safety and relationship developed with a few adults that the child will value.

3. Budgeting – Budgeting is usually a waterfall process in disguise. Budgeting was a tool developed for manufacturing, and should have remained so. But, to a carpenter, every problem looks like a nail, and so budgets are for manufacturing, service organizations and even product development companies. We’re not in manufacturing. Don’t adapt their tools. And, yes, this includes the Toyota Production System. Watch out, they’ll make you decide in your budgets what to do for the next year, and hold you to your promises. They’ll even scientifically measure this. Budgets forces you to spend the best part of each autumn guessing and assuming while you really should be out there gaining knowledge about emergent challenges, and adapting to them. Time is scarce — don’t waste it budgeting.

What does the Industry Think are the Solutions?

  1. Start XP/Scrum/Lean-teams
  2. Start XP/Scrum/Lean-teams
  3. Start XP/Scrum/Lean-teams

John Seddon says it well when he states that everything needs to be projects and tools for us westeners. “Toolheads”, he calls us. I believe he’s got a point. Even Lean, originally The Toyota System, has been subsumed into tools and projects. Every organization has got a lean manager, or a lean team these days — fixing problems functional department by functional department (oh, the irony) by introducing some tools and running some projects, and then moving on. An A3-reporting there, a daily scrum here, a pull system there, 80% code coverage over there, and so it goes. Basically they are piling new tools and projects onto a broken framework, instead of building the capacity to change the system from the inside by getting managers out there, getting knowledge, working on the system. Get away from budgets, spreadsheets, resource plans and other guesswork – get knowledge and let’s use it to improve the way we work.

The current industry solutions only have us doing the wrong thing better. There’s nothing more wasteful than doing well what should not be done at all.

What are the Real Solutions?

We need to acknowledge that the way work is organized is broken and start addressing it from the core. What makes this challenging, is that the entire organization needs to be in on this, not just the lean tools team or the new empowered Scrum team. These teams are usually not empowered to change the system. Start by getting that power. Talk to your management. Talk to your CEO. Be patient. Discuss. Elaborate. Start small, but do it every day.

You need to design your organization towards challenges (think in terms of what you are solving for your customers, and design against that), rather than just defaulting to functional departments with their meaningless budgets and policies.

This means organizing in cross-functional teams empowered to change the way work is done, with management as a support function embedded into the work. Everyone’s goal becomes to establish good flow in how we solve real problems for real customers in the most effective way possible.

This is when magic starts to happen, and the fun kicks in. Solving a real problem for a real customer, and actually being there to witness it, is motivating and stimulating. Communicating directly and related to real challenges, not just via plans, sprint-/project backlogs, meetings, reports, Gantt charts and budgets.

Freed from this burden we can spend time improving the way we work, just a little, but every single day. It’s really quite simple. It’s fun. It’s motivating. And not the least, it is very, very profitable. And it is sustainable. It scales.

No more factories with human cogs, no more economies of scale. We all want to be a linchpin. We need economies of flow.

Anyway, this is how we’re designing our organization, and it seems to work very well. Come to us and take part of this journey. We’re hiring in Oslo and Gothenburg. (Follow the author @geirber or the company @aptoma on twitter, or through RSS)

References

  1. Why Do We Believe in Economy of Scale? Article on Bryce Harrison inc.
  2. Linchpin – Book by Seth Godin, inspired by the same factory problem
  3. 3 Major Problems with the Software Industry (Select *)
  4. The surprising truth about what motivates us (YouTube)
  5. What’s Wrong with Requirements Specifications (PDF)
  6. Cultural Change is Free (John Seddon on Vimeo video)
  7. Systems Thinking (Dry, but good, Wikipedia stuff)
  8. Rethinking Lean service (Entertaining Podcast)
  9. Economies of scale – It’s a myth (Entertaining Podcast)