Waterfall Into Agile
There are some people who still think that the Waterfall approach is the recommended methodology to run a project given certain facts:
- Requirements are very well defined and static.
- The business model is in operation.
- This is just a legacy upgrade. There is no new functionality.
They feel that when you need extremely reliable software, and also have very accurate requirements, Waterfall is the way to go.
In reality, this represents a very small fraction of software projects. Why? Because the only thing certain in business is change. Especially with today’s extreme high pace of technology and innovation. Combine that with de-regulation in many sectors, and you will struggle to find a project that fits the characteristics of a good Waterfall project.
However, if you are re-deploying an existing web application or enterprise application, with the exact same functionality; AND, have all system documention. Then, you can probably get by with Waterfall.
This is the absolute exception and not the rule.
The truth is that today’s projects mostly fit into an Agile or an Agile variant methodology.
When considering Agile versus Waterfall, one can ponder several questions:
- How well defined are my requirements?
- What is the opportunity cost of deploying an application that doesn’t match requirements?
- What is the adoption elasticity of the users?
The last question means if you deploy a system that doesn’t meet requirements, will it still be adopted by the users, and thus missing requirements will get resolved in later releases? Release what you have now and refine it later.
For example, can you live with deploying a poorly optimized shopping cart today, but resolve missing functions like “reorders”, “tracking” or “wishlists” later?
In almost every project, you need to make compromises to make it to the finish line. Agile provides the flexibilty to throw bags off the train, to make it to the end. Using Waterfall, releases are very big. Instead of throwing bags of the train, you our cutting entire boxcars off the chain.
Is there a risk for missing major pieces of functionality? Well if the answer is yes, Agile provides the ability to break down those giant releases.
But it is rare to know all the details of what your software should do when you are at the beginning of a brand new software application project.
Agile also provides an easier way to manage technical debt. If you need to deploy something today that works, but you know it will need to be re-factored. You can survive today’s release and plan to resolve the issues in the near future. Waterfall makes this approach almost insurmountable. The result is hit or miss. If you miss it, it might take years to eventually hit it.
The concept with Agile is to follow a standard project management process, but do it in smaller increments. What do you mean by smaller increments? Stories which span longer than the length of a sprint, which is normally two weeks, need to get broken down into smaller stories. Or, if you want to plan way ahead, you can build an Epic in the backlog which spans multiple sprints. However, the idea is to still release and demo the code very two weeks. This gets the resulting software product out in front of stakeholders while it is being built. This provides opportunity for evaluation and revision, which can either add to the backlog or the next sprint.
This keeps requirements fresh and allows your team to continuously pump-out working software code.
Swimming over the waterfall and into an Agile methodology is not a turn-key change. This requires adoption of the entire team, which includes both the client and the outsourcing vendor. In fact, you will also need executive sponsorship. That’s right! Because before you even sign a statement of work, both sides need to agree on your overall approach.
It is not a great idea to just change everything all at once. Unless you are a brand new team and are working on a brand new project, change should also be implemented in increments. This allows the team to evaluate changes in iterations. Not every project is the same, and not every team works the same. It is actually a great idea to discuss Agile concepts during your bi-weekly retrospectives. What worked? What didn’t work? What puzzlers did you encounter?
For example, let’s say that we are trying 2 week sprints, but all of our stories require 3 weeks or more. Puzzler – how can we break these stories into smaller stories?
However, the overall concept is the same. We implement changes from Waterfall to Agile in increments, just like we code our software.