Agile Software Development Overview

Book cover for the Agile Samurai

Last month I read a classic text on agile software development called The Agile Samurai: How Agile Masters Deliver Great Software by Jonathan Rasmusson.  This book is required reading for all team members in our organization.

When my teenage son (an aspiring software engineer) asked me what the book was about, I told him about how we used to develop software using the traditional or waterfall method, which was a linear approach where each stage of software development works in isolation from the other stages, and one stage is generally completed before moving on to the next stage. The Agile Samurai groups the traditional development stages as follows:

  • Analysis
  • Design
  • Code
  • Test

In contrast, Agile software development breaks down the project into smaller “chunks” and the development stages run continuously throughout the project for each component being delivered. The Agile Samurai defines these “Three Simple Truths:

  1. It is impossible to gather all of the requirements at the beginning of the project.
  2. Whatever requirements you do gather are guaranteed to change.
  3. There will always be more to do than time and money will allow.”

Reproduced with permission from The agile samurai: how agile masters deliver great software. 10 (2010).  Copyright 2010 The Pragmatic Progammers, LLC.

To explain these concepts to my son in another way, I told him a story about when I was pregnant with my firstborn child, his oldest sister. I compared my firstborn child to a “project” that I was delivering, which required the phases of development to be slightly re-ordered as compared to software development.

My firstborn child project started with the design phase of the project, which occurred upon conception.  The design phase was followed by the development phase – that occurred in utero.  The test phase came next.  Testing had some overlap with the development phase and drove the analysis phase of the project.  The test phase included a sonogram during the 16th week of development, and determined a baby boy was on the way on or about August 12th.

That testing feedback helped us derive the following project requirements:

  • Expected date of delivery of male child: August 12th
  • Expected equipment required
    • It’s a Boy! – yard sign
    • It’s a Boy! – birth announcements
    • Crib
    • Diapers
    • Diaper Pail
    • Boys’ room décor
    • Baby boy sleepers
  • Parental agreement on boy name

Although there are many benefits to Agile development, one important benefit is the ability to change your plan when reality calls for a change.  As Jonathan Rasmusson put it, “…when reality messes with your plan, you change your plan—not reality.” (p. 5)

When the development phase of my firstborn project was completed (I delivered a baby a week later than expected), the testing phase began with the obstetrician’s announcement: IT’S A GIRL!

And that’s when we embraced simple truth number 2 in our family life: whatever requirements you do gather are guaranteed to change.

At inQbation we embrace the agile development methodology in almost everything we do. We are certified scrum masters (CSM) and certified product owners.  Contact us at results@inqbation.com and let us know how we can earn your business.

Liked this post? Follow us on Facebook and Twitter for the latest posts, news, and tips!

Tagged under:

Leave a Reply