expectations

You need to accelerate and change gear to get up to speed

  • Thursday, 20 August, 2009
  • By:

Velocity is a simple concept to grasp when planning and managing an agile project.  It is one of the first formula you learn in maths (or is it physics), speed equals distance over time.  On a project the distance is scope, measured in the number of ‘points’ you need to complete.  So if the team has a hundred points worth of scope and a velocity of ten, they will complete distance (scope) in ten weeks.  It’s a simple calculation, but is dangerous and wrong.  It fails to take into account acceleration.

Just in the same way that it takes a car time to accelerate to a meaningful speed, so a project takes time to reach it’s planned velocity.  To reach 60 miles an hour takes ten seconds and means moving through the gears.  You don’t put your foot on the accelerator and suddenly find yourself doing sixty.  Nor do you put the car into forth gear and expect to move without stalling.  It is the same in agile projects.  Velocity is misunderstood; you cannot expect to have your planned velocity immediately without acceleration.  Similarly, putting a fall sized team onto a project is like trying to start in forth gear.  You will stall.

When planning an agile project you need to consider acceleration.  The first iterations will be slow as you come up to speed.  Secondly you need to be in the right gear for where you are at.  Start in first (small team) and change gear (ramp the team up) as the velocity requires it.  Better to have the engine screaming in first (change gear) than to have it stall before it’s even got going.

Sadly, this means the simple pictures on burn-up and burn-down charts are wrong.  They need to take into consideration acceleration and appropriate gearing.  And that is advanced maths.

Are you managing expectations beyond the team?

  • Monday, 30 March, 2009
  • By:

There’s this idea called the Disconfirmation of expectations theory that states that having unrealistically high expectations from the adoption of a new IT application will result in lower levels of realised benefits.  Get customers excited about a new product and fail to deliver on it and you will have unsatisfied customers.  And unsatisfied customers are unlikely to use the product to its full advantage.

There is a risk with products developed using agile approaches that they fail to deliver on their initial promise.  The immediate stakeholders know that the product will evolve incrementally, but is this true of the broader audience? Are they aware of the intended regular heartbeat of delivery or are they expecting a fully featured product at the first release.  How are you managing expectations beyond the immediate product team?

Be wary of what you say early on.  Creating a vision is essential but be mindful of how this is communicated. Early demos, proof of concepts, prototypes, wireframes often show a vision of the end goal, several releases into the future.  Words are easily forgotten, explaining that this is an end goal vision is not enough, you must show a vision of what the cut-down product for the first release is and ensure it is appropriately communicated.

Expectations work both ways, it is easy for the business to tell IT their requirements and assume they will be developed in their entireity in one go.  Similarly it is easy for agile developers to expect the business to understand their incremental approach to delivery. The key to success is effective change management; identifying all stakeholders (both core and peripheral) and create a culture of agility that goes beyond the immediate project team.  In a large organisation that maintains more traditional approaches, agile projects must be supported by a well designed communication plan that builds the relationship between both IT and the business. Identify whose life will be touched by the product and develop a strategy for communicating to them.  This doesn’t mean “they can see what is going on on the project Wiki” this means someone taking responsilibity for listening, engaging and evangelising on the product, the project and its goals.

Musical call tones and my mental model

  • Sunday, 15 February, 2009
  • By:

Musical call tones when you are waiting to be connected to the person you are calling are great from a marketing and technical point of view, but they are inconsistent with (many) user expectations.  Does this mean they are wrong? Is there a cultural or demographic dimension to this?

I have a mental model for the way that phones work.  I dial a number and get a mechanical ‘brrrr-brrrr’ tone.  In some countries it is a simple sine wave tone, but it is a recognisable feedback mechanism that lets me know that the call is waiting for the person (or machine) at the other end of the line to answer it.  If I get a single tone it means the line is engaged or can’t be connected.

I’ve another mental model about music being played to me on the phone.  It means that I’ve been connected to the other person and have been put on hold.  If I have initiated the call, and it is not a free number, it is costing me to listen to the music.

In China, Hong Kong and Singapore musical call tones are becoming increasingly popular.  Instead of the mechanical brrr-brrr you get a song that the person you are calling has selected.  The first time I got this I was calling a colleague in China and I immediately put the phone down.  Was I being charged for this? I associated the music with being on hold, and I didn’t want that on an international call.  The musical call tone broke my long established mental model of how a phone works. That caused cognitive dissonance and I didn’t like that.

To my knowledge, none of the UK telco providers offer this service.  Could this be because consumers would find it hard to accept it?  If so, why is it so popular in China?  Ubiquitous phone ownership is relatively new in China, could it be true that they don’t have such an ingrained mental model of what a waiting call tone should sound like?  Or is it (more likely) an age thing.  I’m just too too conditioned with my ‘brrr-brrr’ and youth the world over will cast it away in favour of whatever is top of the download chart. (Eeugch, I’m sounding old!).