Enfuse Guide: Scrum, an Agile approach
What is it?
Scrum is a specific process framework for Agile. It is the most popular of many Agile frameworks which have been created over the years. Due to its popularity, a number of features from Scrum are often confused with being core features of Agile when in fact they are only specific to Scrum.
Scrum was created for software development, but many businesses are adopting it for non-software change.
Scrum Sprints
Scrum defines specific practices which need to be followed. Core to this is undertaking work in Sprints.
Each sprint is in effect an iteration involving design, build, test and potentially release. The goal of each sprint should be to produce 'shippable code', although it is not compulsory to actually ship (i.e. release) the code into the live environment. The point is that you can if you wish.
Each Sprint will have an agreed Sprint Goal. To meet the sprint's goal, the work required for this is detailed in the Sprint Backlog.
Backlogs
Backlogs are basically lists of work to be done. There are two backlogs to note:
Product Backlog: A prioritised list of the work required to create and maintain the product. This list is managed by the Product Owner
Sprint Backlog: The list of the development work needed to achieve the Sprint’s goal, typically a forecast of functionality and the work needed to deliver that functionality. Managed by the Development Team
The work noted in the backlogs is typically captured in the form of User Stories. A User Story describes a software feature from the end-user's perspective, noting the type of user, what they want and why. In layman terms, user stories are the requirements.
Scrum Ceremonies
There are specific 'ceremonies' (aka meetings) involved in each sprint. These are:
Sprint Planning: Time-boxed event of 8 hours or less, to kick off and plan a Sprint. The Scrum Team review the Product Backlog (i.e. list of work to do) and design this into the Spring Backlog (i.e. work to be done in this sprint)
Daily Scrum: Daily time-boxed event of 15 minutes or less, for the Development Team to get together and ratify/update their plan for the next day of work. These are frequently referred to as stand-ups, although that isn't strictly speaking the Scrum terminology
Sprint Review: Time-boxed event of 4 hours or less, held at the end of the Sprint to conclude the development work. The Scrum Team and stakeholders inspect the output from the Sprint, assessing overall progress and gathering feedback. The feedback typically is caputred as User Stories (basically requirements) for further improvement of the software being produced.
Sprint Retrospective: Time-boxed event of 3 hours, or less, held at the end of a Sprint to review how well the Sprint went. This isn't about the actual output, as that is what the Sprint Review is for. The Retrospective is for the Sprint team to look at how their working practices and interactions can further improve for better results. The output is an agreed set of actions to further improve performance in the next Sprint.
Scrum Roles
The Product Owner is responsible for defining the Product vision i.e. vision for what end product which the team are developing. The Product Owner is responsible for the ensuring the Product Backlog correctly describes and priorities what is wanted for the product.
The role of the Sprint Team is to develop the product. Having been told what the priorities are, they agree sprint by sprint on how to develop these, feedback the Product Owner how much effort is required so that they can agree for each Sprint how much is realistic to produce. To be clear, the Product Owner is responsible for defining what the Product needs to be (and do), but it is the Team's responsibility to develop and produce the product.
To help the team, a Scrum Master is appointed. Their role is to coach the team and help remove impediments to the team doing their role. For instance, a stakeholder constantly coming down and distracting the team with questions could be dealt with by the Scrum master. The Scrum Master is not a Project Manager - their role is very much that of a servant leader. They help and support, but do not tell the team what to do (although they may call out what they see as damaging behaviours for the team to address).
In Summary
Scrum is well documented and very prescriptive, hence is a great starting point for anyone wishing to start being Agile. The above is a very brief introduction to Scrum and we would recommend undertaking Scrum training before jumping into it. We certainly offer Agile and Scrum training, but not alone in this. Most consultancies you work with should have suitable training courses and certified Scrum Master or Product Owner courses are easy to source also (although slightly pricier).
One point to note is that Scrum is relatively rigid in its approach and this can become tiresome and even restrictive for Agile teams. For this reason, over time many Agile teams opt to trial other approaches such as Kanban which give them more flexibility. This natural progression should be considered by anyone starting to implement Agile in their organisation.
