Reprise: Leave your laptops, Blackberries and phones out of meetings

At the end of last year, or was it the start of this year, I wrote a blog entry which got a lot of attention: Leave your laptops out of meetings. I was talking specifically about laptops but I could have easily included Blackberries, iPhones and other portable devices.

In todays Financial Times two professors from Toronto Rotman School of Management make the same call: Why e-mail must disappear from the boardroom. Their piece specifically addresses e-mail and boardrooms but its the same argument I was making.

Professors Beaty and Weber wonder what how directors can concentrate on discussions when they are doing something else. And the question what will happen when someone decides to sue a company for decisions taken by directors who are not concentrating.

So there are three good reasons to leave your laptop out of the meeting, switch off your Blackberrry and ignore your SMS messages:

  1. You cannot do your job properly is you trying to do two things at once
  2. You are opening your company to negligence claims
  3. It is rude; you are insulting the people who are in the room asking for your attention

For the record I very really take a laptop to a meeting, only really if I have something on it I want to share. I don’t own a Blackberry, iPhone or other portable e-mail device. And I set my mobile phone to silent when I arrive at an office.

I am guilty of occasionally viewing an SMS during a meeting, and even more occasionally sending an SMS during a meeting. I apologize to everyone in a meeting where I have ever done so.

I fully support Beaty and Weber’s call: think of the message and example it would send if a company board stated that Blackberries and laptops were not to be used in meetings.

The Scrum Wall (another Agile failure mode)

I recently came across the expression “The Scrum Wall”, as in the expression “Hitting the Scrum Wall”. Its akin to “the pain barrier”, or “feel the burn” in aerobics workouts of old.

Once I heard it I knew what it was, I’ve talked about this before, now I know it has a name.

The Scrum Wall is the thing Bob Martin described at the ACCU conference. And it is probably why Jeff Sutherland endorses Test Driven Development and other technical practices from XP.

You hit the Scrum wall when you adopt Scrum and everything goes well, then, after a few Sprints things don’t work any more – to use an English expression, they go pear shaped. You can’t keep your commitments, you can’t release software, your customers get annoyed and angry, it looks like Scrum is broken.

This is what happens when you adopt Scrum without technical practices such as Test Driven Development, continuous integration and refectoring. When teams adopt the Scrum process, they go faster, show progress, things look good… and then the quality becomes a problem. Now the team are fighting through quick sand.

The code quality is poor and developers are expected to continue to make progress. Maybe the Scrum Master/Project Manager reverts to past behavior and demands overtime and weekend working. Maybe the team start busting a gut to keep their commitments. Either way the team is heading for burn-out.

That’s the wall.

A true story about CMM

About a decade ago I worked for a major supplier of financial information in London. The company decided it wanted to improve its software development process and the answer to this problem was to adopt CMM – the Capability Maturity Model. Initially the become level 2 and then move on the level 3.

The little group I worked in interfaced to financial trading institutions in the City of London. My project in particular had to respond quickly to changes at the institutions.

The CMM roll-out was a akin to a neutron bomb in reverse. The people were left in place, but their processes and practices were replaced en-mass. Developers attended CMM training and instructed in how to develop software according to the new process.

The effect was devastating. One manager likened it to pouring quick setting concrete on the railway tracks of progress.

I went out and I bought myself a book on CMM so I could understand it. What I learned was that CMM was a way of measuring maturity. It was a meter, imaging it as a ruler. It was a way of assessing your organization. You could measure yourself as 1 CMM, or 2 CMM, up to 5 CMM. It was not a method of working.

The CMM body of knowledge also contained recommendations, “best practices” and examples of good practices but it was not itself a process. It was a meter for measuring your maturity.

From the book I learned that Watts Hymphrey advised companies to: focus on improving their processes first and let the CMM measures improve by themselves.

What I observed in practice was the destruction of working practices an processes. I never observed any attempt to involve those doing the work in process improvement. The consultants knew best. Opposition was to be overcome. Process improvement was something that was done to others.

This wasn’t the company for me and I left. The company was eventually certified as CMM Level 2 and was expected to move to level 3 in time. Time went by and I don’t think the company ever made level 3. I heard that internally CMM was recognised as a mistake and the work was quietly allowed to die. The company also announced major moves to offshore development.

Fast forward to 2009. I recently met someone who was an outside consultant to the company and advised them on CMM adoption. He told me that he, and the other consultants, had advised the company to build on the practices they had and improve them. They specifically advised them not to write new processes and impose them on people.

He also told me that when the company did its own retrospective on the CMM project it was seen as a mistake to have written and imposed new processes on developers. A far better way would have been to improve what was in place with the people who did the work.

So the moral of the story:
• There is a lot of good in CMM – and the more recent CMMI.
• CMM itself is not a process, it is a meter, it is a means of measuring yourself.
• The key is process improvement, focus on improving and the levels will come.
• Don’t replace, improve, evolve. Involve your own people.

The role of the Agile Coach

I was at EuroPLoP most of last week – a great conference! And I was busy preparing for the conference for the days before that – because I was Programme Chair.

So, not much time for blogging. But I did manage to get a piece in the latest Agile Journal on the Role of the Agile Coach. Originally this was based on the “What does an Agile Coach do?” piece in this blog but the final result was a completely new article.

Agile @ DevelopMentor

I’m pleased to announce that I have entered into a partnership with DevelopMentor. For those who don’t know DevelopMentor they are one of the leading IT training companies in the USA and Europe. DevelopMentor are traditionally a tech-heavy company. Traditionally they offered hard corse courses in C++, C#, Java and so on. They have not so far offered anything for Agile development. Well thats were I come in.

The partnership is in two parts. First DevelopMentor are licensing some of my training material. The first of these is my Foundations of Agile Software Development using Scrum (a 2 day course.) This course is now available in the USA and Europe – and probably most other places if you ask nicely.

The second part of the deal is for me to deliver training to DevelopMentors clients. This will include the Foundations Course plus other courses, again in the UK, Europe, the USA and elsewhere.

For more details see DevelopMentor’s Agile courses see their website.

Initially DevelopMentor are launching with three courses: Foundations of Agile, Requirements with User Stories and Test Driven Development. The first public delivery is schedule for September when I will deliver the Foundations course plus the Requirements course over 4 days (22, 23, 24 & 25) in London.

If your are interesting in the public course get over to the DevelopMentor website quickly, within a couple of hours of them announcing the course they took the first bookings.

Actually, we expect most of the interest to come from companies wanting in house delivery of the course. I delivered the foundations course in Denmark a few weeks ago and got very good feedback from the class.