The silly hat method

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.

© Copyright 2009 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

Ubuntu Netbook Remix

The latest release of Ubuntu for netbooks demonstrates the increasing quality and flexibility of Linux.

I have been using an Asus EEE PC 901 netbook for almost a year.

The netbook came with a tailored version of the Xandros Linux distribution. This is OK, and works very well with the netbook. But I found it hard to install all the software I wanted, and a lot of the available software was not up to date.

I played around with other Linux distributions. I tried the Easy Peasy distribution, installed on a removable memory card.

Esay Peasy is based on the Ubuntu distribution, but with a desktop optimised for a small screen. I found this much easier to use than Xandros, but I had problems with the WiFi and the built-in webcam. Over the weeks as the underlying Ubuntu updated itself, the problems with the WiFi and camera went away.

Recently I decided to take the plunge and overwrite the pre-installed Xandros with a different Linux distribution.

I looked around for the most up-to-date distribution, and decided to install the netbook version of the Ubuntu 9.10, known as Ubuntu Netbook Remix (UNR). The desktop is very similar to Easy Peasy.



Even before I installed it, I was impressed with UNR. Like many other Ubuntu installations, you can run the distribution directly from the installation medium without installing it. This let me check that all the hardware worked before I committed to the install.

If you are a Windows user, Ubuntu also has WUBI, a windows-based installer that allows you install Ubuntu from inside Windows, creating a PC you can boot into Ubuntu or Windows as easily as installing any other piece of Windows software. The Ubuntu filesystem is stored in a file in the Windows file system, so you do not even have to mess around with disk partitioning.

UNR has everything you would expect of a modern Linux distribution. It comes with all the normal applications (office, photo, messaging, email, etc), and a software centre to choose from thousands of other free applications. As well as open source software, I had no problem installing proprietary software such as Skype and Google Earth. Everything works brilliantly.

I had previously tested that it supported the hardware on the netbook itself, especially the WiFi and the webcam. But I was really impressed that it worked out of the box with additional peripherals, such as a separate webcam, a digital camera, and a network printer.

In Windows, each of these requires additional drivers. Supporting my camera is particularly impressive - unlike most cameras it does not act as a USB storage device and so requires extra drivers. UNR also correctly identified and automatically installed drivers for my network printer, which I have never managed to do before on Windows, Linux or Mac.

I am sure that anyone using recent versions of Linux has had similar experiences. Linux functionality, ease-of-use, reliability, flexibility and depth of hardware support is improving at a surprisingly rapid rate. Where will it stop?

© Copyright 2009 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

Being awesome

Who do you help to be awesome at what?

I recently read an excellent article by Joel Spolsky on figuring out what your company is all about.

In it Joel recounts some advice about presenting your company mission in the form:

• We help $TYPE_OF_PERSON be awesome at $THING

This approach is really great for IT because it so accurately describes the role of IT. The only purpose of IT is to help people do things. To deliver any value you must be able to articulate WHO it helps to do WHAT. If you waffle on about "strategic enablement" or "information is the life blood of the organisation", you have lost the plot.

I also really like the strong word "awesome". We need to up our game from "enabling" to helping people be "awesome".

It sounded like good advice, so I tried it on our own business at Metrici, and particularly on our Metrici Advisor service. It was harder than I thought, but it was a very valuable lesson.

Trying to think of WHO we help was hard. Do we help managers, consultants, businesses, decision-makers? Yes, we do, but that is a bit too broad. They do not catch the essence of who we help.

And WHAT do we help them do? Gather information, evaluate, make decisions? Yes we do, but once again that is too broad.

After a bit of head scratching, we looked at the name of our own product and figured out our mission.

• We help advisors be awesome at giving advice.

This really works for us, and it sums up neatly everything we do.

We define advice as:

• Recommendations
• Measures
• Assurance
• Evaluation
• Justification
• Priorities

The service helps:

• People who specialise in giving advice.
• Managers who advise their own organisations.
• Anybody who investigates and makes decisions, because they advise themselves.
• Anybody who takes advice.

The advice-giving is awesome because it is:

• Quick
• Rigorous
• Insightful
• Consistent
• Actionable
• Justified

This mission even helps us clarify some misunderstandings.

• Metrici Advisor is not a survey tool. If you just want a quick opinion survey, use something like Lime Survey. If you want to give advice based on information gathering, use Metrici Advisor.
• Metrici Advisor is not a process management tool. You can use Metrici Advisor to advise on your processes, or you can make Metrici Advisor part of your advisory processes, but either way Metrici Advisor does not manage the processes for you.

Clarifying our mission also clarifies which parts of the service need to be given more emphasis in our marketing:

• Reusing libraries of best practice.
• Driving out effective recommendations using the rules engine.
• Linking to background information from anywhere in the tool.
• Producing final reports directly from the tool.
• Customising the standard materials, rules, analysis and reports for each organisation.

Just playing around with a few words has really helped us sharpen our mission, and given us a powerful tool to explain ourselves to our customers and partners.

Try it yourself, for your business, your services, or your software. Who do you help to be awesome at what?

© Copyright 2009 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

Necessary complexity

Necessary complexity is a unifying principle that should underpin our IT management and design.

As you go about your work, what do you think about?

If you are like me, a lot of the time you think about the immediate task. Planning, proposals, design, programming.

But stepping back from the immediate, what sort of concepts do you use to help you think?

This is important for us in IT. IT is pure though stuff. It is an extension of our thinking selves. Like a builder uses concrete, bricks, mortar and wood, what are the mental materials we use when we put together IT solutions for our organisations and clients?

A lot of the mental constructs we use are not specific to IT. We have ways of thinking about time and money and political relationships. These are important, but they would be much the same if we were working in any field.

We also think about the technology detail. We think about how much RAM our servers need, what operating system to install, how to configure firewalls, and the syntax of the substring command. These are specific to IT, but they are not really concepts. They are just the syntax for representing the ideas we have about IT. But where do we get those ideas?

To crystallise the question, what are the mental constructs we use that are particularly related to IT and are not just the detail of the technology?

I can think of a few. Normalisation, partitioning, componentisation. These have analogies in other fields, but their meaning in IT is very specific.

But there is one concept that underpins a large part of this: necessary complexity. It is something we should always think about, something that permeates all the aspects of our IT work.

Necessary complexity can be defined as, "as complicated as it has to be, but no more". Necessary complexity is important generally, but particularly in IT because IT has both the power to simplify and the ability to confuse.

Many of the concepts we use in IT boil down to the pursuit of necessary complexity. For example, we use normalisation techniques to fully represent the semantics of data in a form that can be stored as efficiently as possible. Normalisation is a way of making data as complicated as it needs to be, but no more. Normalisation is the pursuit of necessary complexity in data design.

The same applies to IT architecture and methods. Huge frameworks have been defined for IT architecture and methods to cope with the complexity of the IT task. But these have in many cases gone too far, and there has been a counter-movement to simpler designs and more agile methods. As an industry, we are searching for architecture and methods that are as complicated as they need to be, but no more.

When we are considering what IT response is appropriate for our organisations and clients, we need to think of necessary complexity too. We need to define sophisticated approaches that meet the complexities of the requirements. But often we get carried away with the designs and technology, increasing complexity but not value. We need to take a step back, and make sure that all the complexity is necessary.

© Copyright 2009 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.