Six Sigma in IT Development

Agile Development – Suitable for Six Sigma?

Agile methods have dominated the field of software development over the last decade, and they have proven successful for managing and executing software development projects.

Agile teams usually focus on fast and short-term improvements, either through daily collaboration or through periodic vehicles such as retrospectives. Sometimes agile teams lack a bird’s eye view/strategic approach to process improvement or problem solving. This is where Six Sigma comes in.

The introduction of Six Sigma to produce software products or to improve existing software development processes was not so popular, mainly because Six Sigma was always understood as a structured methodology to reduce variation in a repetitive production process, as opposed to a human-centric and innovation-oriented process such as software development. If one also takes into account the value of the Agile Manifesto “Individuals and Interactions via Processes and Tools”, one would argue that one will always find variation in a software development process because it depends strongly on the capabilities of individuals and teams, which makes them the main source of variation

During sprint reviews in agile software development, most agile teams would focus on soft observations and short-term improvement actions instead of taking a bird’s eye view – from a bird’s eye view or from a problem solving and improvement perspective. Even informed decision making in this phase is sometimes based only on soft observations rather than solid data and actions. This is where Lean Six Sigma comes in. The DMAIC method is used in agile development to improve an existing process and quickly solve emerging problems.

DMAIC in agile software development

Define Phase

In the definition phase of a typical DMAIC project, the primary goal is to define the problem. Various inputs can be specified here

(1) Voice of Customer (VOC): Represents the input from the customer’s perspective. It refers to criteria that affect customer satisfaction, such as defects, costs, expectations, value delivery, etc.

(2) Voice of the process (VOP): Represents the input from the process that aims at improvement. It refers to the understanding of the process activities, inputs, outputs, roles and responsibilities involved, and limitations.

In the agile development project, the voice of the customer (VOC) was gained from the perspective of the customers waiting for new versions and product releases. The value for these customers was mainly influenced by the delay in the release of new versions (as a result of large stabilization phases). The problem also affected product sales and delayed revenues.

As far as the voice of the process (VOP) was concerned, it essentially represented the approach the team was taking to product development at that time, namely Scrum. It also referred to the problems and issues they faced in relation to the nature of their product and the technologies used.

With the help of the fishbone diagram, they were able to identify factors that have an influence on the final product and that occur as disruptive factors. Based on the described disruptive factors it is possible to define measures to implement a SixSigma initiative.

Measurement phase

In the next step, the disturbance factors, which were worked out from the fish bone diagram in the measuring phase, must be divided into qualitative and quantitative factors

At that time, the factors (quantitative and qualitative) formed the current performance basis. They represented a snapshot of the current questions and problems that needed to be addressed. This was also the basis for improvements, and it was expected that all improvement measures to be taken later would eventually contribute to the improvement of these factors.

Fortunately, most of the contributing factors (X) identified during the definition phase were controllable factors, as they were related to our team and within our control limits

Analysis Phase

In the analysis phase, the factors are further studied using various methods:

• Interviewing various team members to obtain their input on the weight of each of the factors identified
• Examine some artifacts, such as the team-done-definition and script examples, and the coverage of unit tests for new functions compared to old functions from previous versions
• Investigation of measurement baselines for defects that contained data on defects discovered during development sprints.
• Investigation of correlations between the size of user stories and the amount of bugs discovered during development and the amount of bugs that leaked out afterwards

Throughout the analysis phase, it is possible to create a prioritized list of causes for which improvement measures are to be identified after the causes have been investigated and examined. Typically, a Six Sigma team should consider at this point what the “low hanging fruits” or “quick wins” are. By working on this factor, which should lead to a quick win, the team must ultimately lead to an improvement of the main problem, such as reducing the number of accumulated bugs.

Improve Phase

At this stage, a list of root causes identified during the analysis phase and a list of improvement actions to be implemented and piloted in future sprints should be available

These improvement measures were then introduced gradually through several iterations, and with the introduction of these measures the improvements were finally measured.

Finally, one is enabled to measure improvements in various factors (X) that contribute to an improvement of the main problem (Y).

Control Phase

In this phase of exit control it is important to ensure that the improvements achieved are sustainable. This is achieved by implementing the improvement actions in all future releases and by incorporating new practices into the team’s ongoing process.

For example, if it is determined that a “Definition of Done” has not been clearly formulated, a New DoD can be introduced. If there were problems with unit testing, new team members should be trained in this area to prevent bugs and delays.

Conclusion

The SS Method thus proves to be extremely fruitful, even in the field of agile software development. It allows you to point out disturbing factors and to turn the necessary screws to improve the quality of the output.