Achieving Agility While Staying in Compliance – Part 3

So now you are up and running with scrum, doing sprints, and delivering valuable functionality at frequent intervals. Furthermore, you team is constantly learning and improving by identifying and eliminating project impediments, and by diligently closing out the actions arising from the sprint retrospectives. Your customers and management teams are cheering and applauding! You may be at or close to, a framework of concurrent planning, development and validation as discussed in the previous article, and represented by the following diagram:

Of course to get a product to market, you need to do many things outside the boundaries of this diagram: contract negotiation, sales and support processes, and there is much in the ISO/TL 9000 standards devoted to these areas of running a business. You should continue to operate these processes as you have previously done, per the definitions in your quality management system. The question now is: how do you run a truly agile “Product Realization”  system, while satisfying the requirements of the standards?

Let’s take a look at the key requirements for Product Realization for ISO/TL 9000  as defined in chapter 7 of both standards.  For ISO9001 there are 20 individual requirements, and TL 9000 adds an additional 60 requirements (or “adders”) to this list. For our purposes we are going to ignore the sections on Purchasing (7.4) and Control of monitoring and measuring equipment (7.6). This reduces the number of requirements to  11 and 40 for ISO9001 and TL9000 respectively. The sections of both standards we need to concern ourselves about are as follows:

  • 7.1 Planning of product realization
  • 7.2 Customer Related processes
    • 7.2.1 Determination of requirements related to the product
    • 7.2.2 Review of requirements related to the product
    • 7.2.3 Customer communication
  • 7.3 Design and development
    • 7.3.1 Design and development planning
    • 7.3.2 Design and development inputs
    • 7.3.3 Design and development outputs
    • 7.3.4 Design and development review
    • 7.3.5 Design and development verification
    • 7.3.6 Design and development validation
    • 7.3.7 Control of design and development changes

Now let’s take a look the typical kinds of artifacts associated with these requirements. These artifacts are the things that an auditor will want to see to verify that you are indeed compliant with the standard. (I’m going to confine this to ISO 9001 for now).

Requirement ISO Artifacts Scrum Artifacts
7.1 Planning of product realization Defined Lifecycle Model
7.2.1 Determination of requirements related to the product Product Requirements Document (PRD) Product Backlog
7.2.2 Review of requirements related to the product Requirements Review Record
7.2.3 Customer communication Product information, Notification about problems, Problem escalation procedures
7.3.1 Design and development planning Project Plans, Test Plans, Traceability Matrix Release plans, sprint plans, User Story estimates
7.3.2 Design and development inputs Engineering specifications User Stories
7.3.3 Design and development outputs System architecture specs, details designs, source code, user documentation
7.3.4 Design and development review Records of design and code reviews, and actions taken
7.3.5 Design and development verification Records of design verification results and follow up actions to address issues
7.3.6 Design and development validation Records of design validation results and follow up actions to address issues
7.3.7 Control of design and development changes Records showing review and approval of all changes

As we can see, there are very significant gaps in the artifacts required by the scrum process compared with those mandated by ISO 9001, or TL 9000. That is not to say that scrum teams are not actually doing most of what is required. The issue is that in the absence of any ISO-compliant document or record control processes, whatever artifacts do get generated may not meet the standards required by ISO or TL. So now the question becomes how do we generate the required records without overburdening the scrum teams, and taking us right back to where we started, in direct opposition to one of the fundamental principles of the Agile Manifesto!

The ideal solution is to have the required records and data generated automatically as the teams execute their sprints and releases. So now this gets us to the question of tools, and what will really help a team to meet the requirements of standards like ISO 9001 and TL 9000 while staying agile. Here is a list of categories of tools, ordered by the degree of control they provide over project data and records:

  • Sticky Notes on a Whiteboard
  • Spreadsheets
  • Wiki’s
  • Bug Tracking Tools
  • Web-Based Agile Project Management Tools
  • Web-based ALM Tools with Agile Project Management Capabilities

The best overall class of tool will be one that includes the following capabilities:

  • Web-based: available to distributed teams
  • Web-based: data available to management and executives, and those beyond the engineering function
  • Document control (approval and versioning of key artifacts)
  • Record control: secure storage of project data (review reports, test results, change records)
  • Requirements Management
  • Test Management
  • Project Planning (Releases and sprints)
  • Project status tracking and reporting (including burndown charts)
  • Bug Tracking (or integration with major commercial tools like JIRA)
Print Friendly

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>