700

by Henry Hwangbo, Guest Author

Agility is a term that is applied to everything from sports to dog shows, and everything in between.  More recently, agility has been used to describe engineering methods, including software.  In the mid-1990s, “lightweight” software methods gained some traction, aided in part to the growth of object oriented analysis and design.  Finally in 2001, the term agile was ratified as a software development approach and described in the Agile Manifesto (and Dilbert).

During the last 18 months, I have talked with several companies who are looking to become more cost efficient in building software.  Many IT leaders are asking if an agile approach is a possible avenue.

In my experience, the types of resources available and the system environment should have more impact on your choice of methodology over the type of project.  For example, I find agile great in concept, but tough in implementation, unless you have most of the following:

1. Little or No Mainframe Development - has anyone tried to do agile with COBOL batch programs and 3270 screens or no UI at all?  How do you get the business folks to validate the business rules?
2. Rock Star Developers - not all developers are created equal and it’s very difficult to find good developers, much less get them all on one project
3. Small Teams (both technical and business) - if you need to coordinate 80-100 people (and get them to agree to a direction) because of the systems/business involved you can call it agile, but it’s not agile
4. Business Folks Who “Get It” - business analysts that come from the waterfall world will try and define every single requirement to the tenth degree
5. Green-field Development - it’s much easier to do agile if you do not have to worry about integrating with existing systems; the less dependencies, the better
6. Project Managers Who “Get It” - planning, dependencies, and issue/risk prioritization are different depending on the SDLC methodology; “status updaters” and “process bots” need not apply.

From a purely theoretical standpoint, agile (and other) iterative methodologies will win.  The better question to ask and answer is:

“Is an agile method realistically feasible
given our current set of IT capabilities?”

That means understanding the people, technology, and processes and either selecting the methodology to fit those factors or changing the factors (e.g. hire agile developers - don’t use in-house developers)  and project (e.g. remove dependencies on mainframe systems, reduce scope to a single business unit) so it’s easier to build in an iterative/agile fashion.

700