The A-Team

People tend to treat development processes like religions. There are lots of extremists.

Everywhere I have worked has taken a somewhat agile approach to delivering succesful software deployments, without subscribing to any single agile approach in its entirety.

I have found that one thing, in numerous forms, is key to the success of agile: communication.

It is important that the development team is close knit and pulling in the same direction. Regular stand up meetings help to keep everyone on track and provide the most notice of blockers and hence the most chance of avoiding/mitigating them.

It is important that customers (anyone who consumes the output of the process) have opportunities to provide input, feedback and guidance.

It is important that the documentation burden is minimal and that all documentation is clear and concise.

Communication requires dialogue. If only one side is investing in the process then it is unlikely that the information exchange will be succesful. Further more it is likely that the input will not be received in a timely manner. I know, I know, one of the principles of agile is being open to changing requirements at a late stage of development. The key word in that sentence is late, there will always be a time when it is too late. Attempting to change requirements within a sprint, whilst expecting the overall duration of the sprint to remain the same, requires a certain level of delusion.

One of the distinctions between agile and other methodologies is the emphasis on people rather than processes. The streamlined processes require discipline and trustworthy and motivated participants. Agile demands the ability of the participants to sustain a high pace whilst maintaining their focus on technical excellence. As such, holding people responsible for their actions (or inaction) is not a bad thing. After all, it is only a mistake the second time it happens, the first time it is an opportunity to learn.

To me there is nothing ground breaking here, so why do people insist on making it so complicated? I suspect it is because agile quickly highlights weaknesses. A wise man once said “A players like to work with A players”.