Leave your laptops out of meetings

The new year is just here! And can I suggest a new year’s resolution?

Normally I bite my tongue and don’t mention this. I’ve not blogged about it before because what ever client(s) I’m working with at the time I blog about it will automatically assume I’m talking about them. (Yes, I know people at client sites find and read my blog so I try to self-censor.)

But, I’ve just finished up a major engagement (coaching 4 development teams in the same company) and new stuff kicks off in the new year, so I can say this for once.

Please, don’t take your laptops to meetings. And if you do leave them powered down.

If you go to a meeting it deserves your full attention. If you don’t want to give it, or can’t give it, than make your apologies and say: Sorry I can’t make it, go on without me.

If you do go then give the meeting your attention. OK, occasionally we all need to take a phone call but it is far less often than we think. I remember breaking my own rule a few years ago to take a phone call, but then I was waiting for my farther to die.

Phone calls are different to laptops. A phone call is an interrupt. It says “Someone wants you.” By definition if someone has sent an e-mail it is less important, or at least less urgent. So as much as I dislike meeting interrupted by phone calls I can accept them - personally, I switch my phone to silent and reject calls that come during meetings.

If you are so important you carry a Blackberry (or similar) and urgent (meeting interrupting work) arrives via e-mail it may be a sign that your organization can’t prioritise. But at least a Blackberry is small.

The problem with a laptop in a meeting is it creates a barrier between the user and the other people in the meeting. Every time someone lifts their screen I see a sign that they don’t want to be here, don’t want to hear what is said, and don’t want to be part of the team.

That screen is big. Its a big barrier. Its a sign. It says “I don’t need to interact with you people.”

And what do people do with these laptops?

I tell myself they are answering e-mail, important requests that cannot wait. But... well... I heard about a case recently where the senior manager in the meeting was booker herself a flight on EasyJet. I once went to a meeting which was so packed I had to stand at the back, from where I could see a manager (director level) surfing Amazon.

And people who are typing? Are they really replying to an urgent e-mail or having an Instant Messenger conversation with their significant other?

I once took an IM from a colleague in the New York office. Later in the day I saw him in the London office. He’d landed that morning and spent the first few hours in the London office in meetings. So when I IM’ed with him he was in a meeting on a totally different subject and he could have asked me face-to-face an hour later.

Please, stop taking your laptops to meetings. I’d rather you make your apologies and not turn up at all.

A future for software development in the west?

To read the papers one would sometimes wonder if there is a future for software development, indeed IT in general, in Western Europe and North America. Sometimes it seems there is an continual flow of work to India, China and other low cost centres. Personally I think there is a future but only if development groups fix themselves.

First lets be clear: I’m talking about corporate IT here, not independent software developers or other companies who develop software to sell. That is another story, another arguement, lets still to corporates today. Corporate IT departments support business operations by providing them with custom software.

Second there is another force at work: the commoditisation of business processes and the IT that support them. Lets leave that to one side for the moment.

So, I’m specifically talking about IT groups within businesses that need custom software to support some business activity.

Unfortunately such corporate IT departments do not have a good track record. Something like 87% of all such departments are ineffective and do not give the business what they need. (I’ve taken the figure from The Alignment Trap reports which I’ve blogged about before.) In such circumstances IT represents a cost not a benefit. Such companies might be better off not doing IT at all.

If you are doing it, and you are not seeing the benefit, and you are paying the cost then its sensible to look at reducing that cost. Outsourcing and/or offshoring is a valid option.

It might not be nice to hear but if you work in such a group it makes sense to send the work elsewhere. Sending it elsewhere might not fix the original problem but at least it will be cheaper.

So what’s the solution? How do you save your job?

Instead of looking at the cost look at the benefits. Some IT groups have forgotten how to do this simply because their delivery record is so bad. When you only consider the cost side western corporate IT cannot compete, give up now. In order to compete you have to look at the benefit side to.

When things are going well, when an IT group can deliver and can deliver benefits then it is less likely that management will want to change things. When things work, and work well, then any change is a risk. When things don’t work the risk is lower.

Next you need to maximise the benefits. That means looking at how you can add more benefit. And specifically add benefit in ways that offshore low cost centres can’t: quicker turn around, reduced documentation, more interaction with the business.

There is a price to pay in moving work to a low cost centre. Such centres have disadvantages: language differences, cultural differences, distance, time zones, lack of domain knowledge. Sure they can offset these differences but that involves costs. Plus they are getting more expensive (particularly as the pound and dollar fall).

Corporate IT departments can demonstrate their value by responding to business needs more quickly, and by reducing the cost of servicing those needs. When work goes offshore the turn around rate slows because work must be communicated. That means it needs to be more closely defined - this is especially true if the work goes to a third party. Opportunities to change’s ones mind are reduced and the potential for differences increased.

Yes offshore centres can offset these differences but at a cost. Each time the cost goes up the advantage is reduced.

So if you fear your work may go offshore heres what to do:

• Demonstrate the benefit of your work - move the conversations from costs to benefits
• Concentrate on co-operating with your business customers
• Turn work around more quickly
• Reduce the cost of requests and changes of mind - reduce the paperwork
• Work more flexibly
• Understand the business and find ways to innovate

XP Day 2008

I spent Thursday and Friday last week at XP Day 2008. The conference changed its format from last year. Rather than being a conference aimed at people wanting to do Agile Development it focused on people who do Agile development. This meant the sessions changed rather than being introductory or “how to” material they became Open Space discussions. Instead of being lecturers session leaders were facilitators.

Very few sessions were arranged in advance but one that was was Designing the Agile Company led by Giovanni Asproni and myself. This session used a dialogue sheet technique to promote discussion.

XP Day also had space for Lightening Talks. These were unscheduled talks lasting no more than 5 minutes - so very focused. I briefly outlined the Requirements Trap - or rather the Alignment Trap which I blogged about last year. This short talk got a lot of interest and a lot of people asked for the references so here they are:

• Original Alignment Trap article in the MIT Sloan Management Review
• An abridged version from the Bain Consulting website
• My blog entry on the Alignment Trap and Agile software development

I enjoyed XP Day a lot and learned a bunch of stuff - mainly by having to think about it. Yet I found the conference lacking because I found myself speaking to the same people; I already known most of these people, I read their blogs, I talk to them at XTC and a bump into them at other conferences. One of the nice things about Oredev last month was new faces. I guess you can’t have everything.

Oredev

I have been at the XP Day conference for the last two days but before I blog anything about that conference I want to record a few notes about Oredev last month.

The first thing to note about Oredev is that it is big. About 900 people. While the topics cover, and type of attendee make it look a bit like ACCU Conference but it is more than twice the size of ACCU (usually about 300-350) and it felt it. While quantity has a quality all of its own I missed the intimacy of ACCU.

My own session was well received. Hard to tell how many people attended the session, I would guess 50 to 100, but in a room that could hold 1,000 it felt empty.

Still I met a bunch of nice people and heard some good talks. Bob Martin was on form, his keynote talk took more prisoners - “Professionalism is spelt TDD” and programmers should me more like the Boy Scouts of America. The Boy Scout have a rule: When you camp somewhere, always leave the campsite tidier than when you arrive. Bob suggests programmers should apply this rule to working on code.

While I enjoyed several of the other talks (Gabrielle Benefield, Diana Larsen, Dag Krogdahl stick in my mind) it was Luke Hohmann’s that explained something to me. Luke’s talk was about product management - and regular readers know this is one of my hobby horses - but in passing it answered a question I’ve had for years.

What is Enterprise Software? - or more to the point What is Not Enterprise Software? Luke gave 4 attributes of enterprise software:
1. Enterprise software is expensive: you don’t buy it for the home, only corporations buy it
2. Enterprise software is tended by people: system administrators, etc.
3. The software is critical to some aspect of the companies business
4. Enterprise software is more valuable when it is integrated with other enterprise software

Gemba - Lean tour

Jason Yip works for ThoughtWorks in Australia. He is currently (or maybe was) on a Lean study tour in Japan - I’m jealous, where do I book mine? - and he’s blogging about his findings. Well worth reading, so far several points have stood out for me:

• Andon cords are being pulled all the time: a Toyota factory isn’t the perfect place some of us (myself included) imagine sometimes. Faults happen, things need to be fixed and improvements made - all the time.
• Toyota do pay bonuses: for ideas that lead to process improvement
• Hansei is the Japanese word for serious reflection. In the Agile world Retrospectives are Hansei. As regular readers know I always suggest keeping your own personal journal for reflection, more Hansei.
• Pika Pika is a Japanese term translating to “spic and span”: workers keep their work area clean and tidy. Obvious really, how else can you see the problems? (I’m always shy of people taking cards of the board and putting them on their desks after one engineer I knew lost several this way. We tidied his desk and found work.)
• “The Toyota Production System (TPS) is not a system; it's a religion” - to all those who have critised Lean and Agile for being too religious, you were right.

If that isn’t enough, Jason also has a nice set of hand drawn sketches to illustrate Agile and Lean!

Books for Product Managers

Turns out books about Product Management are a little likes buses: None then 3 turn up at once!

I’ve been looking for a good book on Product Management for a while so I was interested to see Tuned In by Craig Stull, Phil Myers and David Meerman Scott published. I’ve not had a chance to read it yet (so don’t take this as a recommendation) but I intend to.

Then, at Oredev I met Luke Holmann and had the pleasure to hear him speak. Turns out Luke has a book in the product management space too, its been out for a couple of years but somehow I’ve missed it. Again I’ve not had the chance to read it yet but I intend to, it is Beyond Software Architecture.

Finally, one of the Product Managers I’m working with just now leant me a copy of another book, Expert Product Management by Brian Lawley. This is small book and as such doesn’t cover the role of the Product Manager in full. It simply covers several aspects of product: Road mapping, Beta programmes, Reviews and Product Launch. There is good information here and as its small you can read it quickly. Still, I’m hoping on of the other books will turn out to be the Product Management book I’ve been looking for.