University of Twente Student Theses
Agile Scaling @ Topicus : s caling scrum with help of Agile Scaling frameworks at Topicus Finance
Leeuwen, M.M. van (2015) Agile Scaling @ Topicus : s caling scrum with help of Agile Scaling frameworks at Topicus Finance.
|
PDF
5MB |
| Abstract: | Context - At the mortgage department of Topicus Finance where the product FORCE is developed, there are several challenges regarding working with multiple Scrum teams, such as knowledge sharing and task planning. Next to the fact that there are multiple teams working on one product, there are also three different customers, Customer X, Customer Y and Topicus itself (Pakket). Topicus posed the question how to deal with this challenge and still remain Agile. Research goal - Propose, test and partly implement an Agile Scaling framework to improve the functioning of the Scrum teams working on FORCE version 3 Conclusions - Of the three researched frameworks, there is no single Agile Scaling framework which offers a complete solution for all the challenges faced by Topicus. As part of this research we did a case study at Company B Department C, where we observed that not one entire framework had been implemented, but several different practices are used to fit their specific context. Based on the two examples of Topicus and Company B it is likely that there is not one single answer to the Agile Scaling challenges which companies face. Therefore in the future companies should clearly investigate their Agile Scaling challenges, and select the practices from the frameworks which best fit their organisation. Furthermore, the adoption of Agile Scaling frameworks requires changes in the way of working of the employees as well as in the structure of the organisation. Although the employees acknowledged that change is needed and they were involved in the decision making, the actual change was challenging. So knowledge from the change management field is very useful for the adoption of Agile Scaling frameworks. While, there were some difficulties in implementing the Travellers1. However at the end of the experiment the team members and especially the Product Owner were enthusiastic about the Travellers method and its results. Additionally, the chosen Large Scale Scrum (LeSS) practice, Travellers, could not be implemented in the exact way as described by the literature. The idea of exchanging teams was kept, but the shape of the Travellers concept had been altered to fit the context of Topicus. Next to the implied effect of knowledge sharing, the Travellers experiment also lead to mutual respect and understanding for the differences between the internal and external customer teams. Also, this experiment lowered barriers between the two teams, and team members indicated that it is more likely to approach each other in case help is needed. Lastly, the team member of Pakket who had joined the Customer Y team, noticed personal growth by stepping out of her comfort zone. Recommendations - The recommendations are split in recommendations for now, short-term, longterm and recommendation for further research. Now - Chickens2 - Topicus should repeat the Chicken experiment but with more structure and guidance to see whether this will result in enhanced knowledge sharing. This can be achieved by the creation of an Environment Map and a planning of which stand-ups to visit in advance. Travellers - The Travellers should be continued in the format used with the experiment. So briefly it can be stated that the Travellers experiment needs to be executed in the following way. o Exchange team members who voluntarily choose to join o Plan one to two Sprints in advance o Choose a topic which is easy to get started on (if possible) o Let somebody from team A join team B for one Sprint, afterwards change o The people who switch places preferably have the same function (i.e. developer) o After the exchange plan an evaluation with both teams to share experiences on wider level Short-term - Shared Space (LeSS) - Start with the increase of shared space, since this is also mentioned by the team members as a necessity. This means that the Customer Y teams have to move at least to the same side of the building as where the other FORCE teams are located. Joint Sprint Review Bazaar (LeSS) - This can be done in addition to individual Sprint Reviews. During this bazaar each team requires their own space where they can explain and demonstrate what they have been doing the previous Sprint. Open Space (LeSS) - This is a meeting where team members have the opportunity to share their concerns with people of other teams. At the start of the meeting people share what they want to discuss, and these topics are scheduled in parallel meeting sessions of 20 minutes. Same start/stop day - In order to make joint meetings possible, all the teams need to have their start/stop day on the same day. Long-term - Uniformity/standardisation of teams - More uniformity and standardisation across teams is needed in order to be more flexible with the planning of work. This means that there should be one single Product Backlog, one Definition of Done and one Definition of Ready. Joint Sprint Planning - When there is one Product Backlog and teams have the same start/stop day, it is possible to start using the Sprint Planning as done by Company B. SAFe® - As indicated by the Product Owners, Scrum Masters and team members there is a demand for a translation of the strategy and vision towards a more operational level, so decisions regarding the development of the product can be made so it supports the strategy and vision of the company. LeSS focuses on practical coordination tools on team level. SAFe® on the other hand takes the entire organisation in to account. SAFe® describes Agile Scaling on team, portfolio and program level. Therefore LeSS and SAFe® complement each other. SAFe® uses the strategy, vision and roadmap of the company as input for the Product Backlog. Future research - Scientific Proof of Frameworks - During this research I noticed scientific proof of the success of the different Agile Scaling frameworks is lacking. For the majority of these frameworks cases are available which can be used for further research to get scientific proof of these frameworks. Characteristics Frameworks - Furthermore, additional research should be done on what framework is best in which kind of situations. So, when organisations have defined their Agile Scaling challenges, it is easier to select the most suitable framework. |
| Item Type: | Essay (Master) |
| Faculty: | EEMCS: Electrical Engineering, Mathematics and Computer Science |
| Subject: | 54 computer science, 85 business administration, organizational science |
| Programme: | Business Information Technology MSc (60025) |
| Link to this item: | https://purl.utwente.nl/essays/67970 |
| Export this item as: | BibTeX EndNote HTML Citation Reference Manager |
Show download statistics for this publication
Show download statistics for this publicationRepository Staff Only: item control page