Hawaiʻi's Technology Community

The Rise of Agile

Recently, a customer whose organization had been entrenched in using the Waterfall development model asked me what the Agile methodology is and what it is good for. I decided to post my paraphrased response here in case you find yourself needing to convince a Waterfall customer to use Agile too.....

Agile methodology is a risk-mitigation approach that grew increasingly effective in our rapidly changing times. In a traditional Waterfall model, projects had distinct phases one following another: heavy upfront analysis, requirements definition, design, implementation, testing, evaluation/maintenance. This works well in static, predictable environments. But in a world where both the business and technology landscape started changing faster, the Waterfall model was prone to several fatal flaws:

Even the best and most thought-out upfront analysis could not predict what the project needed to accomplish.
The process could not adapt to changes in needs after the initial phases.
The process could not respond to epiphanies in better approaches from stakeholders after seeing parts of the project in development.

Agile seeks to address these pitfalls. There is still some upfront analysis and requirements definition and there is still testing at the end, but what used to be distinct phases are now sort of blended into "mini waterfalls", or in Agile parlance, "sprints", running back-to-back for the project duration. The project team thinks about what should be done at the start of a 2-week sprint, does it, releases the current build it to stakeholder(s) to identify any possible issues, and iterate this way until project completion. Throughout the project, it is important not to lose the forest for the trees either, always asking if the over-arching project goals are being met. This approach provides much more transparency and control to stakeholders, and utlimately lessens risk.

Next Post >

Comment

You need to be a member of TechHui to add comments!

Join TechHui

Comment by Matthew Sacks on March 14, 2012 at 1:05pm: You might also check out http://agilemanifesto.org/ if you haven't already.

Comment by Matthew Sacks on March 14, 2012 at 1:04pm: Hi Joseph,

Project management in general was really developed for aircraft engineering, where once a design an blueprint was solidified, the work went forward to fabricate whatever it was that what was set out to build. That process worked fine for a 2 year project to build an airliner, and also worked for a 1 year time schedule to release boxed software.

Agile development sought to address this as the Web and dot com booms where software changed at a much more rapid pace due to needing to react more quickly to customer demands. Agile sought to address this faster demand to produce software by keeping releases short and concise cycles (it doesn't necessarily have to be 2 week iterations) and testing often and releasing often.

I've found that in a Web environment, an agile methodology especially relying on continuous integration works well, but it doesn't necessarily mean it will work well for everything. For software engineering that is more closely tied to the hardware (embedded systems) it probably won't work as well.

Comment by Daniel Leuck on February 6, 2012 at 4:01pm: Good question Chris. We identify the absolute minimum required for a working system and price that. Then we ask the customer how many two week sprints they would like for wishlist items (i.e. the list of features in the icebox.) The quote is base (minimum working system) X number of sprints X cost per sprint. In each sprint we do as many items in the wishlist as possible and release the current state to the customer at two week intervals. Once the customer is comfortable, assuming their organization allows it, the engagement generally converts to an ongoing time and materials arrangement.

Most new customers, especially those new to software development, are going to be skeptical at first. Waterfall is easier to understand at first. You have to sell them using prior work and references. Once they see the app evolving and how close agile keeps them to their project things become much easier. Its all about building confidence and trust.

Comment by Chris Kutler on February 6, 2012 at 6:39am: Daniel,

Can you talk a bit about how one would bid for a contract using the Agile method. How do you do an upfront estimate of the cost and the time?

Comment by Anže Žnidaršič on February 4, 2012 at 1:01pm: Nicely written.

Is there a list of software development companies in Hawaii using agile?

Comment by Daniel Leuck on February 1, 2012 at 5:39pm: Agile is often harder to sell, but once customers see it in action they never go back. One challenge I've had over the years is figuring out how to utilize agile methodology for government customers who require fixed price contracts and waterfall-like project plans (often by policy or even law.)

RSS

Welcome to
TechHui

Sign Up
or Sign In

Or sign in with:

The Rise of Agile

You need to be a member of TechHui to add comments!

Sponsors