Agile project management has its roots in the Lean manufacturing approach pioneered by Toyota during the latter half of the twentieth century. The software development community fully embraced the Lean ethos, adapting its principles to form the foundations of the incremental and iterative development methodologies that make up Agile. A reaction against the traditional, sequential approach to project management, this new approach was later ratified in The Agile Manifesto in 2001. Scrum, a framework for developing and sustaining complex products, is perhaps its most popular incarnation.
So how to do you go about “going Agile”? How does the Agile process work? In this post, we present an Agile primer for the as yet uninitiated, taking you through the basics of Agile and how to apply them in practice in your organisation.
Scrum is a process framework which has been used to manage complex product development since the 1990s. The overall aim of Scrum is to make clear the relative efficiency of your product management and development practices so that you’re able to improve them.
The Scrum framework, in short, consists of Scrum Teams and their associated Roles, Events, Artefacts and Rules. Each component within the framework serves a specific purpose and is an intrinsic part of Scrum practise – and its success. The individual elements are bound together by Scrum Rules which govern the relationships and interactions between them.
Scrum methodologies are underpinned by three theoretical pillars:
Scrum holds that the significant parts of the process must always be visible to those responsible for the outcome. Transparency requires that those aspects are defined by a common standard, so that observers are able to share a common understanding of what it is they’re looking at and therefore make progress.
Scrum users must frequently inspect Scrum Artefacts in order to determine how the project is progressing towards the Sprint goal, so that they can detect undesirable variances – and detect them early. However, these inspections should not become so frequent that they themselves become an obstacle to progress. Inspections are most fruitful when they’re diligently performed by skilled inspectors at the point of work.
The ability to adapt responsively is one of the real boons of Agile. If an inspector determines that one or more aspects of the process deviate beyond acceptable limits, and they anticipate that the resulting product will therefore not fit the bill, the process or the material being processed must be adjusted.
The Scrum team consists of a Product Owner, the Development Team and a Scrum Master. The Product Owner is responsible for maximising the value of the product and enabling the work of the Development Team. In turn, the Development Team are responsible for delivering a potentially releasable Increment of “Done” (meaning usable, potentially releasable and therefore for the purposes of Scrum, complete) product at the end of each Sprint. The Scrum Master is responsible for ensuring that Scrum is understood and its rules, theory and practices enacted.
Prescribed events are used in Scrum to create regularity and to minimise the need or unnecessary meetings. All events are time-boxed and each has a maximum duration. Once a Sprint begins, its duration is fixed and it cannot be shortened or lengthened. The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent and no wastage is incurred. Each event is an opportunity to inspect or adapt an element of the project and each event specifically designed to enable critical transparency and inspection.
The heart of Scrum is a Sprint, which houses all of the Scrum events. A Sprint is a time-box of one month or less during which a “Done” product Increment is created. The best Sprints have a consistent duration throughout a development effort and a new Sprint starts immediately after the conclusion of the previous one. Sprints consist of Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective. Like projects, Sprints are used to accomplish something. In fact, each Sprint may be envisioned as a project with no more than a one-month horizon. Each Sprint comprises a definition of what is to be built, a design and a flexible plan that will guide the building of the work, and the resultant product.
The time-boxing of Sprints is a key part of their makeup. When a Sprint’s horizon is too long the definition of what is being built may change, complexity may arise, and risk may increase. Sprints enable predictability by ensuring that inspection and adaptation of progress toward a Sprint Goal takes place at least every calendar month. And, crucially, Sprints also limit risk to one calendar month’s worth of cost.
The work to be performed in the Sprint is planned at the Sprint Planning meeting. This plan is created by the collaborative effort of the entire Scrum Team. Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint – for shorter Sprints it’s generally shorter. The Scrum Master presides over the event, ensuring that it runs to plan, to time and that attendees understand its purpose.
The aim of Sprint Planning is to find answers to the following questions:
The Sprint Goal is the objective for the Sprint and comprises one coherent function which can be delivered via the implementation of the Product Backlog. The Sprint Goal is set during the Sprint Planning meeting. It provides guidance for the Development Team as to why it is building the Increment and gives them some flexibility regarding the functionality implemented within the Sprint.
Daily Scrums improve communication, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision making, and improve the Development Team’s overall knowledge of the project. These meetings take the form of a 15-minute time-boxed event designed to enable the Development Team to synchronise their activities and to create a plan for the next 24 hours. Scrum members inspect the work achieved since the last Daily Scrum and forecast the work that could be done before the next one. To keep things simple, the Daily Scrum is held at the same time and in the same place every day.
During the meeting, the Development Team members provide answers to the following questions:
A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if necessary. During the Sprint Review, the Scrum Team and stakeholders collaborate to discuss what was done during the Sprint. Based upon this Review, together with any changes made to the Product Backlog during the Sprint, together attendees determine the next steps for optimising value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration. For one-month Sprints, this meeting will be allocated a four-hour time-box. For shorter Sprints, the event is usually shorter. The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint.
The Sprint Retrospective is an opportunity for the Scrum Team to inspect what is happened during the Sprint and to create a plan of improvements for the next one. It occurs after the Sprint Review and prior to the next Sprint Planning meeting. The Retrospective takes the form of a three-hour time-boxed meeting for one-month Sprints, with shorter meetings for shorter Sprints.
The purpose of the Sprint Retrospective is to:
Scrum Artefacts represent work or value and are intended to provide transparency and opportunities for inspection and adaptation. Artefacts defined by Scrum are specifically designed to maximise the transparency of key information so that everybody involved shares the same understanding.
The Product Backlog is an ordered comprehensive list of everything that might be needed for the product and is the single source of requirements for any changes to be made to it. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering. Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be “Done” within the Sprint time-box. A Product Backlog is never complete, evolving as the product and the environment in which it will be used evolves. It’s dynamic, and constantly changes to ensure that the product is appropriate, competitive and useful.
The Sprint Backlog is a sub-set of items from the Product Backlog that have been selected to be achieved during the individual Sprint, supplemented by a plan for delivering the product Increment and realising the Sprint Goal. The Development Team forecasts what functionality will be achieved in the next Increment and the work needed to deliver that functionality.
The benefit of the Sprint Backlog is that it makes visible all of the work that the Development Team identifies as necessary to meet the Sprint Goal. It contains sufficient detail that changes in process can be understood in the Daily Scrum.
As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated.
The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint in order to meet the Goal. Only the Development Team have the privilege of changing the Sprint Backlog during a Sprint.
The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the Increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in usable condition and meet the Scrum Team’s definition of “Done” – regardless of whether the Product Owner decides to actually release it.
When a Product Backlog item or an Increment is described as “Done”, it’s crucial that everyone understands what “Done” means. Although this varies significantly from team to team, members must share an understanding of what it means for work to be complete, to ensure transparency. This definition of “Done” is used to assess when work is complete on the product Increment.
Get in touch with Michelle Tackie to find out more!