Avoiding Agile Must-Dos

I’ve worked with a few organizations so heavily focused on the operational aspects of Agile that they only thought of Agile as a set of practices teams had to follow and where doing good Agile meant completing projects successfully.

At companies with that perspective, instead of describing qualities like adaptability and quickness, Agile becomes a standard, mandated approach to team structure and project management practices for things like planning, estimating, and reporting. This operational interpretation of Agile and focus results in losing any of its benefits.

These companies require their Agile teams to do things like:

• Adhere to particular team structures and roles: Cross-functional team, Product Owners and Scrum Masters.
• Follow processes and meetings: Scrum or Kanban, user stories, daily stand-ups, estimates, sprints, sprint planning and story grooming.
• Track and share metrics and reports: Cumulative flow diagrams, burn-down charts and report on average throughput.

While these practices aren’t inherently bad, when the goal is output and production volume, when the goal is working towards a fixed scope target, and when management tells teams how to work, the chance of developing any real agility is lost.

Agile as Better Waterfall

“Agility” does not mean “Good at waterfall.”

Agile is not a project management approach, and it’s not a better way to deliver waterfall projects. Agile offers an alternative to doing projects at all.

There are a few reasons why we’d want to avoid projects:

• Large scope and long lead times.
• High-risk with plans based on initial assumptions and limited knowledge.
• Work delivered in big batches validated only at the very end of the project.
• Changes are expensive and slow to integrate into the plan.
• Complex systems with extra overhead are needed to manage all the work, status updates, project reports, code branches, meetings, etc…

If companies use Agile for project management, then it doesn’t matter what tools or practices they’ve implemented. Even if you’re using Kanban boards, user stories, and story maps, if you try to sprint your way through a waterfall project, all of the same issues and risks inherent to projects still apply.

Instead of viewing Agile as a set of practices designed to make your projects more successful, consider it a way to avoid them altogether. By building small, delivering often, and validating your assumptions as you go, Agile principles support an approach that limits risk, reduces overhead, and lets you respond faster to change.

From Operational to Outcome Focus

Outcome-Focused Agile

Agility doesn’t come from focusing on operational practices and producing outputs. Real agility happens when teams and organizations prioritize adaptability, learning and outcomes.

When the focus is on generating learning and outcomes, it includes the elements of learning from users, reducing risk, prioritizing impact over output, empowering teams, and continuous improvement:

• Learning from users
  • Learning from users through feedback and observations
  • Discovering new problems worth solving
  • Learning as you build
  • Integrating customer insights and feedback throughout development
  • Adjusting scope based on what you learn
• Reducing risk
  • Building small and releasing often
  • Shortening feedback loops to quickly course correct
  • Validating assumptions frequently
  • Working with short, tactical planning horizons
• Prioritizing impact over output
  • Focusing on the value created, not on the amount of work completed
• Empowering teams
  • Trusting teams and empowering them to self-organize with less bureaucracy
  • Giving teams the ability to act without asking for permission
  • Letting teams choose how they work
• Continuous improvement
  • Continuously seeking better ways of working
  • Reducing dependencies
  • Experimenting with new approaches

Instead of trying to accomplish projects by setting up teams with rigid structures and requirements, teams should be allowed to evolve their approach. Teams learn as they work.

Conclusion

Unlike agile practices, management can’t impose agility onto teams. Agility is an outcome of a way of working, which has to be something the team wants to do and supported by the rest of the organization.

Agility isn’t achieved by forcing teams to use Agile practices, maximizing how much volume of work teams can deliver, or getting better at projects. It’s the outcome of teams working towards their goals by shortening feedback loops, experimenting, learning, and adjusting.