Including these tests within each sprint not only gathers more rapid feedback for the team but
also encourages the team to automate these processes, increasing the overall fidelity of their
results while also automating governance. Consistent automation of the complete promotion
model also allows release managers to better understand software status.
·
Building shared objectives driven by the business.
Traditional approaches measure release teams
based not on the amount they change but on minimizing the impact of that change. They measure
development teams on the amount they deliver and how well they stay on schedule. The tension
between these two conflicting measures incents different behaviors, increasing friction between
the two groups. Giving everyone the same business-oriented goals helps remove this friction,
allowing the entire team to balance quality and functionality in the context of a change.
© 2011, Forrester Research, Inc. Reproduction Prohibited
July 26, 2011
Water-Scrum-Fall Is The Reality Of Agile For Most Organizations Today
For Application Development & Delivery Professionals
13
R E C O M M E N D A T I O N S
UNDERSTAND THE LIMITATIONS OF WATER-SCRUM-FALL, AND PUSH THE
BOUNDARIES
Unless you are a software-as-a-service (SaaS) vendor, it is highly likely that the Agile process
you are following resembles water-Scrum-fall. Most firms do requirements and planning before
forming a Scrum team. Once management is happy with the plans, development follows a
backlog-driven Scrum model. The development team delivers software frequently, but the
production release process runs at a different cadence, picking up the software at the intervals
the release plan defines. This model is not inherently bad, and it does at least afford some level
of agility at the development-team level, but if application development professionals want to
maximize the value of agility, they should:
·
Push back on the water-Scrum side of the model.
Spending too much time upfront will not
increase the quality of the release; on the contrary, it is wasteful. Documents are a poor proxy
for working software, and thus any documents created should be just enough to introduce the
problem area and allow high-level planning and development work to commence.
9
·
Ensure they have built a truly Agile team for the middle of the process.
Just calling a
team Agile is not enough; Agile teams should include all the people necessary to deliver
working software, coupled with clear measures that allow the team to focus on delivering
the right software that maximizes business value.
·
Increase the frequency of the releases to production.
Application development
professionals should challenge the status quo of infrequent releases and push to better
integrate release processes into the development team.
