An Agile Perspective Why Bother

I thought I would step back a bit for this blog post and revisit the reason why we are even doing this. Why completely change the way we deliver software?  So, in this article, we will discuss some of the aspects that make Agile successful and introduce some important ideas that are at the heart of the Agile methodology.

First, it is essential to understand that Agile, as with any methodology, is not a silver bullet.  There are plenty of examples where Agile failed.  While the essence of Agile is straightforward, the challenges lie in understanding the business need(s), sticking to the principals you believe in, being patient, and focusing on transparency, communication and accountability.

Agile Manifesto

In 2001, a group of software experts got together at a ski lodge in Utah and developed the Agile Manifesto. This group identified a short set of values that helps guide much of the agile movement.

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

They believed that while there is value in the items on the right, the focus should be on the bold faced items on the left.  Agile has gotten a bad rap for a misinterpretation of these values. I hope to help set the record straight as I explore Agile software delivery.

One of the primary pillars of Agile is to do the right amount of something, and no more.  This varies greatly based on the circumstances of a given project.  A start-up with a small budget and a short time to market will require much less formal process and documentation than a larger organization implementing a product regulated by the FDA.  Each of these projects will benefit from using the principals of Agile.

Individuals and Interactions

Many projects using sophisticated tools and processes have failed.  Much of the Agile process was designed to be implemented using 3x5 cards and a white board.  In fact, many Agile professionals prefer this approach.  By meeting regularly with the Product Owner and developing the features they want delivered in the priority they specify, we will be on a path for success.  These features are maintained in a prioritized list called the Product Backlog.  The Product Backlog is then broken down into 2-4 week Sprints.  I will talk about Sprints in more detail below in the Working Software section.

During a Sprint a daily standup team meeting is conducted every day.  The meeting is time limited to 15 minutes and focuses on reporting progress on the features included in the current Sprint.  Each team member reports what they did yesterday, what they have planned for today, and any impediments they face in completing their work on time.

The trick, as with much of Agile, is knowing the proper level of detail for your given project.

 Working Software

Agile believes that working software is the primary measure of progress and that the project owner (usually the business owner) will learn more through a set of short delivery cycles called Sprints.  Sprints are typically two to four weeks in duration and deliver the Features the Product Owner has identified.

Features are identified in a way for them to be self-contained and small enough to be completed in a single Sprint and to be Potentially Shippable.  This means that each feature is coded, reviewed, tested and deploy-able at the end of each Sprint.

This is one of the most powerful aspects of Agile.  It is very common for developers to start working on one thing, get sidetracked, and begin working on something else that is cool.  Using Agile, the team completes the features the Product Owner wants 100% in each Sprint.

Customer Collaboration & Responding to Change

Many projects that have very elaborate and long specifications, detailed contracts and project plans have failed  Experience has shown that it is virtually impossible to spend weeks or months developing long specifications and deliver what the business needs.  I was once told, "You delivered exactly what I asked for but, that is not what I need."  Even if it were possible to develop a perfect specification, it is likely that the business needs have changed since the time the requirements were gathered.

As we progress Sprint by Sprint, the Product Owner learns things they need just by seeing the product evolve.  Often we discover features late in the game that were never even considered early in the project.  As long as the new features add quantifiable business value, this is a good thing.  If we discover a set of features we never imagined and it saves our company more than it costs, we are happy.

Sometimes we actually stop development before we complete the product.  During Release Planning we carefully review the Product Backlog and deliver the high value features first.  We all know that most people typically only use a small percentage of the features in a given product.  Microsoft Word is a good example of this.

By following the rule of doing only the right amount of something and no more, we can often save money by delivering only a portion of what we originally intended.  Of course it is up to the Product Owner to make that call.

The Agile Manifesto and the simple elegant ideas it professes are the most important change to how we deliver software that I have seen in my decades of experience in this field.  I will never deliver software any other way!