Agile Manifesto is a journey, not the destination
We cannot get started without making clear what the Agile Manifesto is. So let’s push that out quickly. Agile Manifesto is a document that states we should prefer:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Being a curious person I tend to ask “why?”. Does following these principles make your process agile? If you want to be agile, you probably have to deploy these techniques, but are they enough?
It depends on how you define agile:
Brian Marick, Agile software development and Glade air freshener: “While I like the word “agile” as a token naming what we do, I was there when it was coined. It was not meant to be an essential definition. It was explicitly conceived of as a marketing term: to be evocative, to be less dismissible than “lightweight” (the previous common term).”
James Bach, Who Stole Agile?: “It was always my understanding that “agile” meant agile. The Agile Manifesto looks to me like an enumeration of the factors that allow software development to be agile. That’s why I like the manifesto.”
So if you define “agile” as the marketing form of lightweight, you’ve probably done enough when you’ve follow the Manifesto. But if you want agile in the meaning it’s defined in dictionary, that is, quick, the Manifesto can lead you the way, but not take you to the destination.
As marketing can assign some good-sounding label to anything and find blind followers, we’re not interested in the first definition. We’ll rather take a look why should we produce software fast. Why exactly is faster better? Why should we take agility further than states the Manifesto?
Karel Kravik: “There’s simple truth behind the scenes but nobody has yet stated it in that way.”
Software has time value
Time value is best explained in money example: €100 now is worth more than €100 in a year – if you had €100 now, you could put into deposit and earn interest during the year, that is, if the interest rate were 10%, you would have €110 at the end of the year. Yet there is another factor that eats away your interest earnings – inflation. Inflation is a property of money to lose value during time. So if during the same year inflation is 3%, you end up with €110 having the purchasing power only about €106.8.
Wikipedia thoroughly explains the time value of money.
Now picture you’re a custom software developer. Your clients order software from you because:
- They can cut more costs than they pay for your software
- They can earn more money with software than they pay for it
People don’t order software because they find it fashionable to use it instead of holding paper documents in archives; they lose money while not having it.
If you’re a software product developer, it’s even simpler – as long as you cannot sell your product, you’re burning cash developing it.
Basically, not having software costs money.
It may not be simple, but if we really wanted, we could calculate the expenses of Hansabank when all the payments now going through Internet bank were made in bank offices. We only had to take the number of payments and an average cost of payment which, in turn, depends on the average salary of cashiers in different regions…
Imre Lumiste, Changelogic technical lead, also engaged in job interviews: “That’s a good impossible question.”
Karel Kravik: “And here is a rhetoric question – have you ever asked yourself why we see so much beta software nowadays?”
We see beta products because they’re there to gain mindshare, to get publicity, to build community around the product. Now when you want to calculate future value of money, you have to know the interest rate, but can you predict future mindshare?
You don’t know the interest rate
Here the analogy ends; it’s not nearly as simple to calculate the future value of software, in fact, it’s impossible. What make it impossible are things you don’t know and cannot predict – you are not aware of the risks you’re taking nor the optimal criteria for setting your priorities.
Karel Kravik: “Imagine you put €10M into deposit and you don’t know the interest rate – would you prefer taking your interest yearly, monthly or weekly all other circumstances being the same? Or maybe even daily?”
The point I’m trying to make is that as long as you don’t have the software (or feature) you don’t know how it will affect the future value. Now it’s your choice if you want to figure it out once a year or once a week - the fundamental difference here is that the wider the time window is the bigger is the risk you’re exposing yourself to.
You’re exposing yourself to the possibility that maybe the customers don’t like your software; maybe it doesn’t satisfy their needs nor match their expectations. So they end up not buying it any more, in turn meaning no money for the developers. And isn’t it rational to find that out after a month rather than a year?
Here is the place where all the fluff about agility and adaptability starts to make sense – rather than trying to predict the future value long ahead, you check it periodically, the shorter the period the less you have to predict.
Karel Kravik: “Just like long development in isolated branches is more probable to result conflicts during merge, long development without reality check is likely to end up with conflicts between your opinion of what is good and your customers’ expectations.”
There is one more factor that comes into play when we’re calculating time value – inflation.
You don’t know the inflation rate
The other essential component when calculating future value of money is inflation – the rate by which money loses its value.
By default your software too loses value; it loses value even if it’s not ready. And it may even never get ready, because your competitor brings out a superior product half a year before you.
So when you’re planning a release you have to draw a line somewhere – feature A goes in, feature B doesn’t, can we afford refactoring or not; you have to draw the line what is “good enough”.
The problem is that “good enough” is perceived differently by developers and the people who really use the software. Developers like it if the code is elegant, abstracted to the right level, optimized to the right level, readable and maintainable to the right level. A programmer is actually never quite satisfied with the code; he can tinker with it forever.
Now from the standpoint of business people – they are satisfied if it looks beautiful and does what it should do, they don’t care exactly how ugly it might look to a developer.
The twist is that if you focus too much on, say, maintainability, it could happen that you will never have to maintain it because there will be no chance to sell it in the first place. Focusing on technical perfection does not increase your user base.
Karel Kravik: “It’s like taking a loan with 10% interest rate and put it to a deposit with 3% yearly interest rate.”
To turn that interest rate differential into your favor you have to be lightweight; you have to operate cheaply; you have to be really focused on the core concept and push it out as soon as you can; as soon it is “good enough”.
Karel Kravik: “Just as developers occasionally write temporary code to test technical concepts, software products or individual features can be considered as tests too – tests of business ideas. There is no point to design them for a long run until you are not sure they’ll survive.”
The Manifesto
While the Manifesto gives us some clues how to be more lightweight, that is, cheap and if development is cheaper, we can probably release faster too, it doesn’t explicitly state what is the reasoning behind this; neither does it tell us how to be quick.
Karel Kravik: “If I had to sum this post up in Manifesto-like manner it would look like this:”
- Working software now over working software in the future
- Frequent reality checks over long predictions
- Good enough over perfect
Add comment August 23rd, 2006