Carrying on from my previous posts applying the economists tools to thinking about software development (Supply & Demand in software development and Software supply over time). In this post I want to see what happens when we apply Agile...
We start with our supply and demand curves as before:
First we need to define Agile, not a trivial matter. Lets simplify this by saying “Agile practices”, specifically:
- Short iterations and regular releases (or at least demos), e.g. every two weeks
- Planning meetings, planning poker estimation (or similar, or #NoEstimates), velocity (or commitment if you prefer)
- User Stories, Epics, task breakdown (if you do this sort of thing)
- Stand-up meetings
- Team retrospectives and team planning boards or electronic equivalent
- Test driven development and continuous integration
- Pair programming, code review and shared code-ownership
- Acceptance Test Driven Development (ATDD), Behaviour Driven Development (BDD), Specification by Example (SbE), and other automated testing mechanisms
The first thing to note about all these techniques - and indeed the majority of what we tend to call “Agile” - is that these techniques work on the supply side. They operate on the supply curve, the net effect is to increase supply.
Possibly, if used in the right fashion, BDD and SbE might effect the supply side. But since most of the efforts to use BDD I encounter are little more than super-charged TDD we’ll leave it there for now - see Dan North’s blog for a better discussion BDD v. TDD.
Projects - specifically projects but other work initiatives too - are often still judged on the basis of: on schedule, on feature and on budget. Agile in this fashion is what I have called Iterative Agile, or at best Incremental. The team is still seeking to deliver a fixed quantity of software. Thus the demand curve is unchanged. (We will return to the demand curve in another post and discuss how Agile techniques might affect it.)
While Agile tools promise increased performance this is only in the long run. In the short run we can expect teams to slow down as they adopt these tools. We can also expect costs to go up as companies to spend money to buy in this expertise.
Maybe they hire the likes of myself to supply training and consulting in adoption (yes! I’m for hire, see my company website Software Strategy). Even if they don’t pay the likes of me costs will go up because engineers need to learn these skills. Companies rationale for hiring me is that I will help reduce the period of time for which they are slower and reduce the risk. The deal is: hire me and I will help you get to increased productivity faster (and with less risk).
Putting this in terms of curves:
A team starting on Ss can expect to move left (1) to Sasr (agile short run) before moving to the right (2) - Salr (agile long run) - reduced supply before greater supply. In the first instance the price per unit increases while the quantity delivered falls but after the second move the price per unit falls and the team produces more software.
Leave consultants like me to one side for a moment and simplify it. Imagine a team which “just does it”. Assume for a moment that the team members stay the same and the amount they are paid each week stays the same. When the team start doing something new they slow down, they produce less software each week so the average price of per unit increases. As they get better the same team better their original performance, earn the same money, produce more software and as a result the average price per unit falls.
Hopefully that all makes sense and isn’t controversial.
But I think something else happens. This is a hypothesis, at the moment I can’t measure it so please tell me - in the comments on this blog - whether you agree or think I’m wrong.
Staying with the supply curve, consider again the tools we were looking at:
- Short iterations and regular releases make it cheaper to make small changes. Therefore the supply of the small quantities of can should take place at a lower cost. And since the delivery - or at least a demo - is earlier the whole “project” could be cancelled if things don’t work out. Thus the bottom of the curve moves left over time.
- Automated testing (TDD, ATDD, etc.) reduce the quantity of faulty software produced and increase the amount of useful software increased at any point thereby raising all points on the curve. With less “technical debt” teams can deliver more functionality more cheaply.
- The same techniques - TDD, ATDD, etc. - and shared code ownership also make it easier for new engineers to become productive because a) there are more code examples of how the system works and b) places a safety net under any work they do, allowing them to experiment and learn faster, and get their changes to production sooner.
The net consequence of these changes is to flatten the curve, not entirely but certainly reduce of an angle. In economics terms we increase the elasticity. Changes in price - adding or removing a developer - causes a bigger effect on the quantity supplied than before.
Supply moves from the initial Ss curve to the Savlr (Supply Agile Very Long Run). As the chosen name implies, this takes some time to occur.
Now there is a catch. Consider the total amount of software bought and the total price paid (price x quantity.) To do this look at the next two diagram.
The green area represents the total paid for the software. You can’t see it here but on my graphics tool I can see price is 10 high and quantity 7 wide, so 70 (whatever) units.
In this diagram, on the new supply curve, the blue area represents the total spend. Again you can’t see it but on OmniGraffle it is 5 high and slightly more than 9 wide, almost 45 units of total spend.
Now if you are producing software for your own company - either to resell (e.g. Microsoft) or to consume yourself (e.g. a bank) - this model is good news. You get more software for a lower overall spend.
But, if you are an outsourced provider of software selling custom software to a client this is bad news. You now deliver more software for less money, about 36% less in total. If profit is tied to revenue (time and materials) then this is bad.
No wonder outsourced providers can be reluctant to embrace Agile or to do it badly. If you are a consumer of outsourced software development services you might want to think about that.
Next time I want to turn my attention to the software demand curve.
(As a footnote, using the same analysis techniques it is possible to show that reducing supply of software - moving the supply curve left, either because the software ages or because Agile adoption is slowing things down - will result in a greater overall spend for less software. This might be good for outsourcer suppliers but isn’t so good for in-house development.)
The biggest change which automated testing introduces is the change in the cost of releasing the software, the "transaction cost" of getting software out the door. Reinertsen's Flow goes into detail on this.
ReplyDeleteThis is significant from the point of view of how a firm functions, in the sense of Nobel prize winner Coase's "The nature of the firm", available here:
http://www.doutorlinux.com/pesquisas/economia/institucional/Coase_Nature_Firm.pdf
In it he talks about the point at which it makes more sense for a company to internalize production vs creating a service on their own. In short, your analysis is a special case of this underlying relationship among the incentives of the market participants.
This mental model would suggest that if it's possible for firms using software to internalize the production of software using agile at a lower cost than by using external providers (regardless of how they produce it), it will be rational for firms to push for that. External software providers (agile or not) will be forced to deliver at lower cost using agile or will go out of business if they refuse to change and don't provide enough value for money. There's also the whole issue you mentioned at @londoncd, that external consultants tend to work on projects, which causes its own problems. At the same time, if a company is in a serious pinch, it will often be capable of paying high consulting fees and still earn more than they pay for the consulting. This is the typical prevention vs. cure argument.
While I am certain the curve shifts outward, I'm not yet exactly clear on how the elasticity of supply is affected. I can kind of see where you are going, but I don't quite understand all the links. If you can expand more on this, it would be interesting.