How we avoided falling into trap of mini-waterfall pattern during Agile Sprints - By Kamaldeep Chawla

While working on a new project with my EDM team, the team decided to try the agile sprints for delivery of the project (we are largely waterfall organization but some flexibility at team level to run agile). This decision was driven from failure of phase1 of the project at UAT phase and business rejection to use the new data and replace their existing reports. This increased our business need to validate/test smaller chunks and bless before we could go deeper into development and production, our business was happy to hear such words and excited to try the new approach.

Since the team and business both were new to agile Sprints, and I was a new Scrum master working with this team for first time, I had to be careful to not be an “agile dictator” and instead coach the team so that they can organize themselves more as agile sprints and adhere to agile values rather than falling into trap of recurring waterfall sprints.

We as team worked on a few things throughout sprints.

1. We worked with business to prioritize the reports and we stick to priority throughout the project. Business was allowed to change priorities (remember we are agile) and they leveraged that  right but the team was always transparent in terms of what will it cost to change priority and that helped business take smart decisions.
2. As part of demo of sprint 0 we walked the business through how based on their priority, we broke each report into granular level components and based on business definition of each component, we picked up a few components (based on our velocity) and we tested the data outcome against their reports before we started development. Once developed, we passed each component to business for UAT while team continues to build other components.
3. Once confirmed the components worked with business we migrated and exposed the components to production for business to use in reports. At this point business could request for changes if the components are not providing them the desired functional results.
4. If during our data testing, we found issues with data testing that required fixing the workflows, we had stories created (since we were cross functional team), and the team will move on to next priority.
5. The team will pick up stories based on velocity and priority but based on their delivery cycle, they divided their DoD into 4 stages, to ensure business gets what they want by end of these 4 stages
         a. Each component passes data testing and matches the data outcome of the business reports. This helped business gain the confidence in data.
           b. Components that fail the data testing, needs to be fixed before can be picked up for component.
           c. Development will be followed by UAT testing by business in QA environment.
           d. If UAT passed, Production deployment.
6. By end of sprint 2, our business was very versed with the 4 stages and was ready to help us with whatever  we needed end of each stage.
7. Business was heavily involved into UAT and was more and more satisfied and open to use the new data.
8. The business and team were consistently conversing every sprint on priorities, component definitions, on data issues, business logic, reports and everything else that matters for successful delivery.
9. By month 4, business was able to maintain a 3 month product backlog, which helped team with managing resources needed (being a cross functional team) and project the delivery of complete report.
10. The team was comfortable with the new agile sprints and understood the importance of agile values.
           a. Individuals and interactions over processes and tools.
           b. Working software over comprehensive documentation.
           c. Customer collaboration over contract negotiations.
           d. Responding to change over following a plan.