Introduction and Overview What is ISO 9000? Implementing ISO Required Processes Quality Infusion Offer of Proof in the Sprint Review Q&A

Transcription

1 Jim Schiel

2 Introduction and Overview What is ISO 9000? Implementing ISO 9000 Required Processes Quality Infusion Offer of Proof in the Sprint Review Q&A

3 About me 23 years with major ceremony, global organization From leading transition to agile development About ISO 9000 ISO 9000 often seen as product differentiator Focuses on producing a quality product How to implement ISO 9000 with Scrum

4 For organizations that build products or provides services Achieve high customer satisfaction through consistent products Family of standards ISO 9000:2000 defines Quality Management Systems (QMS) ISO 9001:2000 requirements for QMS Quality Management System how you document and maintain your processes Management Responsibility Resource Management Product Realization Measurement, Analysis, and Improvement ISO9000 doesn t give you quality, it simply makes you consistent. Say what you do and do what you say.

5 Need management involvement Provide commitment & time Create a Quality & Process team Going to have to spend some money Learn ISO 9000/9001 and/or get help Change/create several organization policies Leverage Scrum to provide the engine for policy enactment and continuous improvement.

6 Getting Started? Make this all part of a project s first Sprint Create Quality Policy & Audit Plan Define Document Control & Review/ Approval Policies Define Nonconformance Policy Define CAPA Policy Corrective and Preventive Action how we fix things and how we keep them from breaking in the first place Forget about perfection, go for good enough for today.

7 Involve all roles. What s your goal? Why are you doing this? Write it up and explain your commitment Our policy is that we develop only the highest quality products. Our policy is that we partner with our customers to build the best custom software. Outcomes: Written Quality Policy approved by executive management

8 Internal audits are key for ensuring compliance Who will do them? Who is trained to do them? How will they be done (all policies or focused, surprise or scheduled, both/all)? Who enforces the outcomes (corrective actions)? Surprise audits can be problematic. How will you account for the potential loss in velocity when the audit interrupts the team. Quality Manager may need the authority to override the Product Owner. Who will be engaged to handle formal compliance audits? Outcomes: Modified quality policy or separate document

9 Where are formal artifacts stored? How are they versioned? How are they named? How long do we keep them? Outcomes: Modified quality policy or separate document

10 Who reviews which artifacts? Who approves them? This will also drive which artifacts must be created during development. Take advantage of this to find out who REALLY needs what information. Also a good idea to create some kind of template or description so everyone knows what each artifact is supposed to hold. Outcomes: Modified quality policy or separate document

11 What do we do when a defect is found at the customer site? How do we confirm the defect? (do we bring their environment to us, do we go to them, do we just take their word for it and hope to recreate?) How do we prioritize the defect? (routine, annoying, serious, critical?) How do we assess the impact of the defect on other customers? Which customers are affected? How do we inform the customers? What do they do until it s fixed? Outcomes Modified Quality Policy or a separate document

12 Corrective Action How do we fix defects at the customer site? (hot fix, patch, complete redelivery, we VPN in and change it?) How do we track which customer has what versions? Fixes? Patches? Preventative Action How do we ensure that defects don t make it to our customers? Outcomes Modified Quality Policy or a separate document

13 Create them during a project s first Sprint (put it on the backlog). Create a project definition Scrum team with the Quality Manager (person/role) on the team to drive this. Collect learnings from Sprint Retrospectives Every year (more often if you re a beginner), update your policies based on business realities and Sprint Retrospective feedback. Do this whenever you begin a new project too. Tailor the policies as needed when the project begins and when Sprint Retrospectives indicate a significant problem.

14 DONEness Definition how we define when a PBI is complete. Organizational definition necessary for all projects Project definition necessary for all Sprints in a project; may be modified based on tailoring Team definition team s extensions to DONEness Whatever you believe is needed to ensure quality in the product goes in the DONEness Definition!! DONEness definition is a controlled document it must follow the document control policy Defects which priorities (per the nonconformance policy) are allowed to go directly to a Scrum team?

15 Build applicable policies right into organizational DONEness (quality infusion) Document control By the end of the Sprint, all PBI-related artifacts must be updated (their change description tables updated), and checked in to the project source repository. Change logs should include the date and name of person who made the changes. Review and Approval policy Before the end of the Sprint, completed source code must be reviewed by two senior team members. Make sure that you have some kind of proof that a review was done Preventative Action policy Root causes for critical defects should be determined and review during Sprint Retrospective for potential policy and/or DONEness definition changes.

16 Sprint Planning Always make sure you have the latest version of the DONEness definition!!! Convert those DONEness needs into tasks Update story narrative document and change log Ensure all artifacts are checked into project repository John to review source code for correctness and coding standards. George to review source code for correctness and coding standards. Can create fewer tasks for experienced teams, but there needs to be proof of any reviews (what was reviewed, who reviewed, and for what).

17 During the Sprint Team ensures that all tasks are completed properly. If you have to deviate from a defined process, be prepared to document why during Sprint Retrospective. When marking a PBI DONE, do a complete check against DONEness.

18 Sprint Review Create a Sprint Review Record What was reviewed (can refer to PBI ID# if applicable)? Final status of each item (DONE or NOT-DONE)? This must be tested against DONEness definition; review as much as possible be prepared to offer proof of documentation, tests successfully run, internal reviews, etc. Who approved? Collect their signature as well. Save the record based on your document control policies.

19 Sprint Retrospectives Document all retrospective findings and save as a project artifact (follow document control policy) Teams should alert quality manager whenever 1. A policy is unclear or incorrect. 2. A policy had to be deviated from during the Sprint and why. 3. The team finds an improvement to the policy 4. The DONEness definition is missing something Quality manager should review all retrospective findings to locate trends and common problems. Depending on the amount of changes/deviations, the Quality Manager should convene discussions to update formal policy documentation.

20 Audits will result in corrective action reports Describes something that is not in compliance with documented process. Could be an action or inaction by a team member Could be an activity that isn t covered by a defined process, but should be Comes with short and/or long-term timeframes for identification and enactment of solutions. Policy documents should be changed. DONEness definitions should reflect the change to ensure that Scrum teams create proper tasks on their backlog.

21 Enabling ISO9000 with Scrum can be done in an agile manner Create a starter set of policies Teach Execute Assess and correct Repeat Just like building a complex system, build your quality policies slice-by-slice, learning as you go.

22 Jim Schiel