2012 19th Asia-Pacific Software Engineering Conference
Process Model of Software Method Transition Natalja Nikitina and Mira Kajko-Mattsson School of Information and Communication Technology KTH Royal Institute of Technology Stockholm, Sweden
[email protected],
[email protected] on managing software development projects by means of strictly defined roles such as Scrum Master, meetings such as daily standups, demos or retrospectives, and finally, by process artifacts, such as a release backlog. [10] Kanban is a new method that is gaining an increasing popularity. It is based on Just-In-Time and Lean production system. In contrast to Scrum, it is less prescriptive. It does not include development iterations or process artifacts, and it does not define roles or meetings [9]. Kanban’s core constituents are (1) visualization of the work-flow, (2) limitation of work in progress, and (3) measurement of lead time [9]. Similarities between Scrum and Kanban allow combining the two methods. Such a combination is being referred to as Scrumban [11].
Abstract—Transitioning from one software development method to another has become a common routine for many companies. Despite this, very few reports give clear and detailed guidelines on how to conduct a process transition. This paper reports on two real-life process transitions and suggests a general process model of Software Method Transition (SoMeT). The SoMeT model aims to guide a transition from one software method to another. Keywords-process improvement; method adoption; SPI
I.
INTRODUCTION
Transitioning to new software development methods has become a common routine for many software companies today [1], [2]. It is, however, a risky adventure that may not always bring the desired and long-lasting results [2], [3]. This may be for reasons such as, for instance, strong belief in the goodness of the new software methods and unawareness of the scale, complexity and impact of transitioning from one method to another [1], [3]. Many times, transition is done without using any clearly defined transition process model or suitable transition strategy. This is mainly due to lack of common guidelines on how to perform process transition [4]. So far, the majority of the reports dealing with process transition primarily focus on the results of the transition and on the positive characteristics of the newly adopted software methods [5], [6]. Very few reports have defined process transition models. To the knowledge of the authors of this paper, only one report outlines a general model of a transition from traditional to agile methods [4] and only two reports give a detailed account on how two real-life process transitions have been carried out as part of a software process improvement (SPI) effort [7], [8]. In this paper, we suggest a process model of Software Method Transition (SoMeT) to be used for transitioning from one method to another. The SoMeT model lists process transition activities inherent in the transition process. It has been elicited by studying two real-life process transitions that have been conducted in one medium-sized software company. Both transitions concerned a change from Scrum to Scrumban and both were conducted as part of an SPI effort in the company’s two offices in Sweden and Vietnam [7], [8]. II.
III.
The organization studied is a medium-sized Swedish software development company. Since the company wishes to stay incognito, we do not disclose its name. The company has a geographically distributed software development, consisting of 20 developers located in Stockholm, Sweden, and 20 developers and 20 testers located in Hanoi, Vietnam. Initially, the company used poorly implemented Scrum which had led to dissatisfaction with the process in the Swedish development office. In response to this, the company management initiated SPI, resulting in a transition from Scrum to Scrumban, to be referred to as the Swedish transition. The Swedish transition was conducted in a Big-Bang manner by implementing the core process changes within only two weeks. The success of the Swedish transition encouraged the company management to transition to Scrumban in Vietnam as well. The Vietnamese transition, however, differed somewhat. Its design and strategy were adapted to the prevailing circumstances in the Vietnamese development office. The Vietnamese teams were neither willing nor ready to transition to another method. Hence, the company could not implement transition in the Big-Bang manner. Instead, they chose to implement it in a more cautious iterative manner. IV.
RESEARCH METHOD
The research presented in this paper is of a comparative character. Our specimens are two transition process models mirroring the processes that had led to two successful transitions from Scrum to Scrumban. These process models include a body of knowledge encompassing process phases, activities, lessons learned and roles involved. They have similar overall design; however, they differ due to different conditions in which they were performed. To reveal their variant and invariant parts, we followed a comparative research method. Our research method consisted of four main steps: Preliminary Design, Comparison, Analysis, and Consolidation.
SCRUM, KANBAN AND SCRUMBAN
Scrum and Kanban are light-weight agile methods, which involve collaborative teamwork and informative workspaces, and recognize the importance of teams’ self-organization [9]. Scrum is a well known iterative and incremental method resulting in a piece of working software to be delivered at the end of each development iteration, called sprint. It is focused
1530-1362/12 $26.00 © 2012 IEEE DOI 10.1109/APSEC.2012.87
THE ORGANIZATION STUDIED AND ITS CONTEXT
276
model, we gained an improved understanding of the Swedish and Vietnamese transitions. Hence, we took the liberty to do minor restructurings of a few phases and rewordings of the role titles in the transition models presented herein. As illustrated in Figures 1 and 2, both transition models consist of Pretransition, Process transition and Post-transition stages.
During the Preliminary Design, we studied the two process transitions by using action research. Here, we actively observed the two process transitions, and put their overall designs into two transition process models, the models that slavishly mirrored the Swedish and Vietnamese transitions. The results of this step have already been reported in [7], [8]. During the Comparison step, we compared the two transition models using the descriptive comparison method [12]. Here, we used the following comparison criteria (1) Purpose focusing on the general overview and purpose of the transitions, (2) Culture comparing the cultural contexts of the two offices, (3) Roles focusing on the roles driving the transitions, (4) Attitude presenting the engineers’ attitude towards the transitions, (5) Strategy and design concentrating on the strategy of the transitions, and (6) Lessons learned listing the experiences gained during the transitions. In the Analysis step, we looked for properties such as similarities, dissimilarities, inconsistencies, duplications and redundancies which we then analyzed and attended to. We did it by following the comparison method [12]. We first analyzed the process activities in their specific contexts, explained them from the perspective of their domestic processes, and, based on that, we then determined what process activities and in what order should be included within the process model. Last, in the Consolidation step, we compiled the collected and analyzed data and created the SoMeT process model for transitioning from one development method to another. V.
A. Swedish Transition The Swedish transition commenced as an ordinary SPI activity that had been brought about due to engineers’ dissatisfaction with the process (see SPI initiation phase in Figure 1). To get an initial understanding of the poor process conditions, it was decided that the current development process would be pre-assessed (see Pre-Assessment phase). To assure that everybody was on the same wavelength with respect to process knowledge, the engineers got trained in both current and candidate development processes (see Training phase). The pre-assessment of the process made the company realize that the process suffered from serious problems such as low engineers’ motivation, insufficient development process flow, and increase of technical dept. Hence, the company started a thorough process examination (see the Assessment phase) during which the company listed, analyzed and prioritized the process-related problems, identified their causes, defined their solutions, measured the process and assessed the engineers’ satisfaction with the process. Having a clear picture of the process and its malfunctions, the company suggested to transition to Scrumban (see the Solution proposal phase). This implied that the company adopted some of the Kanban principles such as continuous non-iterative workflow, and kept some of the Scrum practices such as retrospectives and daily standup meetings. When the transition to Scrumban was proposed, the engineers got highly engaged in it. Therefore, the company
PROCESS TRANSITIONS
This section presents the Swedish and Vietnamese transition models. Due to space restrictions, we briefly describe them. Their detailed descriptions are in [7], [8]. The descriptions provided in this paper differ somewhat from the descriptions in [7], [8]. This is because while creating the general transition SPI initiation: A-1.1 Initiate process improvement A.1.1.1 Identify needs for SPI A.1.1.2 Get management support for the SPI Pre-assessment: A-1.2 Study current process A-1.2.1 Identify the strengths of the process A-1.2.2 Identify the weaknesses of the process A-1.2.3 Identify gaps and overlaps in responsibilities Training: A-1.3 Train the stakeholders in candidate process model for transition A-1.3.1 Train the stakeholders in current process model A-1.3.2 Train the stakeholders in candidate process model for transition Assessment: A-1.4 Assess current process A-1.4.1 List, analyze and prioritize process related problems A-1.4.2 Identify problem causes A-1.4.3 Define solutions for the identified problems
Pre-transition Stage A-1.4.4 Measure the process A-1.4.5 Assess stakeholders’ satisfaction with the process A-1.4.5.1 Determine the factors that impact the stakeholders’ satisfaction A-1.4.5.2 Establish stakeholders’ satisfaction levels A-1.4.5.3 Measure stakeholders’ satisfaction Solution proposal: A-1.5 Propose and analyze candidate process models for transition A-1.6 Choose a candidate method for process transition Transition decision: A-1.7 Decide on the transition A-1.7.1 Identify the common parts and gaps between the current and candidate process models A-1.7.2 Determine (preliminary) process transition changes A-1.7.3 Present the candidate process model A-1.7.4 Decide on the transition A-1.7.5 Assign a role of the Transition Manager
Transition planning and preparation: A-1.8 Motivate the stakeholders involved in transition A-1.8.1 Announce the process transition A-1.8.2 Announce preliminary transition changes A-1.8.3 Assure common understanding of the impact of transition A-1.9 Establish a transition team A-1.9.1 Identify the “supporters” of the process transition A-1.9.2 Include the supporters in the transion team A-1.10 Plan transition A-1.10.1 Set goals for process transition A-1.10.2 Determine process transition changes A-1.10.3 Identify impact of process transition A-1.10.4 Define a process for Process transition stage A-1.10.5 Define a process for Post-transition stage A-1.10.6 Create a transition plan and schedule A-1.10.7 Determine the transition budget A-1.10.8 Announce process transition plan and schedule A-1.11 Prepare for transition
Process Transition Stage Big-Bang transition: A-2.1 Implement the determined process change(s)
Post-Transition Stage Repeat those steps for each iteration: Process assessment: A-3.1 Review the changed process A-3.2 Identify and prioritize/reprioritize the process related problems
A-3.3
Review the structure of the process review and revise, if needed A-3.4 Assess stakeholders’ satisfaction with the process A-3.5 Measure the process Process change planning: A-3.6 Determine the next process change(s)
A-3.6.1 A-3.6.2 A-3.6.3 A-3.6.4
Propose solutions for the top priority problems Identify the next set of process change(s) Assign people to the role of the Change Manager Plan for how to implement the determined process change(s) Process change: A-3.7 Implement the determined process change(s)
Figure 1. Detailed design of the Swedish transition
277
B. Vietnamese Transition The Vietnamese transition was initiated by setting transition goals, getting management support, assigning the role of a Transition manager and announcing transition within the organization (see Transition initiation phase in Figure 2). To gain an initial understanding of the situation, the company studied their current process and assessed the staff’s knowledge of and satisfaction with the process (see PreAssessment phase). Here, they found out that their staff possessed poor process knowledge and that they lacked interest in process transition. This made the company to start a comprehensive training in both the development methods and in process transition (see Training phase). After training, the company made a thorough assessment of the process (see Assessment phase). They analyzed the current process, identified process problems and their causes and defined solutions. Here, they also found out that the training resulted in an improved understanding of the process, but it did not generate interest in process transition. Despite the findings, the company decided to continue with process transition. It was decided however that the transition would be conducted in a slow and iterative manner. After it, the company established Transition team and started planning and preparing for the transition (see Transition planning and preparation phase). The actual transition lasted for five months and it consisted of consecutive rounds of process assessment, change planning and process changes (see Process Transition stage). Each round started with the planning of the process changes (see the Process change planning phase). To assure successful transition, the implementation of the changes was always conducted by Change managers, who were
management took the opportunity of using the momentum of high engineers’ engagement, and instantly accepted the transition (see the Transition decision phase). As a start, the company designated the role of a Transition manager and decided to map out action plan (see the Transition planning and preparation phase). It was agreed that the overall transition would consist of two stages (1) a Big-Bang transition implying a very short and immediate transition from Scrum to Scrumban and (2) iterative process tuning for stabilizing the new process. Besides creating the action plan, the Transition manager (1) started a campaign aiming at motivating engineers towards transition, (2) established Transition team, and (3) defined strategy for the transition. The Big-Bang transition took two weeks (see Process Transition stage). Here, the company implemented all the planned major process changes such as cancelling Scrum sprints, outlining clear development stages, and other changes. After transitioning to Scrumban, the company started iterative process tuning consisting of consecutive rounds of process assessment, change planning and process changes (see the Post-Transition stage). Here, the company continuously assessed the process and engineers’ satisfaction with it, as well as measured the process quality attributes during bi-weekly retrospectives (see the Process assessment phase). The results of process assessments (see the Process change planning phase) provided input for determining next round of process changes to be implemented by Change managers, engineers who volunteered to perform the change task (see the Process change phase). The process changes made during this stage concerned changing the organizational structure, and setting product and project vision, to mention a few.
Pre-transition Stage Transition initiation: A-1.1 Initiate process transition A-1.1.1 Identify needs for process transition A-1.1.2 Set (preliminary) goals for process transition A-1.2 Get management support for process transition A-1.3 Assign a role of the Transition Manager A-1.4 Announce the process transition Pre-assessment: A-1.5 (Initially) assess current process A-1.5.1 Study current process A-1.5.1.1 Identify the strengths of the process A-1.5.1.2 Identify the weaknesses of the process A-1.5.1.3 Identify gaps and overlaps in responsibilities A-1.5.2 Assess stakeholders’ satisfaction with the process A-1.5.3 Assess stakeholders’ knowledge of current process A-1.5.4 Assess stakeholders’ knowledge in candidate process model for transition
Training: A-1.6 Train the stakeholders in process transition A-1.6.1 Present experiences from previous process transition A-1.6.2 Present the need and potential benefits of the process transition A-1.7 Train stakeholders in process A.1.7.1 Determine educational needs A-1.7.2 Design educational program according to the educational needs A-1.7.3 Train the stakeholders in candidate process model for transition Assessment: A-1.8 Assess current process A-1.8.1 Analyze current process A-1.8.2 List, analyze and prioritize process related problems A-1.8.3 Identify problem causes A-1.8.4 Define solutions for the identified problems
Repeat those steps for each iteration: Process change planning: A-2.1 Determine the next process change(s) A-2.2 Update transition plan and schedule
Process change: A-2.3 Implement the determined process change(s) Training: A-2.4 Train and coach the stakeholders in the process change(s)
Repeat those steps for each iteration: Process change planning: A-3.1 Determine the next process change(s) A-3.1.1 Propose solutions for the top priority problems A-3.1.2 Identify the next set of process change(s) A-3.1.3 Assign people to the role of the Change Manager
A-3.1.4 Plan for how to implement the determined process change(s) Process change: A-3.2 Implement the determined process change(s) Training: A-3.3 Train and coach the stakeholders in the process change(s)
Process Transition Stage
Post-transition Stage
A-1.8.5 Measure the process A-1.8.6 Evaluate readiness towards process transition Transition planning and preparation: A-1.9 Establish a transition team A-1.9.1 Identify the “supporters” of the process transition A-1.9.2 Include the ”supporters” in the transition team A-1.10 Plan transition A-1.10.1 Set goals for process transition A-1.10.2 Identify the common parts and gaps between the current and candidate process models A-1.10.3 Determine process transition changes A-1.10.4 Identify impact of process transition A-1.10.5 Determine the strategy for the process transition A-1.10.6 Define a process for Process transition stage A-1.10.7 Define a process for Post-transition stage A-1.10.8 Create a transition plan and schedule A-1.10.9 Determine the transition budget A-1.10.10Announce process transition plan and schedule A-1.11 Prepare for transition Process assessment: A-2.5 Review the changed process A-2.6 Identify and prioritize/reprioritize the process related problems A-2.7 Update the list of the prioritized problems Process assessment: A-3.4 Review the changed process A-3.5 Identify and prioritize/reprioritize process related problems A-3.6 Review the structure of the process review and revise, if needed A-3.7 Assess stakeholders’ satisfaction with the process A-3.8 Measure the process
Figure 2. Detailed design of the Vietnamese transition
278
alternative ways of working. In contrast, the Swedish engineers were highly initiative and enthusiastic to propose new ideas and solutions.
Transition Manager and Transition team members. All implementation was assisted with intensive training (see Process change and Training phases). This means that the staff was trained and coached while making changes. The process changes implemented during this stage mainly concerned cancelling Sprints, establishing new process infrastructure, and changing the structure of the meetings. After transitioning to the desired method, the company started iterative process tuning, (see the Post-Transition stage). Here, they followed a similar process change structure as during the Process transition stage. This time, however, its goal was to tune and stabilize the newly introduced process as well as to establish mechanisms for its continuous improvement. At this stage, the changes concerned introduction of coding guidelines, adjustment of work in progress limit and other tuning activities. VI.
C. Roles We have distinguished three primary roles within process transition. These were: Transition manager, Transition team and Change managers. We strongly believe that these roles are pivotal for succeeding with the transition. Both process transitions were led by the Transition manager whose main responsibility was to lead the whole transition by planning preparing and implementing it. The Transition manager was supported by the Transition team whose role was to assist in the planning, preparation and implementation of the process transition. Finally, the Change managers were responsible for implementing the changes to the process. D. Attitude The attitude of the Swedish and Vietnamese staff towards process related problems and transition was different. We believe that it strongly impacted the design of the process transition. The Swedish engineers were active actors in the transition process. It is they who identified the process problems and, were eager to change the process. They got so actively engaged in the process transition, so that they even took initiative for starting and driving it. The Vietnamese engineers, on the other hand, were more passive actors in the transition process. They did not have much interest in the process and they could not easily identify process problems. They were simply satisfied with the process as it was. Assigning individuals to the role of Change manager strongly depended on the attitude towards transition and process literacy. Therefore, during the Swedish transition, the roles of Change managers were often assigned to the engineers who had volunteered to do process changes, while in the Vietnamese transition, the roles of Change managers were mostly assigned to the Transition manager or members of the Transition team.
ANALYSIS
This section compares the Swedish and Vietnamese transitions using the defined comparison criteria. A. Purpose Although the purpose of the two transitions was to improve development processes, the reasons behind the transitions substantially differed. While the main reason of the Swedish transition was to motivate and satisfy the engineers, the reason behind the Vietnamese transition was to reach a uniform way of working in both offices. We believe that the reasons behind the two transitions have been important determinants of the designs of the transition processes. B. Culture Despite belonging to the same organization, the two offices were impacted by their local cultural contexts and milieus. They differed in: x Organizational Structure: The Vietnamese office followed strongly hierarchical structure, whereas the Swedish office had a relatively flat structure with no significant differences in social behavior with respect to age, status or position [13]. x Communication: Because communication in Vietnamese culture is based on paying high respect to one another, the Vietnamese engineers had difficulties to share or criticize one another’s work, process or ideas. The Swedish staff, on the other hand, had an open and direct style of communication [13]. x Working Relationship: The Vietnamese engineers had a tendency to build social relationships outside the workplace whereas the Swedish engineers followed a modest and reserved behavior at their working place, keeping it separated from their personal life. We believe that the cultural differences strongly impacted the level of the engineers’ openness and tolerance towards process problems. While the Swedish engineers were highly intolerant to the existing problems, their Vietnamese colleagues hardly perceived them as problems. While the Swedish staff was highly vocal in expressing their opinions, the Vietnamese staff hardly raised any protests against the current process. Additionally, the culture affected the level of initiative. The Vietnamese engineers were respectful to the existing management decisions and rather shy to discuss or suggest
E. Strategy and Design Both transition models differed in their overall process design. The difference lied in the design of the Process transition stage. In the Swedish transition, the main transition phase was a very short one-off activity performed within only two weeks. One of the main reasons was the opportunity to use the momentum of high engineers’ engagement. In the Vietnamese transition, on the other hand, the main transition phase was protracted till five months, during which process changes and training on those changes were carefully introduced and implemented in an iterative manner. One of the main reasons here was the fact that the Vietnamese engineers were not ready for process transition; they were rather reluctant to perform it, and they needed a significant amount of training and coaching. For this reason, we strongly believe that staff’s knowledge of and attitude towards transition are important determinants of the design a transition process. F. Lessons Learned During the two process transitions, the company had learned many lessons worth highlighting. These are:
279
x Training and education of all the stakeholders in the new development method may boost their engagement and motivation in transition and decrease inertia to change. To achieve a better understanding of the principles behind the changed process, coaching and mentoring in the process should complement the training sessions. x Organization’s readiness to the process transition should be assessed prior to process transition, and it should be considered in the transition strategy and design. x Regular continuous process reviews, such as retrospectives, should be continuously performed and revised to ensure the sustainability of the positive results that had been achieved by the transition. x Involvement and engagement of the staff contributed to the success of process changes. All the stakeholders, including managers, developers and testers, should participate in process reviews and propose improvement changes. x To ensure the ownership of process transition and continuous SPI, the roles of Transition manager, Transition team and Change managers should be defined and assigned.
activities were not pure transition activities, but rather supporting activities belonging to training and SPI processes. Bearing the process differences in mind, we realized that we could not define a process transition model that had a rigid structure and imposed order of its activities. The model should allow free choice and order of activities within a process wherever it is relevant and necessary. To achieve this, we structure the SoMeT model into two building blocks: taxonomies and a process frame, see Part D in Figure 3. The taxonomies consist of process transition activities, grouped by their common purpose, according to the degree of their relationships. The process frame, on the other hand, consists of process phase containers standing for the reserved spaces to be filled in with the relevant taxonomy activities. The SoMeT model is shown in Figure 3. As shown in Part D of Figure 3, the SoMeT model encompasses three taxonomies of activities: (1) Transition activities including the core activities that are required for performing a transition process, (2) Training activities including a set of training activities needed for assuring that people understand the process transition, and, (3) SPI activities adding the transition process with continuous SPI activities. The taxonomies of the activities are presented in Figure 3. As indicated by the dashed pentagons in Part D of Figure 3, the SoMeT model’s process frame only includes three main process phase containers: Pre-transition during which one initiates the transition, Process transition during which one conducts the actual transition, and Post-transition during which one tunes and improves the process. These containers can be filled in with any activity listed in the taxonomies. This is the only process structure that is imposed by the SoMeT model. The taxonomy activities are structured into hierarchies of activities, where the primary generic activities define the major process steps, and their lower-level sub-activities enable the realization of the primary steps.
VII. PROCESS MODEL OF SOFTWARE METHOD TRANSITION The SoMeT process model suggested in this study is based on only two models of executed process transitions. The two transitions were designed for the same purpose, and they were performed within the same company. They had a similar overall structure and they consisted of similar activities. More than 70 % of the activities were the same in both transitions. Despite the strong similarities in the overall process structure and the use of the same activities, it was not trivial to merge them into a generic process transition model. This is due to the following: 1) some of the activities were performed in one transition but not in the other; 2) some of the activities were performed in different process phases, 3) some of the A A-1 A-1.1 A-1.2 A-1.3 A-1.4 A-1.5 A-2 A-2.1 A-2.2 A-2.2.1 A-2.2.2 A-2.2.3 A-2.3 B TA-1 TA-1.1 TA-1.2 TA-1.3 TA-1.4 TA-1.5 TA-1.6 TA-2
Transition Activities Initiate process transition Identify needs for process transition Set goals for process transition Get management support for process transition Define a role responsible for process transition Announce the process transition Assess current process Evaluate readiness towards process transition Study current process Identify the strengths of the process Identify the weaknesses of the process Identify gaps and overlaps in responsibilities List, analyze and prioritize process related problems
Training Activities Train stakeholders in process Assess stakeholders’ knowledge of current process Assess stakeholders’ knowledge in candidate process model for transition Determine educational needs Design educational program according to the educational needs Train the stakeholders in candidate process model for transition Train and coach the stakeholders in the process change(s) Train stakeholders in process transition
A-2.4 A-2.5 A-2.6 A-2.7 A-3 A-3.1 A-3.2 A-3.3 A-3.4 A-3.5 A-3.6 C
Identify problem causes Define solutions for the identified problems Measure the process Assess stakeholders’ satisfaction with the process Plan transition Establish a transition team Propose and analyze candidate process models for process transition Choose a process model for process transition Identify the common parts and gaps between the current and candidate process models Determine process transition changes Identify impact of process transition
A-3.7 A-3.8 A-3.9 A-3.10 A-3.11 A-3.12 A-3.13 A-4 A-4.1 A-4.2 A.4.3 A-5
SPI Activities
SA-1 SA-1.1 SA-1.2 SA-1.3 SA-1.4 SA-1.5 SA-2 SA-2.1 SA-2.2 SA-2.3 SA-2.4 SA-3
Assess the process Review the changed process Identify and prioritize/reprioritize the process related problems Review the structure of the process review and revise, if needed Assess stakeholders’ satisfaction with the process Measure the process Plan process changes Propose solutions for the top priority problems Identify the next set of process change(s) Assign roles responsible for the next process change(s) Plan implementation of the determined process change(s) Implement the determined process change(s)
Figure 3. Process model of software method transition
280
Decide on the transition Determine the strategy for the process transition Define a model for Process transition stage Define a model for Post-transition stage Create a transition plan Determine the transition budget Update transition plan and schedule Prepare for transition Announce process transition plan and schedule Motivate the stakeholders involved in transition Prepare for the process transition Implement the determined process change(s)
D
Taxonomies Transition Activities
Pre-Transition
Training Activities
SPI Activities
Transition
PostTransition
Process Frame
The structure and order of the taxonomy activities in Figure 3 have only presentational purpose. The activities are grouped by their most intuitive and natural placement within the primary generic activities. When matching them against the executed Vietnamese and Swedish transition processes, we have found out that the majority of the taxonomy activities had their natural placement in one of the process phase containers. For instance, activity “initiate process transition” has a natural placement within the Pre-transition phase container. We have also observed that some activities do not have any natural placement. They can be continuously repeated or they may be performed in different process phases. The main taxonomy, called Transition activities, is presented in Part A of Figure 3. It includes the following highlevel core activities: x Transition initiation activities (Activities A-1 - 1.5 in Part A in Figure 3) aiming at initiating process transition, defining its resources and assigning roles responsible for it. These activities should be performed at the beginning of the process transition. Therefore, their natural placement is in the Pretransition process phase container. x Process assessment activities (Activities A-2 - 2.7 in Figure 3) aiming at analyzing the process, defining solutions for its problems, evaluating readiness towards process transition, and identifying stakeholders’ satisfaction. Their natural placement is in the Pre-transition process phase container. x Transition planning activities (Activities A-3 - 3.13 in Figure 3) focusing on determining a strategy for process transition and creating a transition plan. Their natural placement is the Pre-transition process phase container. However, the Activity A-3.13 (Update transition plan and schedule) can be placed in the Transition process phase container as well. x Transition preparation activities (Activities A-4 – 4.3 in Figure 3) emphasizing preparation for the process transition. Their natural placement is the Pre-transition process phase container. The activity A-4.2 (Motivate the stakeholders involved in transition), however, can also be placed in the Transition process phase container. x Process change implementation activity (Activity A-5 in Figure 3) has a natural placement in the Transition process phase container. The supporting taxonomy, Training activities, presented in Part B of Figure 3, consists of the activities required for educating and training the stakeholders with the purpose of improving their understanding and knowledge of the development process and process transition. This taxonomy is not complete, since it concerns only training that primarily concerns process transition. Due to their high context dependency, the training activities have no natural placement. They may be conducted anywhere in the transition process. The supporting taxonomy, SPI activities, presented in Part C of Figure 3, consists of the activities aiming at tuning and improving the process. Just as the training process, the SPI is a comprehensive process, which consists of a large number of activities. Our SPI taxonomy, however, only consists of the activities that concern the process transition. Their natural placement is in the Post-transition process phase container. In case of the iterative process transition, however, some of the SPI activities can also be placed in the Transition process phase container.
VIII. FINAL REMARKS In this paper, we have presented the process model of Software Method Transition (SoMeT) to be used for transitioning from one software method to another. The SoMeT model was the result of two action research studies as conducted in two distributed offices of the company. The SoMeT model consists of taxonomies of process transition activities and a process frame including containers to be filled in with the taxonomy activities relevant for the process context at hand. It enables dynamic binding of process transition activities to the process frame’s containers and provides an opportunity to tailor the process on the fly. Therefore, it allows for flexibility when designing the executed process transition models. Even though the SoMeT model was based only on two transitions, we believe that it can already be used by the organizations that plan to conduct process transition. Using it as a template, the SoMeT model can help the organizations to properly plan and prepare for process transition, to choose appropriate transition strategy and to establish appropriate mechanisms for continuous SPI. Due to the fact that the SoMeT model is based on only two process transitions, it needs to be further evolved and evaluated in different organizational contexts. Irrespective of what the future will show, we intend to further extend and evaluate the SoMeT model within other organizations, either via action research or via historical studies of the already executed process transitions. REFERENCES [1] [2]
[3]
[4]
[5] [6]
[7]
[8]
[9] [10] [11] [12] [13]
281
C. Schwaber, G. Leganza, and D. D’Silva, “The Truth about agile Processes,” Forrester Research, 2007. M. Laanti, O. Salo, and P. Abrahamsson, “Agile methods rapidly replacing traditional methods at Nokia: A survey of opinions on agile transformation,” J. Infor. and Soft. Techn., 53 (3), 2011, pp.276-290. H. Svensson, and M. Höst, “Introducing an Agile Process in a Software Maintenance and Evolution Organization,” Proc. CSMR’05, IEEE Press, 2005, pp. 256-264. M. Pikkarained, O.Salo, and J. Still, “Deploying Agile Practices in Organizations: A Case Study,“ Proc. EuroSPI 2005, ed: Springer London, 2005. R. Jochems, and S. Rodgers, “The rollercoaster of required agile transition,” Proc. Agile 2007, IEEE Press, 2007, pp. 229-233. T. Dybå, and T. Dingsoyr, “Empirical studies of agile software development: A systematic review,” J. Inform. and Soft. Tech., 50 (910), 2008, pp.833-859. N. Nikitina, and M. Kajko-Mattsson, “Developer-driven big-bang process transition from Scrum to Kanban,” Proc. ICSSP’11, ACM, 2011, pp. 159-168. N. Nikitina, M. Kajko-Mattsson, and M. Strale, “From Scrum to Scrumban: A Case Study of a Process Transition,” Proc. ICSSP’12, IEEE Press, 2012, pp.140-149. H. Kniberg, and M. Skarin, Kanban and Scrum: making the most of both. C4Media Inc, 2010. K. Schwaber, and M. Beedle, Agile Software Development with Scrum, 1 ed., Prentice Hall, 2001. C. Ladas, Scrumban - Essays on Kanban Systems for Lean Software Development, Modus Cooperandi Press, 2009. R. Sapsford, and V. Jupp, Data Collection and Analysis, 2nd ed., Sage Publications, 2006. G. Hofstede, Culture’s Consequences: Comparing Values, Behaviors, Institutions and Organizations Across Nations. Sage, 2001.
