planning

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.

Have you considered the cost of context switching

  • Tuesday, 24 March, 2009
  • By:

One of the great things with running a project with Microsoft Project is that it enables you to allocate resources to activities and you can assign the time they work on each activity.  A resource can then work on several projects at the same time, 50% on project A, 50% on project B.

With this ability it is easier to accommodate multiple projects that the business request.  Rather than having to say we can’t start on a project in six months when the current one finishes, we can run both projects at the same time, using the same resources.  We can do things in parallel rather than in series.

Only it doesn’t really work like that.

One of the great things with running a project with Microsoft project is that it enables you to allocate resources in a way that hinders productivity, effective planning and quality.

The problem is with context switching and the overhead that multi-tasking brings.  This article succinctly describes the problem.

No matter how efficient you think you are, multitasking comes with a high cost. Because we’re people, we don’t swap out the content of our brains as easily as a computer does, and we definitely don’t swap in the old state when we’re ready to return to the original task.

Gerald Weinberg, in Quality Software Management, Vol. 1, Systems Thinking (Dorset House, 1992), estimates the context-switching cost among three tasks to be 40 percent. That means that 40 percent of your available work time is spent on non-task activities. The rest of the time is split among the three projects. So, if you thought that in a 45-hour week, you could spend 15 hours on each of three tasks, don’t kid yourself. You’re really spending eight hours on project A; eight hours on project B; eight hours on project C; and 24 hours context-switching, figuring out where you were and what you have to do next. The time spent on each project works out to about half of what you expected.

So whilst it is easy to appear to please business sponsors by taking multiple projects on at the same time, and the model of working in parallel rather than in series being a politically favourable approach, in fact the costs of multi-tasking far outweigh the benefits.

What is the story?

  • Tuesday, 13 January, 2009
  • By:

One of the problems with IT development is that it is tactical and piecemeal in its approach. Functionality is added in response to competitor or broader market activity. Expect to see an increasing number of brands doing something ‘social’ (and tactical) on the web, but don’t expect these new initiatives to be (strategic) seamlessly integrated into the existing digital channel offering.

This piecemeal approach extends to larger initiatives as well. In refreshing the website or developing new digital channels such as mobile and TV, IT will typically build out features and functionality prioritised upon their perceived individual business value regardless of what the sum value of the proposed release is. (Focusing all your effort of building functionality that delivers to your bottom line will seldom be as successful as you predict if it is not supported by features that meet the customers needs).

So when it comes to thinking about new features and functionality, where’s the best place to start? I’d suggest collaboratively, thinking around the customer. Collaboration is important to ensure that everyone starts with the same vision. It needs to be shared it with the broader audience, the product teams, IT; anyone whose day to life life will be touched by the project when it starts. I’d argue that you cannot start this soon enough. You don’t need to spend time doing analysis, interviewing all stakeholders individually, coming up with a document that is circulated and reviewed and re-written (with all the delays and waste that such a process incurs). Start the process getting all those stakeholders off-site for an afternoon and get the thoughts out on the table.

Commence with a presentation that introduces thinking in terms of customers and customer journeys. The below SlideShare presentation does this for the airline industry, addressing a new customer experience across channels. I acknowledge that it is pretty simple and doesn’t touch on half the ideas that airline executives may have. That is the point, it is just enough to get people thinking about different customer types and their touchpoints without getting bogged down in detail. This is what we want the participants of the off-site to share.

[slideshare id=912224&doc=airline-deck1-1231817842408345-3&w=425]

Once we’ve been through the presentation we break out into small groups a, each taking an individual customer (or persona) and build up a story; a day in the life of… (It is important not to forget the internal users of the system). These breakouts last 15-20 minutes with ten minutes for the team to play back their findings. As they build out a richer picture of the customer interactions they are asked to sketch out what the user interfaces may look like. The process is rapid, intense and iterative, but always focussing upon the customer journey; how will the customer realise their goals. When the teams tell their stories an analyst captures the essence of the requirements on index cards. The final exercise is to lay all these cards on the table and ask the team to group them into similar areas then prioritise them according to their perceived importance. In an afternoon you will have achieved four things. Firstly, you will have captured a vision for the new product in less than a day, with all stakeholders understanding not only the vision itself, but also the process that developed it and the concerns and issues that different parts of the business have with it. Secondly you will have an initial prioritised roadmap for its development. This will change, but it is a good strawman to circulate. Thirdly you will have introduced all the stakeholders together – projects succeed or fail based upon the strength of relationships and getting people engaged from the start will go a long way to creating shared ownership. And finally you will have generated energy, engagement and traction; to do the business case and to get the project started, recognising that just one part of the business having a vision is not going to bring it to the life that they dream.