TDD Demo

I presented the Test Driven development in Excel demo at Agile Scotland last night. It went very well. The mistakes I made only served to get the audience more involved in the presentation by jumping in to help me out. Here are the slides and a review which have kindly been posted on Clarke Ching's site. Thanks Clarke.

Pair Programming

I wanted to tell you story a I recently heard about Pair Programming in the field:

A friend of mine, we'll call her Alice, has recently started working in a the offices of a small financial firm here in Dundee. She was asked to work on creating a financial report in Crystal Reports which would access the company database. The database schema is huge containing over 1000 tables and views and my friend knew that there was no way she was going to be able to learn enough about the database to produce the report on time. She is the only person in the organisation with enough Crystal experience to produce the report so I sugested she pair with someone who knows the database. She was hesitant at first but I explained that the combination of skills would help her meet her deadline.

Everything started well. Alice managed to get one of the database guys from another team, we'll call him Bob, to agree to pair with her. Alice and Bob sat at the same desk and sailed through the issues that came up. Alice could quickly sort out any Crystal report problems and was clear on the business need behind the report and Bob could sort out any problems with the logic in the query and the data that was returned. It was a perfect pairing combination of technical and business knowlege with just enough overlapping skills to be able to communicate together effectively.

Bob's manager wasn't so impressed. When she looked over all she saw were two people doing the same task. Two people that could be doing their own work and not wasting time sitting together. That night she decided to speak to Bob and sort this out. She asked Bob how Alice and he were getting on. Was he going to be doing the same thing tomorrow. Was he sure that it was necessary to sit with Alice. She suggested he install Crystal on his own machine to make it easier to work seperatly. She even suggested that Alice needed time by herself to learn on her own and implied that by pairing he was somehow holding her back.

Bob did what he thought was right, he wanted to please his manager, and told Alice that they couldn't pair any more. He told her how she had to learn for herself and that he couldn't waste the time pairing. Alice was hurt. The previous day had been a real sucess and she had come in full of enthusiasm to finish the report. The report suffered. Alice spent all the next morning struggelling with the subtle database issues and making little progress on the report itself. She finally got fed up and went to speak to Bob. She told him about the problems she had run into and asked him again if they could pair. Bob relented and they moved to the same desk. Progress on the report  leapt forward. They easily overcame any issues that came up and finished the report by the end of the day well before deadline. Pairing does work.

Bob's Manager, the customer of the report, is still unconvinvced about pairing but can't deny the obvious difference in progress. She was acting in the what she felt was in the best for the business, trying help make progress on the report faster but her actions had the exact opposite effect. There is a lack of understanding of the nature of the work on her behalf. If the report is the product of the work then this was a product development task not a product production taks. She failed to understand that.
Bob's manager isn't alone. This a reaction I've come across again and again when explaining Pair Prograqmming.

The problem is one of education, how to educate managers on the benifits of Pair programming. I've seen live demos but It's a difficult practise to demonstrate because you almost have to be in the pair to understand what's happening. I've seen some exercises on the web such as Industrial Logic's Pair Draw which may help in getting the point across and the articles at PairProgramming.com but I'm interested to hear what have you tried? How have you convinced both programmers and managers that Pairing is a good idea. What gave you the "Aha" moment when you learnt to Pair?

I'm going to try the pair draw exerceise with a group next week. I'll let you know how it goes.

"Project Backlog" is negative

A friend of mine recently pointed out that the term "Project Backlog" from scrum for the work still to be done in an Agile project has negative connitations. It sounds to non technical people like the project is behind, that there has been a build up of work and you're having to catch up. I think this is probably why Ken Schwaber chose that term, the project is only up to date when all work outstanding has been done, but I'm having a difficult time selling the idea to my customer and I think it is because of this negative connitation I hadn't previously thought about.

In the project I work on are in the enviable position to have spare development capacity and not enough customer capacity. Customers write stories for an iteration days, sometimes hours, before the iteration planning meeting and only have time to write one iterations worth of stories. The customers look at creating stories for the "backlog" as unncessesary because we're always crying out for more stories, why bother store them up. This is a big problem for us in development. We can't see what's coming up so design decisions often have to be reworked in the next iteration. Prioritising work to be done is missing becasue we just do the work when we get it. Design has to happen in the iteration where the work is done and we sometimes do work that wouldn't be necessary if we had a slightly longer term view of the upcoming work.

So I think it's time to rebrand the list of work still to do. Suggestions so far are "Work item list" or "Work Pool". I really llike the work pool name because it creates an image of something that has the same properties as I want from my list of "work to do". Diving into an empty pool is obviously dangerous. If a developer runs out of work they can dip into the work pool and many other useful management metophors. I'm sure you can think of others.

Let me know what you think and any other names you can think of.

Pete