The most common questions asked by my peers and managers regarding Agile software development is this. What is it, how can it benefit me, and how can it cut my costs down?
So what is Agile Software Development?
Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. The term was coined in the year 2001 when the Agile Manifesto was formulated. – Wikipedia on Agile Software Development
What this means is this. The Agile methodology allows for the design and construction of software to be more nimble and accepting of change. As requirements change, people change, or business needs change over time, the team can refocus it’s effort on a new goal, more aligned with the strategic plan of the organization. Like a military unit in war, when the general says march to point A initially, but then when you’re half way there, says march to point C instead, this methodology allows for development teams to have the flexibility to operate in the world in which businesses operate today. It’s hard to plan 12, 24 or even 36 months out, because in most instances knowledge of what business environmental factors will be in place that far out is so unknown.
There are many specific agile development methods. Most promote development iterations, teamwork, collaboration, and process adaptability throughout the life-cycle of the project. – Wikipedia on Agile Software Development
When we describe teamwork during an Agile methodology construction, we do not just mean the teams of developers and their project managers. We also mean the stakeholders, and the end users as well. Constant feedback, and involvement from these people, the key consumers of the end product, will help the development team drift closer to a successful, useful, and better aligned system.
What about costs?
Costs are a little different for the Agile methodology. One must not think in terms of long term project costs, though this is somewhat important, but the cost it takes to build each component, and if it is better to spend money one step at a time, with concrete results or simply write one big check and wait. The difference between Agile and Waterfall regarding costs, have to do with what needs to be asked for up front. The typical Waterfall project will go through these steps; obtain a general idea of how long the project will take, and projection of costs. Go ask for funding. Start the project by doing a requirements gathering. If this changes the length of the project go ask for more money. If money is granted, then the teams begin the process of design, implementation, verification, and maintenance. At any point in time, if the team runs out of funding, they will go with hat in hand and ask for more funding. Each time funding is requested, the requester has nothing to show for the other monies that have been spent, except to say we are making progress. Often times a project plan will be used to illustrate progress, which will represent a virtual set of goals, with graphs showing estimated tasks, and percentage completion This is a lot different than building a house or a car or a bridge. A consumer of these products can see and touch them so even without being an engineer of any kind, they can make a judgment about progress. If a bridge is half done, the consumer knows it’s not yet safe to use, but it looks like it’s half done. If a car doesn’t have it’s engine yet, but it has a body, and 4 wheels and a steering wheel, consumers know this car can’t run but the construction teams are making progress.
In software development a stake holder needs to see screen, flow of data, or movement of parts to feel as if progress is being made. Agile unlike Waterfall lends itself to this, by breaking the project down into iterations, which involve creating a concrete benchmark that will be achieved within the given time line, then acting upon that. At the end of each iteration the stakeholders and end users can be shown real progress. If the end result does not meet the new business reality, because the iterations tend to be short lived time frames and tackle small chunks of the overall system, it’s very easy to adjust the iteration’s work product.
The Agile methodology allows for project finalization to occur at the end of any iteration. But unlike the Waterfall method, at the end of each iteration you typically have a working product. It might not be what was originally envisioned, but it is never the less a working system. This allows the stakeholders to choose between funding additional work or going live with the product as it stands at the end of the iteration. That flexibility is key to controlling costs with Agile. I believe it’s better to allow your customer (and stakeholders are our most important customer) to be free to make that choice.
So if you’re a consulting organization, how can this work?
To be continued….
