What are the tools and techniques of using agile methodology

Using agile tools and techniques can help your digital service team to:

self-organise and plan
communicate (within the team and with the rest of your organisation)
continuously improve the way you work
get support from senior responsible officers (SROs) and service managers

You might also hear these tools and techniques called ‘agile ceremonies and artefacts’.

Daily standup

The standup is a daily meeting for the team to discuss what they’re working on and whether there are any problems or dependencies they need to resolve (for example, needing help from someone else).

Standups should last no longer than 15 minutes. You should hold them at the same time every day. It’s best if you do standups in front of your team wall.

good and bad standups – a video presentation by Adam Maddison, Head of Agile Delivery at Government Digital Service (GDS)

See: standup meetings on Wikipedia

Sprint planning meetings

Sprint planning meetings are a feature of Scrum. You should hold them at the start of each sprint.

At a sprint planning meeting, the team decides what to work on next and how they’ll do it.

The length of the meeting will depend on how long your sprint is.

Read: sprint planning by Ken Schwaber and Jeff Sutherland, the creators of Scrum

Team review (show and tell)

The team review is a regular meeting which gives team members the opportunity to demonstrate their work. It can also be called a sprint review or a show and tell.

You can invite stakeholders like directors or suppliers to this meeting and use it to tell them about the user stories you’ve completed or other work you’ve done.

You’ll need a screen to show your work and enough space for people to join in.

If your service is part of a larger organisation or programme you may want to open up your review to the rest of the organisation every few weeks.

This gives you the opportunity to show the most important work you’ve done, talk about what you’ve learned, explain your plans for the next few weeks and answer questions. It also gives other teams the chance to see how your work relates to theirs.

See: how a Ministry of Justice team got stakeholders involved in sprint reviews

Retrospective meetings

Retrospectives, sometimes called ‘retros’, are regular meetings where your whole team talks about what’s going well and what is not.

Teams usually hold retros at the end of an iteration (for example a sprint) and use them to talk about the work from that period of time.

The point of a retro is to fix any problems in the team and to make sure you keep doing the things that are working.

How to run a retro

One person should host the retro and decide on questions for the team to talk about.

If you’re hosting, pick broad questions that allow the team to set the agenda, rather than strictly setting it yourself.

Retros should have an open atmosphere where every member of the team can speak honestly and feel confident that their colleagues will listen.

Allow 60 to 90 minutes for the meeting and use a private space where you can stick post-it notes to the wall.

A basic retro could follow these steps:

The host explains the questions at the beginning and sticks a post-it note to the wall for each question.
Each team member writes down one or more answers for each question on post-it notes and sticks them to the right part of the wall.
The group discusses issues as they come up, or at the end.
The host decides on actions to fix any problems raised, and assigns them to members of the team.

You could choose to cover 3 or 4 of the following topics:

what went well in the last iteration
what went badly in the last iteration
what’s puzzling the team or what the team does not understand
who the team wants to thank (eg other members of the team)

These topics are just examples, there are many different types of retro. You can find more in the Retrospective wiki.

If you’re hosting the retro, you should pick topics which you think will prompt useful discussions in your team, for example on transparency, team learning or your working process.

Make a list of actions

You should use the information you get from your retro to improve your work and your working environment.

Make a list of actions that you’ll carry out to fix the problems that your team highlighted and assign them to people in the team.

You should aim to get the actions done before the next retro.

End-of-phase retrospectives

Some teams run a longer retro at the end of discovery, alpha and beta. These usually include people who’ve been involved in the work from outside the team, too, like procurement or policy colleagues.

This type of retro can:

identify what could be improved in the next phase of the project
help people from procurement, policy or other disciplines work more effectively with service teams across the wider organisation

ONS ran an end-of-phase retro to identify which ways of working to continue and which to stop in the next phase of their data discovery project.

User stories

User stories are a way for your team to briefly record the things you need to do to build the service. You can use them to prompt discussions about features when you’re ready to start work on them.

See: writing user stories

The backlog

Your team will have a product backlog where you’ll store the user stories you have not started work on yet in order of priority. If you’re following Scrum methodology you’ll also have a sprint backlog to store the stories the team has agreed to work on in that sprint.

See:

Creating an agile working environment for more information about tools that can help you manage your backlog
product backlog by Ken Schwaber and Jeff Sutherland, the creators of Scrum

Team walls

Your team wall is a wall near where you sit on which you keep a visual record of your work.

The wall shows what your team has done, what they’re currently doing and the work still to do.

It helps your team to collaborate and allows other people in the organisation to see what you’re doing.

See:

You may also find these guides useful:

Agile Methodology is a people-focused, results-focused approach to software development that respects our rapidly changing world. It’s centered around adaptive planning, self-organization, and short delivery times. It’s flexible, fast, and aims for continuous improvements in quality, using tools like Scrum and eXtreme Programming.

Tip: Find application errors and performance problems instantly with Stackify Retrace

Troubleshooting and optimizing your code is easy with integrated errors, logs and code level performance insights.

How It Works

It works by first admitting that the old “waterfall” method of software development leaves a lot to be desired. The process of “plan, design, build, test, deliver,” works okay for making cars or buildings but not as well for creating software systems. In a business environment where hardware, demand, and competition are all swiftly-changing variables, agile works by walking the fine line between too much process and not enough.

Agile Methodology Overview

It abandons the risk of spending months or years on a process that ultimately fails because of some small mistake in an early phase. It relies instead on trusting employees and teams to work directly with customers to understand the goals and provide solutions in a fast and incremental way.

Faster, smaller. Traditional software development relied on phases like outlining the requirements, planning, design, building, testing, and delivery. Agile methodology, by contrast, looks to deploy the first increment in a couple weeks and the entire piece of software in a couple months.
Communication. Agile teams within the business work together daily at every stage of the project through face-to-face meetings. This collaboration and communication ensure the process stays on track even as conditions change.
Feedback. Rather than waiting until the delivery phase to gauge success, teams leveraging Agile methodology track the success and speed of the development process regularly. Velocity is measured after the delivery of each increment.
Trust. Agile teams and employees are self-organizing. Rather than following a manifesto of rules from management intended to produce the desired result, they understand the goals and create their own path to reach them.
Adjust. Participants tune and adjust the process continually, following the KIS or Keep It Simple principle.

For training purposes, there’s a comprehensive, downloadable overview here.

Examples of Agile Methodology

The most popular and common examples are Scrum, eXtreme Programming (XP), Feature Driven Development (FDD), Dynamic Systems Development Method (DSDM), Adaptive Software Development (ASD), Crystal, and Lean Software Development (LSD). Teams generally pick one or two methods. The most widely used methodologies are Scrum and XP, which dovetail nicely.

Scrum is a hands-on system consisting of simple interlocking steps and components:

A product owner makes a prioritized wish list known as a product backlog.
The scrum team takes one small piece of the top of the wish list called a sprint backlog and plans to implement it.
The team completes their sprint backlog task in a sprint (a 2-4 week period). They assess progress in a meeting called a daily scrum.
The ScrumMaster keeps the team focused on the goal.
At the sprint’s end, the work is ready to ship or show. The team closes the sprint with a review, then starts a new sprint.

Here’s an example of how Scrum works: Bill meets with a customer to discuss her company’s needs. Those needs are the product backlog. Bill chooses the most important tasks to work on in the next two weeks. His team meets in a daily scrum to target work for the day ahead and address roadblocks. At the end of the sprint, Bill delivers the work, reviews the backlog, and sets the goal for the next sprint. The cycle repeats until the software is complete.

Image via Open-Ware.org

eXtreme Programming. Often used with scrum, XP is an example of how Agile can heighten customer satisfaction. Rather than deliver everything the customer could ever want far in the future, it gives them what they need now, fast. XP is centered on frequent releases and short development cycles. It uses code review, pair programming, unit testing, and frequent communication with the customer.

Here’s an example of how XP works: Bill builds a list of customer requirements by having the customer tell “user stories” that outline the features. From these, he builds a software release plan. The software will be delivered in iterations, with one delivered every couple weeks. The team works in programmer pairs, using daily meetings to smooth roadblocks. The customer delivers feedback in the form of more user stories. The cycle repeats until the software is delivered.

For more examples, see this article.

Tip: Find application errors and performance problems instantly with Stackify Retrace

Troubleshooting and optimizing your code is easy with integrated errors, logs and code level performance insights.

Benefits of Agile Methodology

The benefits of Agile are tied directly to its faster, lighter, more engaged mindset. The process, in a nutshell, delivers what the customer wants, when the customer wants it. There’s much less wasted time spent developing in the wrong direction, and the entire system is quicker to respond to changes. For a more comprehensive list of benefits, see this post.

Faster. Speed is one of the biggest benefits of Agile Methodology. A faster software development life cycle means less time between paying and getting paid. That, in turn, means a more profitable business.
Increased customer satisfaction. With Agile, customers don’t wait for months or years, only to get exactly what they didn’t want. Instead, they get iterations of something very close to what they want, very fast. The system adjusts quickly to refine the successful customer solution, adapting as it goes to changes in the overall environment.
Values employees. Employees whose ideas are valued are vastly more productive than those who are ordered to follow a set of rules. The Agile Methodology respects employees by giving them the goal, then trusting them to reach it. Since they’re the ones with their hands on the controls and the ones who see the obstacles that crop up every day, employees are in the best position to respond to challenges and meet the goals at hand.
Eliminates rework. By involving the customer at more than just the phases of requirements and delivery, the project remains on-task and in-tune with customer needs at every step. This means less backtracking and less “out on a limb” time between the time we do the work and the time the customer suggests revisions.

Best Practices

The list of best practices is long and involved, with dozens of tools to pick and choose. We’ve outlined a short list of the main benefits below. For a more comprehensive best practices guide, see this article.

Set priorities. A product backlog is a list of prioritized tasks maintained by a product owner.
Maintain small release cycles. The product should be released in increments every 2-4 weeks, with stakeholders giving feedback before proceeding.
Use pair programming. Two programmers work side-by-side at a single computer. This technique actually results in an identical degree of productivity to separate programming but delivers higher quality.
Refactor. Rework code regularly to achieve the same result with greater efficiency and clarity.
Use test-driven development. Code the unit test first to keep the project on task throughout. Test-driven development as an Agile best practice also produces greater employee engagement, since it transforms testing from a boring grind to a coding challenge.

Agile Methodology Tools

The list below shows some of the best tools on offer. For a complete list, see this post.

ActiveCollab. An affordable tool for small businesses, ActiveCollab is easy to use. This software development aid requires little training and provides excellent support.
Agilo for Scrum. Stakeholders get updated automatically on the project’s progress with Agilo for Scrum. Features sprint reports and burn down charts for better data mining.
Atlassian Jira + Agile. This powerful project management tool facilitates development by incorporating Scrum, Kanban, and customizable workflows.
Pivotal Tracker. This methodology tool is geared specifically for mobile projects. A little jargon-heavy, it’s user-friendly after a brief orientation period.
Prefix. This free tool from Stackify provides an instant feedback loop to catch and fix bugs before they can deploy.
Retrace. For a more robust solution complete with monitoring, errors, logs, and more, Stackify’s Retrace provides app performance insights from integration to QA to production, at the code level.

Additional Resources

Make use of the non-product style tools and resources for success below, including the original Agile manifesto and a few downloadable templates for implementation.

Agile Manifesto. This is the original document that kicked off the Agile movement. It contains all 12 key tenets of the methodology at large.
Burn Down Charts. These are visual representations of work left vs remaining time. Download an Excel template here from SmartSheet.com.
Agile project plan. This is a tool for tracking the progress of the overall Agile project. This article from Ambysoft outlines the entire project planning process.
Agile product backlog. This helps product owners track and prioritize customer requirements. You can download an Excel template here.

Agile is a popular development methodology widely used by development teams who need to ship apps efficiently. But Agile development requires Agile support, so dev leaders must arm their teams with the tools and resources they need to succeed. Check out this post for some valuable tips for making Agile less fragile. Also, check out our great list of scrum boards.