Andy Pols CTO, Entrepreneur

Some random thoughts...

Two Phase Commit is just like a wedding

Michael Thorpe told me about this wonderful explanation of two stage commits (from the book Transaction Processing : Concepts and Techniques):

The chapter on two phase commit compared it to a wedding with the minister being the commit point. “do you take this man” (vote to commit) - yes, then PREPARE to commit, “do you take this woman” (vote to commit) - yes, then PREPARE to commit. “Anyone out there have a good reason not to do this?”  no, then “I pronounce you man and wife” - transaction is committed.

Fearless Change

I’m reading the excellent book Fearless Change by Mary Lynn Manns and Linda Rising. It’s a book of patterns for introducing new ideas.

I’m experimenting with the patterns to help me introduce agile developement into organisations. So far so good. I recommend it. They have an interesting quote from David Baum’s Lightning in a Bottle.

If your change process is like most, about 15% of your folks are going to be thrilled and will only want to know what took you so long. About 15% will utterly reject the need for change, and won’t be happy no matter what you do. The remaining 70% will sit on the fence and quietly watch to see who’s winning.

This middle 70% is where you need to put your most time and energy. That is where the victories really count. The 15% who are positively excited will need very little support and encouragement. They are already motivated by the change. For the negative 15%, there may be nothing you can do.

How true.

Thinking in an Agile way

Continuing on the theme of breaking the self imposed rules I heard a wonderful story about a team working in an environment that involved a customer requirement to provide an audit trail of all project design decisions.

This was a real rule.

Many teams would interpret this as a requirement to have lots of heavy documentation and associated traceability. This would have been a self imposed rule.

This team solved the requirement in a wonderfully low energy way. They simply hung a long roll of brown butcher’s paper around the room. Whenever people on the team made a decision, they made a note of it on the paper, dated it and signed it. This acted as a short term information radiator of team decisions. Once it was full, they rolled it up, marked it with the date range and filled in it the corner of the room.

The auditor loved it as it was quick and easy to see what was happening over time.

Focusing On Business Value

Here are some tips I picked up this week from a friend. He has just started at a new company. His new company has lots of projects without any clear indication of their business value.

So he got them to draw a matrix like this and place their project in the appropriate box:

</table> This really helped people think about the business value. Just trying to justify the position in the box, makes you think about the value of the project. We're not just doing projects for doing them sake (hopefully). It was surprising how many high-risk, low value projects appeared on the grid! You can now ask "Why are we doing these?", followed by, "Shouldn't we be investing our energy elsewhere?" The best bit of advice came at the end. I asked him, "But won't they simply do the chart to humour you, and then return to their old ways?" "Don't be silly, I'll just keep giving people more work until they stop working on non-important stuff!" Still, I thought it was an interesting technique that was worth sharing.
Low Value To Customer High Value To Customer
Low Risk
High Risk

Task Estimating Techniques

I have noticed a couple of common problems when the team meet the business to estimate what they are going to do next:

  • There is too much talking and the estimating takes far too long.
  • It does not involve the whole team. Some people don’t feel confident to participate while others dominate the proceedings.

Here is a little technique that is worth trying if you find yourself in this situation:

  • Get someone to read out and quickly explain the task that needs estimating.
  • On a count of three (as if playing Rock, Paper, Scissors!), each developer presents a hand showing their estimate with a finger representing a unit of work. If you feel that the task is too big for 5 units of work, simply break the task down and repeat for the smaller tasks.
  • We take an average of the team estimates.

The nice thing about this is that it is quick, fun and appears to provides reasonably accurate estimates (probably because it involves everyone).