Agile fundamentals for teams

In this video, we'll introduce the Agile delivery framework, Scrum. We'll explore: 

• its origins 
• how it works 
• and its application to the delivery of public sector services.  

Scrum has three pillars: transparency, inspection and adaptation. These support the idea of working in iterations. It encourages teams to work through experimentation. This enables them to learn, then adapt. This includes what they are doing and how they are doing it. It originated in the development of computer software in the early 1990's. It emerged as a response to traditional project management challenges. Since then, many other industries have applied Scrum with great success.  

Let's look at the make up a typical Scrum team. There are three primary roles: 

• a Product Owner who is accountable for maximising the value of the product or service 
• a Scrum Master who is accountable for ensuring the team succeeds 
• the Product Team, who design and create the features for the product or service 

We’ll look at these roles in greater detail later in the course. 

A Scrum team is usually made up of no more than 10 people. This is small enough to remain agile, but large enough to complete significant work. There are no sub-teams or hierarchies. Instead, they all focus on a working towards a single Product Goal. They are a multi-disciplinary team, bringing together people of different skills sets. This is dependent on the skills they need to achieve their goal. They are also self-organising. This means they decide amongst themselves, who does what, when, and how. 

A Scrum team will create a Product Backlog. This is a list of the features that the product or service needs, arranged in order or priority.  

To design and develop these, the team works in time-boxed iterations called "sprints". These are usually between one to four weeks long. This allows teams to inspect and adapt their work at regular intervals. This enables them to adjust their plans based on what they learn. 

At the start of each sprint, the team will plan their work. 

To do this, they create a Sprint Backlog. They select the highest priority features from the product backlog. They will aim to complete these over the course of the sprint. 

But what if an idea for a new feature comes up during the sprint? It gets added to the product backlog and prioritised. This means the soonest the team can begin to work on it, is the next Sprint cycle, if it’s a high priority. 

To keep everything on track, each Sprint has a series of events or meetings. These include Sprint Planning, Daily Scrum, Sprint Reviews, and Retrospectives. Each serves a specific purpose. These encourage open communication, transparency, and continuous improvement. Later in the course, we’ll look at each of these in greater detail. We'll focus on their purpose and give you practical tips to get started with them. 

By the end of the sprint, the team should have completed all the items in the product backlog. These features are now available to users. The cycle is then repeated. 

So, you might be wondering, how does this apply to the delivery of public sector services? Well, Scrum isn't only used in software development. Many other industries have adopted this approach to develop services and products. This includes public sectors services. 

Scrum works well when you expect requirements to evolve or change. This is where a flexible, iterative approach is beneficial. It's particularly effective in situations where teams need to inspect and adapt often. This approach is useful when: 

• you can deliver small items of value 
• you can add increments where possible 
• your product requirements in good shape 
• you have a clear roadmap 

If you work in an environment when changes are very fast, this can be a challenge. This is because the team adds new ideas to the product backlog. The soonest they could work on these could is the next sprint. Although teams can mitigate this to some extent, by working in shorter sprint cycles. 

To summarise, Scrum is a structured Agile framework. Teams work in time-boxed sprints, with events built in to keep them on track. It's an approach that encourages collaboration, adaptability, and continuous improvement.