Becoming Agile in a Non-Disruptive Way: Is it Possible?
Download as PPTX, PDF0 likes607 views
The document discusses the feasibility of creating agile teams within traditional software development frameworks. It outlines essential characteristics of agile teams, methods for measuring team agility, and steps to enhance agility through improved communication and cross-competency. A case study conducted within an IT department of a Swedish insurance company is also highlighted, indicating positive outcomes but emphasizing the need for further testing.
Becoming Agile in a Non-Disruptive Way: Is it Possible?
- 1. DSV SU Becoming Agile in a Non-Disruptive Ways Is it possible? 1 Ilia Bider & Oscar Söderberg 5/15/2016 18TH International Conference on Enterprise Information Systems ICEIS 2016
- 2. 5/15/2016 DSV SU Objectives • Questions? 1. Is it possible to create an “agile team” while staying in the frame of the traditional phase base development 2. If yes than how? • We will be answering the first question by giving an answer to the second one (how) – Design Science approach 2
- 3. 5/15/2016 DSV SU Objectives • Problems to solve/questions to answer 1. What are the essential characteristics of an agile team/agile mindset? In what way they are different from those of a non-agile team? 2. How to measure the level of team agility achieved to see the distance to the end-goal 3. How to plan actions to shorten the distance 3
- 4. 5/15/2016 DSV SU Plan 1. What are the essential characteristics of an agile team/agile mindset? In what way they are different from the characteristics of a non-agile team? 2. How to measure the level of team agility achieved to see the distance to the end-goal and how to plan actions to shorten the distance 3. Test so far 4
- 5. 5/15/2016 DSV SU Background: Knowledge transformation SECI model of knowledge transformation of Nonaka: 5 Nonaka, I., 1994. A dynamic theory of organizational knowledge creation. Organization science, 5(1), pp.14-37.. Two types of knowledge: – Explicit – Tacit + One added - embedded
- 6. 5/15/2016 DSV SU Knowledge transformation in TSD ECEA - a model of Traditional Software Development 6 Additional activities, e.g.: • Writing manuals: embedded -> explicit) • Reading manuals (explicit ->tacit Becoming obsolete
- 7. 5/15/2016 DSV SU Knowledge transformation in ASD SEA - a model of Agile Software Development: Avoiding explication of knowledge 7 Difference: 1. Requirements: engineering -> discovery 2. Design + Coding = Embedment 3. One big cycle -> many small
- 8. 5/15/2016 DSV SU Difference between ASD and TSD Social perspective 8 # ASD TSD 1 One team consisting of “universal” members Several specialized teams 2 Stakeholders involvement during the duration of the project Stakeholders involvement during the Externalization and Adoption phases 3 Non-contractual agreement based on trust Contractual agreement is possible
- 9. 5/15/2016 DSV SU Difference between ASD and TSD Technical perspective 9 # ASD TSD 4 Possibility to identify and agree on a core system that can be expanded in consequent iterations Not mandatory, but can be employed. 5 Architecture aimed at expansion Architecture aimed at fulfilling the identified requirements 6 Employing high-level tools, e.g. domain-specific languages, development platforms, libraries Not mandatory – low level, and universal tools can be employed
- 10. 5/15/2016 DSV SU Summary An agile team/agile mindset – a team (a) of generalists (b) capable of creating an application/software from tacit knowledge (c) acquired via socialization with the stakeholders (d) using high- level tools and (e) bypassing traditional phases of requirements engineering and system design 10
- 11. 5/15/2016 DSV SU Plan 1. What are the essential characteristics of an agile team/agile mindset? In what way they are different from the non-agile team? 2. How to measure the level of team agility achieved to see the distance to the end-goal and how to plan actions to shorten the distance 3. Test so far 11
- 12. 5/15/2016 DSV SU Modeling team structure Team-relationship model: Input-output relation 12 Matrix form BM RE AD Impl Test BM RE Model Bugs AD Reqs Impl Design Bugs Test Software
- 13. 5/15/2016 DSV SU Modeling team structure Team-relationship model 13 Communication intensity • High – once a day • Average – 3 times a week • Low – once a week BM RE AD Impl Test BM High Average Low RE High Average High Low AD High High High Impl Low Average High Test Low Low Average High
- 14. 5/15/2016 DSV SU Planning the next step Team-relationship model 14 Communication intensity • High – once a day • Average – 3 times a week • Low – once a week BM RE AD Impl Test BM High Average Low RE High High High Low AD High High High Impl Low High High Test Low Low Average High
- 15. 5/15/2016 DSV SU Modeling team structure Team-relationship model 15 Cross competence Percentage of the members of the column team having working knowledge of the row phase BM RE AD Impl. Test BM 50% 75% RE 75% 75% 50% AD 75% Impl. 50% 50% 75% 50% Test 50%
- 16. 5/15/2016 DSV SU Planning the next step Team-relationship model 16 Cross competence Percentage of the members of the column team having working knowledge of the row phase BM RE AD Impl. Test BM 50% 75% RE 75% 75% 50% AD 75% 50% Impl. 50% 50% 75% 50% Test 50% 50%
- 17. 5/15/2016 DSV SU Modeling team structure Timeline intensity 17
- 18. 5/15/2016 DSV SU Planning exclusion of RE & Design New timeline intensity 18
- 19. 5/15/2016 DSV SU Moving towards agility 1. Intensify communication between the teams 2. Increase the level of cross-competency by mixing people from different teams 3. Run phases in parallel 4. Adopt high-level tools – as soon as possible (will make it easy to deal with 1,2,3 above) 5. Plan for minimum viable system when starting new development 6. Do not plan to much in each iteration 7. Increase stakeholders involvement by inviting them to review the system under development 19
- 20. 5/15/2016 DSV SU Plan 1. What are the essential characteristics of an agile team/agile mindset? In what way they are different from the non-agile team? 2. How to measure the level of team agility achieved to see the distance to the end-goal and how to plan actions to shorten the distance 3. Test so far 20
- 21. 5/15/2016 DSV SU Business case • The development of the method of moving to agile has been done in parallel with a case study of an IT department in a Swedish insurance company • The models demonstrated in the previous slides approximately correspond to the ones built for the business case • The method , the models, and suggestions for the next step were presented to the management of the IT department 21
- 22. 5/15/2016 DSV SU Goals with presentations To test whether: 1. The method could be understood by people not very familiar with the agile practices 2. They can accept concrete suggestions based on this method, provided that they are approved by the higher management. The last check (approximately) corresponds to “reediness to use” in Technology Acceptance Model 22
- 23. 5/15/2016 DSV SU Questions asked after 1. Have you understood what kind of organizational changes the transition to agile will require? 2. Have you understood the action plan for movement towards a more agile development process? 3. Are you prepared to submit the action plan to the upper/higher management for approval? 4. Are you prepared to set the suggested plan in action if approved by the higher management? Positive answers on 1,2,4. Some debates on 3 regarding how to influence the decision maker 23
- 24. 5/15/2016 DSV SU Summary of the test • The results are encouraging, but far from sufficient • More testing is required 24
- 25. 5/15/2016 DSV SU Q & A Thank you for your patience Questions and comments Please Contact: ilia@dsv.su.se 25