Agile Presentation

I attended a presentation last night by Alistair Cockburn. He is one of the authors of the agile manifesto and the presentation covered some of his latest thoughts on agile. Here is a summary of the points that I found most interesting.

Software engineering is a poorly chosen term. Software design and development is really a craft rather than an engineering discipline. There can't be a single, optimal process because software is developed by people and people are different. There are different motives, cultures, objectives, personalities, etc. that all influence how a project will evolve.

Agile is not so much a process as a set of techniques that should be tailored to fit the situation.

You can never get it exactly right in software development, but you should be constantly learning and improving. Waterfall methods are late learning. At the end of a project, you recognize things you have done wrong and that you may be able to improve next release. With agile, learning and adjustments happen throughout the process.

Process cannot fix all problems. For example, if two of the key people on a project hate each other, no process in the world will ensure that there is good communication and cooperation between them.

Large projects have large communication penalties. The more people you must communicate with, the more time you spend communicating and the less writing code or creating other deliverables. If you have two developers in a room working on a project, communication is easy and efficient. As you increase the number of people or the distance between them, communication becomes more difficult.

Paper is the most common form of project documentation, but also the least efficient. The most efficient form of communication is two people talking face to face with a whiteboard.

Distance is one of the factors that effects process. On one project Alistair was involved in, the UI designers were in Norway and the developers in China. The developers complained that they could not work efficiently because the UI designers kept changing the design throughout the iteration. The UI designers took a trip to China and then the process worked fine. They were still changing the UI design throughout the iteration, but, because they were in the same building and the same time zone, the changes could be communicated immediately and the reasons for the changes were clear.

Transparency effects productivity. The more everyone knows what everyone else is doing, the better coordinated they will all be.

Look for the bottlenecks in a project. Many people try to eliminate bottlenecks, but that is impossible. If you remove one bottleneck, another point becomes the new bottleneck. Some are difficult to eliminate. For example, maybe one job optimally requires 1.5 people, but you can't efficiently assign a fractional person. It is best to just accept that there will be bottlenecks and to make sure the bottleneck does not slow the project. For example, if database design is the bottleneck, make sure that designer has everything they need when they need it. In other parts of the process, inefficiency is not necessarily a bad thing. Areas that are not the bottleneck can "waste" some time without affecting the end date or success of the project. One way to use the extra time for people outside the bottleneck is to make your best guess and charge ahead. One one project Alistair was involved in, there were two options (A and B) and much debate and research was needed to make a decision. While that was going on, he told the developers to implement B. There was a 50% chance they would guess right. If they were right, time would be saved. If they guessed wrong, they would be no worse of than if they sat on their hands waiting for a decision and in all likelihood they would at least learn some things. When the decision came back to do B, it was already completed.

You should do knowledge acquisition tasks early in a project to reduce risk. Do the things you aren't sure how to do first. The things you know how to do you can estimate with greater confidence and they can be left to later in the project with little risk of delaying the end date.

You need to understand the business to understand how to optimize the process. When Alistair first starting to work with defense contractors, he couldn't understand why they would move key people off a project in the middle. This decreased the quality of the outcome. Most companies make money by creating the best product they can. Why purposely hurt a project by removing key people at a critical time? He came to understand that defense contractors make their money by winning contracts. They need their A team to do that. When the project is underway, the A team is better used to win the next contract while letting the B team deliver on the current one.

More information on Alistair's work is available at http://alistair.cockburn.us/index.php/Main_Page