Wild Apricot Blog

View: Tags | Archives

Top Five Reasons why Agile Methodology is important for non-profits

Lori Halley 25 July 2007 2 comments

For the first time, I am participating in the Nonprofit Blog Exchange developed by Emily Weinberg. In this round, I have the pleasure of being paired with Michael Stein's blog. I'm a regular reader and subscriber to his blog and always find it valuable. Every article points to information that informs readers about some of the social, cultural and organizational issues we face and impact IT decision-making.

A recent blog entry noting the importance of agile software development for non-profits caught my attention. I particularly liked his reference to Agile methodologies:

"Agile development recognizes that the road is going to bend - indeed it is rarely going to be straight. So agile methods stress responding rather than controlling."

The topic of Michael's post couldn't have been better, since we use Agile ourselves and engage in it on a day to day basis. If you're not familiar with the term, Agile is applied to a number of software methodologies which apply effectiveness principles to software development. In 2001, the Agile Manifesto was created, widely regarded as the definitive guide of agile development and principles.

So who's using it and what does it have to do with non-profits? The following are some ideas why, in our opinion, Agile Methodology is important for non-profits:

1. Non-profits are always short on human resources - so a proper software can make a huge impact on them, much more than on a regular business. Businesses can hire new people and train them whereas non-profits have to make do with what they have. Agile software development is more effective for any business period, but for non-profits the impact is multiplied.

2. Many non-profits select software without defining their needs first (they do not know - do not have resources or time to define that). In this case going with the simplest possible solution is the best approach (instead of falling for a slick software demo), which is exactly what Agile is about: the simplest thing that can possibly work.

3. Others do try to define their requirements in detail. Which quickly becomes a very expensive and futile exercise. If you do not have professional (and costly) business consultants/software analysts, there is a very good chance you will still miss out on many important details which will eventually be your downfall. And even if you do have the best resources and build the most detailed and comprehensive requirements for your software, this will not help for a number of reasons:

  • you will still miss a number of important things
  • things will keep changing on you
  • you might end up realizing that a solution for all your needs is too expensive and you will have to start over. Agile software development goes though iterations and fixed time and budget to address these issues

4. Software development is very complex. Even for the best software engineers producing estimates still includes a lot of guesswork. Best ones know that. Worst one do not fully understand it yet or might even hide from you. Agile reduces the margin of error by not trying to guesstimate the whole thing at once, just the next step.

5. Your needs and requirements will change over time (some driven by you, other by the environment - laws, regulations, industry trends). Agile software methodology assumes the ongoing change and is tailored for that.

Agile basics and other useful articles

The following links provide additional information on Agile methodologies - the key values and principles behind these methodologies:

Lori Halley [Engaging Apricot] Lori Halley [Engaging Apricot]

Posted by Lori Halley [Engaging Apricot]

Published Wednesday, 25 July 2007 at 2:00 PM


  • Wild Apricot Blog said:

    Wednesday, 01 August 2007 at 10:21 AM

    The following is a list of some of the currently most popular posts on this blog for June and July 2007

  • Agile Method said:

    Friday, 12 December 2008 at 4:28 AM

    An Agile project, by the definition of the word, is able to stop on a dime, regroup and move in a new direction as Customer requirements change.  Since the product is delivered at the end of each iteration, the Agile team expects that the requirements will change, or at the very least be refined.  This is one reason I feel that Agile development is a must for Government projects.  In many cases the end user is another group within the Agency, or even another Agency in a completely different sector.  The initial pass at requirements in a typical project is handled before the RFI ever hits the street and the team is first assembled, and many times the remote group or Agency, who is not always funding the project, is not brought back into the loop until User Acceptance Testing.  Understanding that the stories an Agile process will produce will bring all assumptions to the forefront, it may allow the original requirements to be refined immediately by fleshing out any details that may have been overlooked, thus improving the Client/Customer relationship and the project as a whole.

Sorry, this blog post is closed for further comments.

Search: WildApricot.com 

About results ( seconds) Sort by: 
Sorry, an error occured when performing search.
Scroll to top