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!
