BT

How to Audit an Agile Team

by Vikas Hazrati on Apr 20, 2010 |

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.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Two different things by Jim Leonardo

Are we talking agile coaches or auditors? A coach is a management 'consultant' whose role is to improve existing processes and mentor the team, the leads, or its scrum masters in id'ing and making improvements. An auditor is someone who is there to observe and report only. There's a role for both, however, if an audit is what you're after, you don't want the auditor in the position of auditing their own work or in the position of suggesting work for themselves to do. Sometimes there may be some bleed over, but I would be suspect of asking someone to report on the progress/capability/maturity of the team if there's a chance they might be the one tapped for "improving" the team. Either be clear that's what they are there for upfront or rule out the possibility of them doing so upfront. Any other option causes a clear conflict of interest.

Re: Two different things by Vikas Hazrati

Hi Jim, I agree with you that these 2 are separate roles however, more often than not, we have been called to be an auditor first and then transition into a coach. Not sure if this a rare occurrence for others. Many times the stakeholders have felt that they would like to first get a report on how the team is doing because they suspect a few things which are not right. Once you report then they expect you to handhold the team to plug in those gaps. So there is a definite bleed over from one compartment to the other and then the general understanding is that since you know the shortcomings and the holes, can you also help in improving.

Re: Two different things by Rashina Hoda

Hi Vikas, Good to see you discuss this important topic. I too find these are 2 separate roles often played by the same person (an Agile Coach): a Mentor role that helps the team get trained in Agile and encourages continued adherence to Agile practices and a Terminator role that is able to discern problems in the team in terms of members who don't contribute positively to the team and engage with senior management to remove them. Part of the Terminator role involves evaluating people and their contribution to the Agile team. Details at: Organizing Self-Organizing Teams

Re: Two different things by Priyank DK

Hi Jim,

I too experienced both roles are same. Major here is visibility about Scrum Practices not the roles, whether Scrum is progressing towards the goal or any impediments are there in achieving the goals? Both the roles here are to chuck out risk and impediments of any scrum -

Auditor would for sure take observation, report the compliance, bring in the best practices and share best practices across scrum. Objective of audit is that Scrum can improve and everyone should have visibility to plan further. So if you find the Visibility practice need improvements plan audit.

And the other payer is Coach who helps Scrum to implement best practices, KT and gives consulting over agile practices and work flow. This facility is to manage Risk, lubricate Agility and enable information across Scrums. More or less both roles are same because Coach has to do health check (call informal audit or review) frequently for the project to find out the need of improvements or else team should upfront ask for consultancy. In Agile way we can publish improvements in retro or in daily stand-ups (Review practice brings Coach role frequent to Scrum).

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

4 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT