Is Your Cloud Project Ready to be Agile?
Agile development and the cloud are like hand in glove. But Agile can be dangerous if your organization isn't ready for it. Here are some questions you need to consider to determine if your IT organization is seriously ready to implement Agile.
Tue, February 21, 2012
CIO — In the decade since the Agile Manifesto, the movement has encouraged a number of best practices like test-driven development, user-centered design, iIterative development, clean code, refactoring, continuous integration, and—arguably—cloud computing. I'm a card-carrying Agile zealot, and to me its benefits are unarguable. (Although here's a great spoof site that does argue against it.)
There's a catch, though: not every IT organization can really implement Agile, let alone profit from it. There are organizational, project, and personnel characteristics that can make Agile downright dangerous. The awesome price of freedom is that you have to live up to its obligations.
Is your IT organization ready to be Agile, seriously? Score yourself on these questions:
• Is this the right project? Be discriminating about where you apply Agile, as certain projects just fit better. For example, if the project has a lot of code that was developed using waterfall methodologies or is inextricably bound to tools and infrastructure that can't be modernized, you should do your learning elsewhere. If the project by its nature must be released as a "big bang" or slash-cut deployment, you'll need to have a very experienced Agile team.
• Are the expectations for UI functionality and schedule reasonable? You can't design a good UI with a gun to your head.
• Is this the right project, revisited? Is the project already in trouble? Does it have achievable goals? Is the project late, already over budget, and mired in politics? Take a pass on Agile until things are in balance.
• Are these the right users? Agile projects demand a lot from team members, and that goes double for the internal users who are on the team. Are the user representatives flexible yet consistent, well informed yet willing to learn new habits, energetic without the need to throw their weight around? Do the user representatives actually know the business process, and don't have to guess "how would this work in the business?" Do they have an inherent sense of what is technologically within reach given your budget and schedule? Are they personally investing their time in the team's success, or are they likely to point fingers? Think Disneyland: Users must be at least this mature to ride the Agile roller coaster.
• Can the focus stay on business value? Agile deliveries mean doing something small and meaningful and valuable, and doing that fast. Over and over again -- to deliver the most valuable things first and to build trust. If your company uses terms like requirements document, cost per function point, or defects per KLOC, Agile is going to be a rough transition.
• Does upper management really get it? Some Execs can't stop from "helping" -- scrutinizing weekly progress reports, asking who's assigned to specific tasks, demanding schedule updates mid-iteration, celebrating hoped-for success before they're delivered. They may also think Agile just means they can ask for more features at any point in the project without consequences. Dilbert has a great series on this topic: if you see the boss here and particularly here, you might not want to push Agile quite yet.
