How do you know if your team is truly Agile?

You’ve got a product backlog. You’re working in two-week sprints. Sticky notes litter your scrum board. Congratulations! You’re an Agile team!

Or are you?

A common challenge within development teams is that while they’ve implemented various pieces of the Agile methodology, they never truly get over the hump to experience all the benefits of the process.

There is no one-size-fits-all definition of exactly how Agile should be implemented. The Agile Manifesto simply provides guidelines. This leaves room for interpretation as development teams are free to choose the components of the methodology they can implement within their culture. So you might put in place a “code & fix” team that feels Agile because of its rapid output, but isn’t really because what they produce has major flaws due to a lack of thoughtful design up front. Or you may have an engineering team that operates with backlogs and sprints but is completely driven by a non-Agile release schedule set by executives on high.

Sometimes it is hard to see the forest through the trees. This post will help you determine if your team is achieving the results that Agile intends.

The opposite of Agile — the waterfall approach

In order to understand Agile, you need to know what it is not. The opposite approach to Agile development is the waterfall approach. This method originated in the manufacturing and construction industries where after-the-fact changes are prohibitively costly, if not impossible. At the time, there were no formal software development strategies, and IT teams needed some sort of structure to follow. Thus the waterfall approach was born.

The method is divided into sequences where progress is seen flowing steadily downwards as it passes through phases of conception, initiation, analysis, design, and so on. The idea is that each phase must be completed in order to move on to the next. The foundation of this approach is that time spent early in the software production cycle can lead to greater economy at later stages. For example, a bug found in the initial phases costs less to fix than a bug caught in the final stages. (This is also true in Agile, but Agile recognizes that long timelines lead to changes in requirements or environments, which introduce unintended problems that could never have been foreseen.)

Waterfall projects typically mean you’ll spend about 20-30% of your time in the design phase, 30-40% of the time coding, and the rest dedicated to testing and implementation. Your projects are highly regulated, and different parts of the team are in the hot seat at different times in the project lifecycle.

What it means to be Agile

An Agile team follows Agile principles, but not every team will implement the Agile methodology the same way. There are some key characteristics you should be experiencing if you are operating in the spirit of Agile and delivering the results that an Agile team is supposed to deliver.

• You are in touch with customers and responsive to their needs
• You have team-defined milestones and work plans (as opposed to orders coming down from executives)
• Your team is highly collaborative
• You are continually delivering output that is actually usable (i.e., the product doesn’t start to all “come together” 6 months after development begins)

How you know your team is Agile

Here are a few questions you should ask to determine if your team is truly Agile.

1. Does the team regularly produce value for stakeholders?

Creating value for both your customers and for the business side of the company is an important principle of the Agile development methodology. Because if your stakeholders aren’t happy, then your software probably isn’t going to be that effective. The key to becoming a true Agile team is to involve stakeholders at all stages of the development process.

As a tester, what this means is that you need to understand the end user experience. If your consumer isn’t happy with the way your mobile application handles page load time, or if your web application is too buggy, we can make a safe bet your consumer isn’t happy. Don’t just test functionality as defined by user tasks — set your bar to be the overall experience of the customer.

In order to develop a strategy that will deliver value to your stakeholders, ask:

• Do we actively consider usability issues in the development of the solution?
• Do we identify stakeholders at the start of the project?
• Do we have regular discussions with key stakeholders to better understand their needs?

2. Does the team validate their work to the best of their ability?

In an Agile team, you take a test-drive approach to development. Minimally developers should be testing their code at least daily. With test-driven development (TDD) you write a single test before writing just enough code to fulfill that test. There aren’t any hard-and-fast rules to validating your work, but a key point is that the development team is intimately involved in the testing process.

Answer yes/no or fill in the blank to some of these statements to see if you are following a strategy to validate your own work:

• We perform our own regression testing…
• We take a test-driven development approach….
• At the end of the project, “final” testing is….
• We follow non-solo development techniques such as…

3. Is the team self-organizing?

Disciplined Agile teams have this one down pat. Self-organization means that the team members themselves are planning and estimating their own work (with the help of course from the scrum master.) To be self-organizing means teams will perform their work within the context of an effective governance framework, which guides and monitors their efforts, including working towards a common infrastructure and programming guidelines.

Take a look at these strategies listed below to see you are a part of an Agile team:

• In each iteration/sprint we hold a planning meeting
• We hold daily stand-up meetings to coordinate
• We produce status reports at least once a sprint
• At least once a week, a senior manager will attend
• We measure our velocity and use that to estimate project completion times

4. Does the team strive to improve their process?

A common practice at the end of each sprint is to identify potential ways to improve the software process. More important, teams will act on one or more of their issues in the next sprint, which improves their approach throughout the whole project. Really disciplined teams make the effort to track their progress over time and share their ideas with the team.

Here are a few strategies Agile teams implement in order to continuously improve:

• Hold a retrospective session at the end of each sprint to identify issues
• Address those issues in the next sprint
• Measure and track our progress of adopting improvements to the process

Conclusion

If your organization wants to try Agile, it’s not hard to find a couple of practices that you can put in place to lay claim to the Agile moniker. However, Agile is designed to deliver results, not processes. Use the questions above to determine if you are actually achieving those results, so you know all the effort is worth it.

This blog was originally published in September 2014 and was refreshed in July 2021.