page 1/8 Waterfall  Agile  Scrum Development department

page 2/8 WATERFALL  AGILE  SCRUM Projects with different length; 1 year  3 years 6 weeks chunks of development phases  stabilization in between Development Quarters (560) One common thing: We had problems in completing on time Long stabilization phases were required due to bugs Started working after some Agile principles in 560, but the interpretation of this varied from team to team  implemented differently. No documented process ADP was not updated

page 3/8 WATERFALL  AGILE  SCRUM Quite a lot of issues popping up after 560  did a project retrospective library/560_evaluation.pptx library/560_evaluation.pptx Process too vague Team interprets working processes differently Lack of training in work processes Lack of commitment  follow an Agile process properly  Scrum (implemented in 561) Hired an external consultant (Benjamin Sommer) Started with a meeting with the Product owners/management (buy in) Our Scrum coach was here 1 month (program)program Sessions on choses topics Involved in sprint planning and reviews to give feedback on different teams We started to document the process in the Handbooks

page 4/8 WATERFALL  AGILE  SCRUM The scrum roles were implemented Product owner Divided between Product manager and PDM Scrum masters In house certification Previously we had tried with Project managers Team leaders …but the role has always been a bit difficult What should be the resp/authority of this person versus PDM The scrum roles solved this issue – clear roles which suited us very good

page 5/8 WATERFALL  AGILE  SCRUM TFS work items were changed User stories were introduced with all fields needed All teams used TFS the same way Platform and ABW aligned their work items TFS gives us everything we need Sprint burndowns etc The Office room is design around this way of working Boards Team sitting together Daily standups

page 6/8 WATERFALL  AGILE  SCRUM Half year projects VERY successful internally Deadlines are met Comparable projects Short time horizon Possible to plan No crisis of a feature was not included  realistic planning Focus on bugs From thousands to hundreds Acceptable levels and clear goals Short system test twice a year So: 561, 562, 563 were on time with quality and functionality BUT: the marked was not able to handle so frequent releases  1 year releases We tried to run M4 as 2 half year projects since we wanted to keep the benefits

page 7/8 WATERFALL  AGILE  SCRUM CMMI introduced in 2011 Documented process through the project handbooks W/Home.aspx Proof that our scrum methods are satisfying strict CMMI requirements

page 8/8 WATERFALL  AGILE  SCRUM Further scrum actions Benjamin is coming here in May to talk about Retrospectives – how can we improve our improvement process Responsibility taking Experience packs – we must figure out how this fits with our way of working Define clear processes for Experience packs as well Project info W/Process%20asset%20repository.aspx