Organizations are increasingly adopting agile software development methodologies through a combination of bottom-up adoption and top-down change. However, the reality of agile adoption has diverged from the original ideas described in the Agile Manifesto, with many adoptions resembling what Forrester labels water-Scrum-fall.

This happens in part because agile adoption has been practitioner-led, leading teams to focus on domains they can influence, mainly the team itself. Areas outside of their control, such as project planning and release management, continue to follow more-traditional approaches, meaning that Scrum adoption is limited to the development team. That team is presented with a detailed project plan and a set of requirements that it then works through, incrementally delivering software (but not to production) as the production release process runs at a different cadence.

While this model is not inherently bad, application development professionals need to carefully consider and make the right decisions about where the lines fall between water-Scrum and Scrum-fall. Otherwise, they are unlikely to realize agile’s business benefits, such as faster time-to-market, increased business value, and improved flexibility and responsiveness.

In recent research, Forrester offers the following advice to help organizations manage the water-Scrum and Scrum-fall boundaries to increase agility:

Water defines the upfront work
Governance rules require many organizations to define requirements and plans before starting work. In some companies, these plans form the basis of a contract between the business and IT that defines project direction, timeline and budget.

One vice president of development framed this in conversations with Forrester, saying: “We have to spend time upfront with the business building the requirements and plans to ensure that we know what they want, and they know how long it is going to take and how much it is going to cost. The problems start when the business does not know what they want or the architecture is new to us.”

Given these realities, it’s imperative that application development and delivery professionals 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. How many times have end users only understood the problem after they have seen a solution that was not quite right? Feedback late in the cycle tends to be less welcome, as the team has to balance the feedback with the significant cost of changing the application.

Scrum comes in the middle of the process
Scrum in particular has become popular; many teams are adopting its basic principles, such as daily meetings, the roles of product owner and Scrum master, and Scrum planning and retrospectives. Scrum’s success can be associated with many things, but in particular a strong focus on teams and team dynamics has attracted many people who feel that traditional approaches lack a real people focus.

Developers like delivering software, so the practice of frequently releasing software makes intuitive sense. However, teams should guard against embracing Scrum principles but missing some of their most important characteristics.

For example, applying Scrum to only developers is a recipe for disaster. A proper Scrum team must comprise all the people necessary to deliver working software. Typically, this means developers, testers and business analysts working toward a common goal.

The reality of water-Scrum-fall is that change will continue. The water stage defines the overall direction of the project, but the team will have many insights during the project that challenge initial ideas. By supporting change while at the same time ensuring that the team understands the impact of that change, the team will not only build better applications, but will also learn more about its process for future implementations.

One way to drive the point home is to ask the project’s management a simple question: “Do you want the technology to help us adapt quickly to threats and opportunities?” If the answer is yes, then tune the approach to favor discovery and action over planning and execution.

Fall: Limits to release frequency
Frequent software releases to the customer enable rapid feedback and ensure that valuable software is being used as early as possible. However, most organizations do not have the architecture required to support dynamic, flexible releases; instead, they do infrequent releases backed by heavy processes and governance. Adopting agile processes will not itself change the firm’s underlying enterprise architecture; therefore, teams have to make the best of the situation.

Application development professionals should challenge the status quo of infrequent releases and push to better integrate release processes into the development team. Incrementally add to sprints such release process activities as preproduction testing, data migration, and security and performance testing. 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.

Dave West is a vice president and research director at Forrester Research, serving application development and delivery professionals.