Specifications VS Value
This Is Your Project On Waterfall#
On a project that is using the Waterfall software lifecycle, all of the requirements need to be understood upfront. This is easier for a business to understand. They know exactly what they are getting and when. The project’s managers can easily break down timelines and build reports. The engineers know exactly what needs to be built and can plan out how shared components can be optimized to help the build. The project’s specifications are known and agreed upon, and the conclusion of the project is well-defined. What could possibly be the issue with this approach?
The issue is that when this upfront plan is made, everyone has the least amount of information that they will have in the entire duration of the project. Every single day that the assigned team works on the project, more information will be learned, leading to better decisions; the team will discover things that they didn’t even know that they needed to know. This additional information is going to change the plan. It’s going to change what the business deems as the most important features to build. It will likely inform the business that features they thought they needed are no longer needed. However, in Waterfall the plan has already been determined. The specifications agreed upon early in the project must be contractually fulfilled. The alternative would be to stop the current work and go back to planning once the team discovers that they are not building the right things. This is an option that no business will accept. “Stop work” is a laughable suggestion to a client for good reason. The business is trying to get a product to market. Opportunities have expirations and cannot be missed. So the project marches forward - the team being unable to react to what they have learned.
Waterfall isn’t kind on deadlines either. All of the estimates about effort and time are made at the beginning of the project. The estimates are the least accurate at this point. Despite honest intentions and best efforts, the estimates will be wrong. When the team begins to fall behind the estimated schedule, is that the fault of the team members? Is it even fair to say that they fell behind when the estimates were so uninformed? Clearly, it is not. However, the team committed to meet these specifications with this timeline. In order to accomplish this, the project requires heroic behavior from the team. This comes in the form of pulling long hours, working weekends, and even breaking some company policies in order find additional efficiencies.
What are we left with? A burnt-out team working vigorously to deliver something that the client no longer needs on a date that is later then they needed it. But we met the specifications! So why doesn’t that feel like a victory? Is it possible that specifications are the wrong measure of success?
This Is Your Project On Agile#
On a project that is using the Agile software lifecycle, the project team embraces the undeniable fact that they do not have all of the information yet. Not knowing is the plan! The team’s goal is not to be omniscient in their knowledge and make perfect decisions but instead to focus on building features that are easy to change. The goal for the team is to optimize the learning cycle and then be able to quickly incorporate what they have learned back into the product. The team doesn’t know all relevent information at any given point in time. Therefore, the team builds the part of the project that is determined to be the most valuable feature - at that time.
The focus on value means that the business is continuously getting what they perceive as most important at every moment of the project. Both the team and the business are able to take what has been learned in the development process and make another informed decision. These decisions are also not permanent. The team reincorporates their newest revelations back into the project and adjust the next direction frequently. This allows for the team and the business to experiment at low risk.
Deadlines become less important. If a team is constantly delivering the most valuable features, then the project is always useful. This is because the business consistently benefits from getting the current iteration of the product in front of users. This iterative addition of value to user and business means that a missed deadline is less impactful. Users are delayed features instead of entire products.
Conclusion#
Waterfall’s focus on specifications is ideal for contracts. However, it places the value added to a company and its customers as a secondary objective. The customers don’t get what they need, the business doesn’t get as much value in the product, and the team that builds it becomes jaded and burnt-out. Agile’s focus on value more accurately matches the reality of software engineering on a cross-functional team.