Anyone who has worked on waterfall projects knows the challenges: The lack of communication between the business users and the developers; the predetermined (and immovable) requirements; the quality issues that are not evident until you are too close to the release date to safely address them; and the frustration of having to wait months (and sometimes years) before your efforts result in a live working solution.
When you make the move from waterfall to Agile projects, you have two choices: You can choose to either block out your waterfall experience altogether (like any traumatic event!) or you can choose to leverage your experience to make yourself an even more effective Agile team member. Here are three ways that you can use your waterfall experience to your advantage:
- Become a better team communicator
- Better align requirements with emerging business and technical information
- Relentlessly pursue high quality outputs
The first opportunity for leveraging your waterfall experience is to use what you learned from the disconnected team structure of waterfall projects to become a better team communicator. You know firsthand how challenging it is to try to interpret written specifications without the benefit of getting clarification from the business users. When you work on an Agile project, that frustration can make you more likely to value your time with the Product Owner, to ask targeted questions, to listen closely to their responses, and to prepare follow up questions for the next iterative review. Equally, you know how difficult (and risky) it is for business analysts, system architects, developers and testers to produce a cohesive solution when they are working in isolation of each other. That knowledge can make you more likely to get actively involved with the cross-disciplinary team in the planning and estimation sessions, the daily stand ups, and the sprint reviews; to use these as opportunities to clarify requirements and address your concerns; and to appreciate the breadth of input that the team members provide.
The second opportunity is to leverage the flexibility that is provided to Agile teams to align requirements with the business and technical information that emerges as the project progresses. In your waterfall projects, if the business needs changed over time, you were often left with two options: Update the signed off specification and wait for another approval cycle to continue your work, or continue developing a solution that you knew was incorrect in order to meet the requirements identified in the original specification. In your Agile work, you now have the ability to work with the business users to actively incorporate these changes, to grow and adapt the solution to align with the most current information available. Not only does that flexibility allow you to produce a solution that meets the ongoing business needs of the organization, it gives you the satisfaction of knowing that you are delivering genuine business value instead of obsolete functionality. Similarly, in Agile projects, if you hit a technical constraint in your development work, you no longer need to find workarounds or “fake out the system” to achieve the originally defined objective. You can bring your concerns to the team to brainstorm a more effective solution. You can go back to the Product Owner to discuss viable business alternatives. You can take action to address the technical constraint before it becomes an insurmountable hurdle. Waterfall approaches do not give you the flexibility to change course in the middle of a project to achieve the intended business objective. Agile methods do.
The third opportunity is to relentlessly pursue high quality outputs throughout the project instead of waiting for the “Test Phase” to find critical issues. You know from your waterfall experience how difficult it can be to address issues that are found at the end of the delivery cycle. That is why Agile methods encourage you to take active measures to ensure that the team is protected from firefighting and failed solutions. Implement upfront quality control measures like Test Driven Development, automated testing harnesses and continuous integration. Use pairing to actively confirm code quality. Be open to refactoring the solution as new information emerges to establish the most efficient and extensible system design. Equally, in your waterfall experience, you knew the frustration of finding out that the issue that you have spent the past two days working on could have been resolved in half an hour if you had spoken with another member of your team. Use that pain to your advantage. If you have an issue, pair with another team member as quickly as possible. Communicate the issue. Do not wait for a formal meeting to resolve it. Agile methods also encourage you to focus on continuous improvement to protect the team from repeating the same mistakes. Look for more effective communication channels. Reduce waiting times, task switching and other overheads. Embrace retrospectives.
Waterfall projects are notorious for running short on time and then fast tracking people to their next project without stopping to consider why the work is consistently misaligned to business requirements, over budget and behind schedule. One of the most valuable advantages that you can bring to an Agile project is your motivation to make the team more effective and your determination to help them avoid falling back into the traps of waterfall approaches.
