I'm presenting at the Agile Conference 2011

I'm presenting at the Aile Conference 2011, next August, in Salt Lake City, Utah.

This is an interesting experience for me, as it is the first paper, and the first conference participation. It happened to be the best Agile conference in the world.

My paper is titled: "Process Increments: An Agile Approach to Software Process Improvement". You can browse the abstract and the conference proposal at this link.

See you there inshaAllah!

Motivating teams to pilot Agile projects

This is an excellent advice by Gerald Weinberg, in this interview. The idea is that when doing organizational change, we need some projects to pilot changes before applying then to the rest of the organization. If projects are selected by management, the project team will view it as an assignment and may not cooperate very well. This is a problem that we need to handle when working with Agile adoption projects.

Weinberg suggests an excellent technique that he used many times, and had excellent results. He builds upon the innate developers' attraction to new ideas, technologies, frameworks, etc. The technique is to announces that if any team wants to become a pilot, they have to defend why they deserve it!

Simple and effective. He says that teams argued that instead of having one or two pilots, they all want equal opportunity of becoming pilots. Far beyond what a consultant would dream of!

Patterns of Agile Adoption Failure

Many teams are trying Agile methods, or rather techniques. Many of them fail, and suffer from this failure, usually because the failure induces resistance in the rest of the organization, and makes later attempts to Agile adoption much more difficult.

The following are four patterns of immature Agile implementations, where team concentrate on some superficial agile techniques without really embracing Agile values and principles:

• Usually team starts with stand-up meetings, and it fails, because it simply hurts their legs for standing 1-2 hours daily! Moreover, the meetings are boring, and take a lot of time discussing issues. The team feels that this "Agile" thing is naive and wastes their time.
• Teams do sprints:
1. Either one complete sprint for every waterfall phase. That is a sprint for analysis, another for design, another for development, and a final one for testing. So, it simply becomes sprintfall rather than waterfall !
2. Or one sprint for every big requirement or group of requirements. The problem with this approach is that no feedback loop exists. In other words, they have split a big waterfall project into smaller ones. Just bigger management overheads
• Teams use sticky notes and decorate the walls with whatever they do, even with requirements in a typical waterfall project. After a while, they lose interest in updating the board notes. Because every step take a lot of time (2-3-weeks), and they cannot see any value of maintaining two databases of requirements and tasks (board and electronic)
• Team does everything just right, but do not take feedback from customers. Somehow better, but still waterfall in the large. Teams iterate to get feedback and to adjust their development effort along the way. If they do not get feedback, the value of iterating is not realized

These are some failure patterns, there are many others; if you have any experience with this, please let us know about it :)

Why have principles behind practices and techniques?

The answer is very simple. If you can identify the principle behind the practice, you will open the door for creativity to invent other practices which may better realize the principle!