It is amazing just how far I have come in providing value from what I do as an IT consultant.  I started my career as a Nuclear Engineer.  So I was trained to design, plan, and document everything I did.  As I transitioned into software development, I naturally gravitated toward those same disciplines.  I found comfort in techniques that supported my training such as Unified Modeling Language (UML) for documentation, up-front system analysis and design, Gantt charts, and change control.

Besides my engineering background, I was also driven by the well-documented industry belief that the cost of change increases exponentially over the course of a project (McConnell, 1998, p. 29).  Therefore, as a software development manager, the various software development life cycle (SDLC) procedures that I created followed a very Waterfall approach that included code freezes and change control boards.  My intent behind these processes was to have a very defined and repeatable process in the guise of the capability maturity model (SEI, 1994).

Throughout my IT career, I continued to believe that this rigid Waterfall approach was necessary to minimize the cost of software projects.  That is, until I was given an opportunity to be a member of a project team that was going to try an agile process.  This agile process was called “Extreme Programming.”  Because of my background, I was hesitant to think that this agile process would work.  But I went into the project with an open mind, and came out of it a firm believer that agile software development had potential.

And then I looked at the numbers.  Our most recent Waterfall project of similar size had over 1,000 defects and delivered late.  Yet our agile project went to production with only 10 defects and on time!  To be honest, I don’t think I would have believed it if I hadn’t been a part of it.  It convinced us to start using agile software development for all our projects.

Participating in this agile project taught me what the Manifesto for Agile Software Development (“Manifesto”, 2001) says: value individuals and interactions over processes and tools; value working software over comprehensive documentation; value customer collaboration over contract negotiation; and value responding to change over following a plan.

And I have never looked back.

Software Engineering Institute, Carnegie Mellon University. (1994).  The Capability Maturity Model: Guidelines for Improving the Software Process.  Reading, MA: Addison Wesley Longman, Inc.

McConnell, Steve.  (1998).  Software Project Survival Guide.  Redmond: Microsoft Press.

Manifesto for Agile Software Development. (2001).  Retrieved from http://agilemanifesto.org/