Agile Lab - Training, Coaching and Consultancy Blog

Thursday, 10 December 2009 at

Getting the right project management method for Web Development

Many web development companies would accept that their approach to managing projects could be improved. But the project management methodologies that are out there don't seem to fit well with the real experience of delivering web development projects:

PRINCE2 (initially designed for large government IT projects) seems to focus almost entirely on the production of documentation and seems to have almost nothing to say about getting things done.

Agile methods (initially designed for large corporate IT projects) have a much better focus on getting software written, but seem to have very little to say about the integrative nature of web development.

My own solution, based many experiences of helping web development companies is to derive inspiration from Lean. Lean is the name given to a set of project management principles derived from the hugely successful way that the Toyota Motor company produce cars. Car manufacture might seem like an initially unpromising place to look for ideas on how to run a web development company, but concentrating on the principles of the Toyota Production System, Value, Flow, Poke Yoke (mistake proofing) and What is it? rather than the practices, produces a powerful set of approaches for substantially improving the effectiveness of a web development team.

Find out more about my course, and book a place here: "Building the Lean Web Development Team".

For further information, contact (07736 807 604)

Labels: , , , , , , ,

Wednesday, 9 December 2009 at

Building the Lean Web Development Team: Flow

How do you make sure that you're team is most effective and efficient that it can possibly be? Well, of course you can start by making sure that they're all kept busy all the time right? Hmm. Consider the following diagram:

lean concept of flow diagram

A diagram showing the Lean concept of flow

OK, the little balls represent little bits of work. The width of the "pipe" represent the capacity to deal with the work at different stages of the process. Here are some issues to consider at each stage of the process.

A to B for the customer - a long wait

What's important to the customer, what the customer experiences is end-to-end time. For the customer, all the blue dots aren't the same. Some of the blue dost are work that is being done for them and some of the blue dots are work that is being done for other people who they really don't care about. So for the customer, the speed that the individual blue dots get from A to B does matter. This is a big problem, because even if the system is working flat out, there's still a high likelihood of delays.

A to B for the team - it takes too long to learn

What's important to the team is end to end time. Certainly if there's to be any possibility of learning from one project to the next. Projects tend to take ages to finish, they're stopped and started, stopped and started and tend to end with a whimper rather than a bang. By that point, absolutely nobody is in a mood to go back over the project and see what went well, and what went badly. If a whole project could go from – say – start to finish in a couple of weeks, there'd be a lot more learning.

What's happening at C? The team.

Things which aren't good. The person or people who is trying to get work done at C is probably finding their work very stressful. No matter how hard they work, things don't seem to get any better. The person at C might be very tempted to try to cut corners and reduce the quality of their work as a way of reducing the backlog. This is far from good since, the bottleneck in many projects is the testing and/or release phases.

What's happening at C? The work.

And bad things are happening to the work that's piling up at C. Details of the work are being forgotten by the people who sent the work down the pipe, the situation outside the pipe that caused that work to be in the first place is changing. The work is "going stale". Even worse, it might be that work that's queuing up at C just gets forgotten and disappears.

Some solutions

  1. Make sure you have ONE good definitive list of all the work. Get it out of emails, get it off of post-its hidden under coasters, enter it straight after telephone conversations into whatever means you use to capture the work.
  2. Limit the work in progress. Have some kind of system for limiting the amount of work that is being dealt with by the team and ensuring that no new work is taken on until work that is currently in progress is finished. One way of doing this is to have a "Kanban" board which has only a limited number of slots on it for work that is being done.
  3. Focus on end-to-end time. Start counting. Take notice of how long each piece of work takes to get from started to finished. What are the points where a piece of work is in the system but no work is being done on it? Is lots of work piling up at that point.
  4. Change the process. A bit at a time. And understand that changing the process does not mean tell "everyone on the team to try harder" (especially the people at point C). Move extra people to stage of the process that causes the delay. Automate as much of that stage as can possibly be done (this works for both testing and deployment). Train addition members of the team so that they can help with this stage. Or [cue dramatic music] think about ways to remove that stage altogether.
  5. Encourage people to do things "other than work". When the pipe is full, the last thing you want to do is to have your team filling it with more work in progress. This might be a very good time for them to learn new skills (so they can help out at point C) or to "tidy up". Work on that build script, install that testing framework, experiment with that continuous integration server.

I cover this, and the other three crucial aspects of Lean in my course which is running on January 20th 2010 – "Building the Lean Web Development Team".

For further information, contact (07736 807 604)

Labels: , , ,

© Agile Lab, 2007-2009. All rights reserved.


Powered by Blogger

Subscribe to Posts [Atom]