Since that time, agile has had tremendous success. However, the simple elegant words of the Agile Manifesto has caused misunderstanding and in some cases caused projects to fail.
Sometimes, folks in the agile community are our own worst enemy. Every time I hear someone say “That is not true agile” I cringe. There are also folks who are reluctant to change and feel that agile is the approach that has no documentation or goes on and on and never ends. This also gives me a headache.
So, I thought I would write some words about agile from the direct perspective of the Agile Manifesto. If we keep the overall idea these people had in mind and allow for flexibility we can increase our chances of success.
I will start with the four main points of the Manifesto. They are:
- 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.”
The phrase “while there is value in the items on the right” is often left out of our thoughts as we deliver agile solutions.
I will explore each of the four points and provide my insight as to what they mean to me.
Individuals and interactions over processes and tools
People are required to deliver software. The people who want and need the product must explain it to the people who will deliver it.
This is very hard to do. The people who need the software are overworked at their normal day-to-day job. When it is decided that a software product is required, these people must take the time to think about what is needed in addition to their regular job.
As detailed processes and sophisticated tools were developed, the focus shifted from the people to the tools and process. Vendors would sell a process or tool as a solution. All along, it was still people.
What this point means is the focus should be on the people and the communication between them. The process and tools should be the minimum needed for a given situation.
For a startup firm, building a product with a short time to market, a simple lightweight process and little or no tools may be the proper solution. Here a large whiteboard and 3x5 cards may be best answer.
For firms that are regulated and audited, more process is necessary and more formality is needed. This will be different based on the situation. An objective should be to use the minimum amount of process and tools and no more. Use just enough to get the job done.
Start with the people and then decide what level of process and tools are necessary for a given circumstance. Use established agile techniques to facilitate individuals and interactions.
Working software over comprehensive documentation
Many projects have failed that have thick binders of software requirements. This is the model for the typical waterfall approach. Under this approach, the delivery team interviews the customer and documents the requirements.
The customer is asked to read the requirements and sign off on them. Then the delivery team builds and tests the product described in the requirements.
We have learned that it is virtually impossible for a customer to document the computer system they need. If they could do this, it is likely that the needs will change between the time the requirements were signed off and the product ships.
The agile approach of building potentially shippable increments of the product in short periods of time is one of the most tangible changes and benefits an agile process provides. This demonstrates progress and builds confidence with the customer and delivery team because useful software is constantly being delivered. The customer also sees an evolving product and will notice things they never would have using a thick binder of requirements.
So what level of documentation is proper? The philosophy of agile is to do the least amount of something and no more for a given situation. A regulated industry will require much more documentation and trace matrices than an unregulated one. Agile process can accommodate this whole spectrum of needs.
Customer collaboration over contract negotiation
This is one of the most misunderstood points of agile. No one is saying that we do not need contracts and all collaboration is informal. I take this to mean that the iterative delivery approach will have a better chance of delivering a product that provides the customer with a competitive advantage than a signed contract early in the lifecycle that is difficult to change.
When we focus on a contract, we get a false sense of security and think everyone agrees to what is being done. After all, we have a signed contract–we must be okay.
In reality, we do not know what we do not know. An iterative approach is the best solution to this problem.
We need contracts, they just need to be flexible and have the proper change control built in to accommodate an agile process. There is a “sales” effort that is required to convince the customer of the benefits of a more “flexible” contract approach. We need to explain that while there will be many opportunities for change, the customer will be in complete control.
What if we are forced to do a fixed price contract? Does this mean we cannot do agile? I believe we can. Although this is not the preferred approach, agile still provides process that increases our chance for success. With fixed price contracts we need to include proper language in the change control section and include this in our process. We can specify acceptance criterion in our contract and review changes in our sprint review meetings to accommodate this type of situation.
Responding to change over following a plan
Many projects have failed that have elaborate project plans with detailed Gantt Charts. We make the plans so complex and detailed that it is difficult to modify when changes occur.
Agile process replace project plans with release schedules and burn down charts that accommodate change. We can still track progress and in fact progress is more transparent than in a typical waterfall project plan.
Agile is actively transparent. This means that the progress on the project, good or bad occurs as a result of the process. There is little need for separate updating of progress reports.
In conclusion, it’s the results that matter
The point of all of is to focus on results that add business value and competitive advantage for a firm. Of course, this was always the intention of waterfall projects, it simply did not happen very often.
All too often we focused on the process and documentation that resulted in a false sense of security and we did not communicate with the people who in the end, are the most important.
However….
There are also examples of agile projects forgetting the importance of the “Items on the right”. This is also a recipe for failure. Delivering the proper software product is still very hard. Agile does not change that fact.
Using an agile approach give us permission to lessen the need of formality but we should not forget it. We will close with one of the twelve principles of agile that is pertinent to this discussion.
Simplicity--the art of maximizing the amount of work not done--is essential.I will review these twelve points in my next few blog posts.
