(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)
Thursday, August 23, 2007
How many products make up a project?
Software applications are often defined in advance as masses of features, loosely organized into modules and components. One of the things I do as a matter of course when starting a project is to count the number of products. A “product” is a piece of software that stands alone and delivers value. In the context of a big project, products are parts of the project that could, all by themselves, be projects.
For example, I was once working with a company that wanted to move their customer service operations from an old proprietary minicomputer system to a web system with an equally proprietary but much more current database back-end. They also wanted “workflow” while we were at it.
I pointed out that the web “port” was a product, and so was the workflow. You could build a workflow system that worked alongside the legacy software, and it would deliver business value. Or you could port the legacy application, and again deliver business value. So this project was really two separate products.
The value of drawing this distinction lies in understanding that the capacity of a team to effectively develop simultaneous products is nearly always one. That’s right, no matter what the size, teams are most effective when they work on one product at a time. And by teams, I mean the full team, including stake-holders, business analysts, everyone, not just the programmers.
When you work on one product, you have a clear vision, priorities are straightforward, you know when you’re “done”… It all works smoothly. When you work on two or more products simultaneously, all this falls apart in a hurry.
This is not about maximizing programmer productivity. In fact, it has nothing to do with programmers. It’s about a very scarce resource: management attention. Whether you are building a commercial application for an ISV or a client project for a government ministry, there is a very limited ability of the stake-holders to digest the project’s progress and contribute with feedback and priorities.
Developing multiple products simultaneously hits the stake-holders hard, forcing them to try to manage the relationships between them in their head, understand the impact of changes from one product onto another, and juggle twice as many documents and meetings.
The results are invariably poor.
So what to do? The answer is surprisingly easy. Divide large projects up into their natural products, then develop the products serially. Work out which product can be developed first, and then start with it, religiously rejecting attempts to extend it horizontally with features from the other products.
When it is done and delivering value, build on it by adding another product. Repeat until done.
As mentioned, this has nothing to do with programmers. It’s about maximizing the business’s benefit. This is the theory behind incremental delivery practices such as SCRUM, implemented at a coarse level.
And that project I mentioned? They ported the application, and in the process discovered many ways to extend it to add much more value than the workflow would have provided.
Software applications are often defined in advance as masses of features, loosely organized into modules and components. One of the things I do as a matter of course when starting a project is to count the number of products. A “product” is a piece of software that stands alone and delivers value. In the context of a big project, products are parts of the project that could, all by themselves, be projects.
For example, I was once working with a company that wanted to move their customer service operations from an old proprietary minicomputer system to a web system with an equally proprietary but much more current database back-end. They also wanted “workflow” while we were at it.
This is not about maximizing programmer productivity. In fact, it has nothing to do with programmers. It’s about a very scarce resource: management attention.
I pointed out that the web “port” was a product, and so was the workflow. You could build a workflow system that worked alongside the legacy software, and it would deliver business value. Or you could port the legacy application, and again deliver business value. So this project was really two separate products.
The value of drawing this distinction lies in understanding that the capacity of a team to effectively develop simultaneous products is nearly always one. That’s right, no matter what the size, teams are most effective when they work on one product at a time. And by teams, I mean the full team, including stake-holders, business analysts, everyone, not just the programmers.
When you work on one product, you have a clear vision, priorities are straightforward, you know when you’re “done”… It all works smoothly. When you work on two or more products simultaneously, all this falls apart in a hurry.
This is not about maximizing programmer productivity. In fact, it has nothing to do with programmers. It’s about a very scarce resource: management attention. Whether you are building a commercial application for an ISV or a client project for a government ministry, there is a very limited ability of the stake-holders to digest the project’s progress and contribute with feedback and priorities.
Developing multiple products simultaneously hits the stake-holders hard, forcing them to try to manage the relationships between them in their head, understand the impact of changes from one product onto another, and juggle twice as many documents and meetings.
The results are invariably poor.
So what to do? The answer is surprisingly easy. Divide large projects up into their natural products, then develop the products serially. Work out which product can be developed first, and then start with it, religiously rejecting attempts to extend it horizontally with features from the other products.
When it is done and delivering value, build on it by adding another product. Repeat until done.
As mentioned, this has nothing to do with programmers. It’s about maximizing the business’s benefit. This is the theory behind incremental delivery practices such as SCRUM, implemented at a coarse level.
And that project I mentioned? They ported the application, and in the process discovered many ways to extend it to add much more value than the workflow would have provided.
