After finishing Goldratt's first book, the Goal, I immediately jumped to David Anderson's book on Applying TOC in Agile Management. Preetam also has left some interesting comments on my blog on the differences between s/w and manufacturing which should not be neglected.
One important thing which is still puzzling me at this stage is, if you have to account for throughput, how do you measure value. Value here is the value of a story or a feature. If you are a services shop building an application for a customer, it is upto the customer to determine this business value of a story. Quite often this is not easy to determine, specifically for people like Subject Matter Experts you are dealing with to gather your requirements, who do not deal with sales at all.
In a manufacturing plant, if you have signed a contract to deliver 10 cars for say $100,000. The cost of an engine still waiting in the queue (work in progress) is almost equal to the value of 1 car, $10,000. However the similar analogy is not easily applicable to a software development team. If a story is in progress, it cannot be easily translated to how much $$ is part of inventory.The story might be part of a bigger feature. Also, determining the business value for that feature in $$ itself can be tricky
David's book touches upon in-house IT shops providing IT services (eg: SaaS) or implementing a software product. In these cases, revenue from Sales can be directly mapped to what is being developed. Which is what should happen, in order to increase the throughput of the system, and hence increase the revenue. This is not the case when you are providing IT services to other clients (not in-house).
Some might say you can use story estimate (ideal days or points). Again this represents cost and not value. The iterative nature of Agile also makes it difficult to apply the same principles as a manufacturing plant.
While I am still looking for some answers, the learning on how to deal with bottlenecks, optimizing the whole system, and applying the same to software development, from both the books, are still quite useful.
One important thing which is still puzzling me at this stage is, if you have to account for throughput, how do you measure value. Value here is the value of a story or a feature. If you are a services shop building an application for a customer, it is upto the customer to determine this business value of a story. Quite often this is not easy to determine, specifically for people like Subject Matter Experts you are dealing with to gather your requirements, who do not deal with sales at all.
In a manufacturing plant, if you have signed a contract to deliver 10 cars for say $100,000. The cost of an engine still waiting in the queue (work in progress) is almost equal to the value of 1 car, $10,000. However the similar analogy is not easily applicable to a software development team. If a story is in progress, it cannot be easily translated to how much $$ is part of inventory.The story might be part of a bigger feature. Also, determining the business value for that feature in $$ itself can be tricky
David's book touches upon in-house IT shops providing IT services (eg: SaaS) or implementing a software product. In these cases, revenue from Sales can be directly mapped to what is being developed. Which is what should happen, in order to increase the throughput of the system, and hence increase the revenue. This is not the case when you are providing IT services to other clients (not in-house).
Some might say you can use story estimate (ideal days or points). Again this represents cost and not value. The iterative nature of Agile also makes it difficult to apply the same principles as a manufacturing plant.
While I am still looking for some answers, the learning on how to deal with bottlenecks, optimizing the whole system, and applying the same to software development, from both the books, are still quite useful.
No comments:
Post a Comment