Whether it is in software development, business analysis, portfolio management or business strategy, everyone wants to be Agile - and nobody wants to admit they aren't Agile. But what does it really take to be Agile? What is the state of Agility like?
First things first, lets get a grip on just what we mean when we say Agile. There are, at least, three different things people talk about when they talk about Agile.
There is the Agile toolkit, that is, the tools, practices, techniques and routines which can help you do a better job. The toolkit is, currently, largely comprised of tools that help you develop software. It contains things like short time-boxed iterations, daily stand-up meetings and frequent planning meetings for project management; test driven development and continuous integration for software engineers; and user stories, feature injection and last-responsible-moment for analysts.
Building on the toolkit are the Agile methods: Scrum, Extreme Programming, DSDM and the new kid-on-the-block Kanban. The methods are prescriptions of how to do things. They draw on the toolkit and add examples, case studies, certificates and the like. Using an Agile method, we are told, will bring about the State of Agile.
Which brings us to the third thing we mean when we talk about Agile: the State of Agile. This is were we, or our employers, want to be. Being Agile implies we are quick on our feet, we can respond to change quickly, we can deliver quickly and seize opportunities. Its not just about speed, although speed makes a lot of things easier; its about delivering what people want, when the want it, where they want it.
This then is out objective: Agility. Using Scrum or DSDM, holding stand-up meetings or writing User Stories are not ends in their own write. They are techniques and practices that have been observed to help organizations achieve Agility.
There are times when we as individuals and as organizations are responsive. If being Agile is somehow different then it implies consistency. One swallow does not a summer make, one act of fast response does not prove Agility. Being Agile has to mean a pattern of being responsive, and fewer, if any, instances of unresponsiveness.
So, given all the hype around Agile where can we find it? To paraphrase the cyber-punk author William Gibson "Agile is already here, its just unevenly distributed."
Being Agile isn't easy, it takes more than sprinkling the Agile Fairy Dust on your team, or using the right buzzwords. Like most things worth having, it takes some effort.
Small companies find it easier to be Agile by their nature. Increasingly larger companies contain pockets of Agility but it doesn't exist across the board. Many of these pockets are isolated.
The London Business School Professor Donald Sull has suggested there are three dimensions to Agility: Strategic, Portfolio and Operational. Most of today's discussion around Agility, particularly in the technology space, relate to just operational Agility.
Today's Agile tools allow opportunities to be spotted sooner and acted on quicker. For many companies that is enough. After all, one doesn't need to be the fastest animal in the jungle, just faster than your competitors, and faster than those who would eat you.
Even these operational tools offer the promise of more. Unfortunately Agile teams can find themselves in difficulty when the wider organization isn't Agile. Teams that could seize opportunities and satisfy customers better find that the annual planning cycle and budgeting rounds are not a good fit for Agile.
This is where Portfolio Agile comes into play. In a world were Lehman's Brothers disappeared overnight, where credit markets froze solid in a few days and volcanic ash brought an industry to its knees it doesn't make sense to decide your projects in September, provide budget in January, start them in February and spend the rest of the year force them into an artificial timetable.
Agile practitioners know this because Agile is empirical in nature and feedback driven. Agile practitioners don't claim to know how long X will take at the start, set them a deadline and they'll sure as hell try and meet it but they've wont predict until they have data.
Portfolio management - and governance for that matter - need embrace some of the Agile tools themselves. Regular reviews, small amounts of money given out when requested and work redirected when the benefits don't show.
Obviously this is going to effect, and be effected by: Strategy. Ask yourself: do you want to be an Agile company? Is Agile your strategy? Or just a means to an end? Are you prepared to do things different to be Agile?
Actually, Agile and modern business strategy are a pretty good fit already. Many strategists gave up on long range planning and five year plans a while ago. Strategists have long known strategy is only part planned, it is also part emergent, the result of learning and feedback.
Still an Agile strategy needs to be turned into action - talk without action doesn't get you very far. Broadly speaking strategy is turned into action through two routes: the operational decisions that are made day-to-day, and the structure and form of the business.
Successful strategy execution depends on thousands of small decisions made every day by employees at all levels in the organization. The Agile way is: fail fast, fail cheap; be prepared to try something, take a risk, see how it goes, if it works do some more, if it doesn't then stop doing. Remember: Agile is empirical, try something, see what the result is, adjust.
Which conveniently brings us back to form. If you are going to build something to see if they come you need to structure your teams so the team is responsive and responsible. The team needs to be equipped with all the skills it needs: builders, analysts, and everyone else to do end-to-end work. Fail cheaply also means the teams should be minimally staffed at first and only grow with success.
Agile strategy without Agile delivery might work, but it could be very expensive. If your strategy isn't Agile then there might still be tools in the Agile toolkit to help you do it, and some of the methods may help delivery. Agile methods can be used to cut costs but that won't make you Agile, it will only make you cheap.
As more and more companies want to be Agile the question that becomes more and more important is "Why do you want to be Agile?" which is another way of asking "What do you want Agile to do for you?". Only when you understand that do you really know what your objective is.
Author: Allan Kelly, Software Strategy
Allan Kelly is a Conference Speaker for the Business Analysis Conference Europe 2010.
He will be presenting the following session: “Objective Agility: What does it take to be an Agile Company?” at the conference.
Allan Kelly helps companies and teams adopt and deepen their Agile practices. His focus is on the management of software development work, including business analysis; product, project and change management, and business strategy alignment. He is the author of "Changing Software Development: Learning to be Agile" and is currently working on a book of business strategy patterns for software companies.
Article photo © Sylvie Thenard - Fotolia.com