Insights
We explore what Agile and Scrum really mean, how they work, and why they could be good for your charity projects
Agile, in its simplest form, is an iterative approach to project management, originally used for software development. Agile was set up to help deliver value to customers quickly, releasing small changes to software on an ongoing basis, rather than waiting until something is completely finished. Because, let’s face it, it is never completely finished!
Agile is a project management methodology that makes it easier to respond to change and regularly listen to your customers, which is something all charities had to do more of over the last few years of turbulence.
Though Agile was originally created for software development, the methodology can be used for any kind of complex project, whether it is digital or not. It also extends beyond projects and can be used at an organisational level, but here we are focusing on project management.
With the world changing at an ever-increasing pace, it has never been more important to be able to try new things, to pivot and listen to your customers, and to ensure you are providing the best possible service or product for their needs.
Whether you are testing new digital marketing campaigns, building a new open philanthropy process, or designing a new website, Agile can help you deliver your project in a way that reflects and adjusts with your end user at the forefront.
The word agile gets used regularly in varying contexts and though there are similarities to the verb agile, compared to the noun Agile, they are ultimately different and shouldn’t be confused.
The verb ‘agile’ is described as “marked by ready ability to move with quick easy grace” or “having a quick resourceful and adaptable character”. In project terms, being agile in this sense will certainly help you practise Agile working, but it’s important Agile doesn’t get confused with flexible working, hot desks and changing working hours.
Over 20 years ago the Agile Manifesto was created. Agile is often referred to as a mindset and the Agile Manifesto helps you understand how you can ‘live’ that mindset throughout your work. It refers to four Agile values and 12 principles.
The values are:
The manifesto says, ‘while there is value in the items on the right, we value the items on the left more’. This means there is still planning, documentation, contracts, and processes and tools, but listening to customers and the team and responding to change is always more important.
Ultimately, let’s stop getting so hung up on the paperwork and reports and focus on getting the work done to create a big impact instead. I am sure lots of people can resonate with this, whether you are working in Agile or not.
People often read the Agile values and think, yes I get that, easy peasy. But the truth is Agile is often easy to understand but difficult to master. Organisations can be so ingrained in the traditional processes and protocols and getting sign off from the right people, that it often slows down projects, causing frustrations and blockers.
One of the key things about Agile is how the team works together. Teams are often non-hierarchical and self-organising, so the team decides together who is best placed to do what, and the work that should be prioritised next.
The Agile Manifesto is a guide and to be used how it works best for your team and organisation. It should also be something the team agree to sign up to and never something forced upon a team or organisation.
Whereas Agile is a mindset and core set of values and principles to deliver projects, Scrum is one of several specific methods used to facilitate a project. It is more the nuts and bolts of how a team and project can be run.
Scrum is the most popular Agile methodology, but others include Kanban, Lean Development and Extreme programming (XP).
The Scrum Framework generally sits around a series of ‘ceremonies’ or meetings that help the team deliver value through adaptive solutions.
As with all things in Agile the structure and ceremonies can be adapted to what works best for the team, but the key ceremonies are:
Sprint: This is where the core of the work gets done. A sprint is usually two-to-four weeks and should have a key sprint goal that is followed by the team, with everyone understanding the work to be done in that time period.
Sprint Planning: This happens at the start of each sprint, where the team gets together and plans and prioritises the work to be done in that sprint. Work that is out of scope for the sprint should be kept in the ‘backlog’ which is basically a big list of the tasks that need to be done in the project. Work in the sprint should be broken down into manageable actions that can be completed in that sprint, sometimes this means breaking up larger tasks into smaller ones.
Daily Scrum: This shouldn’t be longer than 15–20 minutes and is a quick daily run through where each team member answers the questions ‘what did you do yesterday?’, ‘what are you doing today?’ and ‘do you have any blockers?’ This helps the whole team understand how the work in the sprint is going and if there are any ways they can support each other or get external help to solve any blockers.
Sprint Review: At the end of each sprint the team runs a review session where the key work in the sprint is shared. This should be open to wider colleagues and stakeholders so they have a chance to share feedback and be kept up to date in real time on how the project is running.
Sprint Retrospective: This is a chance for the team to get together and look at how the last sprint has gone. It’s a chance to share any issues and look at what’s worked well and areas for improvement. The team is constantly evolving and these short 30–60-minute retrospectives help the team continually improve their working practices to create the best project outcomes and happy teams.
Different structures work for different teams, some might want to have their stand-ups daily, whereas others might find twice a week is enough, some teams have monthly sprints, whereas others make them weekly. Generally the more complex the project the more regularly a team should meet and run a new sprint, as there will be more variables changing.
A traditional Scrum team includes a couple of key roles and would consist of around 5-7 people. Too many people means less time for people to share their thoughts and work and too few can make sprint goals harder to accomplish. It isn’t a hard and fast number though so it depends on the structure of your project team and what works best for you.
The Scrum Master role is a key role in the team, and no, it has nothing to do with rugby! The Scrum Master is the expert in the Scrum framework and helps bring the team together, organising the different ceremonies and helping with any blockers. An important part of the role is removing any distractions that might interrupt the work in the sprint, for example, colleagues asking for help with a ‘quick task’.
The Product Owner is similar to a Project Manager role, ensuring the team understands the project goals and outcomes, monitoring feedback, ensuring a decent return on investment (ROI) and holding the relationship with any external or internal stakeholders.
The rest of the team varies. In a traditional software team it would be mainly made up of developers, but could also include UX designers and testers.
Who is in your Scrum team is up to you, it depends what your project is trying to achieve. The best Scrum teams are often cross functional with expertise in many areas to help achieve project goals. The Scrum Master role can also sometimes be cross functional, often helping out with the actions in the sprint too.
Agile project management and Scrum really are great ways to get your team working in a collaborative and open way to achieve the best products and services possible.
Our courses aim, in just three hours, to enhance soft skills and hard skills, boost your knowledge of finance and artificial intelligence, and supercharge your digital capabilities. Check out some of the incredible options by clicking here.