Agile team evaluation
I’ve been thinking a bit about team evaluation. In the agile world, this is often done by looking at practices – is the team doing pairing, are they doing story mapping, how long is their iteration length?
This is definitely a useful thing to do, but it can sometimes be too prescriptive; a specific practice needs to be good for a team where they are right now, and that’s always clear. I’m a big fan of not blocking checkin on code review, but I need something to replace it (continuous code review through pairing or mobbing) before it makes sense.
Instead, I’ve tried to come up with a set of questions that focus out the outcomes that I think are most important and whether the team is getting better at those outcomes. I’ve roughly organized them into four categories (call them “Pillars” if you must).
1: Delivery of Business Value
- Is the team focused on working on the most important things?
- Are they delivering them with a quality they are proud of?
- Are they delivered in small, easy-to-digest chunks?
- Is the team getting better?
2: Code Health
- Is the code well architected?
- Are there tests that verify that the code works and will continue to work?
- Is the team getting better over time?
- Is the architecture getting cleaner?
- Is it easier to write tests?
- Is technical debt disappearing?
- Are bugs becoming less frequent?
- Are better technologies coming in?
3: Team Health
- Is the team healthy and happy?
- Is there “esprit de corps” in the team?
- Are team members learning to be better at existing things?
- Are team members learning how to do new things?
- Does the team have an experimental mindset?
4: Organization Health
- Are changes in approaches by the team(s) leading to changes in the overall organization?
- Are obstacles to increase speed and efficiency going away?
- Are the teams trying different things and sharing their findings? Or is the organization stuck in a top-down, monocultural approach?
- Is there a cleared vision and charter for the organization?
- Does the organization focus on “what” and “why” and let the teams control the “how”?
This is a useful set of questions to assess agile teams, thanks Eric!
FYI: I've added it to my a web page that I maintain on agile self assessments and tools at http://www.benlinders.com/…/agile-self-assessments.
@BenLinders