How to Audit an Agile Team

Stakeholders of an Agile project often seek the help of a seasoned Agile coach to gauge the effectiveness of the Agile process and practices that their team is following. The intention is to plug the holes and make the team more effective. Recently, on the Scrum Development group, Scott Killen started a thread on how to do an audit on an Agile team.

George Dinwiddie suggested that he would prefer a one to one interview with the team members. According to George, this is much more effective in unearthing data than doing a retrospective with the entire team. He quoted an interesting presentation of the AYE conference where Johanna Rothman spoke about ways to unearth data. She mentioned that the best way to do assessments is to ask open ended questions and avoid the interview traps. Johanna suggested the following

Interview tips:

• use open-ended questions as much as possible
• use behavior-description questions as much as possible to get real live examples
• use meta questions to ask about what else to ask about
• separate strategic questions of management from tactical questions of technical staff

Interview traps:

• never ask leading questions, such as "is your manager a bozo?" You won't get an honest answer and the question diminishes your authority, authenticity, and credibility. A lot to lose in one question.
• avoid opinion questions such as, "Do you like what you do?" Instead, reframe it as, "What's working for you here?" and "What prevents you from getting your job done?"

Don Gray suggested that his approach to audit a team would be based on the concept of smoke jumpers.

Do you know about smokejumpers? They're brave, self-sufficient firefighters who parachute into remote areas wearing eighty pounds of gear and ready to fight a forest fire. If the jump goes well, they land safely. After extinguishing the fire, they may have a ten-mile hike out. It's not a job for the faint of heart, slow of mind, or weak of back.

Just like smoke jumpers, coaches might need to jump into a software project midstream and make an impact. The best way to do that is to walk lightly, build trust and conduct simple small experiments which lead to visible results.

Alan Dayley was of the opinion that coming into a team as an auditor brings a negative notion. According to him, audit is a very command and control type of term. He suggested that the coach is like an outside voice who is there to guide the team and help them improve. He suggested the following strategy,

I would start with nearly silent observation of a sprint, or just a first few days of one, right at the transition point between sprints. For example, attend the Sprint Review, Retrospective and Planning just to see and maybe ask a few questions. Then, start filling in the gaps of knowledge and practices that appear to be present.

Cory Foy, agreed that audit is a bad term. He added that in his experience, the real dysfunctions go beyond the team and end up well within the organization as a whole. He suggested that he would do one to one sessions with the team members and would also have a discussion about their workflow. Cory defined workflow as,

One other thing I like to start with on teams is a discussion of their workflow. How does something get from a customer request to being shipped? That might help pull a lot of good information about pain points.

Thus, the group seemed to agree that for conducting assessments, one to one interaction would be a better option. There was also a general agreement that using the term audit and going in as an auditor might not go well with the team. If one is smoke jumping then the key lies in building trust, gathering information about the territory and doing your job well by being with the team.