Software development is both knowledge and art work, "productivity" implies both quality and quantity.
The Agile’s best advantage is its agility -the ability to adapt to the changes, being customer-centric, interactive communication and incremental improvement. However, from efficiency aspect, what is average Agile’s “Productivity Ratio”: What percentage of the team effort does directly contribute to produce working software? Is there any ideal ratio in the mind (such as 70 direct build /30 others, or 80/20 rule fit in?), or paradoxically, does such a ratio make sense or not.
Determining what "adds value" will be interesting and that different "customers" will have different perspectives. So start with a basic definition, direct value = "any activity that directly relates to the transformation of a "sprint ready story" into a fit-for-purpose software feature (both functional and non-functional)." There's a whole stack of activities - sprint planning, sprint reviews, retrospectives, daily scrums, defining acceptance test, etc. etc.. that fall outside of that definition, but that the teams still must do. Perhaps you can term that "in-direct value". Just understanding that rough split between direct and indirect would be interesting enough for starters. You could then get more discerning as you gather the metrics and dig deeper.
The Agile’s best advantage is its agility -the ability to adapt to the changes, being customer-centric, interactive communication and incremental improvement. However, from efficiency aspect, what is average Agile’s “Productivity Ratio”: What percentage of the team effort does directly contribute to produce working software? Is there any ideal ratio in the mind (such as 70 direct build /30 others, or 80/20 rule fit in?), or paradoxically, does such a ratio make sense or not.Determining what "adds value" will be interesting and that different "customers" will have different perspectives. So start with a basic definition, direct value = "any activity that directly relates to the transformation of a "sprint ready story" into a fit-for-purpose software feature (both functional and non-functional)." There's a whole stack of activities - sprint planning, sprint reviews, retrospectives, daily scrums, defining acceptance test, etc. etc.. that fall outside of that definition, but that the teams still must do. Perhaps you can term that "in-direct value". Just understanding that rough split between direct and indirect would be interesting enough for starters. You could then get more discerning as you gather the metrics and dig deeper.
Usually development time is multiplied with 2.5 to 3 to have an overview about cost for delivering the product. What ratio people target (if they do) or what the best teams - defined as those who've really focused on maximizing activities that add direct value to the customer and minimizing all other activities. It captures coarse-grained data about value-add time vs. total time, and provides an optimistic reading of ratio percentage. Although optimistic, the result can be useful and capture data in the same way for all the teams you're measuring. General rule of thumb? 80% time-on-task adding value to customers is about as good as you're going to get with most teams and that's in environments that place a high value on doing relative to the value they place on formal meetings.
It will be tough to assign a value to that without being specific about what "adds value" means. But it has prompted you to think more deeply about the definition of value and measuring the ratio of "direct value add" to "indirect value add.". Many Agile teams commonly spend 15-20% of their time working through design details and subsequently creating the limited artifacts to document the discussion and help the future folks that may have to do maintenance understand why things are the way they are. ALL such activity adds value in the sense that it helps provide a stable and robust product to the subscribers of business services. Sprint Retrospectives, on the other hand, are of great value to the team and help contribute to a high-performing team moving at a sustainable pace. And many activities are the elements of different stage of software development, the activities such a sprint planning often have an element of design; that requirements and development are closely tied; and trying to unpick these things with any accuracy in an Agile project will be a futile, time-consuming task, that adds no value to anybody but the bean counter ...
It will be tough to assign a value to that without being specific about what "adds value" means. But it has prompted you to think more deeply about the definition of value and measuring the ratio of "direct value add" to "indirect value add.". Many Agile teams commonly spend 15-20% of their time working through design details and subsequently creating the limited artifacts to document the discussion and help the future folks that may have to do maintenance understand why things are the way they are. ALL such activity adds value in the sense that it helps provide a stable and robust product to the subscribers of business services. Sprint Retrospectives, on the other hand, are of great value to the team and help contribute to a high-performing team moving at a sustainable pace. And many activities are the elements of different stage of software development, the activities such a sprint planning often have an element of design; that requirements and development are closely tied; and trying to unpick these things with any accuracy in an Agile project will be a futile, time-consuming task, that adds no value to anybody but the bean counter ...
Software development is knowledge work, and even art work, because the mind is learning (making discoveries) all the time, and it wouldn't really be possible to say which of these contribute in some way and which don't. So you could make the argument that this supports the idea that we spend nearly no time adding value, or you could make the argument that this supports the idea that we spend nearly all our time adding value. Hence, such productivity ratio can only be considered as an overview estimation, to help management plan thoughtfully, not an absolute performance management indicator to make it too rigid.
0 comments:
Post a Comment