Home
agility

Overview

Software development methodologies have been with us for a long time now. These methodologies typically tend to include a process, modeling techniques, or both. Some examples of the past and present methods include Structured Systems Analysis and Design Methodology (SSADM), Object Modeling Technique (OMT), the Rational Unified Process (RUP), and many others. Recent studies have shown us that the traditional approach of doing big requirements up front (BRUF) or big design up front (BDUF) using a waterfall approach such as SSADM not only can result in a significant waste of time and effort but also can cause many software developments projects to be challenged and/or fail entirely.

The Problem

In the past, many projects have approached software development in a serial fashion, that is, completing each phase of a software development lifecycle (e.g. requirements, architecture, design, coding, testing) in its entirety before moving on to the next phase. Furthermore, many of these projects estimate the time frames to complete a project based on these big, up front efforts, which is similar to looking into a "crystal ball." To make matters worst, most organizations attempt to keep the big documentation (produced up front) up-to-date throughout the lifecycle but are almost never able to keep it current, as the project progresses. This method of working results in failed and/or challenged projects, as reflected in the following diagram from the Standish Group International, Inc. (standishgroup.com):


source: standishgroup.com

The Standish Group further claims that the larger a project gets, the higher it is at risk of failing as reflected in the following numbers.


source: standishgroup.com

Furthermore, many applications build in features, which are either never used, rarely used or only sometimes used (as shown in the following graph); needless to say this results in more expensive software and wasted efforts:

One Possible Solution: Agility

According to the Standish Group, the top ten factors for a project's success are:


source: standishgroup.com

Note: Most of the stats provided in this document are taken from the Standish Group International, Inc (standishgroup.com). Although these are taken from one source, they match what I have experienced over my 20 years in Information Technology (IT).

Many of the problems outlined earlier in this document, can be solved using newer, truly iterative style, methodologies.

In 2001, seventeen methodologists came together to unify their methodologies under one umbrella – they jointly defined the term, Agile (agilemanifesto.org, agilealliance.com). The remarkable thing about this event was that these seventeen methodologists agreed on a common set of principles (see story at http://martinfowler.com/articles/agileStory.html).

Some of the underlying values of the various Agile methods include:

  1. Be customer focused - In short, satisfy the customer. Develop only what is requested, nothing more, nothing less.
  2. Embrace change - In today's fast paced world, change is bound to happen. The user should be able to change the system (they are paying for it). So, it is better to accept this fact and embrace it.
  3. Iterative development - Develop working software in small chunks (e.g. 2-month major release with 2-week iterations resulting in production-ready code). Favor building software in increments with continuous enhancement (via refactoring) versus big requirements/design up front (BRUF/BDUF).
  4. Motivated people - Build projects around a motivated staff; give them the environment and space they need to get the job done.
  5. Communicate - this is the key to success and accordingly users, developers, testers, and other stakeholders must communicate well. Also, favor face-to-face communications (versus emails, for example).
  6. Measure of progress - Use working software (code, database) as measure of progress versus documentation and project plans.
  7. Sustainable development - Project stakeholders (users, developers, testers, etc.) must be able to maintain a constant pace of software development (see iterative development above).
  8. Simplistic elegance - Favor high-impact business features versus over-engineered or cool technical solutions.
  9. Continued efficiency - capture lessons learned, good design, best practices, templates, checklists, glossary, etc.

My Perspective

In my opinion, which is based on the Agile values mentioned above combined with many years of experience in IT, some current issues with software development include:

  1. Big requirements up front (BRUF) and big design up front (BDUF)
    • The idea of getting all the requirements done up front (waterfall method) and locked down is insane and an archaic style of developing software. Some release level requirements should be done up front, the remainder (more detailed) requirements can be obtained at the beginning of an iteration in the form of acceptance tests (which are incidentally coded into unit tests).
    • Similar to BRUF, trying to get all the architecture and design done up front is unreasonable because you will invariably discover better ways of developing the system at hand once developers begin coding. Some architecture/design in Cycle 0 (Jim Highsmith) is a good idea but it should be kept to a minimum, requiring minutes to hours of discussion depending on the complexity of the system (but certainly not many days or weeks). Furthermore, keeping BRUF and BDUF documents up to date throughout the software lifecycle is a task many organizations attempt but invariably fail to keep current -- we have to stop lying to ourselves that BRUF and BDUF work!
  2. Terminology - This is a personal pet peeve of mine since I find this to be an issue that many technical people are ashamed to admit is an issue. When you have acronyms galore, redundant terms (e.g. store, persist) or ambiguous terms (e.g. pessimistic locking, immutability), it not only causes problems amongst the technical staff but also is an ineffective way of communicating with the users.

This web site attempts to address these three issues via its methodology, modeling, madness, and resources web pages.

The Agile Community

If you are interested in learning more about Agile methods and/or participating in the agile community, visit one of the following web sites: Agile Alliance, scrumdevelopment, extremeprogramming, agilemodeling, and Agile Draw.

© <%= (new java.text.SimpleDateFormat("yyyy")).format(new java.util.Date()) %> Visual Patterns, Inc. All rights reserved.