Sunday, September 22, 2019

How do I know if I am successful in Agile?

In Agile, Working software that meets the Customer's needs, is the primary measure of success.  There are several principles of Agile, that support the Agile Manifesto, that focus on this:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Each of these principles speaks to certain aspects of the development process.  Each has its own bearing on the finished product.  Satisfying the customer's needs is the ultimate goal of any project. An Agile approach to this helps to ensure that the needs are met by allowing the customer to see what is being developed along the way and to provide valuable feedback. 

Since the overall project is being broken down into small pieces it is much easier to adapt to changing requirements.  By not spending a huge amount of time and effort in trying to create the entire software solution before finding out if it meets their needs, any changes are much less costly and much easier to implement along the way.  In traditional project management if you are creating the detailed plan at the beginning, you run the risk of not knowing what you don't know and completely missing the mark after investing a large amount of time, effort and resources. Agile reduces that risk significantly because you don't try to plan what you don't know.



Thursday, September 19, 2019

The 12 Principles of Agile Software Development

The Agile Manifesto is a succinct philosophy designed to allow teams to effectively deliver value to an organization and it's customers.  It is based on 12 Principles which guide the team and organization to meet its goals. 

According to Agile Manifesto website (agilemanifesto.org):


Principles behind the Agile Manifesto



We follow these principles:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity--the art of maximizing the amount
of work not done--is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

 As you can see the true measure of success is the delivery of working software that meets the customers needs. Continuous feedback and adaptation is a key to meeting those needs.

I will be exploring each of these principles in future posts.

Monday, September 16, 2019

What is Agile?

Many companies are talking about being Agile but there is a question most people have is 'What is Agile'? According to the AgileManifesto.org, Agile is a software development philosophy that was defined in 2001 when a group of developers gathered at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah and created the agile manifesto to wit:

Manifesto for Agile Software Development


We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

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


That is, while there is value in the items on
the right, we value the items on the left more.
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas



© 2001, the above authors
this declaration may be freely copied in any form,
but only in its entirety through this notice.


What does this really mean? Does it mean that there is no plan? that no documentation is required? that processes and tools don't matter?  Not at all.  These are important but not as important as their counterparts - Responding to change, working software and individuals and interactions.

Let's look at these individually.  The first is Individuals and Interactions over processes and tools.  What they are saying is that in order to effectively collaborate and meet the customer's needs, we need to interact with others in a positive way. The idea is that we shouldn't get hung up on the processes and tools to be used, rather talk to people and value their input.  Diverse viewpoints help to strengthen a team as long as the teams values the individuals and listens to them.

Working Software over comprehensive documentation. Here they are saying that the focus on the team should be to create working software without getting hung up on documenting everything.  That's not to say that some documentation isn't important, just that the working final product is more valuable than volumes of documentation.  The documentation should be enough to explain the logic and choices so that a future team needing to revise the software can easily understand the choices made.

Customer collaboration over contract negotiation.  This one is a little trickier as it values working with the customer and getting their input as the software is created.  The idea is to not have to have everything go through lengthy negotiation and formal change orders.  That's not to say that some negotiation isn't needed, but that it shouldn't be seen as a battle to be won or lost.  The end result should be something that both sides feel good about and that they had input into. Too often the contract negotiations seem to turn the developers and the customer into adversaries instead of allies. It is much easier to work with and ally and value their input than it is to work with someone seen as the enemy.

Responding to change over following a plan.  This is a big one that can get out of hand rather quickly.  The idea is that we recognize that we know very little about the final product and how to get there at the start of a project. In traditional project management this is when we would lay out the entire plan and then try to stick to it, even though we really didn't have a lot of information as to whether it is right or not.  This can result in a lot of wasted time and effort building the wrong thing because you won't know it is the wrong thing until very far down the road. In agile the feedback loop is very short and allows the team to present something to the customer much sooner and with much less time, energy and money invested to find out if they are going down the right path.  Frequent inspection of the product and solicitation of feedback is key here as it is much easier to affect change early than late in development. There is still a plan but it is more flexible and able to adapt.

Along with the manifesto they put together 12 principles of Agile that are distilled into the manifesto. I will cover these in the next post.