Data driven; People based

DATA DRIVEN; PEOPLE BASED
January 22, 2020 Alexander Nemtsov

Typical concerns of CTO, CFO, COO and others
• Lack of visibility into the output and productivity of software development resources
despite these resources being a significant cost center
• Find that the scant data available is not reliably comparable across individual developers or
groups of developers particularly when spread across multiple teams that may be in
multiple geographies
• Are unable to get consistent, objective and reliable measures of the effort that has been
delivered by outsourced or off-shored teams to evaluate and monitor value for money
• The bigger your organization, the more you must spend to coordination vs productive stuff

4
ATTRACTIVE PEOPLE ARE PERCEIVED TO BE SMARTER, FUNNIER,
AND MORE LIKABLE THAN LESS ATTRACTIVE PEOPLE

Different measurement purposes require different measures
1. Compare market vs market to assess investment opportunities
(examples – GDP, GNP, CPI, PMI and others)
2. Evaluate the overall performance of organization for comparison with other
organization or with some standard.
3. Evaluate how major parts of the organization are functioning, and whether that
functioning are improving or declining.
Examples of measures – Utilization, Staffing time, Attrition etc.
4. To control how the parts of organization are performs and operates.
Examples: Defect Containment, Reopen Rate and others
5. To motivate the personnel
To improve the performance by encouraging behavioral changes of individuals
by providing feedback
Ideally, to separate the performance effects due to personnel from the effects
due technology
Organization
Division
Unit
Individual
Market?

Different measurement purposes require different measures
6
1. Compare market vs market to assess investment opportunities
2. Evaluate the overall performance of organization for comparison with other
organization or with some standard.
3. Evaluate how major parts of the organization are functioning, and whether that
functioning are improving or declining.
4. To control how the parts of organization are performs and operates.
5. To motivate the personnel
To improve the performance by encouraging behavioral changes of individuals
by providing feedback
Ideally, to separate the performance effects due to personnel from the effects
due technology
Organization
Division
Unit
Individual
Market?
LET'S FOCUS HERE

One person, many outcomes
7
1. Creates code
2. Makes documentation
updates
3. Produce Estimates
4. Etc.
Software Engineer Quality Engineer Business Analyst
1. Writes Test cases
2. Produce Test
execution results
3. Creates Estimates
4. Etc.
1. Requirements
2. Etc.
Productivity can be measured only in context of particular outcome. The same person may be very
productive at making new code but have an issues with producing estimates.
The set of measures will be incomplete if we won’t consider all the desired outcomes for every role
in software development.

Data driven insights about Software Engineers
On top of historical data we may observe how individual's performance change over the time.
It’s may be observed on individual level or may be grouped into some aggregations.
The individuals may be grouped by Teams – this will give managers ability to identify performance outliers.
Or by Locations (UA/BY/HU/etc) – may be used as justification for business related decisions
How to read:
Relative Velocity (%)
Speed of coding for particular person compared with Standard
Engineer. Can be considered as measure of Quantity.
This person have average velocity -25% compared to Standard
Engineer. Considering that he is D3, it’s okay.
This person velocity way higher than other people on the same
positions
Churn rate (7 days)
amount of lines rewritten in short period of time.
Can be used as measure of Quality.
Frontend Developers have high churn rate because
they making a lot of prototyping and polishing.

Let’s join the dots from outcomes to measures (plz help to finalize!)
9
Outcomes
What we want?
Decisions
That leads to that outcome?
Insights
That leads to that decision?
Measures
That shows this insight

Velocity it’s amount of coding output per timeframe
• Two different code changes contains the same “amount of output” if they typically
take the same labor time to produce.
• Consider two consecutive commits of the same author. The commit interval is the
time difference between them (e.g. 15 minutes, or 3 days). Labor time that produced
the code change is less or equal to the commit interval.
• Short interval (e.g. 15 minutes) may match with coding time but longer commit
intervals (e.g. couple of hours) most likely will include coding breaks.
• Time spent coding could be estimated as expectation value, which can be computed
by taking the area under the probability curve
• We use the coding time model described above to create datasets that associate all
code changes with estimated coding times.
• Next, we train a model that, given any code change, estimates the coding time
typically required to produce it.
• Such model would then represent the coding time profile of the “average” or
representative “standard engineer”

12

The team’s an open book
How to read:
Green zone – High performers
These are your weightlifters.
White zone – Okay
It’s the regular persons with performance close
to average. Ideally everyone should be here.
Red zone – Need help! Talk with them to
clarify the possible issues.
By application of statistical
process-control tools (Shewhart's
control charts) we may find the
deviation from the regular
performance within the given
group of engineers.

NOT OVER YET, IT’S ONLY FIRST STEPS
DEV BA QA

Possible pitfalls
16
1. Productivity increase does not bring increase in delivered value.
2. Pushing productivity deteriorates culture
3. Pushing productivity kills innovations.
4. Pushing productivity doesn’t make employees happier.

Data driven; People based

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Data driven; People based

Similaire à Data driven; People based (20)

Dernier

Dernier (20)

Data driven; People based