1
2
3	Background The objective of this presentation is to explore a measure that at first glance seems very simple. When talking to organizations about process improvement, a question often asked is “How will this improve our productivity?” This is a simple question, but to answer it, we need to explore the meaning of the productivity measure.
4	Productivity: The Classic Definition Webster’s dictionary defines productivity as: pro·duc·tiv·i·ty - The rate at which goods or services are produced, especially output per unit of labor. For software products, productivity is generally considered to be the ratio of two measures: How much can be produced? (a size measure) How long does it take to produce it? (a time measure) The size measure is usually Lines of Code (LOC) and the time measure is usually hours. Productivity is most frequently measured as LOC/Hour.
5	Operational Definition of Measures But as with every other simple measure, everything is not as easy as it appears on the surface. First, we need operational definitions of the measures for size and time. For example, Lines of Code (LOC) is a frequently used measure for the size of a software product. How is a line of code defined?
6	Size -1 When defining what a LOC is, consider whether to count logical vs. physical lines of code comments Non-executable LOC Programming language must be considered. An assembly LOC is not the same as a C# LOC Programming language specific standards would help ensure a uniform size accounting. Was the code written using common coding standards? Was the code counted using common counting standards?
7	Size -2 Also consider the type of LOC being counted New LOC? Modified LOC? Deleted LOC? Base LOC? Reused LOC? Also consider the impact of design. A good design may produce tighter, smaller code. What seemed like a simple measure on the surface turns out to be rather complex. And remember, LOC is just one of dozens of size measures that may be used.
8	Productivity and Software Size Consider two teams: Both teams have the same number of team members, use the same programming language, and work in the same organization. Project A makes 10,000 LOC enhancements to a 5-million LOC legacy system. Project B writes a brand new 10,000 LOC system. Both teams finish in the same amount of time. Which team is more productive, as measured by LOC/Hour?
9	Time When measuring time, several questions arise. Elapsed calendar time (end date – start date)? Actual days worked? Time card entries? How do you account for people working on multiple projects? The most accurate way to measure time is to measure actual time-on-task (task time).
10	Task Time -1 Task time is defined as the time spent on tasks that are enumerated in the task plan (project plan) for a project. On typical software projects, task time includes design reviews and inspections coding testing design meetings Task hours do not include many unplanned but necessary tasks meetings courses task coordination advice and assistance handling e-mail, supplies, expenses, etc. hallway conversations surfing the web Teams can estimate task hours, but planning the other activities is guesswork. When measured, tracked, and managed, task hours can often be improved.
11	Task Time -2
12	Where Does the Time Go?
13	Managing Task Hours Task hours can only be improved by the people doing the work. quiet time process documentation more efficient meetings administrative support work-at-home days To do so, they need management support. Task hour improvement costs little or nothing. The following slides show task-hour improvements from teams using the SEI’s Team Software Process (TSP).
14	Improving Task Hours -1 Average task hours per developer per week were improved from 9.6 hours to 15.1 hours.
15	Improving Task Hours -2 Average task hours per developer per week were improved from 11.1 hours to 16.2 hours.
16	Improving Task Hours -3 Average weekly task hours for cycle 1 (weeks 1-14) were 11.36. Average weekly task hours for cycle 2 (weeks 15-49) were 15.77.
17	Productivity and Task Time These teams improved their average weekly task hours Improvement range was from 39% to 57% But did the teams improve their productivity, as measured in LOC/Hour?
18	Unbalanced Workload When project plans are created, resource loading is often unbalanced.
19	Load Balancing During a TSP launch, team members actively seek to balance the team work. Such ruthless load balancing can only be achieved by team members themselves.
20	Balanced Plan
21	Load Balancing and Productivity A project that would have taken about 17 weeks to complete could now finish in 11 weeks. What is the impact on productivity?
22	Code Complete On most projects, an important milestone is the “Code Complete” milestone. This milestone means development work is complete, and the product, feature, or component is ready for system test. Consider two teams, Team A and Team B same number of team members working on identical projects reach “code-complete” milestones at the same time Both teams have the same productivity, right?
23	System Test Defects Typical software projects spend 40% - 50% of their effort in system test. The bulk of the time spent in system test is not validating the product. Instead, the majority of this time is spent in finding and fixing defects found in system test.
24	Quality TSP teams deliver very high quality products into system test. The following slides show time-in-phase data from real world teams using the TSP. Note that the time spent by these teams in supporting system test is MUCH less than 50%.
25	Time in Phase – TSP Team 1
26	Time in Phase – TSP Team 2
27	Cost of Lost Opportunity
28	Mindset Change The TSP encourages personal responsibility and discipline. Team members systematically analyze their planning, process, and quality data to generate process improvement proposals (PIPs). Some sample PIPs implemented and measured by TSP teams: Reviews need to pay more attention to legacy code. One reviewer should concentrate on legacy issues or the first level APIs should be reviewed. Focus on short iterations that produce deliverables ready for system test. Reduce defects escaping from unit tests by producing formal unit-test plans. How do your measure the productivity impact of mindset change?
29	Uses of the Productivity Measure So is the LOC/Hour measure never useful? Loc/Hour is a very useful It is simple to measure. It is very useful for planning purposes At the team level, historical LOC/Hour can be used with great confidence to estimate new work (TSP). At the individual level, historical LOC/Hour can be used with even greater confidence to estimate new work (PSP) It is very useful when used to measure improvement for similar projects over an entire project lifecycle (or at least through system test). As with all measures, when defined and used properly, it is a indeed a good measure for “the rate at which goods or services are produced”.
30	Summary When answering the question, “How does TSP improve productivity?” consider how the following impact productivity precise and accurate size accounting improved task hours ruthless load balancing improved quality, reduced effort for system test and maintenance changing mindset
31	For Updated Presentation For the latest version of this presentation, please visit http://www.sei.cmu.edu/tsp/presentations.html Or http://www.davissys.com/reldoc.htm
32	Contact Information Noopur Davis nd@sei.cmu.edu or ndavis@davissys.com Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890