Agile Business Coach

Why Fuzzy Versus Hard

Consider the following two diagrams, which one feels more complete? Which one would you feel more comfortable giving feedback on.

Normally the feedback of business users is very poor when presented with a word document or visio / powerpoint diagram with hard lines and square corners. The feedback when presented with pencil or pen drawing is much better. Why is this. The reasons are as follows:

1. The business user perceives that the business coach has spent a lot of time and effort on the document / drawings and does not want to upset them by telling them things that are wrong. They will wait until they get to the UAT when they can change the system.

2. The business user assumes a lot of thought has gone into the document and does not want to appear stupid by asking obvious questions.

3. It is difficult for the business user to understand the document / diagrams so they just sign off so that the development will proceed. They do not want to be a bottleneck.

In each case the problem is that the business user perceives that a lot of effort and therefore thought has gone into the document. Drawing the diagrams by hand gives the impression that little effort and thought has gone into the diagrams. In actual fact the hand drawn diagrams have probably had more thought because the business coach needs to prepare not only a diagram but also the story that they are going to tell the business user.

The other good thing about hand drawn diagrams is that it encourages the developers to challenge the results of analysis as well. It also makes the developer think as they transfer any models into code.

Fuzzy Versus Hard : Eliciting Feedback

Fuzzy Versus Hard is a mechanism used to encourage feedback. Early on when feedback is to be encourage, concepts should be presented with fuzzy edges and rounded corners and later on as the concept matures the edges should be harder with square corners. This is a practice used in a number of fields, but not in software development. It is a concept that I have been practicing on my current project.

I normally present the results of analysis in word documents using diagrams created with Visio or Powerpoint. Feedback from the business and other members of the development team is poor, often limited to the pointing out of typos or speeling mistakes. I applied fuzzy versus hard to presenting workflow diagrams with dramatic improvement in feedback. Exactly the kind of feedback I was after.

Instead of creating a word document with visio diagrams, I presented a set new workflows by drawing them by hand on a blank sheet of paper. The business commented on them as I was drawing them out suggesting alterations. After we had been through them a couple of times, we created the word document and visio. We had seen that one of them had scribbled all over a copy of the document with red pen. When we held a review session to discuss the workflows, they turned up with a pristine copy of the document minus the scribbles. We asked to see the scribbles and told them that the document was written in pencil as far as we were concerned. This got the feedback going, they pointed out all the errors in what we had done.

This blog was inspired by a discussion with Allistair Cockburn following a talk by Kevin Tate at the Agile Development Conference 2003. Fuzzy Vs Hard is a phrase that Kevin used during his talk.

What's in a name

Early feedback (We value negative over positive, and fail fast to win early) indicated that this has been discussed extensively already. My view on the naming of XP.

EXtreme Programming (XP) and Test Driven Development (TDD) are superior methodologies to the Rational Unified Process (RUP) or a Waterfall methodology. A number of sources state Agile Methodologies are “Crossing the Chasm” in marketing terms. XP is being adopted by the “Early Majority”, who are following the Courageous “Early Adoptors” like ourselves. We should be aware that a number of superior technologies have failed at the Chasm because they fail to market themselves to a new group of people, the Early Majority. The names “eXtreme Programming” and “Test Driven Development” are off putting to the Early Majority and could cause Agile Methodologies to fail at the chasm at worst or at least slow down their uptake. This article is a call to arms, the Agile Community must rename these practices to more marketable names for those we are now attracting. Otherwise we risk the danger that Agile will fail to cross the chasm and we will be doomed to rename a niche community within the software world.

Geoffrey Moore’s classic book “Crossing the Chasm” explores why great technologies fail to make it to the mainstream. It suggests that consumers are split into four groups named “Early Adoptors”, “Early Majority”, “Late Majority” and “Late Adoptors”. Between the “Early Adoptors” and the other groups there is a Chasm that great technologies fall into. They are taken up by the “Early Majority” but they fail to attract the other groups. These groups have different characteristics and the key ones are the “Early Adoptors” and the “Early Majority”. “Early Adoptors” like to be the first to adopt a new technology and less worried about risk. “Early Majority” only take up a technology when they see that it is proven, they are much more risk averse. They are also a much much bigger group.

Now imagine the scene, a Software Manager in the “Early Majority” group is preparing his weekly status report for his boss. He has two kids, wears a grey suit and has a big big mortgage. One of his top programmers comes into his office all excited about a new methodology that his friend has told him about called “eXtreme Programming”. The programmer gives him an article to read and leaves the room. The manager’s reaction is going to be “This sounds like Extreme Sports…surfing, snow boarding and skate boarding”. He is going to picture the long haired youth with bad attitude that cut him up on the ski slopes of Aspen. “I’ll think about it he says” and promptly returns to his status report. The article gets put into his in-tray. Two months later he finds it again during a clear out, he spots the word “Courage” in bold, and promptly drops it into the bin, unread. Besides, his programmer has left to join ThoughtWorks, leaving him with a real bad resource problem and a whole load of code that no one else can understand. The reason he rejects “eXtreme Programming” is because it does not suit his risk preference. As a member of the “Early Majority”, he is a follower rather than a leader. None of his peers have adopted it, so why should he take the risk? Lets leave it to the surfers and snow boarders at ThoughtWorks.

Imagine a similar scene, the difference is that his top programmer comes in to present an article on “Test Driven Development”. The manager already has a problem with the testing budget as it is. The User Acceptance Test phase of his project is running two months behind schedule. He does not want to adopt a practice that emphasises the riskiest part of his project and potentially causes even bigger cost overruns. Nope, he will stick with the company’s official RUP based methodology.

One of Agile’s biggest problems crossing the chasm is that the most popular and successful methodologies, “eXtreme programming”, has a name that is scary to the group that we are currently trying to market to on the other side of the chasm. Unless we rename the methodology, Agile could remain a niche community rather than make it into the mainstream.

So what names could we chose? Any name that reflects the true risks associated with XP. We know that it is a safer and more successful methodology, that’s why so many of us are fanatical about it and want everyone to use it.

I suggest that the XP and Agile Community chose a new name. Any will do which doesn’t include the words “eXtreme” or “Test”. This could be something discussed and agreed at XP 2004 or the Agile Development Conference.

As a suggestion, How about Excellent Programming? Addison Wesley could print copies of the White Book with “Excellent Programming, Embrace Change” as well as the classic XP version for the informed. Hopefully it will sell even more copies than it currently does. Hopefully Kent Beck will read this blog and agree. I love his methodology and want everyone to use it. Just please help me with the sell to my prospective clients in the “Early Majority”.

Andy Pols now has a Blog

Andy Pols who is the other half of the Agile Business Coach now has a Blog at www.pols.co.uk/blog

eXtreme Programming / Sports

I was talking to the main business user for my project yesterday. We were discussing the IT project team and I explained that I am an Agilist. I said that one of the big problems is the name "eXtreme Programming" because it brings to mind extreme sports. His response was that whilst extreme sportsmen appear relaxed and laid back, they are actually very professional with a proper understanding of the risks they run. In his words, "Extreme sportsmen who are laid back about the risks are all dead."

A new start

This week I should start back to my old project after a period of illness. It is quite exciting because the business users are asking for User Acceptance Test driven development and they want to have programmers that work in pairs. The IT managers want to run the project as a waterfall project.

The business users have spent significant time writing the UAT results before the project starts. The next challenge is to get the developers on the project before too much more analysis is done.

I will keep you informed on the progress.

Feedback

I have been breaking one of my own rules by not asking for feedback on this Blog. Does anyone read it? Is it of interest? Let me know by leaving a comment on the site.