Can you please produce the Background: Scrum Implementation: Analysis: Results:

Of this case study

Can you please produce the Background: Scrum Implementation: Analysis: Results:

Of this case study

Case Study

Scrum was implemented in the design phase of an ongoing project consisting of three four-story multi-family buildings for the Swiss market with a total floor area of about 2'100 m2 divided into eleven flats and 200 m2 of commercial space. Design, engineering and production are done in Tallinn (Estonia) and the prefabricated timbermodules will be transported from Estonia to Switzerland. The project was planned is accordance to the Swiss Standard SIA 112 [2]. That standard includes six phases to construct a building using the traditional sequential approach shown in Figure 2. Phase 1: Strategic Planning Phase 2: Preliminary studies Phase 3: Project Phase 4: Invitation to bid Phase 5: Implementation Phase 6: Management Figure 2: Building phases according to [2] Phase 1 had already been completed; thus, this case study focused on the implementation of Scrum in Phase 2 and Phase 3. According to [2], Phase 2 starts with the project definition, includes a feasibility study and ends with the Thomas Streule et al. / Procedia Engineering 164 ( 2016 ) 269 - 276 273 selection of the best project to meet the defined requirements. For Phase 3, the first goal is to perform a concept and profitability optimisation, followed by a project and cost optimisation. At the end of Phase 3, everything should be ready for the application of the building permit. Phase 4 to Phase 6 were excluded from this study. Since there was not a reference for the time it would take to apply for a building permit, an optimistic initial target for this was set to four weeks from the start of Phase 2. After two weeks using Scrum, it was realized that the original goal was not feasible so the timeframe to apply for the building permit was extended to 15 weeks. This would ensure that the application would be accepted with the minimum number of imposed building restraints or objections from the building officials. The use of Scrum in the project was followed for a period of eight weeks in 2015, and during that time the authors participated in all Scrum Events. In addition, an interview was conducted with the Development Team and the Scrum Master at the end of the eight weeks to get their feedback about the entire process. 4. Implementation of Scrum As Scrum is empirical, it is based on transparency, inspection and adaptation [10]. The general Scrum framework with the multiple events, artifacts and roles (Figure 1) can be adapted to fit the requirements of a specific project. Although it is recommended to use the framework as a whole - not only parts of it - one may modify Scrum to achieve specific goals. In this case however, almost no initial modification was done as can be seen in Table 1. Table 1: Events, artifacts and roles used (9) *Added after implementation of Scrum (from Sprint number five) The Development Team consisted of a total of seven individuals. The area of expertise covered by the Development Team was Architecture (three representative), Building Physics (one representative), Civil Engineering (one representative), Cost Estimation (one representative) and Interior Design (one representative). Instead of the Product Owner creating the Product Backlog, the architects from the Development Team and the Scrum Master were the ones doing it; although this was not the ideal case, it was necessary due to other commitments by the Product Owner that would delay the creation of the PBIs. Every member of the Development Team, as well as the Scrum Master, were required to attend all Scrum Events. They were also required to participate in the Scrum Review and Planning with the Product Owner. Before Sprint number five, the number of Items that could be done in a Sprint was entirely based on the experience from the Development Team, without any systematic way to do that. After Sprint number five, the use of Planning Poker was implemented to determine the effort for each Item, hence how many to use from the Product Backlog. At first, the Sprint duration was fixed to five working days. This meant that on Monday the Sprint Planning was held, from Tuesday to Thursday work took place and information was exchanged during the Daily Scrum. On Friday, the Sprint Review and Retrospective was conducted. After four weeks, it was found that it was not enough time to address all the Scrum Events and do the required work during the duration of the Sprint. Therefore, the Scrum Team decided to adjust the Sprint duration to two weeks, which allowed for a more realistic timeframe. The Development Team used a Kanban board to keep track on what was important during the Sprint, as well as during the entire project. Since the Product Owner as well as the authors were not in the same location as the Development Team, a virtual and a physical Kanban board were used. The virtual one was done using Trello (Figure 3 (a)), a free online organization tool. A view of the physical Kanban is depicted in Figure 3 (b). (a) (b) Figure 3: Screenshot of virtual Kanban board (a) and physical Kanban board (b). Source: the authors. Product Owner Development Team Scrum Master Sprint Sprint Planning Daily Scrum Sprint Review Sprint Retrospective Product Backlog Sprint Backlog Planning Poker Increment 9 9 99 9 9 9 9 9 9 * 9 Scrum Team Scrum Events Scrum Artifact 274 Thomas Streule et al. / Procedia Engineering 164 ( 2016 ) 269 - 276 5. Results The results from the implementation of Scrum were evaluated by grading the Daily Scrums, interviewing the Scrum Team, and conducting a critical analysis of the Product Backlog Items. All Daily Scrums were recorded and systematically analysed using a template with eight questions developed for this study. All questions were graded with marks in the range of 1.0 (not measurable) to 6.0 (excellent). The questions answered at the end of each Daily Scrum, along with their absolute weight for the final evaluation, are summarized in Table 2. Table 2: Weight of Daily Scrum questions The questions in Table 2 were organized in three parts: Q1, Q2, and Q3 through Q8. The weight was set to reflect 1) the importance of the Items and their associated Tasks, 2) the three core questions of the Daily Scrum (What did I do? What will I do? What are the obstacles?) and 3) general information (How long? Where? When? Who?). Figure 4: Weighted evaluation of Daily Scrums The evaluation of the Daily Scrums is summarized in Figure 4. The performance of the Daily Scrum (dashed line in Figure 5), as represented by the average grade, increased from a 2.5 (very poor) to a 4.3 (satisfactory-good) over the 27 observed Daily Scrums. This was attributed mainly to the improvements related to question Q2, as with time the Development Team got much better in getting a clear understanding of the whole process. They could report on what was done since the last meeting, as well as efficiently planning upcoming work while identifying and articulating the main obstacles in their tasks. The average grades for Q1 deteriorated mostly due to the fact that the Items did not consist of Tasks which could be completed in one or two days of work, making it hard to make improvements in this area. The fluctuation of the dashed line is based on the average grade for Q1 and Q2 (dotted line). The average grade for Q3 to Q8 (solid line) varied strongly from day to day, but it was generally on the upper end of the scale (overall average of 5.2); however, no general improvements were observed. At the end of week eight, an interview was conducted with the Development Team and the Scrum Master (with a total of eight participants) and questions were graded from 1.0 (low) to five (high). The main purpose of the interview was to get feedback from the Scrum Team regarding their general perception about the Scrum framework and its implementation. The results from those interviews showed that the duration of the Daily Scrum was appropriate; however, the Sprint Planning and Retrospective were slightly too long, and the Sprint Review was slightly short. In addition, the efficiency (i.e. the added value for the design process) of the different Scrum Events was rated by the interview participants. The Daily Scrum received a 3.9, the Sprint Planning and Review each a 3.5 and the Sprint Retrospective a 3.0, all from a scale from1.0 (does not add any value) to 5.0 (does provide a lot of value). Question Absolute weight [%] Q1 - How many participants completed a Task? 33.3 Q2 - How many participants answered the three core questions? 33.3 Q3 - How long was the Daily Scrum? 6.6 Q4 - Took the Daily Scrum place at the same location and time as always? 6.6 Q5 - Was someone absent, late or left early? 6.6 Q6 - How many participants talked longer than three minutes? 3.3 Q7 - How many participants talked less than a minute? 3.3 Q8 - How many extern participants talked? 6.6 1,0 1,5 2,0 2,5 3,0 3,5 4,0 4,5 5,0 5,5 6,0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 Grade Daily Scrum Average grade of Q3 to Q8 [33%] Average grade of Daily Scrum [100%] Average grade of Q1 and Q2 [66%] Thomas Streule et al. / Procedia Engineering 164 ( 2016 ) 269 - 276 275 As the Scrum Framework (Figure 1) states who must attend the Scrum Events, the attendance necessity was rated by the Development Team and the Scrum Master as well. The grades ranged from 4.0 (Daily Scrum) to a 4.4 (Sprint Review). In addition, the different team members were asked about their view of Scrum regarding the following criteria: x Introduction: How was the introduction to Scrum? x Knowledge: What is your personal state of knowledge about Scrum? x Necessity: Do you understand why did you use Scrum in this Project? x Continuity: Do you know who you can ask if you have questions about Scrum? x Relevance: Do you like the application of Scrum for the Design Process? Figure 5 shows that the Introduction and Knowledge about Scrum were low when the project had started. It is worth to mention that all eight interviewed participants would like to continue using Scrum in the Design Process instead of the traditional approach they had used over years of practice. In fact, after only five weeks of experience, the Development Team was convinced that Scrum was more efficient than their previous approaches and methods. Mentioned benefits of Scrum were a higher transparency, better communication and collaboration, better flow of information and faster project development. Figure 5: Perception from the Development Team and the Scrum Master about the implementation of Scrum for different criteria (1: poor; 5: high) Another important advantage of using Scrum was that the many meetings enabled the single member to see the point of view of other team members and starts to understand why something was done in a certain way. Thereby, team members improved their knowledge in a field where they were not experts, helping to support the concept of cross-functional teams. The participants also indicated some difficulties when using Scrum, e.g. the missing knowledge at the beginning, no clear project leadership and that a lot of time was needed for voting in the Development Team as the team was hold accountable. Finally, the Kanban board has proven itself to a useful tool for the Development Team to keep track on the development. Overall, the disadvantages can be addressed to the low knowledge about Scrum at the beginning of the process; the duties and responsibilities of each member were not clear or well defined. Therefore, it is important to not only implement the events, artifacts and roles shown in Table 1, but also to entirely understand them. Due to this reason, more time was needed for the meetings and the voting, as well as the creation of the Product Backlog. The knowledge gained from this process was very valuable and can be reused for future projects as the description of the Items remains the same and only the scope and some Tasks need to be adjusted. Over time, a pre-defined Product Backlog can be created to significantly expedite the time to complete Phase 2 and Phase 3