An Introduction to Agile Working

What is Agile, and how can it be used to help get things done quickly in a fast-paced environment?

‘Agile working’ may sound like a classic case of buzzy business-speak, but we’re pleased to say there’s real substance behind the name. Agile is a very clearly defined work methodology, underpinned by an exceptional philosophy that prizes adaptability and freedom over hierarchy and dogma. It’s currently in-use by teams at Google, Microsoft, EA and several government agencies around the world.

We’ve put together this article to explain the agile methodology, unpack its components, and demonstrate how organisations large and small can implement it to their immense advantage. Bear with us as we explain the technical language used to describe the aspects of agile – underneath the surface the methodology is simple and accessible, requiring very little technical knowledge.

What is agile methodology?

Agile methodology is a project management framework, used by teams to iteratively and incrementally complete tasks and projects. In most cases agile is implemented in the form of a working framework known as scrum, over short work beats called sprints. To make things simpler whilst you absorb all this information, think of scrum as the way the team is configured, of sprints as the periods over which they do their work, and agile as their overall approach and working philosophy.

Scrum

Scrum is a lightweight working framework used by small, usually interdisciplinary teams to collaborate on multi-faceted projects. Originally used by software engineers in the late 20th Century, scrum is now prevalent in a variety of industries thanks to its proven ability to facilitate teamwork, problem-solving and adaptability.

A scrum team will usually consist of anywhere from 5-9 people – the range widely held to provide the right balance of easy communication and diversity of skills. The team will contain all of the talent required to deliver the project and implement the agile methodology.

In scrum, as in other variants of agile, the team works together over short, regular intervals known as sprints, usually lasting either a week or a fortnight. After and during every sprint the team works to improve its processes and output.

The scrum team structure

One of the great innovations of the scrum framework is the total absence of hierarchy within its team structure. Scrum does away with chains of command and instead combines different specialisms within a flat structure, under the following role titles:

• Scrum master – the in-house scrum expert and advisor. The scrum master is tasked with maintaining and improving the team’s performance within the scrum framework. Think of this person as your scrum evangelist – someone who helps the whole team to learn and use the scrum framework. They also enforce the scrum structure, remove obstacles to the completion of tasks and do whatever they can to aid the team’s progress.
• Product owner – responsible for maximising product ROI. This person focuses the team’s efforts on the work that adds the most value, by ordering the priority of items in the team’s backlog of tasks. The PO is responsible for setting out the requirements to be fulfilled by the product, which are usually expressed in the following form, as ‘user stories’: “As a , I want a so that I can ”. For example, “As a , I want a so that I can .” These user stories build to form – or may individually define – a product’s value to the customer.
• Team member – the members of a scrum team have a high level of responsibility for their own work. Their objective is to utilise their specialisms to help the team deliver marketable product within every sprint. Team members may also need to chip in to progress tasks that lie beyond their area of specialism.

The non-hierarchical structure of scrum masters, product owners and team members works on the basis of a largely democratic approach, with provision for deference to specialist team members (e.g. to the scrum master on debates regarding implementation of the agile methodology).

Scrum materials

Now we know how a scrum team fits together, let’s take a look at the work components that constitute scrum’s processes.
There’s a wide range of agile project management software available that will help you digitally visualise these scrum materials, including JIRA and Basecamp. Instead of focusing on one of these systems, we’re going to teach you transferable definitions that will help you to understand and implement scrum, whichever software you decide to use.

Product backlog

The product backlog is the list of deliverable components that comprise the intended product, covering all future and active sprints. Any task that could assist or facilitate successful delivery of the product may be listed in the backlog.

Backlog items

These are the tasks listed in the product backlog. They are made up of five components, which should all be clearly specified in the item listing:

• Subject – who does the item benefit? (the customer/scrum team/etc.)
• Description – purpose of the task. What needs to be created or carried out?
• Value proposition – how will this item add value to the product?
• Work required – sometimes measured in ‘story points’ (a measure of time/human resources required)
• Acceptance criteria – the conditions which must be satisfied in order for the product to be deemed ‘shippable’

Sprint backlog

Remember sprints, the regular periods of activity during which the scrum team carries out its work? The sprint backlog contains the ‘stories’ (product deliverables achieved through the completion of tasks) scheduled for completion over the course of a designated sprint. Assigned during sprint planning, sprint backlog items may be taken from the product backlog or added directly according to new requirements or ideas. Urgent items may also be added to a sprint backlog while the sprint is underway, in order to maintain the progress of items in the sprint.

Burn chart

This tool is used to show how much of the project scope (measured in terms of story points of tasks completed) is being completed over time (measured in sprints – 1st sprint, 2nd sprint, etc.)

Burn charts can be formatted according to how many story points still need to get ticked off (burn down) or how many story points have already been completed (burn up). The difference between the two burn chart formats is slight – which one you should pick boils down to whether your team will benefit more from a reminder of what they have already accomplished, or from a reminder of what they have left to do.

In our opinion, burn up charts seem to be the more positive approach. When the scrum manager needs to emphasise urgency, they have the option to flip the format to burn down.

Vertical lines are added to the burn chart when more scope is added to the project. A guideline may also be included, allowing for easy visual assessment of the team’s progress.

Sprint task board

The sprint task board shows all to-do, in-progress and completed tasks within the sprint. Prominently displayed within the physical or virtual working environment (or better still, both), the sprint task board gives every team member a holistic vantage onto the sprint in all its complexity.

This open approach is central to the agile philosophy. It allows team members to fully understand their role within a project, it helps them to collaborate freely on tasks, and it makes apparent the areas in which team members or departments require help in pushing a story through to completion.

Sprint items

Sprint backlog items always fall into one of four categories:

• Story – typically, stories are product deliverables added to the sprint during sprint planning (discussed later). Each story can be defined by a ‘user story’, as mentioned previously (e.g. “As a, I want so I can.”)
• Task – stand-alone operational items, usually identified in sprint planning. Individual tasks might play a part in progressing a story towards completion, or in some cases they may facilitate improvements to the team’s processes.
• Epic – a set of stories, all contributing towards the same product outcome. Individual stories within an epic are not considered to possess saleable value unless all stories within the epic have been successfully completed.
• Bug fix

How sprints work

Each sprint progresses through a series of fixed components: sprint planning, daily scrums, project work, story time and retrospective. Together, these stages form one revolution of the sprint cycle – a sprint. Here’s an example of a how a two-week sprint might be mapped out, with project work occupying all undesignated time:

This is a typical schedule using standard sprint component timings. Please bear in mind that your team’s requirements – and therefore the duration and timing of your sprint components – may differ from this example.

Sprint planning

A scrum team’s objective is to deliver viable product (either in the form of new product or improvements to existing product) within every sprint. At the start of each sprint, during sprint planning, the whole team gets together to decide how they will achieve this goal.

Sprint planning meetings are typically comprised of two parts – the first addressing what the team will accomplish during the sprint; the second, how they’ll do it.

Part 1 is led by the product owner, with assistance from the scrum master. In the days leading up to sprint planning, the product owner will have spent time working on new and existing stories with high potential to add product value. In part 1 of sprint planning, the PO pitches the stories to the team, in order of priority as defined by projected ROI. The whole team discusses each story, identifies the acceptance criteria whereby completion of the story will be determined, estimates the scope of work involved and ultimately decides whether or not the story can be accommodated within the sprint. The final authority to accept or reject tasks is shared equally amongst the whole team.

During the second part of sprint planning, the team identifies the tasks involved in delivering each story. These may be split up by department, e.g. marketing/development/creative/procurement. At this point the team may resolve to cut certain stories from the sprint, particularly in cases where a story seems likely to eat up more scope than previously expected. Rejected stories are typically consigned to the product backlog, and may be considered for subsequent sprints.
Scrum masters take note: it’s generally considered good form to bring a healthy supply of biscuits to sprint planning meetings.

Daily scrum

Daily scrums take place around the start of every shift, except on the day of sprint planning. A typical daily scrum involves the whole team standing in a circle, with each member discussing the following points in turn:

• What I did yesterday
• What I plan to do today
• Which obstacles are hindering my progress

Each daily scrum should be free but focused, with each team member sharing important details or issues. It’s the scrum master’s job to ensure the session clocks in at under 15 minutes.

New bug fixes, tasks and stories identified during daily scrum may be added to the product backlog or the active sprint, as appropriate.

In some cases, daily scrums can be made more efficient by getting team members to submit their answers to a digital group chat, to be collated and displayed on a monitor during the daily scrum. This process may help some team members to focus their points, or to more easily digest what has been said by other team members.

Daily scrum represents a great opportunity to stamp your team’s personality on your agile processes. We know of one ecommerce company whose developers pass a Lord of the Rings action figure around the circle in every scrum to identify the speaker – and that may sound a bit silly, but in this case it certainly seemed to ease the team into a good-humoured and creative discussion.

Story time

This meeting’s purpose is to improve the stories currently waiting in the product backlog. The PO and all relevant team members get together to address the following points with respect to each story:

• Define/refine acceptance criteria
• Assign work estimates (e.g. in time/story points)
• Split stories – the more bite-sized you can make a story, the easy it will be to successfully complete. Split each story till you can split it no more.

The decisions made during story time will influence the outcome of the next sprint planning meeting.

Sprint review

This fast-paced session brings the scrum team face-to-face with any senior management, shareholders or clients who are invested in or bear responsibility for the scrum team’s work. The team reports on any planned sprint tasks which could not be fully completed, before presenting all completed sprint tasks. The management, shareholders or clients then provide feedback to the team, for consideration in future planning.

Retrospective

Finally, each sprint closes with a retrospective meeting, in which the sprint team discusses what went well and what could have gone better during the sprint. The objective is to hold an honest, wide-ranging discussion through which the team can identify two or three actionable points that seem likely to improve the scrum team’s output or agile processes in future sprints.

We recommend setting up a group chat channel in which team members can post their retrospective comments – tagged #good or #improvement – over the course of the sprint. When the retrospective meeting comes about, the scrum master can simply read through the channel and guide the team’s discussion of each point. This approach reduces the amount of time you’ll need to allocate for the retrospective itself, and cuts down the number of good ideas which get forgotten about along the way.

Implementing agile

Agile can work wonders for your team. It’s insight-driven, it’s ROI-focused, it enables fast responses to new information and it breeds creativity. Getting every team member fully on-board with this innovative approach to working may be tricky at first, but remember that the scrum framework can be modified to suit your requirements. With every retrospective you’ll come closer to your optimum setup and a satisfied team.