Pols Consulting

Have you every wondered what the acronym UTC stood for?  I came across this little gem in the Javadocs for Solr today:

In 1970 the Coordinated Universal Time system was devised by an international advisory group of technical experts within the International Telecommunication Union (ITU). The ITU felt it was best to designate a single abbreviation for use in all languages in order to minimize confusion. Since unanimous agreement could not be achieved on using either the English word order, CUT, or the French word order, TUC, the acronym UTC was chosen as a compromise.

See, you can have fun reading documentation!

Luke Hohmann is in London and has agreed to come along to XTC on the 17th November to describe and play some of his Innovation Games.

I became hooked on Innovation Games when I read an early draft of Luke’s book. Customers can’t always tell you what they want because sometimes they don’t know themselves, so asking them to rank requirements or write stories might not be the best place to start. I’ve found using Innovation Games really helps with situations like this. Luke has lots of practical ideas for Agile Teams.

Talk starts at 7:30 on the 17th Nov at  Zuhlke Engineering’s offices  (43 Whitfield Street, London W1T 4HD).

It’s free, but please signup on the XTC website so we get an idea of numbers.

Many thanks to Luke for doing this and Keith Braithwaite for kindly offerring the use of the Zulke offices to run this session (knowing Luke, there will be lots of noisy audience participation so our usual pub venue wouldn’t work too well).

We were so lucky to get Dave Snowden as an XPDay keynote back in 2004.  One of the memorable moments was when he used the metaphor of organising a childrens party to explain the various approches to managing complexity.  It certainly resonated with the audience (based on the conversation in pub afterwards – a wonderful XP day tradition!).

Dave’s now uploaded a version to YouTube… Fantastic stuff. I love the deadpan humour.

I have always been a fan of teams sharing experience and knowledge within a company. It’s a great way to learn new techniques, find our how people have solved similar problems and discover who’s doing cool things in your organisation.

Today I witnessed a session on agile software testing that made be rethink this.

The key problem was that the person had been told to do it – it was not something he volunteered to do. He had no passion about the subject.

He started berating the audience for producing “crap”. Not the best technique for wining people over to your point of view!

It also appeared that he didn’t have much experience in using test driven development techniques (as he had some rather strange viewpoints).

Perhaps this is an indication of the corporate culture?

“Predictably Irrational: The Hidden Forces That Shape Our Decisions” by Dan Ariely is one of the best books I’ve read for a long time. Here he is talking about it at TED.

While on the subject of decision making, Joachim de Posada shares a landmark experiment on delayed gratification — and how it can predict future success. With fascinating video of children trying their hardest not to eat the marshmallow. I must read more about this.

I’m also interested in what’s happening as the worlds of TV and the internet collide. So this one by Peter Hirshberg also caught my attention.

After moving all my source code to GitHub, I wanted to build it on my Bamboo build server – especially now that it lets you run the build agents on Amazon’s Elastic Compute Cloud (EC2).

Bamboo does not support git repositories out of the box. I found this Git Repository Plugin by Atlassian’s Don Brown, but it didn’t like the GitHub style repository URL’s when I tried it.

So I wrote my own GitHub repository plugin that is fully integrated with GitHub:

• Adds the option “GitHub” to the list of available repositories when you add or edit a build plan.
• Shows the changes that triggered the build.
• Links the code changes back to the GitHub page containing the commit/diff.
• Trigger the build via a GitHub Service Hook (Fires service hook on each commit)

See the plugin wiki for some screenshots and installation instructions.

Mark has been explaining Solutions Focus to me for a while. It has some really compelling ideas and techniques that Agile people will find useful. So I thought it would be great to get Mark to come along to XTC and explain it himself.

Talk starts at 7:30 on the 13th Jan at The Counting House pub (50 Cornhill, London, EC3V 3PD).  It’s free, but please  signup on the XTC website.

Just to whet your appetite:

The Solutions Focus approach is creating a stir in the fields of psychology and management. Whereas conventional approaches assume stable environments and predicable outcomes, SF is bringing a new, simple and effective flavour to the workplace and the therapy room with a view on ways to make progress while everything changes. Surprisingly, the approach is as effective, if not more so, than conventional methods.

In this session Mark will share his experiences of using SF in many business settings and help us to experience the approach in some quick interactive exercises. We will discuss how SF sits alongside Agile, how the two philosophies reflect each other and how Agile processes like retrospectives might be even more agile with the inclusion of some SF techniques. This will be a session to appeal to both the pragmatist and the philosophical.

I remember having a rant at the eXtreme Tuesday Club a few years ago, “Who cares about working software, if it’s not what the business need? Delivering Business Value is the most important thing!”

This was triggered from seeing too many agile teams get bogged down in the minutiae of the process.  They did not think about how the business would benefit from what they did or how they could deliver value early.  Delivering working software was the only important measure they cared about.  They missed the subtlety of the Agile Manifesto that talked about delivering valuable software:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

I saw several agile projects that delivered software the business did not want.  Chris Matts and I made it our mission to bang on about Business Value back at the Agile Development Conference in 2003.  We published a paper in Cutter in 2004 based on our experience of applying these ideas on our projects.

It’s great that this is starting to get traction in the agile community.  There was even a whole track dedicated to this very subject at Agile 2008.  This has to be a good thing.

On reflection, I think the moniker Business Value was a mistake as it confuses the conversation.  People start assigning a Value to what they do:

• This project will attract 120 new registrations per month This statement is expressed as an absolute rather than a model. The greatest problem with this statement is that it’s impossible to re-evaluate the business value if market conditions change. There is no mention of the cost of generating this revenue or the amount of capital investment required to generate the revenue.
• This project is worth $12M
• This project with generate 4 million page hits in the first year.

Several speakers at Agile 2008 talked about business value Story Points. Joe Little proposed assigning Business Value points to each item in a backlog.  My experience is that this consumes a vast amount of energy and the business people start making up large values to game the prioritization process (Luke Hohmann has a nice posting on why prioritizing the backlog by ROI like this does not work).

I really enjoy watching the BBC television series Dragon’s Den.  Entrepreneurs pitch for investment in the Den from five Angel Investors (The Dragons!), willing to invest their own money in exchange for equity.  When the Entrepreneurs provide a Value, the dragons always probe for the model:  ”How much does it cost to manufacture?”,  ”What’s the size of the market?”, “What form of distribution channel are you using?”, “So how did you come to value your business at $8 Million?”, etc.  It’s impossible for the Dragons to make a sensible investment decision from a simple value.

This is why chris and I always say Business Value is a Model, not a number.

Software development is also an investment and, just like the Dragons (although I’m not suggesting our customers are dragons!), the Business need to probe the model to assess the value of the software investment.

Another problem is the model is is a state of flux.  Few businesses exist in a vacuum.  Markets change, assumptions become invalidated and competitors launch disruptive technology.  If you assign a value to a story based on a model, there is a danger that the model’s assumptions have changed by the time you want to implement it.  People take the business value number for granted and rarely question its validity.  I prefer a less formal approach, and simply use the model as a litmus test to verify if the next chunk of work makes sense as and when you need it.

Creating solutions that deliver the maximum business value should be the primary purpose of what every development team does, regardless of their process.  It’s more then just consuming stories or taking for granted that the items in the product backlog make sense.

One of my clients was telling me about the problems that they are having with “Aspirational Planning“.  I thought this was an excellent description of the problems lots of organisations have with planning.

Then it slowly dawned on me that he was serious – they really do create “Aspirational Plans”.  They are fully aware that they don’t reflect reality (as they take so long to prepare), but the senior management love to spend lots of time and (other people’s energy) creating detailed plans of what may or may not happen one day.

The teams on the ground just roll their eyes when I ask about these plans. I’m going to have my work cut out on this one.

The old bambinos made me laugh with this suggestion.

An improvement on XP’s stand-up meeting, or scrum’s daily scrum is the New Bamboo Hang Up Meeting. You are only allowed to talk while performing pull ups from a steel girder. Not only does this keep the meeting short, but ensures the team reamins physically fit