My last project had a huge bottleneck at system acceptance test (SAT) stage - the SAT team was not able to sign-off stories at the same pace as the dev teams. Though I don't readily have the data, I am certain that the in-process time at the SAT stage was not high. Between the dev team completing the story and the SAT team picking it up were 2 steps - deployment into SAT Servers and showcasing these stories to SMEs and SAT team. Though we were deploying into SAT on a weekly basis, the showcases were done only once in 2 weeks.
There are 2 questions that bother me:
1. Is SAT the bottleneck? Is bottleneck identified purely by the inventory before that stage?
2. How can we ensure we manage the SAT process better?
My thoughts:
1. SAT is not the bottleneck here. If we define bottleneck as the number of stories that can be "processed" at a particular stage, given their ability to work full-time, SAT was not the bottleneck - as their ability to sign-off stories was high (demonstrated during the later iterations of the release). Even if we consider inventory as a measure, given that showcase is a mandatory step before SAT and showcase is done only once in 2 weeks, showcase could be the bottleneck. SAT is like the final assembly. What consumes time is not the assembly itself, but the wait for all parts to come through before they start.
2. I reckon one thing that can be done is: reduce the batch size. Do more showcases. Once a week maybe.
Monday, July 6, 2009
Wednesday, July 1, 2009
Prioritizing stories based on relative affordability
We use value delivered by the story as a primary measure of priority. Would it be more meaningful to consider Relative Value / Cost (relative affordability) as a formula for determining the priority of stories? Cost can be a relative measure of the complexity or effort for implementing and testing the story, determined by the development team (BAs and QAs) - in other words relative size of the story.
This relative affordability of a story gives us a measure of the worthiness of investing in a story. Judging purely based on value is inappropriate because the cost may be prohibitive.
This relative affordability of a story gives us a measure of the worthiness of investing in a story. Judging purely based on value is inappropriate because the cost may be prohibitive.
Estimating value of technical stories
How can we determine the value of a "technical story"?
As discussed below in the case for relative value: The value of a story derives from making the system more attractive for end customers. And that could either be developing a new feature or making the system scale better.
For technical stories that fall under non functional requirements (requirements being the key word here), it should be possible to establish their value based on the above definition. An extreme position would be to de-prioritize any NFR / story that cannot establish how it would make the system more attractive for end customers. There is a possibility that inadequate articulation of the value may lower the perceived value of a tech story. But hey, I would ask the tech guys to articulate the value in a different and better way rather than let it get in the back door.
Note: Value need not necessarily be limited to returns in the short term. Long term benefits should also be considered to be of value, in some cases, more valuable than short term gains.
As discussed below in the case for relative value: The value of a story derives from making the system more attractive for end customers. And that could either be developing a new feature or making the system scale better.
For technical stories that fall under non functional requirements (requirements being the key word here), it should be possible to establish their value based on the above definition. An extreme position would be to de-prioritize any NFR / story that cannot establish how it would make the system more attractive for end customers. There is a possibility that inadequate articulation of the value may lower the perceived value of a tech story. But hey, I would ask the tech guys to articulate the value in a different and better way rather than let it get in the back door.
Note: Value need not necessarily be limited to returns in the short term. Long term benefits should also be considered to be of value, in some cases, more valuable than short term gains.
The concept of Relative Value
One of the interesting things that Chaman brought to my notice was details around TOC and that Throughput should be measured as sales (Rs / dollars).
Now, most people see Throughput in terms of story points that the dev teams estimate for stories. This is natural but inconsistent with the spirit of TOC. Story points, no matter that they are nebulous and a relative measure, are estimated by the people doing the job (devs, qas, etc.). And that firmly land them on the cost side. While it is meaningful to get this estimate, for the purpose of measuring throughput in the context of TOC, we may find "value" estimate by business more appropriate.
Now, given that the stories are not independent units but assimilate into a larger system which is then sold to end customers or used by end customers, the value of a story can't be defined with precision. The value of a story derives from making the system more attractive for end customers. As this is an abstraction of "value", its estimation becomes subjective to interpretation and nailing it down with accuracy difficult. Hence, relative value. My suggestion would be to use the standard sizing / estimation concepts for this. With some changes. Get the business to answer 2 questions:
1. By implementing this story, how much more direct (and indirect) revenue will the system generate? If this cannot be determined quantitatively, then ask the second question:
2. By implementing this story, how qualitatively useful is it making the system for end users / customers?
Use triangulation to ensure the relative accuracy of these numbers. This should enable us to measure relative value being delivered every iteration and hence throughput.
Now, most people see Throughput in terms of story points that the dev teams estimate for stories. This is natural but inconsistent with the spirit of TOC. Story points, no matter that they are nebulous and a relative measure, are estimated by the people doing the job (devs, qas, etc.). And that firmly land them on the cost side. While it is meaningful to get this estimate, for the purpose of measuring throughput in the context of TOC, we may find "value" estimate by business more appropriate.
Now, given that the stories are not independent units but assimilate into a larger system which is then sold to end customers or used by end customers, the value of a story can't be defined with precision. The value of a story derives from making the system more attractive for end customers. As this is an abstraction of "value", its estimation becomes subjective to interpretation and nailing it down with accuracy difficult. Hence, relative value. My suggestion would be to use the standard sizing / estimation concepts for this. With some changes. Get the business to answer 2 questions:
1. By implementing this story, how much more direct (and indirect) revenue will the system generate? If this cannot be determined quantitatively, then ask the second question:
2. By implementing this story, how qualitatively useful is it making the system for end users / customers?
Use triangulation to ensure the relative accuracy of these numbers. This should enable us to measure relative value being delivered every iteration and hence throughput.
Tuesday, June 30, 2009
Why software development is not same as building bridges
I came across a very old post on itmweb titled: Why is software development not viewed as R&D, but more like manufacturing? (http://www.itmweb.com/ubb/Forum3/HTML/000010.html).
One of the replies to the post argues that software development is similar to engineering projects like building bridges. That view couldn't be more off.
Equating software development with building bridges doesn't make much sense to me. For one, building bridges needs a lot of upfront design because you cant change the bridge once built. Software continuously undergoes changes. There is very little that can't be changed / rewritten in software. I would also agree with diltondalton - in that designers and builders of a product are the same. Another way of saying that is that in software, the worker on the ground will have to continuously create as opposed to the very mechanical nature of the their equivalent's work when building bridges. In fact, you don't want the workers building bridges to think. Thats the designer's job.
I would also agree with the spirit of the original post. If you are pedantic, you would argue that it differs from R&D in a manufacturing company. But it most definitely is not the same as manufacturing. As we try and bring in more and more lean manufacturing practices into software development, that becomes all the more clear.
One of the replies to the post argues that software development is similar to engineering projects like building bridges. That view couldn't be more off.
Equating software development with building bridges doesn't make much sense to me. For one, building bridges needs a lot of upfront design because you cant change the bridge once built. Software continuously undergoes changes. There is very little that can't be changed / rewritten in software. I would also agree with diltondalton - in that designers and builders of a product are the same. Another way of saying that is that in software, the worker on the ground will have to continuously create as opposed to the very mechanical nature of the their equivalent's work when building bridges. In fact, you don't want the workers building bridges to think. Thats the designer's job.
I would also agree with the spirit of the original post. If you are pedantic, you would argue that it differs from R&D in a manufacturing company. But it most definitely is not the same as manufacturing. As we try and bring in more and more lean manufacturing practices into software development, that becomes all the more clear.
Monday, June 29, 2009
Caution when choosing Lean Manufacturing practices
When we picked up Toyota's lean practices for use in software development, we underestimated the differences between manufacturing assembly line (hereafter "the line") and software development. I have made an effort to list some of these here and emphasize why we should be cautious while choosing lean manufacturing practices into software development.
1. The line doesn't have any slack. You can't play AoE when the line is moving with units that need you to perform a task. By contrast, software development is asynchronous.
2. Work performed at different stages of the line are very small and always take the same effort - because work is done on a line that is moving. By contrast, work performed at different stages of software development runs into hours / days and varies based on the nature of the story in question
3. Stories though independent, are part of the whole (system). They can't exist independently nor be sold independent of the overall software system, unlike units manufactured on the line.
4. Chaman pointed out that software development is iterative in contrast to manufacturing.
5. The equivalent of software development in manufacturing is probably Product Research & Development (R&D) rather than the line itself.
I am sure there are many more differences. That said, we could as easily build a list of similarities. They key point is to be cognizant of the differences, and ensure we are cautious when choosing and implementing lean manufacturing practices in the software development context.
1. The line doesn't have any slack. You can't play AoE when the line is moving with units that need you to perform a task. By contrast, software development is asynchronous.
2. Work performed at different stages of the line are very small and always take the same effort - because work is done on a line that is moving. By contrast, work performed at different stages of software development runs into hours / days and varies based on the nature of the story in question
3. Stories though independent, are part of the whole (system). They can't exist independently nor be sold independent of the overall software system, unlike units manufactured on the line.
4. Chaman pointed out that software development is iterative in contrast to manufacturing.
5. The equivalent of software development in manufacturing is probably Product Research & Development (R&D) rather than the line itself.
I am sure there are many more differences. That said, we could as easily build a list of similarities. They key point is to be cognizant of the differences, and ensure we are cautious when choosing and implementing lean manufacturing practices in the software development context.
Subscribe to:
Posts (Atom)