Scattered impressions from my recent trip to Australia for the Agile Australia conference.

• The Australian agile community is small and somewhat disconnected from the rest of the world (for a good reason, it's a long flight from anywhere). But however small and disconnected they are, they are no less mature. Many of the issues here were just the same as at Agile2010.
• I was particularly happy to see it announced that Jim Highsmith is joining us at ThoughtWorks. I first met Jim on a speaking tour that included my first visit to Australia. I've always found he has a way of helping people look at software development from a new set of perspectives, so I'm looking forward to having him as a colleague. (There's a worthwhile summary of his talk on InfoQ.)
• There was a strong IT leadership presence at the conference, particularly brought home by Jeff Smith - CIO of Suncorp (one of Australia's largest insurance companies).


Nigel Dalton of Lonely Planet

• A high-point of my trip (before the conference) was my visit to Lonely Planet, where Nigel Dalton gave me a tour of story-walls around the company. I've been a customer of Lonely Planet guide books for twenty years, so it was good to see how much the organization had gained from the techniques we agilists have talked about. Nigel talked at the conference, focusing on the use of agile ideas outside the software development side. On my visit we spent a good bit of time talking about LP's shift to digital publication.
• I did my what is now my usual style of keynote - a SuiteOfTalks. In deciding what to do I was rather torn since there were three talks I wanted to give, but there was only room for two with the expected Q&A. So after delivering two talks I gave the audience the choice: Q&A or a third talk. I was interested to note that the vote for a third talk was almost unanimous.
• As I keep saying, I like being in Australia, but hate going there. 28 hours of travel isn't fun, even with an upgrade. But there's such a nice atmosphere to Sydney and Melbourne and I have lots of happy memories of exploring these cities with Cindy a couple of years ago. I certainly hope to be back for another longer visit with her.

Last week I attended the Agile 2010 conference in Orlando. Agile 20xx is the major US agile-oriented conference whose roots go back to XP Universe and the Agile Development Conference. I've not been a regular attender of the main agile conferences, but I did go last year as well. Rather than make an attempt at a consolidated description, here are a few scattered impressions.

Elizabeth Hendrickson (aka testobsessed)

• Attendance was 1400, more than 2009, but around the same as 2008. So although it has been hit by the Great Recession it's weathered it reasonably well.
• I was delighted to see Elizabeth Hendrickson and Liz Keogh win the Gordon Pask award.
• My sense was that most people were relatively new to agile, which is in line with my sense in 2009.
• There was a much higher proportion of women than I usually see at software conferences.
• There were lots of talks going on, which felt overwhelming to me: 16 stages (tracks) with 214 talks.
• I was pleased to see the tutorial on Continuous Delivery that Jez Humble gave with me seemed well-received. (We currently have it booked again for QCon and OOP.)
• Most of the emphasis was on team collaboration and soft skills. This led to some criticism from people on the programming side.
• My unscientific sample of talks I attended showed a higher proportion of badly presented talks than I would like.
• It seems there's a movement to re-create XP Universe for next year.
• I prefer a conference in a real city to one in a holiday resort.
• This year marks ten years from the first agile-oriented conference.
• The conference went smoothly - which is a testament to the hard work of all the organizers. This is particularly so since they had to deal with moving the conference after the flooding in Nashville. Thank You.

Liz Keogh (aka lunivore)

I have mixed feelings about the complaints on the lack of programming topics. Certainly programming plays a central role in software development and attempts to marginalize it correlate well with dead-ends. But programming is part of a very interconnected system which involves lots of pieces - and making these interconnections work requires exactly these kinds of "soft and woolly" skills. There is a real tendency for programmers to look inward and obsess on technical issues rather than engaging with those outside programming. One of the things I like about XP is that it recognizes this: blending technical excellence with collaboration.

I would hate to see programming detached from the agilexx conference with programmers going to different events. There's a need for places where the intermingling can occur. The JAOO and QCon conferences seem to do a very good job of this - as well as having a better quality control over the talks themselves. Their format isn't universal, and there's room for more options. Our crucial task is to engage in excellence in the programming side without cutting off the essential collaboration.

One of the steady themes I've seen throughout my career is that of the nature and importance of software development. Recently a prospect told one of our salespeople that "software is like sewage pipes, I want it to work reliably and I don't want to know about the details". This is the kind of approach that Nicholas Carr talked about in IT Doesn't Matter. On a contrasting note we've done work for many businesses where IT has been a clearer strategic enabler to their business, allowing them to enter new markets or significantly increase their market share. So is IT a utility, like sewage pipes, or a strategic asset?

I take that the view is that it can be either, depending on the system. A classic example of a utility IT project is payroll, everyone needs it, but it's something that most people want to 'just work'.

So what is the distinguishing factor between utility and strategic projects? To my mind it's all about whether the underlying business function is a differentiator or not. If how you do this function is a crucial part of what makes you better than the competition, then the software that supports this function needs to be as good as you can make it. Note that this distinction isn't about the software, but the business function. As Ross Pettit puts it "This is not a separation of IT by the nature of the technology, but into what technology does for the host business".

The most important point about this dichotomy is to realize that there are two kinds of software projects and they need to be treated entirely differently. The way you staff, run, and budget a strategic project is entirely different to how you do a utility project. Too often people assume that what is good for one is good for the other - and trouble inevitably follows.

Another consequence is that only a few projects are strategic. The 80/20 rule applies, except it may be more like 95/5. While certainly it's most common for people to not recognize the dichotomy at all, it's also common for people to think that too many projects are strategic.

One of the most important ways in which these efforts differ is where the risks lie. For utility projects the biggest risk is some kind of catastrophic error - you don't want the sewage pipe to break, or to miss payroll. So you need enough attention to make sure that doesn't happen, but other than that you want costs to be as low as possible. However with strategic projects, the biggest risk is not doing something before your competitors do. So you need to be able to react quickly. Cost is much less of an issue because the opportunity cost of not doing something is far greater than costs of software development itself.

This is not a static dichotomy. Business activities that are strategic can become a utility as time passes. Less often, a utility can become strategic if a company figures out how to make that activity a differentiator. (Apple did something like this with the design of personal computers.)

One way this dichotomy helps is in deciding between building custom software and installing a package. Since the definition of utility is that there's no differentiator, the obvious thing is to go with the package. For a strategic function you don't want the same software as your competitors because that would cripple your ability to differentiate.

Often people realize this and buy a package for a utility project, but then spend huge amounts of money customizing this - which is just as wasteful. My view is that for a utility function you buy the package and adjust your business process to match the software. Usually this is politically infeasible, so the workaround is to put a low grade software team to work on it. Provide enough care to avoid catastrophe, but otherwise you don't need a high-grade team.

Another way the dichotomy makes its influence felt is the role of agile methods. Most agilists tend to come from a strategic mindset, and the flexibility and rapid time-to-market that characterizes agile is crucial for strategic projects. For utility projects, however, the advantages of agile don't matter that much. I'm not sure whether using an agile approach for a utility project would be the wrong choice, but I am sure that it doesn't matter that much.

Like many classifications, there's a lot of grey in between. Yet this is one of those rare cases where I think there's a strong argument to turn up the contrast and force more binary thinking. As Ross commented in a discussion of a draft of this post: "'shades of grey' give license to pile things into the wrong category; things that are really utility will be given an inflated importance, rather than dispositioned as the utilities they really are." Forcing a binary decision, tilted to minimize what's in the strategic bucket, would help provide the focus that's often lacking in IT initiatives.

Ross goes so far as to argue that there shouldn't be a single IT department that's responsible for both utility and strategic work. The mindset and management attitudes that are needed for the two are just too different. It's like expecting the same people who design warehouses to design an arts museum.

To explore more...

• Ross's article calls for a Glass-Stegall of IT departments.
• Marc McNeil talks of projects as Tractors, nuclear power plants and the bleeding edge
• Neal Ford points out that integration efforts, such as SOA, can't be strategic.
• There is video of the talk I gave on this theme for AMP last year.

A common thing you find in agile projects is that the development team sits in a single open team room. It was advocated early on in Extreme Programming and called out as one of primary practices in the second edition. Agilists favor a open team room as it promotes lots of informal and deep communication between people on the team.

Why

Software development is an intense exercise in collaboration. An open space encourages regular conversations and interactions between people. You can see what everyone's doing and easily ask for help when you need to. Often you get serendipitous communication, where you overhear something that's really useful.

Hearing this, some people are concerned about noise, and would prefer private offices. In practice I find that teams don't find noise to be a serious issue. There's usually a hum of conversation going on, after all pair programming often accompanies this style of development. But the conversation isn't usually that distracting, particularly as you're focused on the conversation with your pair. I suspect the reason it's not that distracting is because the team has a common purpose around a collaborative activity. It isn't comparable to an open-plan office where everyone is doing something different.

Tips for a good Team Room

First make sure it is the right size for the team. While a team room should be open within itself, it should be closed to everyone else. In an ideal world you'd like flexible walls that can insulate one team from another, so an office consists of pods of teams. This is hard to do in practice. Our offices tend to be completely open, with little barriers between teams. This seems to work well-enough, although there are some complaints about the inter-team noise.

Pay attention to natural light. Humans are used to seeing the outside world, and all sorts of natural rhythms work off of light. So it's no surprise that people get very cranky if there isn't enough light about. I've spent plenty of days in enclosed conference rooms, and it certainly wears down my energy.

Provide enough space: about 50 square feet per person (4.5 square meters for those on metric).

With the right kind of space the next key thing is to ensure that the team has control over that space. An important part of agile thinking is that the team is responsible for how it works, and how it organizes its space is part of that. Ideally you want a team to have complete control over their space, with freedom to configure it how they like and reconfigure it at will. Things should be done so it's easy to move things around, because during the project the team will need to change things as the project changes.

The purpose-built tables in our Beijing office have handy baskets for power and other cables.

An immediate consequence of this is to ditch any kind of modular furniture that requires a facilities group to move more than an inch. Most teams I see use simple tables, and you can certainly go cheap here.

The biggest hassle is wires - primarily for power and network access. Ideally you want these underfloor or overhead so that people can easily route wires to the tables, wherever the tables happen to be.

The place to spend money on furniture is for good quality chairs. Programmers spend a lot of time sitting, and any physical damage due to poor posture will have a direct effect on the team's productivity - so don't stint here. It may be that some people will want strange chairs, such as balls or kneeling chairs. Do your best to accommodate them.

Some people are big fans of tables that can be adjusted between a sitting and standing height, as they find that standing for a while helps with back pain. These are harder to find, but worth looking into if your team members need it. Back pain is a common issue, but everyone's pain (and treatment) is different.

You'll need lots of wall space, as agilists love their information radiators. You want plenty of room for story walls, architectural diagrams, whatever people want to stick on the wall. A good bit of this wall space should be whiteboards so people can draw something whenever the mood takes them. Include some wheeled whiteboards. Make sure there's a digital camera around so people can easily record what's on the board. Now that displays are so cheap, consider getting some just for wall displays - this is particularly handy for dynamic displays such as build status. I've seen one team have projectors trained on a wall with various kinds of information displays.

The traditional layout is to have people working around clumps of desks. This gives you regular eye contact with the rest of your team. However I've heard many people sing the praises of the UPod.

People will occasionally need some private space, so ensure there are one or two small conference rooms available, with telephones. These can be used for privacy or when there's a concern about distraction. A large meeting room that the team can gather in for meetings away from the working space is also handy.

I've always been a big proponent of lots of monitor space. Clever software with multiple virtual workspaces is a great feature, but nothing is faster than just moving your eyes. Every workstation should have a couple of 20 inch monitors as a bare minimum. My desk has a pair of 20 inch monitors for my Ubuntu machine and a 25 inch for my mac laptop. I don't think that's at all excessive.

Software development is inherently creative, so expect to see lots of baubly distractions. Toys are commonly found around our teams (as Neal Ford says: "every team needs a plastic kangaroo"). There are good cognitive reasons why this is valuable, it's all about keeping the brain stimulated and creative.

Similarly do provide easy access to snacks and drinks. This helps support informal, conversational breaks in the team area. It's hard to be creative when you have to pay for awful coffee.

If you're working with remote workers, make it easy to set up a video link. Indeed many teams like having permanent video links to any remote workers so you can always maintain that casual video contact.

Useful Links

• InfoQ summary of things for a team room.
• William Pietri describes a team room he's used.
• Bill Wake's gallery of team rooms and charts.
• Rachel Davies's advice on building an agile environment.
• Joel Spolsky is perhaps the best illustration for using individual offices rather than a single team room.
• Rajeev Singh's thoughts on moving into this kind of team room at ThoughtWorks India.
• Photos and discussion of the space at Menlo Innovations.

My thanks to my ThoughtWorks colleagues for helping compile this information.

Translations: | Portuguese |

SEMAT (Software Engineering Method and Theory) is an effort initiated by Ivar Jacobson, Bertrand Meyer, and Richard Soley. Its stated aim is to "refound software engineering based on a solid theory, proven principles and best practices". Like many notorious people in the software world I was invited to participate. Thus far I've declined and feel the need to explain why.

The call for action seemed somewhat vague to me. Although it derided fads and fashions, it seemed very much like a fashion statement itself. To better understand what was going on I took a further look at some of the initial publications in Dr Dobb's Journal. From here I got the distinct impression that the central thrust of the initiative is to create a software meta-method-kernel - essentially a set of common process elements for software developments that you can rigorously compose into a method for your own project.

At this point I lost interest. I spent a fair bit of time in the 80's and 90's mucking around with this idea. In the end I decided that it was too hard and of limited value. Why this is so was primarily crystallized for me by Alistair Cockburn who explained that since people are the central element in software development, and people are inherently non-linear and unpredictable - such an effort is fundamentally doomed. Or at least it is until people become predictable agents that can be described with tractable mathematics - for which event I'm not holding my breath.

My views have since gone along the lines that software process is a much more multi-faceted thing than what a meta-method-kernel would usefully describe. Alistair's work on describing methods strikes me as a much more realistic approach.

Alistair actually did get involved in SEMAT and attended their inaugural meeting. His decision to withdraw further reinforces my lack of interest to participate myself.

One of the arguments used to support the adoption of lean techniques in software is the success of Toyota. So do Toyota's recent quality failings undermine the case for lean software development?

One answer for this is to take a sense of proportion. Lean manufacturing techniques were the underpinning of Toyota's rise from an insignificant company in the 1950's to a global giant in the 2000's. By the 1990's other car companies, and many other manufacturers, were busily copying Toyota's techniques. The general sense is that copying these techniques did much to raise the overall quality of cars in the last decade or so. I would be very surprised if the recent problems at Toyota are enough negate that half-century of success.

But a better answer is to remember that Lean manufacturing is about manufacturing not software. The application of lean ideas to software development is a consequence of MetaphoricQuestioning. Lean ideas can help us come up with better ideas for software development, and as such are valuable. But in the end their usefulness lies with how they are used in software and they should be judged on their record here. Their history in manufacturing, both good and bad, is another industry.