Home > Agile > timely communication

timely communication

Last night Mike and I traveled from Chester to London to see the Michael Vincent lecture at International Magic.  It may seem like a long trip to see a lecture, especially knowing that we would be on the 7:10 train this morning to get back to work, but Michael is a wonderful lecturer and great magician.  Unfortunately there were signalling problems on the lines which caused delays to our journey and resulted in us missing the first half of the lecture.  The way the delays were handled led to an interesting discussion about sharing information and the correlations to delivering software.

We heard a rumour when we got on the train that there were signaling problems, but being that there was no announcement, we assumed that things were fine.  We pulled out of Chester on schedule and only just before arriving in Crewe was the first announcement made.  It looked as though the delays were going to be quite severe.  We were about to head back to Chester when a second announcement was made:  there was a train leaving now for London that would take an hour and forty minutes.  We did the math and saw that we would only miss a few minutes of the lecture.  We ran to the platform, found seats and soon were under way.  As the train pulled out of the station, the train manager announced that due to the signaling problems they could not estimate when we would arrive in London.  It was too late, we were committed to the journey!

Mike and I started discussing how this was handled and the similarities that can be drawn to delivering software.  The staff were all very pleasant and apologetic, but there had been one glaring mistake that was made… they waited too long to share information with the passengers.  Why was this?

Quite possibly because they made an assumption that everyone on the train had the same goal:  to travel to London before the next day.  If that assumption was true, then a delay of an hour, two hours or even 4 hours wouldn’t matter.  We would still all make it to London and it was better than waiting until the next day.  The problem is that wasn’t the goal for everyone on the train, Mike and I were traveling for the lecture.  If we arrived in London too late, the journey would be of no benefit and would have cost us time and money.  We often see a similar situation in software delivery, the importance of time to market.  If a piece of software takes too long, it may not provide the benefits that were originally set out to achieve.  The right decision may be to invest the time and money in something else.

Who is at fault here?  The delivery team? The business? Both? Neither?  It doesn’t really matter, the important thing is to avoid situations where decisions are made too late and by the wrong people.  It is a two way street and to have the best chance of a successful engagement, all parties need to share information. Stakeholders, by sharing your true goals behind the project, the delivery team is better equipped to know what information is important to you and when you need it. Delivery team, if in doubt share information and share it early.  Allow your stakeholders to make the decisions that they need to make and understand when it might not be what you hoped.  In the long run the relationship will be better off for it, and there will be many successful deliveries (they may just not be what you originally planned).

Categories: Agile
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: