Agile Teams and the Triage Matrix

One of those questions that comes up frequently with respect to Agile is team contributions and evaluations. The industry has generally shifted from the old hierarchical model to the dual approach of evaluating burn down charts quarterly-esque and yearly 360 peer, manager and reports reviews. This has resulted in lessening single view biases and of course opened the door to a host of other issues. User story disconnect, poor estimation for new tasks, the donuts factor, etc...Worthy of several dissertations but very useless for the most part from a day to day operational perspective.

How do you get the most of your teams, how do you resolve to know what each member of the team needs to contribute more, to ensure retention and minimize defects. A simple tool that helps reduce the complexity of this task and ensure uniformity to help limit biases is the good old fashioned Triage Matrix.

A triage matrix identifies a happy end state as the relative max of two characteristics; one tangible such as technical skills and the other intangible such as commitment. And the user determines an action plan for each element of the matrix.

I personally use a simple two axis matrix of Technical skills and Commitment. I've seen ones with three axis (bloody HR folks), I've seen various different labels for the top axis such as fit, but generally they all look the same and act the same. Most importantly the axis should be something you are empowered to change for the better...and given your leadership shadow...for the worst if you're not paying attention.

Personally, I've noticed there are things you can change in the workplace and things you can't. Knowing the difference by the way is a hallmark of the sane versus insane. If someone complains about their boss for a personal chemistry reason, my hands are generally tied; it becomes an issue for their chain of command. If someone doesn't get along with their team mates, you can reach out and smooth feathers with team activities, one on one walks, coffee chats, etc... and remind them that their goal is the team's success and why that is important. But ultimately you have to accept that it is on them to make the effort to bridge the divide. You can only facilitate. Find the things you can influence, find the ways you can help, list them, add to the list as you grow and track how effective they are.

For me attributes such as skill set, I can definitely contribute to getting someone up to speed. With committed mid-level contributors, this is often just a matter of providing them the resources to pull themselves up. With committed junior level contributors, this is a matter of making oneself available...but with an immensely rewarding payoff as you see the progress they make in a short period of time. And with less committed contributors it is far less rewarding. Which is why commitment level should always be the primarily focus. Get people committed and with good technical leadership everything else follows. If your team members don't know why they're coming to work beyond the paycheck, then no amount of training or tools is going to shift the dial on the technical skills axis.

You need to give them the vision, you need to show them the outcome of their work (make the value chain into a value loop), you need to identify everything that is distracting them from being committed and work to reduce those distractions to the extent possible. And you need to understand that commitment is a cyclical thingamajiggy, you need to monitor it, nurture it even when it seems strong and be accepting when it flags for legitimate reasons. For some who are bit committed this is simple for those who are very skilled but have little commitment, you need to earn their trust before all else...otherwise they will filter you like spam.

There are four tricky boxes in the matrix. The perfect contributor, the exact opposite, the guy whose wants to give it a shot but can't seem to wrap his head around the code and the gal who has the skills at a mid level but just wants to cash the check and go home.

The perfect contributor is a problem square? Someone who is a technical guru and is gung ho? Yup, lack of challenges will see this high in demand resource bounce for the next challenge. Find the challenges and feed them to this member. And accept that these challenges may be beyond your ability to evaluate...so pull in help to help define the feature and the success criteria.

The exact opposite of the perfect contributor, the person who is lacking technically and is uncommitted, yet somehow got thru the door. This is not so much of head scratch'er; if you don't invest in your skill set and start to lag as the tech advances and no one is there to nurture you...you start to slide into this bucket. And the more you fall behind the more you disconnect until newbies resent you, seniors avoid shop talk and managers view you as a good resource for knowledge about how the system works but not much else. How you deal with this case is often an interview question I give, so I'll just say this is a difficult question that speaks volumes about a person's humanity and character.

The other two are just a result of mismatch, you may have a good team member who is either doing the wrong thing on the team or doing the right thing on the wrong team. Lots of honesty and non-judgmental discussion will sort this out. And these are priority items to address, allow either one to fester and team morale will plummet.

And like all models this one is flawed. There will be outliers, scenarios that don't lend themselves to easy categorization. They'll be rare, but get ready to throw out the book when you stumble across them. In those cases, do your best but try to avoid appearing inconsistent in your treatment; the last thing you want to do is give the impression of playing favorites.

Why don't you just do the same thing for everyone? Ideally you should have a different approach to every individual because no two are ever identical. And in reality a lot of times you will be taking a slightly different approach as local circumstances dictate. But you need to conserve resources, you are a resource, and to conserve that resource means you need a structured, repeatable, measurable way of determining the effort required, the general approach and the benefit to the company and the team.