For development teams, being Agile is less about physical fleet of foot and more about short, sharp bursts of work. The Agile movement is an approach to software development that can be summarised in four values found within the Agile Manifesto, based on a meeting of developers way back in 2001:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
Since then, the technology has changed but not much about these values has. Agile management is a fast-paced, incremental approach to projects, digital or otherwise, that aim to roll out results quickly, with maximum flexibility.
A variety of methods have been developed to implement the beliefs of the Agile movement and, right now, one of the most popular is called Scrum.
An Introduction to Scrum
The Scrum management framework is designed for small, cross-discipline teams. It provides a structure, which includes guidelines on roles and meetings, but teams are responsible for using this in a way that suits them. It’s a framework, not a rulebook.
It is based on short, fixed-length iterations of work called Sprints. These are commonly one or two weeks long spans of work, where a Scrum team builds, tests and releases the next shippable stage of what they’re working on. The hope is that by focusing on smaller changes rather than the whole, progress can be made more quickly.
These shorter, focused bursts of work also mean that milestones come more often. This not only leads to new releases but can also reinforce team morale. This is because fast deliberate work is paired with a tangible feeling of progress, which tends to keep teams energised and purposeful.
Most Agile processes do not include a project manager and Scrum is no different. Typical project manager roles and responsibilities are shared out among the lean teams, which typically consist of only three roles:
• The Product Owner
• The Scrum Master
• The Development Team
The Product Owner needs to have detailed knowledge of the project and represent stakeholders and users, so their requirements are fed back to the development team. The Scrum Master is a dedicated supporting role, focused solely on limiting issues and providing the best possible working environment. Neither of these roles get involved in the actual technical work—that’s the responsibility of the development team.
While it may be initially surprising for such a lean team to have two non-technical members, the nature of Scrum development means it makes perfect sense. With all development team members having a diverse skillset, they take on every stage of development from initial analysis to final testing.
Scrum Meetings and Rules
There are four main types of meetings laid out in the Scrum methodology:
• Sprint Planning
• The Daily Scrum Meeting
• The Sprint Review
• The Sprint Retrospective
The first two of these are self-explanatory. Sprint planning is used to plot out tasks and the daily scrum meeting starts every working day off, outlining objectives and priorities. While a review and a retrospective sound similar, the sprint review is actually a demonstration of the work completed and is often the first time stakeholders are involved. The retrospective is used to assess performance and evaluate potential improvements for the next Sprint.
For the most part, the roles and meetings are the rules of the Scrum approach. While blanket messages can be applied, such as nobody other than the Scrum team should be involved and agreements around the consistency of sprints, it’s typically best for teams to explore their own preferences.
The expected benefits of following Scrum and other Agile methods include the additional immediacy and responsiveness, which lend themselves to improved job satisfaction and, providing teams are appropriately balances, lower running costs. Laid out like this the approach is appealing, but reaching this point requires commitment and the right environment.
While this is only a brief introduction, if any element of Scrum seems irritating instead of helpful, it probably isn’t the right fit for you. However, if it sounds like a smart move, all you can do is take the plunge, try it out and set off on your first sprint.