In late 2016, Aquila Heywood moved from a Waterfall process to an Agile way of working, in particular using the Scrum framework. But why? Probably the easiest way to understand this is to look at how software is built and what the differences are between the more traditional Waterfall process and Scrum.
The Waterfall process depends on the concept of building a fixed amount of software (scope) in a fixed amount of time. This scope can often be large, taking consultants months to put together requirements. When these are eventually completed, an estimate is constructed in order to calculate a fixed time and hence give customers a date of when to expect the software. Even with attempts at re-estimation, this original guess tends to be binding.
The functionality defined by the scope tends to be large and therefore take some time to develop. This means it takes a long time to be tested, and even more time before it is actually given to a customer. There is no feedback from a customer until a release is delivered and often, when trying to satisfy multiply customers at once, the diverse scope can mean that it can take longer than a year to deliver the software.
Not only that, there is often also a 'Well, we might as well...' attitude when functionality reaches a large scale. 'Since we've got the bonnet up, we may as well add this strategic stuff.' This can often lead to building functionality that nobody uses, costing the company both time and money.
Each stage of the process, in terms of requirements, business design and technical design, has bulky documents that are produced only after laborious meetings and signoff procedures.
This way of building software leads to inevitable tensions within teams as they are pressurised to meet unrealistic deadlines and more often than not told to work harder, leading to increased attrition.
So, basically: late delivery, delayed feedback mechanism, functionality that nobody wants and a bad work culture.
Why would anybody want to change that?
So how does an Agile method like Scrum cure the problems mentioned above? For a start, Product Owners focus on value and its delivery. Instead of large unwieldy requirements, functionality is broken down into smaller parts that deliver value even though the larger functionality is not complete. These smaller parts are called user stories, written from the point of view of the person who would use the functionality.
These stories form a prioritised list called a backlog. A Scrum team is formed, normally consisting of a Product Owner, Developers and a Tester. A work increment called a Sprint is set - in our case, two weeks - with the intention of delivering a set number of stories. Before this, however, the stories are 'refined', explained to the team and an abstract estimate of 'points' assigned to them. 'Points' become a measure of the amount of work to which a team thinks it can commit in a Sprint and is also a measure of improvement. This commitment is made in a Sprint Planning session, with the team confident of completing the work due to an understanding of the number of Points they can achieve in this timeframe.
Once work begins, there is a small feedback loop between the Developer creating the functionality and the Tester, who checks it against an agreed 'Definition of Done' - the main quality gate for stories. This definition normally includes the concept of a demonstration to stakeholders in order to establish that the functionality could be delivered to customers, if need be. In fact, we are beginning to involve customers in the early stages, so they are working with the Scrum teams during Sprints.
So, in opposition to Waterfall, smaller chunks of value are delivered more frequently, which is part of a set of early feedback mechanisms to ensure a high level of quality. This also enables a faster reaction to customer or market changes.
But this is not the only improvement.
Part of the Agile manifesto is to value people over processes and tools. This leads to Communities of Learning to encourage staff members to learn new skills or just improve old ones. The old 'blame' culture, caused by tensions created by bad estimations, is gone to be replaced with respect and honesty. After each Sprint is completed, teams have a retrospective looking at the last couple of weeks, thinking about what went well and what didn't. Effectively, they inspect themselves and their process and adapt it, if need be.
Moving to an Agile means potentially faster deliveries, a higher-quality product and happier, smarter staff.
The question isn't 'Why would you move to Agile?', but 'Why wouldn't you?'.