Agile Transformation Myths: I.T. is a Commodity

If you have ever been around a delivery that involves software development then you will know that people make a lot of assumptions about what it takes to write and deliver software features. When it comes to crunch time we have all seen the demands to “just add some more devs” or “give them some overtime”, or someone suggests a new feature late in the day and, rather than bother the busy developers, someone will say “it’s probably going to be like that other feature, so let’s plan for the same effort”.

As with every field of expertise, it is very easy for people who have never written code or delivered software in anger to miss some of the critical aspects of the software delivery process, and therefore not understand the constraints, realities and frustrations of the craft that is software engineering.

There is a fairly common misconception in business that IT (read software delivery) can be looked at as a commodity. This is generally a hangover from old-school manufacturing industry/factory model thinking (although the successful manufacturing businesses have moved on from that thinking whereas many of those outside the industry have not).

Effectively the belief is that you can buy lines of code off-the-shelf, all code is the same, all developers are the same. They are “bums on seats” who type — how can that not be a linear commodity? If I am painting a wall then getting someone to help me means we could paint it in half the time, 2 equally sized walls would take double the time. If we can normally paint 2 walls in a day and have a job with 3 walls that needs to be finished in 1 day, we can stay late and paint a third in the evening.

If that is true, then the same goes for engineering software products — writing software is a linear process, right?

• Writing double the code (whatever that means!) takes double the time
• 2 developers can write code 2x faster than 1 developer
• Asking someone to work an extra 4 hours in a day gives you 50% more “code”
• etc…

A worrying amount of people, even some who have worked closely with software teams for a long time, fall foul of this misconception. This is dangerous.

Whilst what follows is true for any approach to software delivery, it is particularly an issue when a company looks to undergo a Transformation to an Agile delivery approach. In an Agile Transformation, we help business and IT teams work closer together, offer them new methodologies and approaches (Agile ceremonies and artefacts, Continuous Integration, user story writing techniques etc…) to help them deliver in a more Agile way. However, a key step that is missed in most Transformations is bridging the gap in the understanding of what it actually takes to write software. We fail to debunk the myths.

This is dangerous because a waterfall delivery approach (where most companies are transitioning from) often papers over the gaps and can hide the failings that result from these misunderstandings or worse, provides a mechanism to point the finger at another person or another part of the process as the cause of any issues.

In Agile we promote far more transparency throughout, bestow more responsibility onto key roles and because of the speed of delivery, the impact of bad decisions due to these myths is almost immediately exposed. This is scary and needs organisational change and support to ensure the transformation process is not derailed. Mistakes and bad decisions are inevitable, it’s how you react to them that’s important.

Through osmosis some people working closely with software teams will start to appreciate the realities of writing and delivering software, but in my experience unless you address this directly there is rarely a light bulb moment. It only takes a few senior people to hold on to and reinforce these myths, and a few delivery issues as a result, to seriously undermine the transformation approach.

Having said that we need to bridge the gap, we have to face the reality that the majority of non-technical people really couldn’t give 2 hoots about writing code — and why should they? The job of a coach in a transformation is to ensure that everyone gets the understanding and support they need to perform to their best and help their organisation maximise the value it delivers.

The challenge here is to help people appreciate what it feels like to deliver code and understand how some developer behaviours that may seem strange or awkward or counterintuitive are a function of the role. We shouldn’t get upset with them, but instead should accept and find a way to work with them to deliver the best outcomes they can. Coaching that in a non-threatening, fun and non-patronising way is the skill.

Some of the key aspects of a developer’s life that non-developers may find hard to understand include:

• Developers are not born equal: The difference in capability between an average developer and an exceptional developer comes as a surprise to some people, but understanding this is fundamental to understanding software delivery approaches. Stretching the painting analogy, a truly exceptional developer could genuinely “paint” as many as 50 walls in the time an average one paints 1 wall
• Developers work best in a state of “Flow”: That developers work best in a quiet, zen-like state (“being in the zone”) can be surprising and facilitating that state reaps rewards but takes effort. Interrupting a decorator with a cup of tea costs the time to drink the tea. For a developer you could add as much as an hour onto that whilst they recover their mental model of the problem they are solving
• Surgeons around the body: Even the most traumatised patient can only be worked on by a limited number of surgeons, due to physical space and strain on the body. The same goes for software, you cannot deliver software faster using more and more developers — there is a capacity for a code-base and a diminishing rate of return for additional developers thrown at a problem. This is one of the most valuable yet seemingly unintuitive lessons an organisation can learn. Adding more people can quickly cause a team to actually slow down
• The myth of 100% utilisation: Against general expectations, giving people less to do can make them go faster — and forcing more work on them slows them down. This is a culture shock for organisations and is at the heart of a Transformation — helping an organisation find the optimum point below 100% (and note it is probably nearer 50–60%) rather than trying to fully utilise everyone or worse, extend beyond their capacity with overtime
• Estimation — the abuse of developers best intentions: Developers hate to give disappointing messages and their glass is generally half-full — they are arguably the worst people in the world to accurately estimate how long it takes to deliver software. We need to help an organisation break the habit of thinking it needs to-the-minute estimates (which are always wrong). Accepting a different approach to planning and estimation which may have a level of uncertainty but which gives better predictability is of far more value to the business
• Developers need to know why: Obsessively analytical minds work best when they understand why. Yet at times it feels like the objective is being actively hidden from the developers (possibly for fear of taking their mind off delivering software). Colleagues should look to use this behaviour as an opportunity rather than, as I sometimes have seen, getting frustrated by the constant questions
• Features and Code are not the same thing: Delivering software features does not directly equate to writing lines of code. A complex looking feature request could result in a 3-line change in a well-written piece of code. A simple looking feature request, but one which subtly changes the paradigm of the application could lead to a major rewrite. As a non developer it is pretty much impossible to guess which path it will take

Working through these myths and educating at all levels of the organisation is a fundamental part of helping an organisation to grow and change it’s culture so that it is ready to fully engage in an Agile Transformation. Anything less and at best we are potentially facilitating a “Scrum Transformation” (and a bad one at that) and holding the company back from reaching its full potential.

However, the best place to start is with open communication and to challenge any assumptions or myths as soon as we spot them.

Understanding is a 2-way street

If this works to help our non-IT colleagues then surely the same goes the other way.

Our job as Transformation partners is to ensure the learning is a 2-way street. Developers should sit in on customer service calls, should understand how the company’s products and services work, appreciate the annual financial cycles and regulatory limits and the pressures and constraints their (non-IT) colleagues are working under. Not to the level of guru, but enough to appreciate the business model and the context they are developing in. Often this is pushing at an open door, good developers see this is an excellent opportunity to improve their knowledge and show the increasing value they can deliver.

Note on Decorators

I have every respect for decorators and I do them a disservice suggesting theirs is a linear industry — the wrong choice of paint can mean an extra 2 or 3 coats, an exceptional decorator (because they are fitter/stronger/more accurate) may be able to work twice as fast as a standard decorator etc. However, from the discussion above you can hopefully see that the skill of decorating is far more linear than engineering and delivering software.