Get certified - Transform your world of work today


How We Avoided the Mini-Waterfall Trap

8 September 2016

While working on a new project, my enterprise data management team decided to try Agile sprints for delivery. (We are largely a Waterfall organization, but we have some flexibility at the team level to run Agile). This decision was driven by failure in phase 1 of the project during the user acceptance testing (UAT) phase, and also by a business rejection of the new data to use instead of their existing reports. This increased our business need to validate and test smaller chunks and "bless" them before we could go deeper into development and production. Our business was happy to hear about the plan and became excited to try the new approach.

The team and business were new to Agile sprints, and I was a new ScrumMaster working with this team for the first time. These circumstances meant that I had to be careful to not be an "Agile dictator" and instead coach the team so that they could organize themselves in Agile sprints and adhere to the Agile values, rather than falling into the trap of running recurring Waterfall sprints.

As a team, we worked on a few things throughout the sprints.
  • We worked with business to prioritize the reports, and we stuck to the priority throughout the project. Business was allowed to change priorities (remember, we are Agile), and they leveraged that. At the same time, the team was always transparent in terms of what it was going to cost to change those priorities, which helped business make smart decisions.
  • As part of the demo for a Sprint Zero, we walked business through how, based on their priorities, we broke each report into granular components. Depending on the 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 the team continued to build other components.
  • After confirming with business that the components worked, we migrated and exposed the components to production for business to use in reports. At this point, business could request changes if the components did not provide the desired functional results.
  • If, during our data testing, we found issues that required fixing the work flows, we had another team create stories (because we were a cross-functional team), and our team would move on to the next priority.
  • The team picked up stories based on velocity and priority, but, based on their delivery cycle, they divided their Definition of Done into four stages to ensure that business got what they wanted by the end of the fourth stage.
    1. Each component passed data testing and matched the data outcome of the business reports. This helped business feel confident about the integrity of the data.
    2. Components that failed the data testing had to be fixed before they could be picked up for a component.
    3. Development was followed by the business UAT testing in the quality assurance environment.
    4. If the UAT passed, production was deployed.
  • By the end of Sprint 2, our business was well versed with the four stages and was ready to help us with whatever we needed at the end of each stage.
  • Business was heavily involved in UAT and was increasingly satisfied and open to using the new data.
  • Every sprint, the business and team were continually discussing priorities, component definitions, data issues, business logic, reports, and everything else that mattered for a successful delivery.
  • By the fourth month, business was able to maintain a three-month product backlog, which helped the team manage the resources needed and project the delivery of a complete report.
  • The team was comfortable with the new Agile sprints and understood the importance of upholding Agile values, such as:
    1. Individuals and interactions over processes and tools
    2. Working software over comprehensive documentation
    3. Customer collaboration over contract negotiations
    4. Responding to change over following a plan
In the end, we had a happy customer, and we were a well-trained team that was successful at Agile.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 3.3 (3 ratings)


Be the first to add a comment...

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up