Alistair Cockburn
Senior Consultant

Alistair Cockburn is a Senior Consultant with Cutter Consortium's Agile Software Development & Project Management Practice and a contributor to that Advisory Service. He is consulting fellow at Humans and Technology, where he helps clients succeed with object-oriented projects, including corporate strategy, project setup, staff mentoring, process development, technical design, and design quality. He is the originator of Crystal Light methodology and has more than 20 years' experience in leading projects. Dr. Cockburn was special advisor on project management and development issues to the Central Bank of Norway. He coordinated a critical multisite development project using the ideas he advocates: light methodology; a flexible, alert process; communication; and thinking. In the early 1990s, Dr. Cockburn designed the OO methodology for IBM's worldwide Consulting Group, which is still in use today and is applied to business process reengineering. He served on the IBM US Marketing and Services Architecture Advisory Board, for which he reviewed project plans and designs; is the author of Surviving Object-Oriented Projects; and has written papers and articles for a variety of trade journals. He can be reached at acockburn@cutter.com.

For Ralston Purina, Dr. Cockburn orchestrated project setup and requirements for a corporate project in which few of the team of 40 had object technology experience. He later returned to lead technical development, set up the process, and take responsibility for design quality. Over a period of one year, Dr. Cockburn trained and led the requirements team, the analysts, and the programmers.

The German consulting company sd&m (part of Ernst & Young) invited Dr. Cockburn to work with 10 of its senior project managers over several months to capture their experience and the risk-reducing strategies they use on projects. The strategies were captured as patterns in Dr. Cockburn's special "medical pattern" format. The captured patterns will help newer project managers learn to observe and reduce risks on their own projects.

Dr. Cockburn has developed courses in project survival, methodology development, requirements writing, OO design, and project management strategies. He has been invited to teach and talk at the Software Technology Conference, Object World, Software Development, and OOPSLA. He has taught OO concepts and design to hundreds of executives, managers, and programmers around the world. Attendees in his courses consistently give him highest grades for being a subject matter expert with practical experience, skilled in listening, questioning, and explaining.

Dr. Cockburn describes his personal philosophy as: "Computers must support the way in which people naturally and comfortably work, for job satisfaction and for corporate survival. I am committed to speeding this development by improving human-computer communication, programming methods, and development tools." He can be reached at consulting@cutter.com.



AGILE IS THE MINDSET

An interview with Alistair Cockburn, Senior Consultant, Cutter Consortium

Q. Tell me about the last interesting consulting engagement you were involved in.

The company was a new, Web-based subsidiary of a bank. They had just gone live with their first system, which allowed people to do certain types of banking and featured a fancy rewards scheme where people could exchange credit from cell phone minutes to buy movie tickets and the reverse. Their system had a direct link with the bank's mainframe computers, and it also linked to other departments and other companies.

The CTO of the company knew the kinds of recommendations that I make. He called me and said, "We have already done the three- people-in-a-room business. It worked great and we have a system out. But now we have 20 people, and three-people-in-a-room doesn't work any more. What do we do now?"

There were about 50 people in the company, and I interviewed them all -- from the CTO through marketing, management, testing, and development. It turned out that they wanted and needed to redesign the organization's work structure and working conventions, including process, methodology, seating, meetings job descriptions, and so on.

To make such an extensive alteration without requiring spine- snapping changes (see "chiropractic" therapy below), I tried to make it so each particular group only had to make one notable change in its work habits, and all the other changes were very minor (see "micro-touch" therapy below). Then we set some conventions in place, subject to review every two weeks.

After the changes, they put out a new release every other week. After the release, they held a post-release meeting to reconsider their recent experience and to discuss what they were going to keep and what they were going to change in the next weeks. They evolved their way forward from there. (Interestingly enough, one of their changes a few months later was to change from a two-week release cycle to a monthly release cycle.)

Q. What were the obstacles you had to overcome? How did you overcome them?

This company had a dominant problem that I see in many companies these days: people working on four, five, six, or even seven different assignments at the same time. They go from one meeting to another and say, "No, I have not had time to do anything since the last meeting." In this case, it was happening with every individual in the entire company. We went back to [Cutter Business Technology Council Fellow] Tom DeMarco's recommendation from Peopleware to have several hours of focus time each day.

It turned out that the CEO was suffering from this interruption syndrome as much as anyone else and supported the idea wholeheartedly. By the second week of my visit, there were no meetings from 10 am to noon each day.

The other convention we put into place to deal with the problem was to allow workers to bundle their work assignments into two-day blocks. Obviously, they couldn't work on six different things if they were working in two-day blocks, so this forced the management to clean up their priority list. The schedule initially looked horrible, but it was realistic, and after they sorted out the assignment priorities, the number of simultaneous assignments dropped down to two or three in most cases.

Q. Were any of your recommendations met with resistance?

I expected a lot of resistance and was surprised by how little there was. I commented to the CTO, "This obviously isn't going to work, because I've been here less than one day and I already have a dozen recommendations. I'll end up with about three dozen recommendations by the time I'm done, and I haven't really met a company or group that can take on more than two or three recommendations in total."

I was wrong -- they had implemented the most important two recommendations by the middle of the second day! In the end, we came up with 36 items to change, within which were maybe two dozen that were really important, a dozen of which were critical.

They implemented more than half of those 36 within a couple of weeks! That was pretty amazing! How could they do that? As far as I could tell, the key was they were a new company, and so their problems stemmed from absence of good habits. An older company would have had ingrained bad habits, which are more difficult to change. We were therefore building a new culture, not so much changing an old culture.

Q. When you are dealing with "old culture" companies, what is your approach?

I like to use what I call "micro-touch" therapy. It is based on a kind of massage that has a very, very light touch. With this approach, I ask as many people as possible to make such small changes that they don't mind making those changes. The group can achieve a large total effect if each person makes the individual adjustments that don't bother them very much. Then I will eventually ask the group to make one big change.

The opposite approach is what I call "chiropractic" therapy. The consultant makes what amounts to a sudden spine-straightening action on the group. Pop the spine, turn the head around, and say, "Gee, aren't you more comfortable now? Look! You can see your feet!" I know consultants who are quite effective with the chiropractic approach, but I'm not one of them.

As a starter, the two things that I look at first are the frequency of communication and the goodwill in the communication. I always look at the number of interruptions that people get, because multitasking has become so common, as in the e-bank company.

When you observe the frequency of communication, you can find out who should be talking to each other more. For instance, if two people are sitting in different rooms, different floors, or different cities, you already have an indicator that there might be a problem. Then I see what types of adjustments might need to be made.

The goodwill in communication has to do with whether people are willing and able to tell and listen to each other. Projects work because people mention something that is important, useful, handy, or diagnostic -- or whatever it may be -- but if there isn't goodwill, then a person may not mention it or it won't be taken well. Projects live off people detecting little things that aren't right at either the project manager level, the designer level, or the testing level. That's why communication and goodwill are so important.

Q. How do agile methodologies fit with other non-agile or heavy methodologies?

There is a natural tension between them, which means that there is not going to be a resolution. Agile is a mindset. It's not a set of techniques. There is a library of techniques, but it is not the techniques; it's the decision that agility and maneuverability are important. Agile is a declaration that a certain value is a top priority.

Once a person accepts or decides that this value declaration is appropriate for the project, then they can look at the library of techniques or invent new techniques. What I mean again about mindset is that there are some projects where agility is not a top- priority item. Cost, for instance, could be more important.

If you find yourself in stable circumstances and you run a cost-optimized plan, it will take longer but cost less than if you had the same stable circumstances and ran an agile plan. Agile techniques tend to deliver the software faster but more expensively than a super cost-optimized version running under stable circumstances. The trick is that these days, there aren't a lot of places that have stable circumstances.

Similarly, there are life-critical type systems where the safety factors are of such overriding importance that agility becomes one of the minor priorities and not one of the top priorities. Under those circumstances, a number of items out of the agile library can be used, but certain agile policies won't be used because of the life-critical nature of the project. Those projects are striving to create stable circumstances. If you are doing something critical, you don't typically allow the requirements to change at the last moment.

Maneuverability in respect to changing circumstances, and rapid delivery or release of software, is a top priority in the agile mindset. With that mindset, then you can dive into the library of techniques. Agile is not the library, it's the mindset.

-- Cutter Consortium

Alistair Cockburn