Kaizen — Japanese philosophy in modern software projects
For quite a few years now agile software development has been a “buzz term” in the industry. A kind of term every team or company relates to. But what does it actually mean and what value does it bring for the customer?
As a entrepreneur starting new project one defines its goals and features that should exist in the final product. Of course, every project comes with limitations: technological, timing and — maybe most important — budget.
So called “traditional” approach assumes that we are able to define the final product at the beginning and based on that prepare detailed whitepaper of the project scope. Such whitepaper might then be used as a base for a contract with subcontracting agency where every single detail is specified.
To illustrate this, let’s consider a project that contains of some combination of features — for simplicity I’ll just call them “Feature A” and “Feature B”. Assume we want to have some combination of them and put mark it as our “goal”.
Now, the actual realization of the project would be a single line from the start to our goal. The red line in following chart would represent the project life:
But life is not that easy. When limitations comes into scene one has to resign of some of desired features and group them by how important are they for the final product. Of course, there are some tools to help with that (i.e. MoSCoW method) but let’s assume that dreams come true and project has unlimited budget and time for realization.
Even with such brave assumption we cannot be sure that everything will go smoothly. There are numerous reasons for that but let’s focus on two major groups for now.
Human factor
In any undertaking that requires the participation of many people one should take into account misunderstandings. This doesn’t mean that anyone involved has bad intentions but there’s still very high chance that people might realize different set of challenges depending on their expertise and knowledge.
This could lead to unspoken or misunderstood requirements, features, wrong assumptions which further result with miscalculated estimations. For instance engineering team might assume they would use cloud provider to build software infrastructure without knowledge that for legal reasons it’s impossible in specific appliance.
On the other hand customer might expect that the final software would make it possible to export some report in specific format but doesn’t specify it in the specification (if I had a penny everytime I heard “every system like that has it”…)
We could illustrate it on the chart like this:
If you try to draw such chart on piece of paper you might draw the straight line very carefully not to miss your goal but keep in mind that this means your “project” takes longer and, as result costs more.
We need to make peace with that factor while trying to detect and correct any misunderstanding as soon as possible. And depending on its scale we need to be ready to adjust the initial project scope.
We don’t live in void
Another group of factors that we need to be ready for is an effect of a simple fact: our activity is not separated from external world.
In terms of project it means that requirements change with time. Maybe competitors release a new version of their product and we need to add function that became new industry standard, maybe technology we decided to base on became obsolete or unsafe, it might also be the case that some new law enforces some actions and responsibilities (GDPR comes into mind here).
Coming back to our chart this is how we could illustrate it:
As you can see, even if you manage to hit your initial goal exactly on the spot you cannot be sure that this is where you want to be when you actually get there. That’s exactly what happens with software.
The result is that we just need to accept the fact that project changes with time and we need to manage this change somehow.
Iterative approach is one of the answers to that but let me do a quick detour from main topic.
Historical background
The idea of agile software development is nothing new. In fact it evolved from more traditional industries where it’s principles are known as Lean Manufacturing, which modern shape is relatively new because it dates for XX century but the core rules are far older in fact.
Perhaps the most critical person in the history of lean manufacturing and it’s successor, agile, was Sakichi Toyoda — the founder of the Toyota car company. In his company he introduced principles of Kaizen concept to improve the processes with time in small steps.
And this is what we try to utilize and adapt in software life cycle.
Iteration in software development.
Multiple small steps approach means that we stop from time to time to think for a while about the path so far, observe the surrounding and adapt to it. Either by fixing some process flaws, taking advantages of opportunities that arise, empowering the positive aspects of the process so far or adjusting to changing environment.
This could be illustrated in following way on our chart:
As you can see now we drew a line broken into few sections so that we can adjust the direction of next one by looking at the final goal.
Yes, you can say that the line on chart 4 is longer than on any before and that’s obviously true. However keep in mind that in very specific conditions, when all requirements are crystal clear and nothing changes as the time passes by you could aim directly at your goal and hit it with a straight line.
If it happened you would use your review sections just to confirm you were on the right path and move on. In real life project though? It probably won’t ever happen — at least I’ve never heard of any project of this kind. This means that at some point you need to add to your initial straight line another one that will get you from end point to the place you want to be at given time.
On the other hand iterative approach insists that on every end of the period (often called a sprint) you should get set of features that are deliverable so you could end project earlier than you planned if you come to conclusion that it was good enough.
In fact I experienced a project that was estimated for 9–11 months of work for entire team when the estimation was made for initial feature set but ended after just 6 weeks once customer got export result set to csv file and his finance department employees realized they could import it to Microsoft Excel and shape reports in any way they needed.
To be clear: something that might look as bigger project cost when deciding to go with iterative approach is usually an effect of exposing the risk that exists somewhere in there anyway.
Conclusion
Modelling software development is a difficult task. While we can draw timelines based on our experience and project expectations, those times rarely reflect the reality. Adopting the agile methodology allows us to readily embrace and use for our advantage of this unpredictability while delivering safer, cheaper projects.
Thanks
- Andrew Howden and Anton Boritskiy for early reviews
