December 2007

Monthly Archive

How Can We Make the Team More Productive?

Posted by on 23 Dec 2007 | Tagged as: Agile, Leadership, Product Owner, Scrum

On many occasions as a trainer, consultant, and coach I am asked “if in Scrum the team is self-organizing how do we handle team and individual performance problems as a manager?”. From my point of view this question has multiple components that must be treated separately.

What is a “Team”

It takes more to form a team than slapping a group of individuals together and calling them a “team”. Teamwork can grow within a group of individuals who have a common goal and personalities which lend themselves to team building. As a manager we cannot make a team productive, we can only setup an environment to enable productive teams. So how do we setup such an environment?

Shared “Resources”

To start off with, people are not “resources” and the use of this word has been problematic for many organizations. Discussing people as resources gives management the idea that people in their organizations are interchangeable cogs that can be swapped around to meet needs in a reactive fashion. For instance, “we need Joe, who is knowledgeable on that particular application, so we can put Jennifer in his place on that project”. This assumes that Jennifer has the domain knowledge, context, background experience, same competency levels, and personality as Joe. Of course this is not true and therefore we may need to do some mental gymnastics to rationalize this transition but such a transition always has unplanned effects. To be fair, at times it may end up a net positive for the team and product delivery. The assumptions made do not support a predictable result.

In software organizations there may be a need to share “specialists” until their knowledge is shared to enough people or the specialized tool in question is minimized or eliminated. This situation has developed over time in many cases. We may have incorporated specialized technology platforms, maximized individual productivity, or minimized integration conflicts through individual code ownership. The risk associated with too much specialization is apparent in many organizations with mainframe environments using COBOL and individuals developing on these systems who may be close to retirement. An individual contributor may be the only person who knows the code for 1 or more systems. If that person were to leave development on those systems would be crippled tremendously.One way to combat the risks associated with shared people is to setup an environment which supports learning and knowledge transfer. Some techniques that I have seen to be helpful are pair programming, mentor programs, and brown bag sessions. We cannot remove the need for shared people but as managers we can work to make the organization more resilient to specialization risks.

Context Switching

While working with some organizations I have come across many instances of excessive context switching by people across projects. One day I was presenting the use of StoryTestIQ as an acceptance testing tool to a group. During the presentation one of the group members asked how hard it would be for them to use this along with all of the other tools they were currently using on their other projects. My “spidey-senses” started tingling and I asked this person how many projects were they currently on? They answered “seven”. I asked how they could possibly deliver on the commitments of all those projects. There answer is that they haven’t been able to and it has been a real pain.

We can help people do a more effective job by minimizing the amount of context switching they are responsible to manage. This problem sometimes manifests itself with particular specialization but I have also seen this become a cultural norm in organizations. Some potential areas of improvement that can be made in the organization for context switching are enabling sharing of knowledge, restructuring from project focus to product focus for software delivery, and ask the teams associated with a heavily context switching person how they can alleviate this issue over time.

Removing Impediments

As a team starts to commit to an amount of work and deliver that amount of work at the end of each iteration, the team’s velocity begins to stabilize. Velocity is the amount of work the team can do from a particular Product Backlog that the whole team estimated over a specified iteration length. Jeff Sutherland, co-creator of the Scrum framework, once told me that “you cannot expect team acceleration without removing their impediments”. Acceleration in terms of velocity would be an increasing velocity over multiple iterations.

Management can help teams accelerate their velocity by removing barriers to team focus on software delivery. These impediments may be items such as missing hardware, unavailable people, and technology platform issues. As these impediments are removed the team’s focus on software delivery should increase thus accelerating their velocity.

Wrap Up for Tonight

I have mentioned a few organizational environment issues which could be improved and could help your team(s) become more productive. We can help real teams develop by keeping good teams together. If we start to minimize the amount of shared people across projects we can begin to alleviate risks associated with individual specialization within the organization. Working towards more focus for people in the organization who are currently context switching between multiple projects can increase their productivity and projects they are associated with. Also, management can help teams accelerate their velocity by removing impediments raised by the team. All of these I have found have been more fruitful than telling teams to work harder or more hours. Those alternatives usually just lead to software which is more costly to maintain and slowly decelerates the team’s productivity.

Additional material of interest on this topic:

Pete Deemer message to Scrumdevelopment mailing list on IT managers and Scrum:  http://groups.yahoo.com/group/scrumdevelopment/message/22323

Gerald M. Weinberg on Evidence that Teams are More Productive: http://secretsofconsulting.blogspot.com/2007/10/evidence-that-teams-are-more-productive.html