Agile is an umbrella term for a number of different frameworks that guide us through projects in a structured way. A popular one is Scrum – a basic process that helps us introduce controls, quality and continuous improvement into what and how we deliver.
Scrum is unlike traditional approaches to project management, which are controlled by precise methodologies spelling out a pre-defined project path. Instead, it gives us a mindset, a structure and some tools to help address the complexities of large technical projects. Another major benefit of Scrum is that it allows us to scale our approach to suit the size of the project.
The Scrum Roles: Pigs and Chickens
Scrum defines three key roles:
- Scrum Master – responsible for helping the team implement Scrum, providing coaching to the Product Owner and team, and helping team members to resolve impediments
- Product Owner – an individual who fully understands the goals and objectives of the business and is able to take responsibility for steering the project towards these. They should be senior enough in the organisation to make key decisions about the project — to take ownership.
- The Team – the designers, developers, and others responsible for the delivery of the requirements
The people filling these three roles are termed pigs. Anyone with input from outside these roles is termed a chicken. A pig is someone who is fully involved in and committed to the project, whereas a chicken is someone with an outside interest.
People outside the project will always have an interest in it, and continue to be important to the delivery. They could include stakeholders, individuals with specific expertise who provide assurance to the project, and also the users.
What’s important is that the Product Owner and ScrumMaster protect the team, allowing them to focus on the delivery by shielding them from the noise and distraction. The Product Owner acts as a filter, taking input and making decisions on what, and what not, to include in the project — passing on a focused and priorities vision for the project to the team.
Product Backlog: the Starting Point
The project begins with the creation of a ‘product backlog’ in which all requirements for the product are kept.
The requirements for the product are written as user stories, focusing on the user’s position (the ‘who’), the feature they want (the ‘what’) and identifying the value that will be delivered (the ‘why’). As a general rule, if the user story isn’t delivering value — if we can’t truly describe the why — then we don’t waste time and money delivering it. We’ll look at how to write user stories in part 3 of this Introduction to Agile when we discuss how to focus on value in the project.
Starting the Work Cycle: Sprint Planning
At the heart of the framework is a cycle through which we iterate every two to four weeks. These iterations referred to as sprints, begin with a sprint-planning session.
The sprint-planning session identifies the next top priority for the project to give the objectives for the sprint and then takes from the product backlog the user stories required to achieve the objectives. The team estimates each of the stories in turn and continues to accept stories into the sprint until they consider the sprint to be full. Once the sprint backlog is full the sprint begins in earnest.
Traditionally, planning is all done before the project starts — but this is when the least is known. Agile breaks this big single planning phase into smaller planning steps before each iteration. This means that planning happens as close to the work being done as possible so that you’re planning with the maximum amount of knowledge.
Many decisions will be made during a project and these decisions can affect how we approach the later stages. By planning as late as possible we’re able to take the knowledge learned through the project and apply it to the decisions we make later in the project. This helps avoid the situation where we have to engineer out the functionality that was decided on before we were equipped with the information to make the decision. This creates a work cycle of Plan-Do-Review repeated many times, rather than just carried out one time each as with traditional waterfall project management.
Daily Standup Meeting: Staying on Track
Daily checkpoint meetings, called scrums or daily standups, are held each morning. They involve the team, the Product Owner and the Scrum Master. The meeting is a chance for the Product Owner to be kept up to date on progress, to answer questions the team may have, and be part of unblocking any issues the team have encountered. It also means the team make commitments to each other about work to be done, and then everyone is up to date.
The team takes turns explaining to the rest of the group what they achieved yesterday and what they have planned for today and takes the opportunity to highlight any blockers affecting their progress.
The meetings are limited to 15 minutes, to reduce the impact on the day and to maximise the benefits of the catch-up. Any issues raised are generally discussed between individuals after the meeting to free up the rest of the team.
Sprint Review & Improving Performance
At the end of the iteration, there is a sprint review. The team demonstrates functionality developed during the sprint to the Product Owner and anyone with an interest in the project (users, sponsors etc). This is an opportunity to gather feedback from a wide audience. The Product Owner can choose to add new user stories or edit existing ones to take this feedback into account, or to react to new ideas that the demo has sparked. This kind of continuous improvement of the project used to get bogged down in a change request process, but agile provides a framework for handling it as the norm, ensuring that the maximum value is delivered.
The end of the sprint also gives the team the opportunity to review how well they performed during the sprint. They hold a retrospective meeting to identify the elements of the delivery that were good and those that need improvement. This kind of checkpoint helps us to constantly improve the performance of the team and the quality of the delivery throughout the life of the project.
Once we’re finished with the reviews and the retrospectives, we return to sprint planning and the cycle begins again.
Scrum in Summary: Quality and Value
Projects need tight controls and Scrum provides these in a simple way. It’s a very good, lightweight method of achieving a lot with relatively little overhead.
The success of a project generally depends on delivering high value with high quality. By creating regular checkpoints to review and test what’s being developed, we continually shape the product into something that truly works for users.
If the end product meets the needs of the users, then we’ve delivered a product that adds value to the organisation too.