The silly hat method

By Andrew Clifford

Every day at precisely 10am, gather your team. One by one, ask them to put on a silly hat, hop on one leg, and say in a squeaky voice what is their single most pressing problem for the day.

I am sure this method would work. It would provide a forum for communication. The silliness would make it less threatening, and easier to bring up difficult issues. Hopping on one leg would stop the meeting going on too long. It would save time because you would not need written progress reports.

Our IT methods are full of this sort of thing. Our methods work, but they contain a lot of embellishments that are basically unnecessary. You do not have to wear a silly hat to have regular, open, team discussions.

There are many dangers to embellishing our methods. We focus on the embellishments too much, we build bureaucracy around them, and reapply them inappropriately in other areas. But the biggest problem is that it stops us understanding the essential parts of the method.

Our method above would gradually be corrupted. Before long, the only things that people would remember are that you do not have to report on progress, but wearing a silly hat is a good idea.

I have seen this with agile methods. People have walked away with the message "we do not need proper plans and designs", and a with a vague notion that something called a SCRUM meeting would make it all better, if only they had the time to do one.

To avoid these problems, we need to think about the defining characteristics of the method. But there is a catch here. All methods provide defined processes, and encourage good organisation and communication. These are very important, but they are not defining because every method has them in some form.

We need to understand the theories about how the method works, and ways of working based on those theories.

Agile methods contain a lot of good stuff about process and organisation and communication, and there is a huge value in following them. But what are the essential concepts and techniques that make agile methods different, and that must be followed to gain most value? I can think of a few.

• It is hard to understand requirement before the solution is built. Deliver small increments frequently to gain a better understanding of requirements.
• Meeting core requirements and timescales is critical. Let the detail of the solution evolve around these, rather than specifying everything in detail up front.
• There is much more in IT that we could do than we need to do. Focus on the development of the required solution rather than on formalities of the process.
• IT is a detailed and skilled activity. Empower the people actually doing development work to make decisions about the process and product.

I have probably missed some. The important point is to be able to characterise the method by theory and technique, not just by the overall process and the more exotic elements like SCRUM meetings. You have to fulfil the essential characteristics of the method to get the benefits of the method. Otherwise you are in danger of hopping around looking silly.

Subscription