Here is the set of slides from my presentation on the use of the Skills Matrix to help launch Agile teams. This was first presented at AgileTO in March 2016.
20160316 Agile TO Meetup – Skills Matrix [pdf]
And the video on YouTube:
I’m going to be presenting a quick session on the use of a Skills Matrix to help launch a team. If you are in the Toronto area on the evening of March 16, come check it out: Agile TO Meetup.
For many years, folks in the Agile community have been recommending that performance reviews be eliminated from the corporate world. In 2005 while coaching at Capital One, I remember many discussions on the awfulness of performance reviews. This was really my first understanding of the depth of culture change required to be Agile.
Now, this concept of eliminating performance reviews is gaining traction outside the Agile environment. Here is a great LinkedIn Pulse post by Liz Ryan in which she explains in depth about killing performance reviews.
From her article:
A little voice in the back of my brain nagged at me: “Despite your efforts to make them more compassionate and less uncomfortable for everyone, performance reviews are stupid from the get-go, Liz!
“How does one human being get to evaluate another one, when their personalities and perspectives may be radically different?
Consider using other techniques to help with improvement efforts among your staff. Lean has Kaizen. Agile has Retrospectives.
Real Agility means that learning is inherent in the culture of an organization. Performance reviews establish extrinsic motivators for learning… and all the research points to the idea that learning is much more powerful when it is intrinsically motivated.
Consider some other tools that might help your team to work more effectively, while maintaining intrinsic motivation:
Finally, consider that, at least in Scrum, the concept of a self-organizing, self-managing team makes it very difficult to do performance reviews. It is hard to apportion “blame” or “praise” to individuals. Each team member is dynamically deciding what to do based on the needs of the team, their own skills, and their interest. Team members are often collaborating to solve problems and get work done. Traditional roles with complex RACI definitions are melted away. Performance reviews are very difficult under these circumstances.
In 2005 I had the privilege to participate in the first occurrence of this fantastic technique for organizing large numbers of people into Agile teams. It happened at Capital One in Richmond Virginia and my colleague of the time, Kara Silva, led this successful experiment. The problem was that the “teams” that management had set up didn’t make much sense from an Agile perspective. They were functional teams (e.g. a team of testers). But to do Agile well, they needed cross-functional, multi-skilled teams that could work well together to deliver great results each iteration. So Kara and a few other senior people got together all the staff in the department into a big room with a big whiteboard and facilitated a 3 hour meeting to sort out who would be on which team. Everyone was involved – all the people who would be on the teams were in the room. Those teams stayed together with the same membership long after that meeting.
This “team creation event” was a fantastic success for that particular department. What made it a success?
In the Real Agility Program, the team creation event is used to launch a Delivery Group. The key people at the meeting include all the potential team members as well as the three Real Agility Coaches from the business, from technology, and from process/people. Depending on the number of people involved, the team creation event can take anywhere from two hours up to a full day. Longer is not recommended. For larger Delivery Groups, we recommend that the team creation event be held off-site.
Facilitation of the team creation event is usually done by the process/people Real Agility Coach. If you wanted to use this process with other enterprise Agile frameworks such as SAFe (Scaled Agile Framework) you would have the “equivalent” person such as SAFe’s Release Train Engineer as the facilitator.
The team creation event should only be done when the business is ready to get a Delivery Group started on actual product, project or program work. If there is any significant delay between the team creation event and the launch of the Delivery Group on it’s work, then the teams can fracture and you may need to run the event again. A few days should be the maximum delay.
One client we worked with ran the team creation event but had some significant problems afterward because they weren’t really ready. In particular, they still had to make staffing changes (primarily letting go of some contractors, hiring some new full-time employees). As a result, the teams created in the team creation event were not really properly stable. This caused a great deal of disruption and even significant morale problems for some teams. It is essential that the Leadership Team be committed to keeping the team membership stable for a significant period of time after the team creation event. That includes any necessary means to encourage people who are thinking of leaving to reconsider. It also includes a commitment from leadership to respect the self-organizing choices made during the team creation event unless there is an extremely urgent problem with the results.
So, to make it systematic, here are the steps required to run a team creation event:
PREPARATION
TEAM CREATION EVENT AGENDA
FOLLOW-UP
Have you experienced an event like this? Did it work? What was different from what I described?
I am currently working with a relatively new Scrum team (5 Sprints/weeks young) that needs to rewrite their Personal Development Plans (PDPs) in order to better support Scrum and the team. PDPs are still the deliverables of individuals required by the organization and likely will be for some time. The organization is still in the early days of Agile adoption (pilots) and they are large. So, instead of giving them a sermon on why metrics for managed individuals are bad, I am going to help them take the step towards Agility that they are ready to take.
The Plan:
I’ll follow up with another post to let everyone know how it goes.
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:
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).
