Measuring progress in software development has always been up for debate. There was the waterfall era of Gantt Charts created using MS Project which used to breakdown effort into smaller work items with dependencies. These were easily outdated the very next day they were created.
The Agile community brought in the idea of user stories and doing them in small iterations. We then measured progress using a burn-up or burn-down chart which burnt either story points or ideal days. Soon, we started feeling the pain of the inventory we carried between releases which happened in a span of 3-6 months. This prompted us to measure and limit our work in progress and measure lead and cycle times across the delivery workflow.
Releases started becoming more frequent with technology advances in the cloud, virtualisation and deployment automation. The continuos delivery era came through with examples of people deploying almost everyday to production. Startups really needed this to validate their ideas in the market and course correct themselves based on market feedback. A/B testing became common place and measuring validated learning and cost of delay in deploying a feature made more sense for these new businesses.
Anyone can easily get confused trying to decide how one should measure progress or at least start with, in their project. There are 2 key variables in making this decision, the kind of relationship IT has with the Business, and the type of product ultimately being built.
So here is the quadrant I am talking about.
Outsourced / Utility (bottom left)
To the extreme left on the relationship axis is outsourcing your IT. Trust levels are fairly low. It could be a new IT vendor who has not delivered for the business. Work is probably happening outside the office or even the country where the business exists.
The extreme bottom of the product axis sit utility/internal applications which are mainly for keeping the business lights on. (Time Sheets, Payroll, Company intranet etc...). There is no market advantage to be gained by these. They are well defined internal business problems.
Partnership / Utility (bottom right)
Moving right on the relationship axis is only possible by building trust. And that is possible by delivering frequently to the business and also maintaining the people relationships at the right levels. A vendor who is treated as a mere supplier can become a trusted partner for well defined applications and their maintenance as they prove themselves to have the required expertise.
Partnership / Strategic (top right)
This is really the sweet spot. This is where the business has engaged IT to build a strategic product which is probably completely new to the market. It could also be a product that is struggling and badly in the need for new ideas. The IT here is a closely trusted partner which the business can rely on.
Given the volatile nature of what needs to be built, the need for agility is the highest here. Being able to deploy a new feature and rolling back as quickly as it was deployed, if hypothesis fails, is equally important.
Partnership / Outsourced (top left)
This hardly ever happens where a strategic business need for technology is outsourced to a less trusted supplier !
The Agile community brought in the idea of user stories and doing them in small iterations. We then measured progress using a burn-up or burn-down chart which burnt either story points or ideal days. Soon, we started feeling the pain of the inventory we carried between releases which happened in a span of 3-6 months. This prompted us to measure and limit our work in progress and measure lead and cycle times across the delivery workflow.
Releases started becoming more frequent with technology advances in the cloud, virtualisation and deployment automation. The continuos delivery era came through with examples of people deploying almost everyday to production. Startups really needed this to validate their ideas in the market and course correct themselves based on market feedback. A/B testing became common place and measuring validated learning and cost of delay in deploying a feature made more sense for these new businesses.
Anyone can easily get confused trying to decide how one should measure progress or at least start with, in their project. There are 2 key variables in making this decision, the kind of relationship IT has with the Business, and the type of product ultimately being built.
So here is the quadrant I am talking about.
To the extreme left on the relationship axis is outsourcing your IT. Trust levels are fairly low. It could be a new IT vendor who has not delivered for the business. Work is probably happening outside the office or even the country where the business exists.
The extreme bottom of the product axis sit utility/internal applications which are mainly for keeping the business lights on. (Time Sheets, Payroll, Company intranet etc...). There is no market advantage to be gained by these. They are well defined internal business problems.
Start with measuring progress in these cases using effort estimates such as Ideal Days, Story Points, T-Shirt sizes etc... A burn up chart should be a good indicator of where the project stands. Try to work on building enough trust which enables you to move to the right axis in terms of relationship.
Partnership / Utility (bottom right)
Moving right on the relationship axis is only possible by building trust. And that is possible by delivering frequently to the business and also maintaining the people relationships at the right levels. A vendor who is treated as a mere supplier can become a trusted partner for well defined applications and their maintenance as they prove themselves to have the required expertise.
Move progress measurements from effort based units to delivery efficiency based units. Optimise the workflow till production by minimising inventory you are carrying and reducing lead times. A Cumulative Flow Diagram (CFD) can provide the same view.
Partnership / Strategic (top right)
This is really the sweet spot. This is where the business has engaged IT to build a strategic product which is probably completely new to the market. It could also be a product that is struggling and badly in the need for new ideas. The IT here is a closely trusted partner which the business can rely on.
Given the volatile nature of what needs to be built, the need for agility is the highest here. Being able to deploy a new feature and rolling back as quickly as it was deployed, if hypothesis fails, is equally important.
Measure progress here using business outcome based units such as validated learnings and measuring cost of delay of a feature and the impact it has on the business.
Partnership / Outsourced (top left)
This hardly ever happens where a strategic business need for technology is outsourced to a less trusted supplier !