There are many misconceptions about what Agile means. Here are a few of the most common that I've heard:
- Agile is a development methodology. Well, not really, but there are a group of methods that can all be considered Agile.
- Agile is the same thing as Scrum. They are not one and the same. Scrum is one of the best-known and widely-used Agile frameworks, but there are other frameworks that are still considered Agile.
- Agile is a free-for-all way of developing software. Nothing could be further from the truth. Done right, Agile provides the basis for some of the most disciplined software delivery practices available.
So then, what is Agile?
So when you're considering your process or framework for delivering software, prioritization of business needs, how to build compliant products, how to organize product releases, how to organize your teams, how to incentivize your teams, or how to fund the initiatives, just look through your Agile lens, and the decisions you make and actions you take will all be focused on maximizing business value delivery.
Let's make this more real with some examples. When we review them, we'll look at the world much like your last visit to the optometrist, where she asked repeatedly, while flipping different lenses in and out, "With or without?"
Example # 1: Your last software release went into production with a big requirement missing.
- Without the Agile lens: You perform a thorough review of your entire software development life cycle process; identify every gap where requirements might not be properly documented, coded, or tested; and then add an extensive, multistep review process to triple-check that every requirement is traceable.
- With the Agile lens: You hold retrospectives at the team and release levels and determine that you should have more frequent collaboration sessions between the business and IT teams during the sprint. The entire team, business and IT, now have skin in the game to make sure the product delivery is as intended.
Your Agile lens lets you see that "customer collaboration over contract negotiation" (Agile Manifesto) is the clearer path to business value delivery.
Example # 2: A late-breaking requirement with relatively small impact is revealed with four weeks to go before the scheduled release.
- Without the Agile lens: The change-management committee will meet to review the new requirement and determine whether to delay the release or continue it without the new requirement being addressed. Given all the impacts at this late stage of the release cycle, no one can see any way to get this new requirement done in time for the release.
- With the Agile lens: The product owner and the rest of the sprint team will meet with the customer to review the new need, quickly develop a user story with appropriate acceptance criteria, estimate it, and then accept it (because it is relatively small) into the next sprint that starts in a few days. The team expects late-breaking changes and is always working to make the business successful.
Your Agile lens lets you see that "responding to change over following a plan" (Agile Manifesto) is the clearer path to business value delivery.
Example # 3: It's April, and the marketing department wants a six-month warning (OK, they really want a commitment) on all feature-function coming in the late fall release (seven months from now).
- Without the Agile lens: The team will perform extensive analysis on the feature set targeted for that release, trying to determine which features will make it into the release. The team has been burned before when it promised too many features; therefore, it will undercommit to make sure it doesn't repeat another miss. Given all the slack from the undercommitment, the team will fill the time with non-value-added activities rather than push to deliver more. The pace of development will heighten as the deadlines for the release approach.
- With the Agile lens: The sprint team will collaborate with marketing and explain why smaller, iterative deliveries will get them some features earlier. Additionally, they will all discuss which marketing activities are requiring longer lead times, which features are critical to the market, and then work together to determine ways of shortening these lead times through collaboration, lean planning, and prioritization of key feature sets. The sprint team commits every two weeks to what it can accomplish in the next sprint. Marketing gets a clear view every two weeks of real, working software. The team members are familiar with the two-week cadence and what they can accomplish in that time frame without killing themselves.
Your Agile lens lets you see that "Agile processes promote sustainable development" (Agile principles) is the clearer path to business value delivery.
So the next time you ask yourself, "Is this Agile?" put on your Agile-colored glasses and view your next decision or action and whether it would stand up against the Agile Manifesto, Agile principles, and lean principles, and whether it's focused on maximizing business value delivery. In fact, I would highly recommend that you outfit everyone in your organization with a set of Agile-colored glasses.
This blog article "Seeing the World Through Agile-Colored Glasses" got published on Scrum Alliance. This is my take on trying to explain what agile really means. Thinking about agile as a lens for seeing the world, making decisions, and taking action. Take a look!