Insights and outlooks on software development


On time or functionality

Saturday, June 27, 2009 by Thomas L

 1107168876_a1cd450cb8_o One rule in agile software development is:

Quality - Time - Functionality - you can have only two

This generally means that it is impossible to have fixed time and fixed scope, at the same time as you keep a high quality. Of course, there are times where you are lucky and made the full scope on the specified time at the same time as you have a high quality. However, generally, when you enter a project, it's not wise to promise all of these three.

Another rule that I tend to think is hyper-important when developing software is that quality always should be a primary focus. This actually reduces the rule above to:

Time or Functionality - you can have only one

If we widen the scope to include project management outside of the software development arena, we usually have one more parameter, which is resources (or cost). This means that in a building project, it's possible to increase the throughput in a project by adding more people or working overtime.

Adding resources to a project is hard to do when you do software development. If you impose overtime on your developers, they will be more tired and will take worse decisions in the continuous design process that is software development, and if you add more people, your throughput will go down in the short run since the new people will need training from the original project members.

This means that you have a choice when planning a release, either Time or Functionality. What to choose? That's hard to answer generally. I tend to like projects releasing in a continuous takt, like Ubuntu's 6 months lead-time. It gives customers and project members predictability in the planning of e.g. when you are doing upgrades or trainings. However, it's entirely possible to use agile processes to deliver both release types.

Technorati Tags: ,

Filed under , having  

0 kommentarer: