Is Your Team Agile? Take This Test to Find Out

Gilli Aliotti, Agile Coach, Theagilewarrior.com

Agility in tech organizations is often tossed around as if it’s a buzz word, but very few are actually agile.

“Oh, we are agile”, “We’re an agile shop”, “Yes, we run sprints”. But when you take a look under the hood, there are several KPIs to determine if truly an agile operation.

  Allowing the team to try new things, to come up with new solutions to problem statements, fosters a healthy and high-performing team 

Let’s measure your team’s agility with some of these digestible, real-life examples following the

12 principles of agile.

1. Are you delivering working software that is valuable to the customer at the end of the sprint, or even better, several times within the sprint? Good job. Continuous delivery is key and delivering working software in weeks versus months.

If you are spending weeks or even months in different development phases, from analysis (requirements phase), to design, to development, to testing, and then if all is approved, released to the customer after a long period of time, you are not agile. Requirements change over large periods of time, and by the time you gain stakeholder acceptance, they’ve changed their minds all together, let alone our customers may no longer need that feature or functionality. That is why a true agile team have smaller, iterative releases, where you can gain feedback quickly (preferably after a 2 week sprint, or even CI continuous deployment scenarios). This way the team can learn and adjust quickly, and experiment again, without too much time in between. Rapid deployments also foster the ability to get features to market quicker.

2. Are you delivering extremely large and complex requirements to the team?

If your product owner has handed over a manifesto of 20 pages for the next feature to develop, stop right there. These waterfall type requirements are a thing of the past, and don’t allow the team to experiment on several approaches to come up with the solution, and don’t capture changing requirements as we sprint. Simplicity is essential. Also, large requirements fosters bad habits of long-winded months on end waterfall type projects. Welcome changing requirements is key, through smaller iterations. Also clear requirements, both good design, and effective user stories enhances agility.

3. Do you not know what’s going on, and one team is siloed off from another team? How independent and self-organized is your team really?

Working together daily, together, is extremely important. Do you daily standups and share what you worked on yesterday, what are you working on today, and what are your blockers. Be self-organized in that each of the team members work as a whole to decide the implementation, and be like glue working together to solve and test the problem.

4. Is your team self-organizing and true to their velocity? Are your team’s sprint tasks completing within a 2 week (or iterative) period? Good Job. A self-organized team with the ethos of simplicity is essential.

If your tasks are carrying over to the next sprint regularly because they are just not completing then you’re not in touch with the velocity of your team, and perhaps the team are not as self-organized as they could be. Planning according to the velocity of the team is the key to a self-organized agile team. If product owners are pushing more work into the sprint than what is digestible, you are not allowing for a self-organized team, but instead taking a command and control waterfall approach. Allow the team members to estimate the planned tasks with story points to understand their capacity and break down those stories into

bite-sized chunks to keep the sprint actionable. Simplicity is essential both in priority, prioritization and process.

5. Are you often bringing in unplanned work mid-way into a sprint because the product owner or stakeholders say so? Consider that the best agile teams work with boundaries. Whether you work in sprint cycles (plan and protect for 1 or 2 weeks), or Kanban (regular planning that only allows up to 8 tickets in progress at 1 time), you are always helping the team with limits, so that they can stay self-organized and working to the velocity of their team by promoting sustainable development. Build projects around motivated individuals and let them fly.

6. Are you just going from one sprint to another without reflecting on lessons learned, or areas to improve? One of the key agile principles is to reflect how to become more effective. We want the team to continuously improve, and the only way to do that is to reflect on what worked well, and what didn’t. As a self-organized team, they can measure their own success, be accountable for failing, be OK to fail, and continuously improve.

Sprints are, indeed, an experiment. Allowing the team to try new things, to come up with new solutions to problem statements, fosters a healthy and high-performing team.