Introduction to Being Agile

“We’re an agile shop now.” Have you heard this from an executive or leader in your organization? If so, were you underwhelmed with the impact of this statement? Becoming a truly agile organization takes more than a top-down statement or even a few teams implementing agile frameworks. True success comes from being an organization that exhibits agile values.

First, let’s define some things. Agile is not Scrum (or XP, or Kanban). Agile is not JIRA (or Rally, or VersionOne). Scrum is a framework for teams that want an agile way of working. JIRA is a tool that agile teams use to track their work. Neither of these is a complete agile transformation in and of itself, nor are they complete as a combination. Becoming agile requires these things, but more importantly, it requires the organization to change how it thinks and acts.

So, if an agile transformation is an impactful, and therefore likely expensive, change, why do organizations embark upon them? I see five significant benefits to a successful agile transformation, although these are not the only ones that exist:

1. Agile methods enable fast feedback from customers and stakeholders. Traditional methods like waterfall have a very long time gap between when a feature is requested and when it can be in the customer’s hands. In a framework like Scrum, this time gap might be as little as two weeks.
2. Related to fast feedback is enabling teams to do the right work, not necessarily more work. When you get feedback from customers and stakeholders more quickly, your teams can re-prioritize more rapidly and focus on the work that has the most value to your customer.
3. Good agile teams focus on outcomes, not just on outputs. This tends to be a difficult mindset shift for even the most mature organizations. While objective measures like velocity and say/do ratios are important, it’s far more critical to measure the impact a team’s work has on the customer. A good agile team can use OKRs (Objectives and Key Results) or business value scoring methods to measure themselves against their planned outcomes in addition to their objective metrics. For example, a team delivering ten features per quarter might seem high-achieving, but if 6 of those features are not valuable to any customer or stakeholder, are they high-achieving?
4. In a well-managed agile organization, Agile teams can more readily give feedback on vision & priorities up to leadership. Whether via events like big room planning or team-of-teams retrospectives, an organization that is agile from top to bottom makes time for listening to those at the lowest level of the organization. Often, these people have some of the most direct contact with the customers or the product’s inner workings and can have insights that will be lost unless space and time are provided to capture them.
5. Agile teams focus on sustainable development pace and avoid the release “death march.” I spent over ten years as a program and project manager for various software teams before I learned about agile. Almost every project I was involved in had a similar lifecycle: kick off the project, work on lots of code, realize we’re behind schedule, work harder, cut back on testing, realize we’ll need nights and weekends to hit our newest release date, work even harder, finally release something. After several months, the team would usually need some kind of break before getting on the hamster wheel again. Agile teams don’t do this. A fundamental principle underlying the agile manifesto is that teams should work at a pace that can maintain indefinitely. Heroics to meet release dates are not something to be celebrated but should be inspected so the organization can determine how to avoid them in the future. You can read more about the agile manifesto here: agile manifesto here.

You may be thinking, “Great, but you still haven’t told us how to be agile!” Every organization is different, and context is key to successful implementation. However, I think the following statements are good things to think about as ways to check on your transformation.

• Agile is a mindset, not a methodology.
• Scrum is a framework that reinforces the Agile mindset.
• If you aren’t collaborating, you aren’t being Agile.
• If you aren’t delivering value in short increments, you aren’t being Agile.
• Lean thinking can enable better Agile practices.

When in doubt, go back to the principles behind the agile manifesto and ask if your organization embodies them. If not, what can you change to bring your teams closer to doing so?

The Twelve Principles of Agile Software (according to the Agile Manifesto)

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on becoming more effective, then tunes and adjusts its behavior accordingly.