As seen in CIO Review
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. 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
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.
Agile Ninja, Gilli Aliotti, leads agile coaches, scrummasters, scrum product owners, tech disrupters and lean startup entrepreneurs to become “agile warriors” in their careers and lead their teams through rockstar agile transformation. All articles are © Copyright of the Author and this site www.theagilewarrior.com and cannot be reprinted or distributed without permission. If you would like to re-post these articles, please contact us. Or you can tap the social share buttons to share these blogs, with links intact, to your network.