This article describes the successful implementation of a Six Sigma Green Belt project in information technology (IT) in which a software development team applied Six Sigma to reduce the resolution time of software defects and minimize rework, thereby increasing customer satisfaction.
A software development team in a leading environmental services company wanted to reduce the resolution time of software defects and change requests that were submitted by the company’s internal customers. The IT team used a defect-tracking application to track the submitted requests and defects. Work items were assigned to the team members for development and testing; updated code was released to the production environment in build cycles of once a month.
The aim of this project was to reduce the development and testing time of work items and to minimize expensive rework using DMAIC (Define, Measure, Analyze, Improve, Control). In the context of this article, rework is defined as revisiting a work item after it is considered resolved and has been deployed to the production environment.
The software development team, business analyst and customers defined the current problem by the following three parameters:
◉ Resolution time for work items and defects should be reduced.
◉ Customer requirements are not well understood, which leads to costly rework.
◉ Related work items are fragmented across build cycles, which increases the time to resolution.
Historical data from the defect-tracking application as well as up-to-date information was used to estimate the average resolution time of a work item. Using variable data derived by analyzing the submitted tickets, it was found that the average resolution time for a work item was one build cycle (34 days), as shown in the figure below. (As a side note, many projects were taking far too long. A business analyst joined the company and quickly cleaned up the backlog and helped close outstanding issues.)
Work Item Resolution Time
Process Mapping
Process mapping was used to characterize the existing process. Table 1 depicts the current assignment of work items in the team. The priority list of work items for the build cycle is comprised of four items:
◉ Two items related to developing administrative tools in a the software application: admin tool 1 and admin tool 2.
◉ Two items related to editing and displaying customer financial information: finance-related tool 1 and finance-related tool 2.
Table 1: Work Item Fragmentation – Before
The development team manager recognized that software development is a creative process and can quickly get monotonous. Thus, the work was structured so that Developer 1 was assigned two work items: admin tool 1 and finance-related 1 while Developer 2 was assigned the other two work items: admin tool 2 and finance-related tool 2. The mix-and-match assignment of tasks was set to ensure that all developers would get the chance to work on all areas of the application and gain domain knowledge (both functional and technical) of the application.
Several tools were applied during the Analyze phase of this project. Pareto charts were used to quantitatively analyze the customer requests and determine which areas in the application generated maximum customer requests. It was decided to document the code in these areas and provide user training where needed. The 5 Whys tool was used to analyze reasons for rework across build cycles.
◉ Defects in related web pages and modules were reported at different times.
◉ Resolution of work items was not always achieved per the customer’s expectations.
Each of these instances required rework.
The software development team documented a process to improve software development efficiency and to reduce rework. The new strategy included the following steps.
◉ Reduce knowledge switching: The customers, development team manager and the business analyst started investing significant resources in prioritizing and grouping of work items. Similar work items within a software application were aggregated and assigned to the same developer. This allowed the developer to minimize wasted knowledge recovery time between tasks, and greatly reduced software development and testing time.
◉ Reduce rework: Throughout the lifecycle of a work item, the customers and the development team started jointly reviewing the in-development product using prototypes and screen shots. This iterative methodology allowed the customers to request any additional changes early in the development process and reduce expensive rework. Rigorous unit testing and peer code reviews within the development team further increased code reliability. Knowledge sharing between developers (through technical presentations and building domain knowledge within areas of the application) was encouraged.
Related work items were combined and assigned to one software developer in one build cycle. As shown in Table 2, Developer 1 works on the admin tools, while Developer 2 works on the finance-related tools; this continuity in work improved work item resolution time.
The list of work items that was used to assign tasks per month was revised to combine related tasks. Resolution time for work items was monitored. It was found that by gathering detailed requirements, carefully prioritizing work items and assigning similar tasks to the same developer, more development and testing could be accomplished in a single build cycle. The defects submitted to the defect-tracking application were monitored and the number of requests for rework decreased significantly.
The aim of this project was to reduce the development and testing time of work items and to minimize expensive rework using DMAIC (Define, Measure, Analyze, Improve, Control). In the context of this article, rework is defined as revisiting a work item after it is considered resolved and has been deployed to the production environment.
Define
The software development team, business analyst and customers defined the current problem by the following three parameters:
◉ Resolution time for work items and defects should be reduced.
◉ Customer requirements are not well understood, which leads to costly rework.
◉ Related work items are fragmented across build cycles, which increases the time to resolution.
Measure
Historical data from the defect-tracking application as well as up-to-date information was used to estimate the average resolution time of a work item. Using variable data derived by analyzing the submitted tickets, it was found that the average resolution time for a work item was one build cycle (34 days), as shown in the figure below. (As a side note, many projects were taking far too long. A business analyst joined the company and quickly cleaned up the backlog and helped close outstanding issues.)
Process Mapping
Process mapping was used to characterize the existing process. Table 1 depicts the current assignment of work items in the team. The priority list of work items for the build cycle is comprised of four items:
◉ Two items related to developing administrative tools in a the software application: admin tool 1 and admin tool 2.
◉ Two items related to editing and displaying customer financial information: finance-related tool 1 and finance-related tool 2.
Table 1: Work Item Fragmentation – Before
| Work Item | Build Cycle | Developer |
| Admin tool 1 | 4 | Developer 1 |
| Finance-related tool 1 | 4 | Developer 1 |
| Admin tool 2 | 8 | Developer 2 |
| Finance-related tool 2 | 8 | Developer 2 |
The development team manager recognized that software development is a creative process and can quickly get monotonous. Thus, the work was structured so that Developer 1 was assigned two work items: admin tool 1 and finance-related 1 while Developer 2 was assigned the other two work items: admin tool 2 and finance-related tool 2. The mix-and-match assignment of tasks was set to ensure that all developers would get the chance to work on all areas of the application and gain domain knowledge (both functional and technical) of the application.
In the current scenario, similar work items were assigned to different developers, causing work item fragmentation. Both developers would research the same areas of the application independently; they had to understand requirements, trace issues through the modules of code, develop new code and test code for both work items. Since the work items for the developers were distinct, the development and testing times when taken together were significant.
The team realized that if similar work items within the software application were assigned to the same developer, there would be less context switching required, and the development and testing times would reduce significantly (i.e., to a single build cycle). If Developer 1 was assigned both work items related to administrative tools and if Developer 2 was assigned both work items related to finance, the overall development and testing times would likely be reduced.
An input-process-output analysis was used on a sampling of change requests to determine the inputs (x) that affected the resolution time of customer requests. Customer requirements, prioritization of tasks, technical knowledge and communication all had significant effects on the speed of resolution and the quality of the resolved work items. A cause-and-effect matrix was then used to narrow down the factors that would have maximum impact on the resolution time of work items and the amount of rework involved. Unclear requirements and unplanned assignments of work items to developers emerged as the most important points of focus.
Analyze
Several tools were applied during the Analyze phase of this project. Pareto charts were used to quantitatively analyze the customer requests and determine which areas in the application generated maximum customer requests. It was decided to document the code in these areas and provide user training where needed. The 5 Whys tool was used to analyze reasons for rework across build cycles.
Brainstorming by the development team, a business analyst and the internal customers led to the following discoveries:
◉ Requirements were modified after the work item was resolved.
◉ Defects in related web pages and modules were reported at different times.
◉ Resolution of work items was not always achieved per the customer’s expectations.
Each of these instances required rework.
Improve
The software development team documented a process to improve software development efficiency and to reduce rework. The new strategy included the following steps.
◉ Gather clear customer requirements: Ambiguous requirements were identified as the primary cause of rework. It was determined that software development work would begin only after the customer requirements were clearly documented and communicated. This involved much discussion between the customers and development managers before tasks were assigned to the software developers. The requirements-gathering templates were revised and modularized to make sure that all essential information was included. Screenshots were included wherever possible to ensure that requirements were clearly communicated.
◉ Reduce knowledge switching: The customers, development team manager and the business analyst started investing significant resources in prioritizing and grouping of work items. Similar work items within a software application were aggregated and assigned to the same developer. This allowed the developer to minimize wasted knowledge recovery time between tasks, and greatly reduced software development and testing time.
◉ Reduce rework: Throughout the lifecycle of a work item, the customers and the development team started jointly reviewing the in-development product using prototypes and screen shots. This iterative methodology allowed the customers to request any additional changes early in the development process and reduce expensive rework. Rigorous unit testing and peer code reviews within the development team further increased code reliability. Knowledge sharing between developers (through technical presentations and building domain knowledge within areas of the application) was encouraged.
Table 2: Work Item Fragmentation – After
| Work Item | Build Cycle | Developer |
| Admin tool 1 | 4 | Developer 1 |
| Admin tool 2 | 4 | Developer 1 |
| Finance-related tool 1 | 4 | Developer 2 |
| Finance-related tool 2 | 4 | Developer 2 |
Related work items were combined and assigned to one software developer in one build cycle. As shown in Table 2, Developer 1 works on the admin tools, while Developer 2 works on the finance-related tools; this continuity in work improved work item resolution time.
Outcome
The developers now get customer requirement clarification at the start of a work item, write the necessary code and test a work item in a single software development cycle. Since knowledge and context switching are now minimal, development and testing time decreased and resolution time of work items improved as shown in Table 3.
Table 3: Project Savings
| Category | Before (Weeks) | After (Weeks) | Overall Savings (Weeks) |
| Admin tools | 8 | 6 | 2 |
| Finance-related tools | 16 | 4 | 12 |
Control
The list of work items that was used to assign tasks per month was revised to combine related tasks. Resolution time for work items was monitored. It was found that by gathering detailed requirements, carefully prioritizing work items and assigning similar tasks to the same developer, more development and testing could be accomplished in a single build cycle. The defects submitted to the defect-tracking application were monitored and the number of requests for rework decreased significantly.
Posts
0 comments:
Post a Comment