Making the undesirable desirable - a lesson from Tom Sawyer

Today's Google home page celebrates the birthday of Mark Twain with images that tell the story of Tom Sawyer convincing his friends to whitewash his fence for him. It is an example of making the undesirable desirable. You can read more about the story on wikipedia and here are some pictures of the story courtesy of google:

Tomorrow an article I wrote on Agile Adoption will be published by InfoQ. One of the strategies and patterns for change in that article is to "make the undesirable desirable". Here is an excerpt from the article:

"A colleague of mine recently experienced some resistance from his team when he asked them to try pair programming. Instead of forcing them to do it, he simply asked ”What would it take to get you to try it?” When they joked that they would gladly try it if they had a big screen TV to use for paired programming, he quickly obliged and the rest was history. The new behaviour became fun – it became desirable."

Although Tom used this strategy for selfish gain, this strategy can also be used to affect positive change in your organization. You can find more strategies and examples useful for your agile adoption in the InfoQ article.

An alternative to bug tracking tools

One of my pet peeves is working in and with bug tracking tools. I am well aware of some of the arguments for the importance of these tools and I am not trying to address those here. Instead, I'll show you an example of an alternative that I have found useful.

First, using an approach like Specification by Example can reduce the need for bug tracking tools because communication goes up and defect counts go down. But even using this technique, defects still occasionally occur. Here is an example of how to use Specification by Example not only for 'requirements', but also for defects.

In June of this year I spoke at the Prairie Developer's Conference in Regina, Saskatchewan. Some of the speakers and volunteers were involved in creating the website, services, and mobile application for that conference. Since I was doing a Specification By Example talk I decided to use the conference web services to illustrate how easy it is to create your first automated test against a web service using FitNesse. As I was working with the services I found a small defect. Instead of writing up a defect in a bug tracker with the steps to re-produce it, I wrote a test in FitNesse to confirm the defect:

This example calls a service that returns a list of sessions and does a few basic C# calculations on that list. It counts the number of sessions (allSessions.Count) in the conference and FitNesse maps that to the NumberOfSessions variable above. It then counts the number of unique abstracts (allSessions.Abstracts.Distinct.Count) and FitNesse maps that to the Number of Unique Abstracts. FitNesse then compares the numbers and displays the results. In this case, 63 does not match 62 so it displays an error with the expected and actual results as above.

Once the test confirmed the defect, I simply communicated the failing test to the developers. When the developers reviewed the test they could clearly see what the problem was. No back and forth was required to understand the issue or to confirm the steps required to reproduce it. No one had to set the status of the defect to "working", "fixed", "duplicate", "resolved", "more information required", or anything else. One of the developers fixed the issue and even added an additional service that we could call to address the root cause - Are Session Abstracts Unique? I added the new test, ran all my tests again and was pleased to see them all go green.

This process improved communication between tester and developer, ensured that the defect would always be tested and re-tested for, and kept us from spending unnecessary time in a bug tracking tool.

Are we agile yet? Applying fuzzy logic to the manifesto

Some background on logic from my brother who is a math professor:

In Greek logic (the logic of Plato and Aristotle) there are only two truth values. Any statement is either true, or false, but not both. Truth is absolute. This works nicely except for when we say things like:

"This sentence is false" 

If this statement is true, then it is also false, and if it is false, then it is also true, and if it is true, then it is also false - a 'fun' logical circle which causes trouble for Greek logic. This liar's paradox was ignored for about 2500 years. Since sentences are either true or false, then the sentence above obviously isn't a sentence. Case closed.

In the last century, mathematicians started to realize that things were not so simple. A quote from my brother:

"There are contradictions in the laws of physics – We have Einstein’s relativity that explains planetary motion, gravity, all these big things. And we have quantum mechanics that explains subatomic energy and matter, all those tiny things. Unfortunately, they contradict each other in the middle. Because the one requires physical reality to be absolutely smooth and continuous, while the other requires quantum bumps, which are profoundly non-smooth and discontinuous. Right now the laws of physics are both true and false (and by false, I mean true.)"

More common examples of statements that can be both true and false include: "I am young", "I am tall", and of course, "We are agile". Truth becomes fuzzy. The truth of those statements can lie somewhere in between absolutely false and absolutely true depending on who is saying them.

"A newborn is young" = truth value of 100%.
"A 20 year old is young" = truth value of 80%

Thus, fuzzy logic was born. Statements can have a truth value in between true and false.

Now let's apply this to the question "Are we agile yet?" by looking at the four tenants of the agile manifesto:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Many of us have read articles or have been in discussion groups where these statements are discussed at length and usually someone tries to apply Greek logic by making statements such as: "Agile has no documentation" and "Agile means no planning". However, the word "over" in the middle implies that fuzzy logic is at work. The manifesto authors are saying that for agile teams truth should be closer to the left than the right. We should focus more of our time on working software and less of our time creating documentation. Planning is still important but responding to change is more important so our plans need to be more flexible. For each statement, we want the left side to be more true than the right - the truth value should be above 50%. Additionally, having a truth value of 100% for any of the statements above can be a dangerous thing. We should stay fuzzy.

So when answering the original question for your team or organization - "Are we agile yet?" - don't expect a checklist of practices to give you the answer. Instead, ask your team this question: "Given the statements above, which direction are we moving?" If you are moving to the left and have committed to staying on the left side of each equation, then you've joined the club - you are agile. Agile is a direction, and that is absolutely true.

My brother Tim's bio: http://www.cmu.ca/facultystaff/trogalsky.html

A short story about co-location

The post I created yesterday reminded me of this story:

A team I was working on was asked to sit together in a rather cramped area. Five of us (two developers, one application architect, one tester, one business analyst) were asked to share a very small area about the size of a typical office. The business analyst had desk space equivalent to the size of a typical end table; there were monitors perched precariously above us on small shelves; we shared one phone; and the limited wall space we had was covered with our visible boards and stickies. Fun!

As we reflected on our space at the end of the project, this comment was made from one of the developers: "On the bright side, I don't think I looked at the requirements document once. I just turned to the business analyst beside me and asked her what needed to be done!" Co-location for the win.

"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation" - Agile Manifesto

Strategizing to solve a communication problem

My wife spent part of this past weekend on a leadership retreat. Her team was asked to participate in the following game to help them develop their team strategy and communication skills:

Setup:

• One person acts as a builder.
• One person acts as the architect.
• Two people are observers.
• The builder and architect sit back to back in chairs. The two of them are not allowed to look at each other, but they are allowed to talk.
• The two observers stand on either side and watch and are not allowed to talk or interfere in any way.
• The builder is handed a blank piece of paper and some shapes that have been cut out.
• The architect is handed a drawing where the shapes are already put in place - the blueprint.

Playing the game:

• Round 1
• The architect's job is to have the builder re-create the drawing by putting the shapes in the correct placements on the blank piece of paper. The architect is not allowed to turn around, but is allowed to talk.
• The observers are instructed to watch - no talking or gesturing.
• The builder is also not allowed to turn around but is allowed to talk.
• Time how long it takes for the team to correctly finish replicating the drawing.
• Rounds 2-n
• A rule change: For this and any subsequent rounds the observers are allowed to 'tap in' during the round. That is, when they tap the architect's shoulder they can trade places with the architect who then becomes an observer. You can 'tap in' as many times as you want during the round.
• Before starting the round the team is asked to strategize together on ways that they could improve their communication and their results.
• Once again the team times how long it takes for them to correctly finish replicating the drawing.

The teams enjoyed the challenge of working together to improve their communication strategies. The best solution that any team found was to have the observer 'tap in' whenever the builder put one piece in the correct spot. This strategy enabled the builder to easily understand when they had done something right (improving communication) and helped the team to improve their time. Hurray for the team!

This was a great exercise to promote team building, continuous improvement, strategizing, and to encourage the team to actively work on their communication skills. It reminds of some of the ways I have seen and used to help teams improve communication between roles. Does the developer have a hard time understanding the requirements document? Let's work on our documentation skills to make our writing clearer. Does the team struggle to meet it's project deadlines? Let's increase the project management rigour and status reporting. Are bugs found during user acceptance testing? Let's write a better test plan.

Or... have the architect (customer/business analyst/tester/project manager) turn around and talk to the builder (developer) directly. Break the rules (and your cubicle walls). Shorten the distance.