CASE STUDY INTRODUCTION
IT consulting company specialized in custom software development and testing services with two office locations and 100+ people. The firm did in-house software development training for developers at both locations and had trainers, HR, accountants, legal, managers, and accountants on staff. At the time, the company wanted to do an enterprise transformation from waterfall software development to Agile, and get ISO certified.

MAKING THE ASSESSMENT
Every agile coach has their own preference to approach a transformation challenge. Coming from a science and tech background, I chose a clinical approach.
a. Talk to the different managers and leads to understand the current SDLC processes first hand.
b. Review artifacts from previous projects.
c. Understand the current organizational structure and how decisions are made and carried out.
d. Understand how people are assigned to projects.
e. Review (if any) documentation on the current SDLC processes.
f. Review the training material to understand what kind of knowledge the associates come out with prior to starting a project.
g. Talk to the associates that support projects to understand their prospective and thoughts on the current SDLC processes and willingness to adopting agile.

COMING UP WITH THE PLAN
After making the assessment from the approach described above, we then came up with a 5 point plan:
1. Draft the QA-QM manual to reflect agile processes that the organization felt comfortable with and map those processes to the ISO 9001:2008 standards. (We will discuss the QA-QM manual and what that means in the next section).

2. Introduce the agile processes into the training material so future associates will be prepared when working on agile projects.

3. Start an internal community with Agile evangelists to foster growth and continual improvement.

4. Coach the first few teams through the agile process.

5. Look to inspect, adapt, and automate internal processes.

EXECUTING THE PLAN:
1. DRAFT THE QA-QM MANUAL
The QA-QM (Quality Assurance – Quality Manual) is the core of your ISO compliance. In this context, the manual describes and/or references processes on how you ensure and improve quality in your software development life cycle and monitor satisfaction of your clients. We will state and discuss the major sections we implemented for the QA-QM manual using Scrum’s framework.

a. QUALITY POLICY AND MEASURABLE OBJECTIVES
Quality Policy: To provide software design, development, and testing services that meet the current needs and future expectation of our customers.

Quality Objectives: Our overall quality goal is to achieve our quality policy, and maintain the integrity of and continually improve a Quality Management System compliant with ISO 9001:2008.

MEASURABLE QUALITY OBJECTS FOR DESIGNING, DEVELOPING, AND TESTING SOFTWARE:
1. Less than 10% open, major defects after software goes to production.
2. At least 90% functionality code coverage (manual or automated).
3. At least 90% of requirements are completed within the schedule.
4. At least 90% client satisfaction at project close.

b. INTAKE PROCESS: PROJECT CHARTER
The project charter is initiated once the client provides a set of stories to create the initial product backlog. In the project charter, the appropriate dev team (dev and QA) is identified and assigned. The Scrum Master is also assigned based on availability, project complexity, and experience. The Project Charter also specifies the product owner as the dedicated contact person to clarify requirements and define the acceptance criteria. Other criteria to complete the project charter are time box of each sprint, identification of stakeholders, vision, major milestones for the project, and tentative date for delivery.

c. HOW TO ASSESS AND MITIGATE RISKS
When assessing and mitigating risks, two potential issues always comes to mind – contract terms and architecture.

As the software vendor providing services to the client, it is important to write the contract knowing that the client may change or add requirements. Unlike the Waterfall approach, we specified that the allocated client budget drives the features and number of sprints delivered. This helps to set the expectations on both sides.

Architectural vision early in the project is very important to avoid massive technical debt toward the end of the development contract. So, we proposed that at the beginning of each software project, that the team spends time to flesh out the high level architecture and come to a consensus to the best technical approach based on the initial backlog of stories and product owner’s input.

d. MONITORING, TRACKING, GETTING CUSTOMER FEEDBACK

To ensure the project is on track, the client is happy, and the team is healthy, the typical metrics and work items should always be collected and evaluated: team’s velocity, team’s burndown rate, spikes, stories/task breakdown, defects, product backlog, sprint backlog, retrospective feedback, sprint review feedback, and post documentation.

2. INTRODUCE THE AGILE PROCESSES INTO THE TRAINING MATERIAL
Introducing the agile process to an organization can be challenging. But we actually lucked out, since the company did internal IT training, it made perfect sense to introduce the agile processes in the training. That combined with selecting people from the company that showed passion about agile and sending them for certified training was a win-win situation.

3. START AN INTENRAL AGILE COMMUNITY
We also started an internal agile community and invited trainers and associates to get involved. The internal community helped to facilitate and improve on the processes and tools for driving successful agile projects within the company.

4. COACH THE FIRST FEW TEAMS THROUGH THE AGILE PROCESS
Training and talking agile is not enough to ensure people are following the agile processes and understand the concepts. This is why we stayed on to coach a few teams through their projects. We coached them from the inception of the project vision to sprint retrospectives to close out of the project.

5. LOOK TO INSPECT, ADAPT, AND AUTOMATE INTERNAL PROCESSES
Lastly, we found several opportunities for process automation to help support the ISO compliance. So, we decided to create a project for this with a backlog of stories. We called the project IPA (Internal Process Automation) – not to be confused with beer! The areas for electronic automation were: course surveys, client surveys, training surveys, training evaluations, procurement evaluations, preventive/corrective actions, internal audits, request for purchases, recording notes for continual improvement and project end retrospectives, impediment/Help desk issue tracking, understanding your career path at the organization, statuses of all client projects being worked on.
The approach was not to have too many different tools to automate the internal processes. With that said, the choices came down to a custom Sharepoint 2010 or JIRA (w/ custom plugins) solution. Given the maintenance concerns with Jira plugins, we opted for the custom Sharepoint 2010 solution.

LONG TERM SUSTAINABILITY
ISO compliance is very particular about sustainability and continual improvement just like Scrum Therefore, apart from automating our internal processes, we setup a PMO office to oversee the Agile processes that were put in place and to ensure every Scrum team had a team member that was well versed in the quality policy and objectives. These volunteers (Agile evangelists) also participated in a quarterly PMO meeting with managers to review and implement improvements to the organization’s processes, update the QA-QM manual, address non-conformance, and disseminate the information appropriately.
QUARTERLY PMO MANAGEMENT MEETINGS
These meetings are a great way to review feedback from different projects to improve the agile processes across the organization, understand why certain processes may not be followed, help support teams that are not able to follow the organization’s agile processes. Basically, it’s a communication channel between the upper management and project team members.
PMO OFFICE RESPONSIBILITIES
• Oversee Agile processes and look for and implement improvements via feedback from project teams.
• Assign the right people for the projects, and ensure that they can be dedicated for the lifecycle of the project as agreed to in the contract.
• Maintain the project charters and show accountability and statuses of ongoing projects.
• Perform internal audits as necessary ( at least once a year at each office location).
• Record Preventive and Corrective actions.
• Ensure preventive and corrective actions are resolved.
• Responsible for training material to reflect the current Agile processes for the organization.

IMPROVEMENTS AND BEING AGILE RESULTS FROM RETROSPECTIVES, MANAGEMENT MEETINGS, AND AUDITS
When conducting a retrospective, the Scrum Master must record the areas where we can improve or correct and then discuss with the team a timeframe to implement those changes. To really correct or improve, you have to identify the root cause of the problem. This is no different with ISO corrective or preventive actions.

CONCLUSION: THE AUDIT AND GETTING ISO 9001:2008 CERTIFIED
• Single Certification, Multi-Site
• Stage 1 Audit: Location 1 – Readiness (1 day)
• Stage 2 Audit: Locations 1 – Non-conformance (2 days)
• Stage 1 Audit: Location 2 – Readiness (1 day)
• Stage 2 Audit: Location 2 – Non-conformance (2 days)
We passed all the stages at all the sites with no non-conformances!