Comparative study of the results of applying Scrum- and Kanban approaches based on case studies and modeling
2014 promises to be full of interesting training and master classes from the Luxoft Training Training Center. In the first quarter of the new year, Professor of Software Engineering at the University of Cagliari, Italy, will visit Russia with a master class by Michele Marquese.
Michele Marquese was one of the first to engage in research in the field of object-oriented software development using flexible methodologies, in particular, extreme programming. Today, he is working on the development of lean and flexible software development methodologies (in particular, on the Lean-Kanban approach) together with David Anderson, the “father” of the Kanban methodology in software engineering.
We invite you to get acquainted with one of the articles, where Markese is a co-author on the results of applying Scrum- and Kanban approaches based on case study and modeling.
')
Authors: David Anderson, Giulio Concas, Maria Ilaria Lunesu, Michele Marchesi and Hongyu Zhang
The article analyzes the transition from a traditional approach based on an individual SEI development process to an approach of lean software development known as Limited WIP. The data obtained during the analysis of this case study are used to assess the suitability of the development process simulator developed by us, as well as input data for modeling the Scrum process in order to test the possibility of using the Scrum approach.
The case study examines Microsoft’s maintenance team (CMM Level 5), which is based in India and is responsible for minor upgrades and troubleshooting in 80 IT applications used by Microsoft staff around the world. This was the first time that the Limited WIP approach was applied using the Kanban virtual system. The success of the new process in terms of reduced delivery times and a higher level of customer satisfaction was one of the main factors that aroused interest in such a Kanban approach in software engineering.
The maintenance team consisted of two parts: the development team and the testing team, three people each. The teams worked 12 months a year, an average of 22 days a month. Service requests came randomly, an average of 20-25 requests per month. Each request went through an evaluation stage, a “go-it-worthless” solution, a logging stage, a development and testing stage. Despite the qualifications of the teams, this process did not always go smoothly. The number of completed requests was 5-7 per month, and the growth of debts occurred with an intensity of 6 requests per month. When the team introduced the Kanban virtual system in October 2004, there were 80 requests in the backlog, and their number continued to grow. The average time to complete requests from the time they were received ranged from 125 to 155 days, which was not at all suited for interested parties.
To solve the problems associated with the performance of the team, a typical lean development approach was used. Initially, the process policy was clearly outlined by mapping the value stream in order to find out at which stages the loss of value occurred. It was found that the main losses occurred at the assessment stage, which occupied about 33 percent of the total time. In addition, the constant interruptions needed to make higher-priority evaluations hampered problem solving because they took time away from developers and testers.
Based on this analysis, a new process was developed that can eliminate these losses. The first step was to reduce the work at the same time in progress, and add new tasks from the queue at the entrance only after the current task. The number of requests being developed was limited to 8, as well as the number of tasks being tested. This number includes a queue at the entrance to the development and testing and requests that are in the works. Then the inquiry evaluation procedure was completely abolished. Instead, business owners were given the opportunity to meet once a week and select requests to be included in the queue of requests for entry into development. They were also given "guarantees" of the delivery of the solution within 25 days, starting from putting them on the development queue.
In short, the new process was as follows:
• All incoming requests were placed in the request log without prior evaluation.
• Every week, business owners decide which request to include in the development queue.
• The number of requests processed was limited, both in development and testing.
• Developers took requests to work from the queue at the entrance and focused on only one request or a very small number of requests. The executed requests were transferred to the status "Executed".
• Testers included requests with the status “Completed” in turn at the entrance (observing limits) and worked with them, focusing on one request or a very small number of requests. Requests that have been tested are immediately transmitted to customers.
This approach has helped to significantly increase the productivity of teams, significantly reducing the time to execute requests from the moment they are accepted for work to 25 days or less in 98% of cases. It should be noted that the obligations to perform work on time were given only after the request was transferred from the request log to a queue at the entrance. The following improvements were the result of observing that most of the work was done by the developers, while testers were only partially loaded, as a result of which labor was used inefficiently. It was decided to move one tester to the development team and increase the number of simultaneous tasks to 9, which increased productivity. The team was able to clear the log of failed requests and reduce the average delivery cycle to 14 days.
To simulate software maintenance processes, we used an approach that can be described as event-driven or agent-based. The action of the system is presented as a chronological sequence of events. Each event occurs at some point in time and marks a change in the state of the system. This approach is agent-based because it models developers as autonomous agents. The basic entities of the proposed model, common to all processes being modeled, are queries, work performed, and team members.
Using the simulator, we managed to simulate the initial process, the Lean-Kanban process and the Scrum process. To simulate the Scrum process, it was necessary to introduce the concept of iteration into the simulator. This was done using the Start of Iteration event, which occurs at the beginning of the day the iteration starts.
Since the Scrum team has the ability to self-organize, and since the main problem in the work flow is coding, the Scrum team had to organize itself to cope with this situation. In the Scrum model, we allowed one tester to play the role of a developer by creating code. Thus, it was possible to eliminate problems associated with writing code, and speed up the workflow.
We modeled all three models presented using data that simulated service requests submitted to the Microsoft command described above. We have generated two sets of requests covering a four-year timeframe each (1056 days, 22 days per month). The distribution of effort required to fulfill requests is normal: an average of 8.5 days with a standard deviation of 2.5 days. For each of the three studied processes, we performed a series of simulations with one input data. After several runs with different initial numbers generated by a random number generator, fairly stable results were obtained for each process and each input data array.
The simulator almost exactly reproduced the initial process, including its inability to keep up with incoming requests, as well as the average response time to a request, which was about 150-160 days - values ​​that are very similar to real data. In the case of the Kanban process, the modeled performance increased significantly, and the average response time decreased compared to the initial situation to an average of 25 days. The simulation results demonstrated significant improvements compared with the initial process, but significantly lower results than those obtained in real practice, where the performance was 50% higher than in the simulated situation. This fact requires further study, since in practice this increase in productivity was due to the increased productivity of engineers in the team. Improving personal productivity is a parameter that is a priori difficult to use in modeling, without risking to be accused of bias and the desire to present the process in a favorable light.
We also modeled using the Scrum process to work with the same input data with iterations of 3 weeks duration. In general, the Scrum process showed good results, comparable to the results of the Kanban process. In practice, Scrum was not implemented, because at that time it was contrary to Microsoft’s software development policy, which was based on the Individual SEI development process.
Source: Summary of article published in Proceedings of XP2012 Conference
The upcoming master class by Michele Marquese “Lean vs Kanban” is devoted to software development methodologies. Detailed information about the master class on the website of the training center.
Michele Marquese was one of the first to engage in research in the field of object-oriented software development using flexible methodologies, in particular, extreme programming. Today, he is working on the development of lean and flexible software development methodologies (in particular, on the Lean-Kanban approach) together with David Anderson, the “father” of the Kanban methodology in software engineering.
We invite you to get acquainted with one of the articles, where Markese is a co-author on the results of applying Scrum- and Kanban approaches based on case study and modeling.
')
Comparative study of the results of applying Scrum- and Kanban approaches based on case studies and modeling
Authors: David Anderson, Giulio Concas, Maria Ilaria Lunesu, Michele Marchesi and Hongyu Zhang
The article analyzes the transition from a traditional approach based on an individual SEI development process to an approach of lean software development known as Limited WIP. The data obtained during the analysis of this case study are used to assess the suitability of the development process simulator developed by us, as well as input data for modeling the Scrum process in order to test the possibility of using the Scrum approach.
The case study examines Microsoft’s maintenance team (CMM Level 5), which is based in India and is responsible for minor upgrades and troubleshooting in 80 IT applications used by Microsoft staff around the world. This was the first time that the Limited WIP approach was applied using the Kanban virtual system. The success of the new process in terms of reduced delivery times and a higher level of customer satisfaction was one of the main factors that aroused interest in such a Kanban approach in software engineering.
The maintenance team consisted of two parts: the development team and the testing team, three people each. The teams worked 12 months a year, an average of 22 days a month. Service requests came randomly, an average of 20-25 requests per month. Each request went through an evaluation stage, a “go-it-worthless” solution, a logging stage, a development and testing stage. Despite the qualifications of the teams, this process did not always go smoothly. The number of completed requests was 5-7 per month, and the growth of debts occurred with an intensity of 6 requests per month. When the team introduced the Kanban virtual system in October 2004, there were 80 requests in the backlog, and their number continued to grow. The average time to complete requests from the time they were received ranged from 125 to 155 days, which was not at all suited for interested parties.
To solve the problems associated with the performance of the team, a typical lean development approach was used. Initially, the process policy was clearly outlined by mapping the value stream in order to find out at which stages the loss of value occurred. It was found that the main losses occurred at the assessment stage, which occupied about 33 percent of the total time. In addition, the constant interruptions needed to make higher-priority evaluations hampered problem solving because they took time away from developers and testers.
Based on this analysis, a new process was developed that can eliminate these losses. The first step was to reduce the work at the same time in progress, and add new tasks from the queue at the entrance only after the current task. The number of requests being developed was limited to 8, as well as the number of tasks being tested. This number includes a queue at the entrance to the development and testing and requests that are in the works. Then the inquiry evaluation procedure was completely abolished. Instead, business owners were given the opportunity to meet once a week and select requests to be included in the queue of requests for entry into development. They were also given "guarantees" of the delivery of the solution within 25 days, starting from putting them on the development queue.
In short, the new process was as follows:
• All incoming requests were placed in the request log without prior evaluation.
• Every week, business owners decide which request to include in the development queue.
• The number of requests processed was limited, both in development and testing.
• Developers took requests to work from the queue at the entrance and focused on only one request or a very small number of requests. The executed requests were transferred to the status "Executed".
• Testers included requests with the status “Completed” in turn at the entrance (observing limits) and worked with them, focusing on one request or a very small number of requests. Requests that have been tested are immediately transmitted to customers.
This approach has helped to significantly increase the productivity of teams, significantly reducing the time to execute requests from the moment they are accepted for work to 25 days or less in 98% of cases. It should be noted that the obligations to perform work on time were given only after the request was transferred from the request log to a queue at the entrance. The following improvements were the result of observing that most of the work was done by the developers, while testers were only partially loaded, as a result of which labor was used inefficiently. It was decided to move one tester to the development team and increase the number of simultaneous tasks to 9, which increased productivity. The team was able to clear the log of failed requests and reduce the average delivery cycle to 14 days.
To simulate software maintenance processes, we used an approach that can be described as event-driven or agent-based. The action of the system is presented as a chronological sequence of events. Each event occurs at some point in time and marks a change in the state of the system. This approach is agent-based because it models developers as autonomous agents. The basic entities of the proposed model, common to all processes being modeled, are queries, work performed, and team members.
Using the simulator, we managed to simulate the initial process, the Lean-Kanban process and the Scrum process. To simulate the Scrum process, it was necessary to introduce the concept of iteration into the simulator. This was done using the Start of Iteration event, which occurs at the beginning of the day the iteration starts.
Since the Scrum team has the ability to self-organize, and since the main problem in the work flow is coding, the Scrum team had to organize itself to cope with this situation. In the Scrum model, we allowed one tester to play the role of a developer by creating code. Thus, it was possible to eliminate problems associated with writing code, and speed up the workflow.
We modeled all three models presented using data that simulated service requests submitted to the Microsoft command described above. We have generated two sets of requests covering a four-year timeframe each (1056 days, 22 days per month). The distribution of effort required to fulfill requests is normal: an average of 8.5 days with a standard deviation of 2.5 days. For each of the three studied processes, we performed a series of simulations with one input data. After several runs with different initial numbers generated by a random number generator, fairly stable results were obtained for each process and each input data array.
The simulator almost exactly reproduced the initial process, including its inability to keep up with incoming requests, as well as the average response time to a request, which was about 150-160 days - values ​​that are very similar to real data. In the case of the Kanban process, the modeled performance increased significantly, and the average response time decreased compared to the initial situation to an average of 25 days. The simulation results demonstrated significant improvements compared with the initial process, but significantly lower results than those obtained in real practice, where the performance was 50% higher than in the simulated situation. This fact requires further study, since in practice this increase in productivity was due to the increased productivity of engineers in the team. Improving personal productivity is a parameter that is a priori difficult to use in modeling, without risking to be accused of bias and the desire to present the process in a favorable light.
We also modeled using the Scrum process to work with the same input data with iterations of 3 weeks duration. In general, the Scrum process showed good results, comparable to the results of the Kanban process. In practice, Scrum was not implemented, because at that time it was contrary to Microsoft’s software development policy, which was based on the Individual SEI development process.
Source: Summary of article published in Proceedings of XP2012 Conference
The upcoming master class by Michele Marquese “Lean vs Kanban” is devoted to software development methodologies. Detailed information about the master class on the website of the training center.
Source: https://habr.com/ru/post/203726/
All Articles