Many CxO’s struggle with getting their arms around agile team performance, with the lower level of documentation, reporting, and measurement associated with most Agile teams. While it is worth a conversation to determine what the “right” level of documentation might be, here are five simple questions the Agile CxO should ask to gauge agile team performance without burdening teams with non-value added process debt.
1. What is the aggregate TeamScore for all agile ceremonies?
Agile teams depend on “aggressive engagement” to communicate, manage risks, monitor progress, and ensure that the projects are on-track. In fact, this face-to-face engagement is the very reason why agile teams can flourish without “traditional” defined process control.
It makes sense to keep track of extended team engagement at the ceremony level, as rich collaboration is essential for agile success. We use a simple metric called “teamscore” for this, and while it takes some getting used to, the information it provides is “high-value, low maintenance” and a quick, agile way to get a read on team engagement before trouble begins (and it will….).
- What percentage of attendees invited the sprint review actually attended? Without this, we can’t be sure that the “definition of done” has been satisfied. While agile frameworks assume voluntary collaboration, it rarely happens the way it should (don’t get me started….).
- How well attended are the daily standups? Believe it or not, after hundreds of assessments, I’ve learned that this number is typically dismal, calling into question the notion that teams don’t need status meeting or reports because of the daily standup. Personally, I don’t think we need those things either – but we need active engagement if we don’t have them.
- What percentage of required stakeholders participated in sprint planning, backlog grooming, and retrospectives? I’ve noted in many assessments that retrospectives are almost optional for some team members – negating the very purpose of the event. A low teamscore here might indicate that the teams are not, in fact, trying to improve after each sprint.
Aggregate teamscore across all agile ceremonies is an excellent indicator of project risk and team cohesion – two items that are often cited as strong reasons to “go agile.”
TeamScore is an quick and agile engagement metric that provides the CxO with instant information regarding the health of the agile team, and helps them determine whether to dig deeper into projects that may not performing at the highest levels.
2. What percentage of committed Story Points have been met?
Traditional measures like “on-time,” “on-budget” (CPI/SPI) have little meaning on a true agile team (yea, yea, I know…but I mean TRUE agile team). In fact, some claim that “agile teams are always on-time and on-budget.” There is some truth to this, but it isn’t magic, and projects do indeed get behind and cost more than anticipated. With fixed 2-4 week time-boxed sprints there is always a start day and an end day – sprints always end “on-time!”
With fixed team size, and fixed time-boxes, budget is often defined by how many team members and how many sprints are to be executed. Sprints never exceed their allotted budget!
I’m a fan of this method of scheduling and budget – IF THE TEAMS ARE HIGH PERFORMING AND HAVE PROVEN VELOCITY! But that’s a big if, and don’t fall into the trap of making assumptions that agile will manage this for you. In most cases, more care and feeding is required.
A better metric is to simply track story points estimated vs. story points achieved. In theory, a fixed team’s velocity will be a strong predictor of performance, however many teams multi-task and work on multiple projects (sad, but true), perform maintenance as well as development, and have a high degree of turnover. Depending on velocity alone may not be enough.
Instead of CPI/SPI, ask your teams for the sprint commitment data as the best indicator for project success.
3. What is the TeamScore of your Customer or Product Owner?
Once of the key differentiators of any Agile project is the idea that customers and product owners are more closely involved in the process than in the more traditional “waterfall” environment, where some say the customer throws a poorly written requirements specification “over the wall” and shows up a year later to say they don’t like what’s been built. While this is probably unfair to many waterfall-style teams that have had success, it’s true that the failure rate, estimated at 70% by the Software Engineering Institute, is too high. And of that 70%, the reason most cited was “lack of customer involvement” and “understanding the requirements.” Thus the role of “product owners” was identified as pivotal to agile success.
The entire concept of “agility” is dependent upon customer and/or product owner engagement. Without regular interaction between the customer and agile team, the very foundation of the approach will crumble – it’s not if, but when.
Nothing is more important, because without this you cannot be “agile.”
Values like “customer collaboration over contract negotiation” and “Responding to change over following a plan” from the Agile Manifesto become unsupportable.
Using the TeamScore metric described in #1, evaluate your customer engagement, in aggregate, for every sprint. Use this an an early-warning system of project success.
4. What is one thing you did THIS WEEK to build collaboration, trust, and transparency?
Collaboration, trust, and transparency are core agile values, and more than any others define the philosophy and driving force behind the very idea of agility.
Unlike more traditional methods, agile frameworks and techniques are derived directly from these core agile values, and without them it will be impossible to field high-performing agile teams.
By nature, typical engineers are not social, collaborative, trusting, or transparent. Decades of Information Technology command-and-control management has trained them to be even less so, where knowledge is power and politics run rampant. The good news is that this is a fixable problem.
A great Agile CxO is as engaged with his/her teams as much as they insist their teams be engaged with each other.
Begin by asking the simple question of each team – “what is one thing you did this week to build collaboration, trust, and transparency? Collect the list and use it as a guide for new employees and as a tool for coaching those who are struggling with agile adoption.
5. What is one thing gleaned from each team’s retrospective that could benefit all of the others?
Agile teams pride themselves on continuous improvement, “inspect and adapt,” and self organization. These are all good things, and any Agile CxO should encourage this behavior (and demonstrate it themselves), but they should also encourage teams to share with other teams.
I know this is a hot-button topic. Many Agile puristas will argue that the nuclear team is everything, and that the lessons gleaned from Retrospectives is not useful to other teams.
As my farmer grandfather would say: horse-pucky.
To begin with, the number of teams that skip their Retrospective is alarming. Teams don’t like to hear this, but IF YOU’RE NOT PERFORMING A RETRO, YOU’RE NOT DEMONSTRATING AGILE VALUES.
The Agile CxO should not only insist on regular retros, he/she should encourage information sharing across Agile teams. I like using a visual indicator, like a hall-board, but ou can also develop a database, keep a spreadsheet, use Google Docs, Jira, or TFS.
Organizational Improvement requires infrastructure and team work. Asking this question helps get teams focused on the larger organization – and improves EVERYONE.