Transcript UNIT4
Waterfall Agile Scrum Development department page 1/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 2/8 WATERFALL AGILE SCRUM • Quite a lot of issues popping up after 560 did a project retrospective • http://agressord/ProductDevelopment/ReleaseManagement/Document 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) • 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 3/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 4/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 5/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 6/8 WATERFALL AGILE SCRUM • CMMI introduced in 2011 • Documented process through the project handbooks • http://unit4rd/ProductDevelopment/ReleaseManagement/ADP%20for%20AB W/Home.aspx • Proof that our scrum methods are satisfying strict CMMI requirements page 7/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 • http://unit4rd/ProductDevelopment/ReleaseManagement/ADP%20for%20AB W/Process%20asset%20repository.aspx page 8/8