There are two factors that determine an IT project. Projects aim to raise the return on invested capital; the two main enablers are to save money or raise the perceived customer value. Either you become more efficient or you generate new opportunities. There is often a combination of these two where projects aim to both get new opportunities and save money at the same time.
If the first priority is to generate new opportunities and to raise the perceived customer value, the marketers will probably be your customers. And if the main enabler is saving money, you customer will probably be a administrative manager.
Deciding which one is more important – cost savings or opportunities – means analyzing requirements and establishing priorities. You might have several different stakeholders and users and it may be difficult to understand what they really wish to accomplish with a specific feature or demand. That’s when it might be helpful to ask, is this a cost saver or a new opportunity?
If you come up with a plan, you might surprised to learn that your customer will be dissatisfied about cost savings if you developed a project with new opportunities in mind after consulting with various stakeholders and users.
This means that the motivation of IT problems isn’t to solve technical problems; you are foremost there for solving organizational and business problems.
The foundation of Agile methodologies is to work in iterations. This has many benefits:
Benefit # 1: Code that is not used by stakeholders is an inventory cost. If you had a store selling clothes in all models but are not visible to customers, they would never get sold. Their value declines because soon they will be out of fashion.
It’s the same with code. If it isn’t used, you never get real feedback or get the chance to test it. The world around the system constantly changes and soon you will be working on new problems if the code isn’t used. When you move on to new features, this unused code becomes an inventory cost.
A ratio that is used in financial analysis is the stock turnover ratio. Stock turnover ratio = annual sales / average inventory. The average stock is calculated by adding the inventory value at the beginning and end of the year and dividing it by 2. For software development, you could say that the turnover ratio would be “features shipped per year” / “average number of features that are waiting for testing or deployment or not being used by users”.
Benefit # 2: Continuous integration and frequent deliveries generates feedback. Small and fast iterations also mean that the code must constantly be integrated with previous work and frequently delivered to users. This means that the code is tested during integration and also tested by users after it has been developed. If something goes wrong it is better to know about it at once. If you investigate a bug which is the result of work done 6 months ago, the root cause analysis will take some time. But if you get feedback on work done today or recently, you can easily find the root cause.
Benefit # 3: The complexity factor does not become large with small iterations. If you estimate doing two things that are about the same size, you think of the work as a having a linear relationship; that is, if I do twice as much it will take twice as long. If the first thing takes 8 hours and the second one takes 8 hours, you can do it in two days.
But if you have to do both of them in one day with the help of one friend, can it be done in just 8 hours? The answer depends on the dependencies. If both works have dependencies, you need to make sure both parts interact as planned so they don’t interfere or overlap one another.
- If you have one thing to work with, you’re dealing with only one thing.
- If you have two things, you deal with them, but you also have to deal with the way they interact and interfere with each other.
- If you have three things, you have those three things, but at the same time you have three different sets of interaction between pairs of the three, plus you have to deal with the way all three things are combined which leads to seven aspects.
- If you have four things, you have 15 aspects, and so on.
Therefore, if you have 10 things that are related and dependent on each other, doing them might be 1000 times more complex (or to be exact, 1023 aspects to deal with). The number of dependencies multiplied by the number of things to do result in the following formula: (Aspects to handle = 2 x “the things” – 1). What do these things consist of? It could be number of users’ stories, number of integrated components, number of departments involved, number of people in a discussion.
Benefit # 4: Business value comes from the possibility of adapting to change. When you start a project, the decision to start it comes from the possibility of reaching an expected business value. When the first version of the system is released, not all of the features are perfectly adapted to users’ needs. The system, therefore, doesn’t reach the expected business value.
The longer the system is used, the more the business learns what it takes for the system to reach expectations; however, because the releases are infrequent, the system falls short of its value. After a few years, the system shall have reached its minimum accepted value.
When an Agile approach is used instead, the first release lacks a lot of expected features but because new versions are frequently released, the system doesn’t fall short of its value over time. Releases are delivered, because new knowledge is used to re-prioritize work. When the system is used for a period of time, expectations tend to rise.
Delivery of Business Value
The most important observation is what this does to the stock turnover ratio, since the delivered value of the system is based on the time the system is used. The delivered business value is the red area, because it creates value when it is used. So using a system early on shows that the value delivered is at least doubled when using the Agile approach.
When the minimum accepted value is reached, business people tend to think they need a whole new system; only this time the original requirement has changed. The priority now is to add features, and to change and adapt the system to new acquired knowledge, re-factoring and updating it with new technologies. In truth, what the business needs is not a completely new system with perfect requirement specifications. What the business needs is to continuously develop their system in new ways.