Quality in software development is often an afterthought. Most software projects assume that quality is ingrained in the development process, only to encounter major quality issues during the test and deployment phases. Projects without quality plans typically are on schedule through the start of the test phase and then fall behind due to endless cycles of testing and rework. These projects either end up canceled or are delivered with unpredictable quality because of a lack of budget or schedule. “When poor quality impacts schedule, schedule problems will end up as quality disasters” (Seshagiri, 2014, p. 32).
Every developer, as a human being, is fallible and may introduce defects. The development process accounts for this fact and identifies tasks where defects could potentially be introduced. Quality steps are added into the development process to remove any introduced defects as early as possible. Adding quality gates and accounting for anticipated defects in the development phases helps reduce the number of defects passing through and improves the quality of the development process. Quality data analysis and statistical process controls are used to help identify components that may require remedial actions to ensure high quality.
Also Read: How to run Productive Scrum Meetings
Execute the plan
“How does a project get to be a year late?…One day at a time” (Brooks, 1995). Project-level plans will guide the team to achieve its goal only if the plan is maintained periodically to reflect the current status and list the remaining tasks required to meet the final goal.
To understand current status and maintain the project-level plan, individual team members need to understand the status of their commitments on a daily basis. This requires individuals to track data as they work and analyze their status daily. Tools capable of gathering data, analysis, and projections help individual developers understand their current status, identify projections based on completed work, and define quantitative corrective actions required to complete their assigned work on schedule. An individual plan summary, shown in Exhibit 2, addresses the key information required to be understood at the individual level:
• What tasks do I need to work on?
• When should I close each task?
• What are the dependencies?
• Am I making sufficient progress for the week?
Exhibit 2. Individual plan summary.
Corrective actions taken at the individual level helps the individual stay on track and in turn helps the project stay on track. The team is collectively responsible for supporting one another and ensuring that all team members are able to meet their individual commitments.
The project status dashboard, shown in Exhibit 3, addresses key information at the project level:
• What is the project’s current status?
• What is the projected completion date?
• What is required for on-time completion?
• Is the team’s actual effort distribution as planned?
Exhibit 3. Project status dashboard.
The status clearly shows that the project was behind. At this stage, the project was 3.8% behind against the baseline project plan. The team made a collective decision not to take corrective action on the project plan, until research, proof of concept, and pilot component tasks were complete. These tasks provided the data the team required to plan for the remainder of the project. The corrective actions listed below were identified based on the data and current status:
1. Processes were streamlined to minimize non-product engineering effort. When sufficient information was not available, effort buckets were added. These buckets became catchalls. Analysis helped the team identify well-defined tasks and minimized effort buckets.
2. The development process was revised for new component types. For example, design walkthroughs were added in addition to team inspections.
3. The development process was revised for some of the standard component types. For example, unit test case inspection was decoupled from design inspection into a separate task.
4. Development process task percentage distribution was revised for some of the standard component types. For example, percentage distribution for the design phase was made different for user interface, middle tier, and database components.
5. Each team member committed to expending an additional effort over a 12-week period instead of adding 1.5 additional resources. The 12-week period allowed each team member the flexibility to plan on when his or her portion of the additional effort would be expended.
Also Read: Job Profile of a Scrum Product Owner
Project quality is monitored throughout the execution of the project. Poor quality at the component level can cause disasters at the project level. Compromising on quality steps during development—for example, to help with schedule—invariably leads to poor project-level quality and schedule unpredictability during the test and deployment phases. Individual developers are encouraged to strive for developing 100% of their components with zero post-unit test defects (components yield). Based on project data, two key corrective actions were executed:
1. Personal review training and mentoring: This action resulted in a 17% reduction in defects found in team inspections, with a projected savings of 3.4% in project effort and ROI of 9.8/1.
2. Unit test training: This action increased yield by 12.5%; 92.3% of defects introduced during development were removed during development (before integration or system test).
You can attend our Online Certified Associate Project Management Training facilitated by our trainers who have more than 15+ yrs. of training and industry experience.
MSys Training is the markets-leading learning services company. Our customized training solutions are efficiently tailored to meet organization and individual goals. With various training formats, technologies, and approaches, we recognize the need for custom solutions that fit your company’s systems. MSys Training is highly recognized for its global expertise on trainings to co-create significant business value.