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
I find that this happens in circumstances where bad managers are constantly missing deadlines because they are constantly in panic mode.
Panic manifests itself as valuing certain developers and not others, creating owners and specialists so that you can ensure work is completed “fast” and not necessarily right.
Bad managers are also creatures of habit and will therefore introduce process because something someone did once happened to have successful results. As a result bad managers will therefore prefer to introduce impediments and label them as process.
Then during the “postmortem” the bad manager tries to find the person to pin the blame on for missing the deadline rather than identifing and removing impediments.
We have to find a cure for bad management. Right now the only thing that seems to work is “deliver on time”. I am a strong advocate of removing impediments and if you have a bad manager, well then I know what the first step is … remove “the” impediment.
While part of this rings true, the real problem stems from the question of “why is the manager in panic mode?” This can come from a breakdown within the process itself, or by lack of commitment from the team to actually stand behind their estimates, or a failure in the system to allow for the change in estimates as the work progresses without adjusting the scope.
It is important to remember that the scope MUST change if the amount of work changes and time does not. Adding resource may not always work.
The most common failure of a manager is to trust the estimates provided, and “bank” the business on that. While estimates are guesses at best in most organizations, the reality is that those providing the estimates don’t often have the discipline to stay focused on Sunny Day Scenario when creating the estimate, or simple don’t do the research necessary to give the estimate validity.
The manager then has no choice but to turn to those who have proven accomplishment in delivering what was asked - by whatever means necessary.
While it is easy to try to fix blame, it is in reality the whole team that has failed.
Building a team based on trust requires the best effort of each member, manager included, always operating with the success of the other team members at all times. If this level of commitment and trust is sustained, the team will perform better and better, and will deliver the near impossible. If it breaks down, it is the sad responsibility of the manager to correctly identity and cull the team or as stated, “remove the impediment”.
Once a poisoned attitude has been established, it can be very difficult to clean up.
Signs of a problem in a team are exactly as described above. Managers blaming. Panic mode. Fast not right. Owners and specialists. These are all signs that a team is moving faster than their ability to retain integrity. And the march of the clock always wins. And everyone is discouraged with each other. And the team effectively dies.
The key is to focus on the problem. Lose the sense of criticism, either towards each other or others towards oneself. And focus on the improvements - not the failures. Learn, and get better.
Team building is really necessary for a very successful implementation of business plans.”`-
i love team building activities because it enhances my skills in business,*`