the influence of poor planning on software team power and ... · the influence of poor planning on...

http://itconfidence2015.wordpress.com

The Influence of Poor Planning on Software Team Power and Productivity

3°International Conference on

IT Data collection, Analysis and Benchmarking

Florence (Italy) - October 19, 2015

Cigdem Gencel, DEISER (Spain)

Luigi Buglione, Eng. IT (Italy)

http://www.deiser.com/

2 IT Confidence 2015 – October 19, 2015 http://itconfidence2015.wordpress.com

DEISER At a glance

www.deiser.com

http://www.eng.it/


Engineering At a glance

www.eng.it

http://www.eng.it/

http://www.eng.it/

http://www.eng-it.it/spimq


AGENDA

• Software Estimation Problem

– What does the customer want?

– Basic resources in development

• Revisiting the Fundamental Concepts

– Work & Energy

– Efficiency (or Productivity)

– Team Power

– Some important misconceptions

• Empirical Investigation

– Avg TeamPower vs Avg TeamSize

• Conclusions & Prospects


Source: Symons, C., Gencel, C., From Requirements to Project Effort Estimates – Work in Progress

(Still?), REFSQ Annual Conference, Industry Track Keynote, Germany, 2013

Estimation Problem The cost of over-runs and failures

Software industry records show that projects are often delivered late and/or over budget

Failed

>10% over budget

Successful

>10% over budget

‘Successful’

Standish

CHAOS study

2009

European

Union Study

‘98 – ’05

UK Public

Sector Study

2007

ISBSG Study

2013


Shift 1: Agility

Shift 2: GSE

Shift 3: Scale

Shift towards agility in development, distribution of tasks across borders, and increase in scale created more challenges

Source: Gencel, C., Petersen, K., Opening presentation of the 1st Intern. Workshop on Estimations in the

21st Century Software Engineering (EstSE21), The Agile Conference (XP 2014), Rome, Italy, 2014

Estimation Problem Three major shifts in software engineering


Estimation Problem Estimation Methods & Models


Putnam (1978):

• Product size ± a "reasonable" percentage variation;

• A "do-able” schedule ± a "reasonable" percentage variation;

• The manpower and cost for development- ± a "reasonable" variation;

• Projection of the software modification and maintenance cost during the operational life of the system.

Sw Estimations What does the customer want?


Typically a project has the main resources:

• Software team

• Development environment

• Elapsed time

• Money

• ...

Sw Estimations Basic Resources in Development


Productivity = Software size / Project effort

Estimated new

project effort Cost factors

Estimated software size

Assumed project productivity , = f

Estimated

Duration Team size Estimated project effort , = f

Sw Estimations The Common Approach


• In physics, potential energy is defined as ‘the capacity of doing work’

• In SE, it can be defined as the team’s cumulative intellectual work capacity in a development environment for developing a piece of software during a period of time

WEInput = # of people x duration they work

Core concepts revisited Work & Energy


Core concepts revisited Efficiency (or Productivity)

• The law of the conservation of energy says:

• Energy can be transformed from one form to another

• Efficiency is usually less than 100%


• Productivity of software development is denoted as:

where , WOutput corresponds to valuable work, which produces a piece of software with some characteristics:



• Any waste in development would decrease productivity.

• Many studies investigated those factors affecting productivity and hence productivity

• team factors,

• process factors

• project related factors

• …



• Our focus here is on the input work, WEInput:

• To elaborate on some fundamental concepts that are important to build up further estimation models and make meaningful productivity comparisons.

• To differentiate between Work Effort – Team Power – Team Size

Core concepts revisited Work Effort Input – TeamPower


• In physics, Power (P) is defined as “the rate of doing work”.

The term “horsepower”

was invented by James Watt.

Famous for his work on

improving the performance

of steam engines



• Similar to calculating average Horse-Power for measuring the power of the engines, we can define Average Team Power as:

• Hence, the unit of measure for Avg. Team Power is #people (number of people x time/time).



Putnam stated that In fact, time is the independent variable in software projects and the dependent variables (manpower, code production) are usually time rates.


• Brooks stated that estimating techniques fallaciously confuse work effort with progress by hiding the assumption that men and months are interchangeable.

• He then explained that this is only possible when a task can be partitioned among many workers with no communication among them.

• His hypotheses were brilliant, and therefore have gained considerable attention by the community.

Core concepts revisited Some Important Misconceptions

Fred Brooks: Adding manpower to a late software project makes it later


Fred Brooks: Adding manpower to a late software project makes it later

Team Power is expressed in unit of number of people, but it does not mean that this corresponds to the number of people working in the team.


Core concepts revisited A Thought Experiment

Time (months)

Case 1

Case 2

Case 3

Avg. Team Power = 1 person

1 2 3

Avg. Team Power = 1.5 persons

Avg. Team Power = 3 persons

Steven Kareem Jim


Hence, Avg. Team Power normally has limits :

1 ≤ Avg TeamPower ≤ Team Size

However, in a not ideal world:

- Can be below 1!

- Can be above the team size if overtime effort is recorded!

Core concepts revisited A Thought Experiment


• We investigated the nature of the relationship between Avg Team Power and Avg. Team Size using the ISBSG dataset

• We prepared the data for analysis as follows:

Development type: New

Data Quality Rating (DQR): A or B Rating

Recording method: Staff-hrs

Ratio of Project Work Effort to Non-Project Activity: projects that have 90-100%

• We calculated the Avg. Team Power from Work Effort /Duration

• The project duration is calculated by subtracting project inactive time from the total duration (1 month is considered as 152 hrs).

• The Work Effort corresponds to Normalized Work Effort (person-hrs)

Empirical Investigation Avg. TeamPower vs Avg. Team Size


Empirical Investigation Avg. TeamPower vs Avg. Team Size

• Avg Team size seems to increase much faster than Avg TeamPower

• TeamPower stays around 10-12 persons

• Team Power in some cases below 1 person!


• ISBSG dataset indicates that many projects might have suffered from poor planning

• Avg Team Power should be used in estimating duration not the Avg Team size as otherwise this can result in very optimistic schedules

• Low productivity (seemingly) may be a result of poor planning rather than poor skills of the developers!

• Companies should record and track Avg Team Power to detect any problems in planning

Conclusions & Perspectives


Grazie per la vostra attenzione!

Thanks for your attention!


Our Contact Data

Cigdem Gencel

DEISER

[email protected]

Poor Planning

Luigi Buglione

Engineering Ingegneria Informatica/ETS

[email protected]

http://www.deiser.com/

http://www.eng.it/

the influence of poor planning on software team power and ... · the influence of poor planning on...

Documents