Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (18)
Ähnlich wie Coade introduction
Ähnlich wie Coade introduction (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Coade introduction
- 1. Scrum? Hans-Peter Samios – Scrum Master 12/19/2013
- 2. WHY? What problems did we have?
- 3. We want this
- 4. Our “Health Reviews” ...
- 5. There Had To Be A Better Way …
- 6. Agile Adoption is Low Risk © 2007. Intergraph Corporation. All Rights Reserved.
- 7. Approach December 2007 – January 2008 – – 42 teams in 7 locations involving 360 people February 2010 – 22 teams in 7 locations involving 150 people June 2009 – Product Team Meetings – 3D, IM, 2D June - December 2008 – Determine training and engagement model Additional pilots, remote April – May 2008 – Executive Team Formed – Omegas First pilots commenced – Squids, Sprinters February – March 2008 – – Bob Schatz – Ex VP Development Primavera, Agile Infusion 63 team means that “Everyone is on Scrum teams” We’ve only just begun …
- 8. ANOTHER CORPORATE INITIATIVE – GREAT … But what’s in it for me?
- 9. Have Fun! © 2007. Intergraph Corporation. All Rights 12/19/2013 Reserved. Image courtesy of “The Borg” – remember Rule Number 6
- 10. February 2008 Survey – Team Feedback “This is awesome - morale is higher in this environment and the sense of belonging to a team is high” “Everything from development to documentation is self contained” “Focus is on team accomplishments and not individual performance” “Physical interaction with task items on a daily basis seems good” “Face to face location improves frequency of communication” “Overhearing each other keeps everyone up to speed throughout the day” “Impressed by all the done tasks” “Impressed by the burn down chart – not as many unknowns in the middle of the release” “Really liked the test results – proof in that it was demo’d and didn’t crash” © 2008 Intergraph Corporation. All Rights Reserved.
- 11. Jul-09: Do We Think We Are Producing More? 55% say we are producing more – – Only 8% say we are producing less Net very positive © 2007. Intergraph Corporation. All Rights Reserved.
- 12. Jul-09: Do We Think We Are Producing Higher Quality? 62% say we are producing better quality – – Only 11% say we are not Net very positive © 2007. Intergraph Corporation. All Rights Reserved.
- 13. Jul-09: Do People Like This Change To Scrum? 69% are positive about the change to Scrum – – Only 15% are not Net very positive © 2007. Intergraph Corporation. All Rights Reserved.
- 14. Jul-09: Would You Continuing Using Scrum If It Were Your Choice? 77% say “YES” © 2007. Intergraph Corporation. All Rights Reserved.
- 15. AGILE / SCRUM 101 Introducing Agile / Scrum © 2007. Intergraph Corporation. All Rights Reserved.
- 16. Our View of Software Development 12/19/2013 © 2007. Intergraph Corporation. All Rights Reserved.
- 17. Why Agile? 3 things we wish were true – – – 3 things we have to live with – – – The customer knows what he wants Our teams knows how to build it Nothing will change along the way The customer discovers what he wants Our teams discover how to build it Many things will change along the way “Scrum / Agile is a risk mitigation technique when our assumptions about predictability do not hold” © 2009. Intergraph Corporation. All Rights Reserved.
- 18. What is Scrum? An Agile Project Management framework : – – – – – – – – – A wrapper for existing engineering practices Small cross-functional; self-managed teams Prioritized queue of work Time-boxed iterations Multiple, frequent feature-driven planning activities Early detection and removal of obstacles User demonstration and collaboration Inspect and adapt cycle Sustainable pace for the organization Scrum is not a methodology – it is a pathway” -- Ken Schwaber (Boulder, Co, Nov. 2005) 12/19/2013 © 2007. Intergraph Corporation. All Rights Reserved.
- 19. Scrum on a Page Roles: Scrum Master Team Product Owner Team / Process Feedback Sprint Retrospective Stakeholders Product / Release Backlog Daily Scrum Sprint Backlog Sprint Planning 1 12/19/2013 Selected Backlog Sprint Planning 2 © 2007. Intergraph Corporation. All Rights Product Feedback Reserved. 30 Day Sprint Sprint Review
- 20. Roles: Roles and Responsibilities Scrum Master Team Product Owner Stakeholders Scrum Team Product Owner Scrum Master Team Stakeholders 12/19/2013 ► Defines the features of the product, decides on release date and content ► Is responsible for the profitability/value of the product (ROI) ► Prioritizes features according to market and/or user value ► Can change features and priority every 30 days ► Reviews work results with team ► Ensures that the team is fully functional and productive ► Enables close cooperation across all roles and functions and removes barriers ► Shields the team from external interferences ► Ensures that the process is followed. Issues invitations (eg daily scrum) ► Cross-functional, seven plus/minus two members ► Selects the iteration goal and specifies work results ► Can do everything within boundaries of project guidelines to reach iteration goal ► Organizes itself and its work ► Demos work results ► Customers: represent the users ► Functional managers: represent the organization ► Other interested © 2007. Intergraph Corporation. All Rights people Reserved.
- 21. Agile Environment – Temporary Start © 2007. Intergraph Corporation. All Rights 12/19/2013 Reserved.
- 22. Agile Environment – First Built Plan © 2007. Intergraph Corporation. All Rights 12/19/2013 Reserved.
- 23. Agile Environment – After One Year © 2007. Intergraph Corporation. All Rights 12/19/2013 Reserved.
- 24. Task Board / Pull System Backlog Items Tasks In Process Sprint Goals 1. Provide…. 2. User will… 3. Improve… 12/19/2013 © 2007. Intergraph Corporation. All Rights Reserved. “DONE”
- 25. How Does It Get “Done”? © 2007. Intergraph Corporation. All Rights 12/19/2013 Reserved.
- 26. Example – Daily Scrum Meeting © 2007. Intergraph Corporation. All Rights 12/19/2013 Reserved.
- 27. Example – Daily Scrum Meeting © 2007. Intergraph Corporation. All Rights 12/19/2013 Reserved.
- 28. Example – How to Ensure “Done” © 2007. Intergraph Corporation. All Rights 12/19/2013 Reserved.
- 29. Release Burn-down Shows total remaining points in release plan 12/19/2013 © 2007. Intergraph Corporation. All Rights Reserved.
- 30. Release Forecast Shows whether future plan (light colored chart) based on current data 12/19/2013 © 2007. Intergraph Corporation. All Rights Reserved.
- 31. Project Scope Change Shows the impact of changes in the scope 12/19/2013 © 2007. Intergraph Corporation. All Rights Reserved.
- 32. Work Category Shows, in particular, the impact of “unplanned” items versus our expectation for unplanned work 12/19/2013 © 2007. Intergraph Corporation. All Rights Reserved.
- 33. Epics Shows progress on the main epics in the release. 12/19/2013 © 2007. Intergraph Corporation. All Rights Reserved.
- 34. FURTHER READING "No one has to change. Survival is optional“ W Edwards Demming.
- 35. Additional Information PPM Scrum / Wiki Home Page – PPM Scrum Guidelines – http://share.intergraph.com/ppm/spknowledge/tab2/scrum1/Wiki%20Pages/PPM%20Scrum%20Guideli nes.aspx What To Do Now That You Have Finished This Training – http://share.intergraph.com/ppm/spknowledge/tab2/scrum1/Wiki%20Pages/Home.aspx http://share.intergraph.com/ppm/spknowledge/tab2/scrum1/Wiki%20Pages/Checklist%20%20Post%20Team%20Formation.aspx Useful Scrum Links – http://share.intergraph.com/ppm/spknowledge/tab2/scrum1/Wiki%20Pages/Useful%20SCRUM%20link s.aspx
- 36. The Journey Continues … …
- 37. 12/19/2013 EDIT THIS IN "HEADER & FOOTER" UNDER THE "INSERT" MENU 37
Hinweis der Redaktion
- Health Reviews said that “scope freeze” = “project red”Resulted in “death march” projects, lower quality of life and lower moraleTime taken to get new functionality out the door is getting longer and longer; cycle time longerEven when the functionality is delivered we get “that’s not what we want” from the customerEverything we did to get more control, seemed to make things worseAs soon as the software is delivered, it’s the start of crisis issues and problems, as we slipped quality to meet datesEveryone (the executives, sales, field, customers) regarded software development as a problemWorse we’d come to believe that that was “just the way it was” especially for “our complex products”
- Reality is that agile is not “bleeding edge” any more.642 respondents:54.8% were developers, 29.4% were in management41.6% had 10-20 years IT experience, 37.2% had 20+ years37.7% worked in orgs of 1000+ people71% worked in North America, 17% in Europe, 4.5% in Asia
- Image courtesy of The Borg –Rule Number 6 is “Don’t Take yourself too seriously”Also discussion about “quality of life”
- Sprinters team. Temporary housing in conference room. This was first time we tried “co-location” in Huntsville and was an area of high concern. From a management perspective our approach was to say “try it and see”. Recommendation from Bob that people try sitting facing each other, so we did that.
- By the time the Sprinters team got to design their real home, this is what they came up with. The management approach was “here is your team space – design it as you see fit”. The result was a more formal version of the temporary space. Fundamentally the team liked how co-location worked and were happy to have a similar set up in their case. There are in fact two team in this bay – the Sprinters and the Alphas. At the time the plan was put together, there was a lot of concern about how the noise from the team behind the partition would effect the Sprinters work.
- The team room one year later. As a result of a need to integrate another team member into the Sprinters team, the plans were reviewed by all on the team. When they proposal was seen by the team members, they decided that it did not make sense to have any partitions at all, that everyone could work together, and so this is the layout they came up with. So from a team that started with fear and worry about co-location, they went to a team driving the plan for co-location. Note that there was no management interaction with this process – team decided and it happened.
- Once we’ve defined “done”, how does it actually get done. At the heart of this work is a sprint team who is going to do the work. So far you have seen how a product backlog is put together, and you have seen a representation of the “sprint board” where all the tasks for a sprint are defined against the user stories. The sprint board is the detailed plan of what is going to happen in the next 30 days. Lets say you have a user story that says “Engineer defines a “typical” so that they can reduce the number of manhours expended on a P&ID”. After the team has accepted this story (which happens during Sprint Planning 1), the Sprint Planning 2 meeting takes place. This meeting is just with the team. They take this user story and say break it down into 1-16 hour chunks of work.For example, this user story might require some UI development, so the team writes down the task on the post it note and the number of hours it will take, say 5 hours, and slaps it up on the board. It might take some documentation – write down task, hours and slap it up on the board. And so on.Now some of these tasks might come from the definition of done. For example, perhaps an automated test is part of the definition of done for every user story. Then their might be a task that says “develop a QTP” and again the task and hours go up on the board.This third picture shows a team working through their definition of done to understand what they need to do. The second shows a team working through the tasks during a sprint.This is how a lot of the definition of done items are addressed. But as we pointed out before, that is not the only way. We can look at other mechanisms to get things done:. Special teams to address integration issues, for example.. Division of labor so that one team bears the brunt of one item, another for another itemAnd so on. In each and every case the definition is public and transparent and we know who is addressing that item. We also review the definition regularly while keeping in mind the overarching goal – to provide potentially shippable software at the end of every Sprint.