Agile under ISO: Review and approval on agile projects PDF Print E-mail
Written by Ed Willis   
Monday, 27 February 2012 21:10

ISO9001Below I sketch out some approaches to handling document review and approval in an agile context.  The truth of the matter is that most of the discussion is relevant to any project that operates under ISO9001 or implements technical review and approval any other reason – it’s just that the problems alluded to below stand out in in particularly sharp relief on agile projects.

Reflecting on this a moment, I am surprised at the amount of background I have in this area.  I have participated in the development of an ISO9001 Quality Management System (QMS).  I’ve managed aspects of a QMS.  I’ve audited projects, have had my projects audited many times and have helped resolve a few issues uncovered during ISO audits.

But I’m also a big Scrum proponent as the bulk of the entries on this site will demonstrate.

At this stage in my career, I’m no ISO apologist.  If I started a company tomorrow, I can’t imagine what would convince me to adopt ISO9001 – I’ve just seen far too much dysfunctional behavior done to satisfy ISO or ISO auditors to want to tilt at that particular windmill myself.  That said, ISO forms a foundation for many, many companies out there and any attempt to adopt agile methods in those organizations will challenge the teams to find ways to reconcile agility and ISO-ity.

In particular, document review and approval is one area that will inevitably come up.

Introducing Document Approval and Technical Review

Before we get rolling, let’s spend a minute differentiating technical review and document approval – many people lump these concepts together but they’re really very different.

Document approval is a mechanism used to indicate that a given deliverable is of sufficient quality to base further work on.

So when we approve, for example, requirements, we’re saying that it’s ok for people to use them as a basis for their work in testing, design, etc.  While there is some expectation that the approvers have familiarized themselves with the document contents, there is no expectation of a detailed review of the document per se.

Document technical review, on the other hand, is a mechanism used to identify defects in a document.

We would technically review e.g. an architecture document in an effort to find errors in it - the expectation being that they will be cheaper to address in the document than they would be had we developed the software itself with the same errors.

There is a surprising amount of latitude in defining your use of these mechanisms.

For approval, the typical ISO expectation is that any document used to control work will be approved while other documents need not be approved.   This will meet most people’s intuition regarding approval – things like requirements, test plans, architectures, project plans et al require approval, whereas things like meeting minutes and test execution reports do not.

For technical review, there is still more flexibility.  Under ISO, the minimum bar is set at requirements, architectures and designs – those deliverables must be technically reviewed.  Everything else is up to management and the team to decide.

Why bother making technical documentation?

Agile Software DevelopmentThe easiest way to avoid review and approval headaches is to write fewer documents - shocking stuff, no?  Here’s an interesting thought experiment – what if you could write exactly zero technical documents?  For certain, any problems with approval and technical review difficulties would vanish.  The ill effects, though, are the interesting things to consider.  Alistair Cockburn, in Agile Software Development makes the point that there are really only two reasons to develop technical documentation:  to improve the odds of success right now and to help future maintainers somewhere down the road.  This leads to my first tip:

 

  • Tip #1:  Make sure there is a compelling motivation for authoring a document – and don’t create one unless there is someone who really needs it.

 

I’m generally not especially good at guessing what future user needs will be.  Similarly, I have no reason to believe I will be much better at predicting what future maintainers of my system will want.  The best I can do is get those people involved in my projects right now and learn from them what they need as I’m working to deliver the project.  Beyond that, my advice is to develop what the extended project team needs to do its work – if they’re happy then much of what future maintainers will need will also be covered.  That leads to my second tip (which is really a restatement of the YAGNI principle):

 

  • Tip #2:  Be greedy!  When figuring out what documents to produce, involve the right stakeholders but favor making things that produce immediate benefits.  Don’t make documents just because they might be useful down the road.

 

If a given document won’t pay for itself somehow, then don’t write it.

If you optimize the set of documents this way, you will have reduced your difficulties with technical review and approval commensurately.  On an agile project, it is even more important to get this list as small as possible, as the deliverables on it may need to be developed iteratively.  That can make review and approval harder – so keep this list small.

ISO is what your local QMS says it is

QMSA typical approach to adopting ISO9001 is to first define the organization’s QMS.  In an audit, once auditors are convinced that the QMS itself satisfies ISO requirements, they audit against the QMS rather than the ISO9001 standard itself.  And QMSs vary quite a lot between organizations.  Getting to understand your organization’s QMS is an important step to take in taking charge of your project’s execution under it.  It’s a rare QMS that sets project expectations in a black and white manner – typically there are opportunities to configure project commitments in a manner that befits the project’s needs while also satisfying the QMS’s requirements.

 

  • Tip #3:  Don’t assume that your QMS is one size fits all.  Explore what options it provides in tailoring the set of project deliverables to better fit your (and your stakeholders’) needs.

 

Aim to make that small list of documents we talked about earlier be this set of documentation commitments.

I’d be remiss if I didn’t point out that one of the best ways to manage technical documentation in as light-weight a manner as possible is to reuse documentation.  There is no extra credit to be had in ISO for making new documents for each new project (although a surprising number of projects do just that).  Instead of writing an architecture document for each project, use an existing document as the basis for the current project – and in so doing, move away from “throw-away” documents to living ones.  Along the way, you’ll be improving the value you get out having created the documentation in first place because it will form a comprehensive reference about the product for all team members, both current and future.

Technical review best practices

Document ReviewAt this point, you’ve reduced the documents you’re planning to create or update to a lean and mean set that will provide value and has a clear tie to your QMS’s expectations.  Let’s turn our attention now to getting the most out of technical review.  The first thing I’d suggest is to make sure you’re clear on what you’re trying to accomplish with a technical review.  In my experience, technical reviews are used for a mish-mash of at least these three distinct objectives:

Informing people about project direction and progress – as an example, consider the “courtesy CC” on a review.

Obtaining people’s agreement with project direction and scope.

Finding problems with the document.

Here’s a very important tip:

 

  • Tip #4:  Only use technical review for finding defects.

 

For the first objective – informing people - listed above, sending them a longish document is killing them with kindness.  Schedule a walk-through of the document with them and leave plenty of time for their questions.  That will almost certainly make better use of their time.  Or perhaps send them a high-level presentation calling out the major aspects of the document contents.  Either way, sending them the full document is probably not a great way to handle their need to be informed.

For the second objective – obtaining agreement – a walk-through or summary presentation may also be a better approach than involving them in a technical review.  If getting their agreement is really critical, consider making those people approvers of the document.  But having too many approvers is also a poor practice as well, so beware (see below).

In general though, the selection of reviewers should respect the following tip:

 

  • Tip #5:  Be greedy! Only involve people in a document’s technical review that will find defects in it.

 

To get the most out of reviewers’ limited time, don’t give them the impression that you’re looking for more from them than you really are.  For example, if you’ve included security experts as reviewers precisely because you want to leverage their expertise on security matters, tell them that – and direct them to the sections of the document that their input is most urgently needed on.  The time invested in making expectation clear will be paid back in spades in the form of higher reviewer response rates, speedier review and better feedback.

 

  • Tip #6:  Tell technical reviewers where their attention is most needed.

 

One specific case to consider is the situation where you’ve changed only portions of a document – ask reviewers to focus on those areas.  This is especially important on an agile project because the team will  likely to be doing documentation work in an incremental and iterative manner – don’t give reviewers the impression that they have to review the whole document if that’s not actually what’s needed.

Approval best practices

ApprovalThis area is tough.  In most organizations in which I’ve been a part, approval is what a colleague once called “a malignant fascinoma”.  Left to my own devices, approval is one of the first things I would try to get rid of in most organizations.  I suspect that the motivation for formal approval processes stems from three causes:

 

  • the right people aren’t empowered to make decisions (so they must seek approval from those who are)
  • people who should be working closely together are not doing so (so elaborate mechanisms of handoff between them are created)
  • an organizational culture of fear where the last thing anyone wants to do its trust a colleague

 

But I digress - this post isn’t about how approval processes are a bad idea - it’s about how we can manage our agility within a context that demands approval.

Agile projects need approval to go much, much more quickly than most approval processes normally go – but then again agile projects need everything to go faster that the typical development process built on a foundation of plan-driven development lifecycles can manage.  I know of a project that had issues in an audit because they were still struggling to approve their requirements while they were nonetheless releasing “gold candidate” software to their customers.  That’s particularly pathological, but it’s not really that unusual – and certainly the expected performance of most approval processes is glacial compared to the pace of an agile project.

A key question to ask is “How can approval be managed to ensure it does not slow down the agile team’s pace?”

 

  • Tip #7:  Push approval as far down into the organization as it can possibly go.  Ideally approvers are on the agile team itself.

 

Make that the goal – document approvers are on your team:  Product Owner, ScrumMaster and team members (to use Scrum examples).  The extent to which you are successful at this is the extent to which approval won’t be problematic.  If the project is agile, the team will most likely need to develop at least some technical documentation incrementally - having approvers on the team helps ensure that changes can be approved in the same iteration they were introduced.  The further you get away from having your team members be your approvers, the longer approvals will take and the more painful they will be.  Balance that fact against whatever the benefits are that moving approval further up the organization will provide.

 

  • Tip #8:  Have as few approvers as possible – ideally only a single approver for any given document.

 

Similarly the more approvers there are for a document, the longer the approval will take and the more painful it will be.  Balance that fact against the expected benefits that having more approvers will provide.  Use other mechanisms to address the needs of people who would normally want to be approvers (like the walk-throughs and summary presentations suggested earlier).

One thing I can say from painful personal experience is that the time performance of most processes in software development is largely a function of the number of people involved in them – so if a process needs to go fast, involve as few people as possible while still accomplishing the purpose of the process.  This is nowhere more apparent than it is in approval.  Agile projects need to be quick on any numbers of fronts.  Approval is one of them.

Let’s turn our attention to the details of iterative document authoring and approval.  In the limit, the team could iteratively develop every single document it delivers.  Doing so will ensure that each is current at all times but will increase the approval overhead.  At the other end of the spectrum, they could develop documentation only when it is needed and approve it right before it is used.  Documents the team itself will use (for example developer’s guides, test plans, architectures and designs) are good candidates to develop and approve iteratively while others are candidates to develop and approve right before their use or delivery.

 

  • Tip #9:  Develop documents very close to the point where they are needed and approve them right before they are used.

 

Configuration managementOne last tip about approval – there’s no law that says “one document version == one approval”.  If we borrow a configuration management concept, “baselines”, we can define approval in terms of sets of documents.  For example, returning to the documentation the development team produces for its own needs, we could define a baseline containing those documents and then define approval as a single blessing on the specific versions of the documents in that set.  This, in combination with some of the earlier suggestions, lays the foundations for an ISO-compliant approval process that has a chance to go fast enough to keep pace with the agile project.

 

  • Tip #10:  Define baselines of documents used in similar contexts or for similar purposes and then define an overall approval in terms of the versions of the documents in the entire set.

 

Hope these tips prove useful.  I’ve used them all at one time or another and have gotten value from all of them.

I’ve also made every single one of the mistakes alluded to above and paid the price for them.

Hopefully you won’t have to.

I'd like to thank Selaine Henriksen and Emma Henriksen Willis for their help in editing this article.

Last Updated on Monday, 02 April 2012 16:46