Scrum Team productivity is difficult, if not impossible, to measure for a single Team and definitely impossible when comparing productivity of different Teams.

The metric that Scrum Teams usually use to help them plan Sprints is the Development Team velocity; some ‘managers’ believe that Team productivity is DIRECTLY linked to Team velocity; the higher the velocity, the higher the productivity.

Nothing can be further from the truth!

Velocity is Team, product and time specific and should only be used to aid Sprint planning.

The value that a Development Team is delivering per Sprint cannot be used as a measure of productivity either; by its very nature, a Team will deliver higher value at the start of the product development because they will be working on higher value User Stories.

Increasing Scrum Team productivity can only come from ensuring that the fundamental ‘rules’ and ‘values’ of Agile and Scrum are being followed.

The following are the main areas of organisational change that will help improve Scrum Team productivity:

• Senior Management Awareness and Involvement – In the 2015 State of Scrum Report it was stated that: 

“Respondents report that senior management sponsorship and support is far and away the most important factor in adopting Scrum.”

AND

“… though senior management support is considered critical in Scrum adoption, only 7% of respondents reported that as visible in their organizations.”

The need for senior management Agile awareness and involvement in product development is that Scrum Teams are not isolated ‘islands’ in the organisation, they have to interact with other parts of the organisation that may resist changes to their work practices for the Scrum Teams to be productive.

The motivation for these other organisation parts to adapt must come from senior management.  

As an example, an Agile Team was formed to implement a new process to get connecting passengers from one aircraft to another, especially if the inbound flight was delayed.  The new process involved the development of a new IT system and the team planned to release increments of the new software monthly.

However, when it came to the first release, the team discovered that there was an organisational process that required 2 months before ‘desktop ready’ software could be made ‘live’.

The problem was resolved eventually by allowing the team to have a ‘fast-track’ release process but the resolution TOOK a month of discussions with the management of 3 other divisions within the organisation.

When an Agile/Scrum transition starts, it is important to discover all the stakeholders, at whatever level in the organisation, that can influence the early team’s productivity and ensure that they understand the possible implications to them and their subordinates of the Agile transition.

Mark Levison suggests one way of coping with the necessary senior management ‘education’ in his blog, Taking Organizational Improvement with Scrum Seriously;  he proposes a ‘Change Management’ Scrum Team to develop the organisational change product.

Keep Teams Together – The ‘traditional’ approach to product development is to create a project, assign the right people when they are needed throughout the project; there is never one coherent team; ie ‘BRING people to projects’.

The Team members in Agile have all the skills needed to complete a product development; the Team size is generally constant for the whole product development.

If we take Tuckman’s group DYNAMIC model, all groups of people go through ‘forming’, ‘storming’ and ‘norming’ ‘phases’ before the group becomes ‘performing’; it can take a significant amount of time before the ‘performing’ stage is reached.

It therefore follows, that once a Team has reached the ‘performing’ stage, we should keep the Team together after the product development is finished; the ability to work well together as a team is more important than any individual skills.

Keeping teams together can be characterised as ‘bring projects to teams’.Allow the team to determine their Sprint capacity – Some Product Owners (PO) ‘cajole’ some Development Teams to take on more work in a Sprint than the Team members think is possible.

This has 2 possible effects on individual team members:

• They know it ‘won’t’ happen and that they will be blamed.  They become demotivated and do not work productively
• They try to work faster to complete the work and cut-corners, producing low quality outputs.  Overall team productivity falls because of all the necessary rework later
• The team must be allowed to do their own estimation and set their own ‘comfortable’ Sprint capacity; the Team members must collectively believe that a Sprint plan will work at the end of Sprint Planning.
• Do not add work during the Sprint – The aim of Sprint Planning is to set the Sprint Goal and add the relevant Product Backlog Items to the Sprint Backlog that will contribute to the Sprint Goal.
• There are still many established ‘Agile’ organisations where it is normal for Development Teams to receive extra work during the Sprint from different people, most of which does not contribute to meeting the Sprint Goal.
• To be productive, a Development Team need to keep focused on the Sprint Goal, distractions reduce product development productivity.

Most of this extra work can be categorised as ‘fire-fighting’; there are 2 approaches to resolving this ‘problem’:

• Form a ‘fire-fighting’ team to deal with ad-hoc work
• Find the root cause of why this extra work is needed and fix the root cause problem.
• Allow the Team to add improvement work to the Sprint – A common management misconception about Sprint Planning is that all the chosen Sprint Backlog Items (SBI) must be completed; the total chosen SBI estimates must ‘fill’ the Team’s Sprint capacity.
• Not only is this unreasonable, because the effort for each SBI is only an estimate, but it also leaves no room to implement any of the improvements that were identified during the previous Sprint Retrospective.
• A reasonable agreement must be made between the PO and the Development Team for an agreed NUMBER of ‘Improvement’ Items to be added to the Sprint Backlog with a high priority.

Finally, there is a good article by Łukasz Krzyżek about the Scrum Master as a Change Agent for the organisation.