An IT consulting company with two office locations and 100-plus people specialized in custom software development and testing services. The firm did in-house software development training for developers at both locations and had trainers, HR, accountants, legal, managers, and accountants on staff. The company wanted to perform an enterprise transformation from Waterfall software development to Agile, and get ISO certified.
Making the assessment
Every Agile coach has his or her own preference in approaching a transformation challenge. Coming from a science and tech background, I chose a clinical approach:
- Talk to the different managers and begin to understand the current SDLC processes firsthand.
- Review artifacts from previous projects.
- Understand the current organizational structure and how decisions are made and carried out.
- Understand how people are assigned to projects.
- Review any documentation on the current SDLC processes.
- Review the training materials to understand what kind of knowledge the associates come with prior to starting a project.
- Talk to the associates who support projects to understand their perspective and thoughts on the current SDLC processes and the general willingness to adopt Agile.
Coming up with the plan
After making the assessment using this approach, we came up with a five-point plan:
- Draft the QA-QM manual to reflect Agile processes that the organization felt comfortable with and map those processes to ISO 9001:2008 standards. (We will discuss the QA-QM manual and what that means in the next section).
- Introduce Agile processes into the training material so future associates will be prepared.
- Start an internal community with Agile evangelists to foster growth and continual improvement.
- Coach the first few teams through the Agile process.
- 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 to ensure and improve quality in your software development life cycle and monitor the satisfaction of your clients. Here are the major sections we implemented for the QA-QM manual, using the Scrum framework:
- A. Quality policy and measurable objectives
- Quality policy: To provide software design, development, and testing services that meet the current needs and future expectations of our customers.
- Quality objectives: Our overall quality goal is to achieve our quality policy and to 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
- Less than 10 percent open, major defects after software goes to production.
- At least 90 percent functionality code coverage (manual or automated).
- At least 90 percent of requirements are completed within the schedule.
- At least 90 percent 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 ScrumMaster 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 the timebox 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's 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 should drive the features and number of sprints delivered. This helps set the expectations on both sides.
- Architectural vision early in the project is crucial to avoid massive technical debt toward the end of the development contract. So we proposed that, at the beginning of each software project, the team spend time to flesh out the high-level architecture and come to a consensus on the best technical approach, based on the initial backlog of stories and the product owner's input.
- D. Monitoring, tracking, and getting customer feedback
- Ensure that 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 burn-down 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 Agile processes during that training. That, combined with selecting people from the company who showed passion about Agile and sending them for certified training, was a win-win situation.
3. Start an internal Agile community. We started an internal Agile community and invited trainers and associates to get involved. The internal community helped 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 that people follow 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 the 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 ISO compliance. So we decided to create a project for this, with a backlog of stories. We called the project "IPA" for "Internal Process Automation" (not to be confused with the beer!). The areas for electronic automation were course surveys, client surveys, training surveys, training evaluations, procurement evaluations, preventive/corrective actions, internal audits, requests for purchases, recording notes for continual improvement and project end retrospectives, impediment/help desk issue tracking, understanding one's career path at the organization, and 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 plug-ins) solution. Given the maintenance concerns with Jira plug-ins, we opted for the custom Sharepoint 2010 solution.
ISO compliance is very particular about sustainability and continual improvement — just like Scrum. Therefore, apart from automating our internal processes, we set up a PMO office to oversee the Agile processes that were put in place and to ensure that every Scrum team had a member who 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 nonconformance, and disseminate the information appropriately.
Quarterly PMO management meetings
These meetings are a great way to review feedback from different projects to improve Agile processes across the organization, understand why certain processes may not be followed, and help support teams that aren't 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 that preventive and corrective actions are resolved.
- Be responsible for making sure training materials reflect the current Agile processes for the organization.
Improvements and being Agile result from retrospectives, management meetings, and audits
When conducting a retrospective, the ScrumMaster must record the areas where we can improve or correct, and then discuss with the team a time frame 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, multisite
- Stage 1 audit: Location 1 - Readiness (1 day)
- Stage 2 audit: Locations 1 - Nonconformance (2 days)
- Stage 1 audit: Location 2 - Readiness (1 day)
- Stage 2 audit: Location 2 - Nonconformance (2 days)
We passed all the stages at all the sites with no nonconformances!