Each member of an organization has a title or designation that may reflect their responsibilities or profession. These titles may include BA, Tester, Developer, QA, PM, and others. It is normal to be proud of our accomplishments, achievements and titles. Unfortunately in a Scrum team these titles can limit the individual and adversely effect the team. These same titles can label the individual as that role (example – as a tester) and only that role. Within a Scrum team we certainly need the skills, knowledge and abilities that come with that title/role, but we do not want to limit that person to being viewed as only that role. Each of us is the sum total of our experience, education, values, upbringing and history. All of this is of value to the team. We should encourage every member to fully participate on the team, to willingly share their expertise, to contribute to non-traditional tasks and to feel they are valued as a complete person rather than a specifically titled individual. So if the goal is to leave your title behind, then it is implied you can also pick up other skills.
So how can this be accomplished. One way is a Skills Matrix. This is a chart that can be posted in the room to identify the skills needed and the people on the team. On the left column you list all the team members. Along the top you list all the various skills you need on the team. Then each person reviews their row, looking at each skill, and then identifies how many quadrants of each circle they can fill in, based on the range below the chart. The range is from no skills through to teach all skills in a given column. After filling the columns and rows, now the work begins. By using pair programming (an extreme programming method) and other methods like self-study and taking additional courses, the team member can begin to learn other skills. The objective is to have at least two persons on each team who possess each of the skills at the level of performing all the tasks of a specific skill. The goal is not to have every one do everything but to have a least enough people with specific skills to cover sicknesses and vacations so that required tasks are performed. This is a method to capture the full extend of each person’s current knowledge, skills and abilities and expand on it.
Since they are hard to see, here are the labels for the number of quadrants:
For a few years now I have been working with managers and executives to help them do Agile-compatible performance evaluations of their staff. The method that has been most successful is based on a tool that comes from the book Toyota Talent called the “Skills Matrix”. The basic approach follows these steps:
Baseline the skills within a team for each team member.
Set development goals and action items.
Regularly review performance in relation to the development goals.
Of course, the details matter. The OpenAgile Center for Learning has published a brief overview of how to use the Skills Matrix and a convenient A0-size pdf that can be used as a template for a team’s Skills Matrix. I highly recommend using these to get started. If you are a manager, ask your ScrumMaster or Process Facilitator to arrange and facilitate a team workshop to do the initial population of the Skills Matrix, rather than doing it yourself. Once that is done you have a baseline and you should take regular digital photos of the team’s Skills Matrix for record-keeping and as a backup in case of disputes. You should also let the team know that you will be basing performance reviews on how they improve their skills.
The development goals that team members set then should be made such that every team member understands that they have a responsibility to diversify their own skill set and assist other team members in doing this. As a manager, you should review each team members’ goals for development and provide mentoring support when needed. At the end of a fixed period of time (quarterly is a reasonable period), you will review each team member’s development relative to the baseline and the goals set. Of course, normal guidance around performance (or lack thereof) can be given at these regular reviews.
I strongly recommend reading “Drive” by Daniel Pink as an important adjunct to understanding how to do performance reviews for individuals in an Agile environment. In particular, individual performance reviews should not be tied to bonuses. If bonuses are used at all, they should be measured and delivered purely at the team level or organization level without measuring individual contribution.
Of course, Agile team performance can’t simply be measured in terms of skills alone. Performance must also be related to bottom-line results. This part of performance measurement is separate from the development of the team. Another aspect of Agile team performance is how well they are doing Agile itself. Depending on the Agile method you use, there may be various tools to help with this (I would recommend our new product the Scrum Team Assessment as one possible consideration).