RE: [scrumdevelopment] Re: Audit of Scrum project
- If you are really doing scrum, you are inspecting work very frequently. Ideally, the team will be interested enough in scrum to figure out whether or not they are really doing it. Some web browsing and a few books, possibly a coach can help. At a very basic level if you want to check whether you are doing it, you can use the nokia test during a retrospective, to figure out where you are. For more info check out Jeff Sutherland's googletechtalk on youtube about the secret sauce in scrum.
External verification is a nice to have, altough the team's time is probably better spent focusing on creating working software.
Registered Office: 85 Gracechurch St., London, EC3V 0AA
Registered in England and Wales No 3475006 VAT Reg No 710 3140 03
From: email@example.com [firstname.lastname@example.org] On Behalf Of woynam [woyna@...]
Sent: 19 December 2011 15:58
Subject: [scrumdevelopment] Re: Audit of Scrum project
An audit is an independent verification that a group/organization is following a defined process.
There's an old joke that says you can build the world's best lead life preservers, and still pass an audit, provided that you follow your organization's process for building lead life preservers.
There are plenty of examples of organizations that have won industry awards for process (improvement), but have still managed to fail in the marketplace.
So, if an organization has adopted Scrum, then the audit would verify that Scrum is actually being practiced. Is the PO managing a prioritized product backlog? Is the team conducting Sprint planning meetings? Retrospectives? Is the team delivering working software each Sprint?
Now, if the organization has not officially adopted Scrum, and are basing an audit on a waterfall-based process, then you will have problems.
You really only have two choices. The best choice would be to convince your organization to change the audit itself to reflect that your group is now doing Scrum.
The other option is to try to fake it. This is less than optimal, as it generally requires the team to produce artifacts (e.g. design document) simply to pass an audit. It actually quite ridiculous, but it does happen. What this basically says is that the organization is not really serious about producing working software, but rather, becoming excellent at passing audits. See my comment about lead life preservers above.
--- In email@example.com<mailto:scrumdevelopment%40yahoogroups.com>, George Dinwiddie <lists@...> wrote:
> On 12/15/11 7:15 AM, Rama Bharti wrote:
> > In organizations, I have worked for, there are some milestones.In which,
> > at each milestone, there is an audit of project by process team whether
> > all the organizations process are followed or not. Generally these
> > milestones are like Design, Coding, Testing etc (Waterfall).
> You're talking about a phase-gate approach to development. In Scrum,
> there won't be milestones for Design, Coding, and Testing, because these
> things are not separate phases.
> You're welcome to audit a project at any point, but you should audit the
> working system under development, not internal artifacts of development.
> - George
> * George Dinwiddie * http://blog.gdinwiddie.com
> Software Development http://www.idiacomputing.com
> Consultant and Coach http://www.agilemaryland.org