UNIT4

Report
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

similar documents