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.