Measuring Performance & Productivity in Software Development Teams

Successful Outsourcing

Measuring Work & Productivity• Measurement of work

and work products is a well traveled subject in business• For repetitive work – the

tendency is to measure units and repetitions• Number of pounds of fruit

picked by an orchard worker

• For knowledge work – the tendency is to measure the hours spent on the problem• Assumption: The worker has the

skills and knowledge to find a solution for the problem

• Assumption: The worker spent enough time to evaluate the problem properly and provide a balanced solution

• For time/and or payment dependent contract work – did the worker complete the work assigned on time and at contracted cost?

But… Software Development Has Multiple Characteristics• Software development

includes elements of repetitive work, solution-based knowledge work, and contract work (fixed time/payment for contracted work)

• Common measurements• Lines of code (repetitive work) –

Expressed in lines of code per person, per month with variations for size of team and duration of project

• Cost Modeling (accounting based) – Total cost of a project against number of workers on team(s), and length of project. Formulas vary widely with wage averaging, productive hours, total lines of code in finished work, etc.

• Function Points (combination of solution & repetitive) – Amount of functionality or user stories completed in period by team in period. Can be completed and released to production

Often – Characteristics are Joined• To extend measurement outside the current project for

individuals, teams and several projects over a period more complex models are often used.• Moving outside the realm of a project requires normalizing

concepts to have comparable measures• Team performance• Quality measures• Project length • Man hours• Adherence to production & methodology standards• Complex team models (DevOps)• And more…

As Measurement Gets More Complex• We need to question

• What does our measurement tell us? What does it not tell us? • Lines of code/Number of functions

– Was the work efficient or was the output managed to simply produce more lines? Or more (minor or non-critical) functions?

• Every programmer, team, project has a different dynamic depending on the coding language, type of environment, technical complexity, & more..

• If you use a pure “number of X” metric, you must be clear about what it addresses and does not

• Is our measurement comparable? Can it be used over the long term or compared across projects or teams• In most cases, this is

where measurement fails because of lack of effective ways to make projects, teams, situations – “normal”

As Measurement Gets More Complex• We need to question

• Is any measurement better than none? Can we afford to fly blind? • If you have an outsourced

team, multiple teams, multiple projects – the normal tendency is to use measurement to compare and try to understand why some projects work out better than others

• You need to be able to judge when a project is going off the tracks before it becomes critical

• But – if the measurement we are using don’t really address the problems we have – are they helping us? • Are they more than busy

work for managers and bean counters?

• However – even a weak measurement can be useful• If we understand the

shortcomings well

For Agile Teams – There are Methods• What is our real (critical)

goal?• Provide tools to enable an

agile/scrum-based team to:• Manage their backlog and know

where they stand. (When are they pushing too large a boulder up the hill)

• Use methods of measurement they understand and agree to use consistently• User stories, story points,

standup, backlog, burndown chart, etc.

• Manage a project to a successful conclusion, with their own responsibility and initiative

The Reality is – Communication is the Key• The knowledge is inside the team (and always has been)

• With standard agile/tools and their experience they know• Who is a consistent, reliable performer and who produces less efficient/reliable code• When the backlog is getting bey0nd their reach to bring under control (and why this is

so)• Who can be relied on to answer questions fully and who needs to be mentored/monitored

to keep the team’s productivity high• If we stop trying to find the perfect metric for measuring performance

outside of a project and a team, the value of standard methods becomes clear• The team knows what is going on. Team members have a vested interest in

reaching a successful conclusion. • The problem is to get the team to trust each other and the larger project

team enough to surface issues as soon as they see them – without fear – knowing everyone has the same self-interest

Trust & Responsibility• Having enough trust & responsibility for open communication and

collaboration is the real problem we deal with in monitoring and measuring performance• It is the why behind the invention and popularity of agile and lean

• The larger the organization, the more critical and costly the project is to the organization – the less likely it will be that the team will feel enabled to inquire and speak out about problems• In large organizations, metrics are the “shorthand” to avoid a “high touch”

approach for every team and project.• In a costly, critical project, metrics are meant to be the ”truth-tellers” to assure

stakeholders things are under control• The more metrics are depended on – instead of team knowledge – the

less likely it is that measurement will inform in time to avert problems

Responsibility. Trust. Communication.• What is the bottom line?

• Measurement is most useful inside the software development team itself• Outside the team, metrics are just as

likely to be smoke and mirrors depending on the messenger

• If the team doesn’t understand and can’t use their measures as a guide in their day-to-day process – they will fail to give back their primary value – keeping the team on track to a successful conclusion

• Agile methodology relies on individual and team responsibility, trust & communication• If the team cannot achieve these

three points – agile and scum are just a bunch of processes and procedures that may or may not be helpful in organizing their work.

• If they team is just “going through the motions” in taking responsibility for tasks, assessing and managing their backlog, participating in standups and retrospectives – additional measurement and metrics will not provide much value.

Responsibility. Trust. Communication.• What is the bottom line? Three points to consider, along with

common agile/scrum processes and tools1. Working through what may appear to be (or actually are) problems

requires Peer-Level coaching and communication, not blame2. The team knows what is going on

• Having them assess the problems in front of them and helping them develop a solution is key.

• Pointing fingers, avoiding the real issues and using hierarchical (instead of peer) communication will not give them the confidence they need to work through problems

• And what if the team raises an issue that turns out to be nothing of great importance? We will all be wiser…

3. If everyone in the conversation, looking at the issues, addresses every one at a peer-level there is good reason to believe that the next time there is an issue – the team will not hesitate to raise it and deal with it properly

We are Scio Consulting• We provide nearshore software development services

to our clients in North America• We work closely with our clients to assure that the projects

we are involved in have the level of communication and understanding needed to reach a successful outcomes• If you have a project where you think we could help –

contact us