- agile is a set of values embracing flexibility
- iterative is a feedback loop in any process
- lean prones actions only when confirmed as needed
- waterfall is a step by step approach to a “fixed goal”
We hear of many start ups and SMEs using these three terms: agile, iterative and lean. But more often than not they are perhaps just capitalising on the latest buzz word instead of truly embracing these practices and incorporating them into their software lifecycle or product development.
So, what do these terms actually mean and how can they really benefit today’s businesses? Let’s take it step by step.
Waterfall development model
First we must understand where software has come from.
In the early days of software development, we looked at technologies like a product. A new drug, car, or a shoe, has to be thoroughly designed, reviewed and tested before the first unit comes out of the production line. This is what the software industry called the waterfall model, a sequential approach to producing an outcome.
The waterfall method is great because it is rigid, it’s disciplined and forces a lot of thinking to happen early. It ensures each phase of the software development (thinking, designing, building, testing and maintenance) has a proper focus which, by nature, directly yields to more thorough documentation for instance. Another argument of the waterfall model is the old “measure twice, cut once” saying, which many not apply well to software since one can “cut” the same code many times within a short time frame. This makes the waterfall method however well suited for a very large project, or established software.
The unmodified “waterfall model”
Progress flows from the top to the bottom, like a cascading waterfall. wikipedia
The waterfall method is not so great because it is rigid, it’s disciplined and forces a lot of effort to be invested early before any product or market validation has happened. In other words a project relies on a few brains to build something which will work and sell. There is no “feedback loop” built in, so any learnings and tweaking to the product will only happen in the distant future, once the designed and documented product has been built. The flexibility of technologies today and the speed at which things can now be prototyped make the waterfall model less suited for smaller projects, with a smaller team, a smaller budget and a need for rapid improvements, learnings and changes.
Because waterfall takes forever to accept change
While a pure waterfall model delivers all value (the product) at the end, breaking down the delivery process into smaller chunks will inherently deliver smaller amount of value, quicker and more regularly until the product is completed. This is the iterative approach in a nutshell. It takes one project, breaks it into smaller blocks, delivers and provides feedback onto the greater project, many times until all blocks are completed and so is the project.
A simplified version of a typical iteration cycle in agile project management. wikipedia
The iterative method is great because it somewhat breaks some of the waterfall rigidity, just enough to minimise the initially high overhead and introduce a feedback loop in the process. Also, the methodology followed for the iterations, each loop, can be adapted to many environments, resulting in a “heavy” waterfall iterative process, or a “lean” agile iterative process.
The iterative method is not so great because it introduces a degree of variability to a project making the overall planning more difficult. It also requires more ongoing product management (versus more upfront product management) since each iteration requires a degree of product definition (for the selected blocks).
Most valuable product first
A number of years ago, to look at cost reduction, the manufacturing industry embraced Just in time (JIT) inventory management. JIT essentially allowed manufactures to produce a product (or a batch of them!) as they were needed. These products were then delivered directly to the customer or retailer, bypassing the need for warehousing.
The software industry went through the same change. As developed software grew, the waterfall method became costly and was not inline with higher speed-to-market expectations.
In manufacturing, a lean approach suggests “why make a product which is not sold”. In software, a lean approach suggests “why build software which may never serve a purpose”.
Lean software development is great because it eliminates uncertainty by providing tools continuously to test a vision. It also promotes the “build-measure-learn” feedback loop which very quickly improves a product and avoids features which are not generating value to the customer. Lean development eliminates waste due to bad early decisions.
On a financial angle, it allows businesses to spend when spending is essential – just like people buy people movers when they have a family, not years ahead when they are only thinking of having one..
Lean software development is not so great because it forces the entire supply chain to change constantly. Luckily that’s easily alleviated in software, but not so much in manufacturing. It also introduces a level of “unknown” which is not easy to handle for some within a product team. Everyone likes planning!
Why we do things, not how we do things
Agile is completely different from waterfall, iterative and lean models, in the way that it is a set of values, not practices. It is best described by the Agile manifesto, a set of principles with aim to enhance the relationship between human beings and software by valuing;
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Visibility, adaptability with business value and risk of agile vs traditional methodologies. Versionone
Agile methodologies are great because they have, since the late 90s, made the software industry and technical project management practices evolve at (more or less) the same pace as technologies themselves. They now allow for a rather large project to be built leveraging the speed and efficiencies software is capable of, contrary to traditional engineering and project management which is a very establish skill and industry.
Agile methodologies are not so great because it focuses heavily on technologies and takes human variability second. This should be the other way around. Also agile prones flexibility (same as with technologies) but tends to forget the business-driven world we live in where a fixed scheduled is sometimes important.
In the end..
Agile values and a lean model is not error free. There are often struggles when attempting to scale this process. However they are also well positioned to quickly learn from errors, handle uncertainties, and develop value. We at EmpireOne believe that these are well adapted to the majority (but not all) of software and projects of a reasonable size. If you want to read how we apply this to our day-to-day projects, check out how is EmpireOne Group “lean & green”
There are plenty of blogs and sites around talking about the topics from many angles. Ask Google!