Download to read offline
Uploaded byChristian Willoch
2013 12- scrum case presentation
The document discusses the setup and management of a multi-national scrum project, using the STEx case as an example. Key lessons learned include sticking to the scrum methodology, trusting the team, educating stakeholders, being agile in collaboration and communication, and ensuring delivery. It also emphasizes the importance of managing stakeholder interest and the recommended reading for further insights.
2013 12- scrum case presentation
- 1. SETTING UP, MANAGING,AND DELIVERING A MULTI-NATIONAL SCRUM PROJECT -The STEx Case Christian Willoch Manager, Head of Internal IT in Centric christian.willoch@centric.eu
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15. Lessons learned: 1. Stickto the method 2. Trust your team 3. Educate your stakeholders 4. Be agile in your collaboration & communication 5. Deliver!
- 16.
Editor's Notes
- #2 Agenda: How we organised a cross-national Scrum project How we used the artifacts of Scrum How we managed the seremonies of Scrum
- #3 The STEx-project startet in October 2010 when the staffing system used in the Nordic countries was demonstrated for business units in Netherlands and Belgium. Decision was taken later that we wanted to develop one common staffing system for all of Centric, and base it on the Nordic system. The developement of the Nordic system had since 2006 been developed by 99x Technologies in Sri Lanka, and they where picked as partner for developing the next version, called STEx. Kick-off started in Gouda June 2011, with a fit-gap analysis. After that: technology decisions establish project group establish user group development started February 2012, with final delivery March 2013. Scrum was selected as project method, but challenge with a big systems replacement is the discussion on «Big Bang deployment» contra iterative releases.
- #4 Challenges of distance, culture, and language: Developers in Sri Lanka. Product Owner in Norway. Time difference of 3,5 / 4,5 hours was in this case an advantage, creating a good maintenance window. Has to be managed: Seremonies Artifacts Stakeholders
- #5 Main artifact: The product itself. Defining potential shippable state. And for the Scrum process: Stick to it. Trust it. And believe in the benefits. Too many are running projects like «Scrum-but» manner.
- #6 Main artifacts: Product backlog. Has to bee DEEP: Detailed appropriately Estimated Emergent Prioritized
- #7 Main artifacts: the user story. Importance of every time write it correctly: As a <role> I want to <goal/desire> so that <benefit/clause> And: The importance of Condition of Satisfaction / Definiton of Done to ensure test criterias and user expectance management. Too often stories deviate from the format, making them unusable/not understandable later. Benefits of good and consistent user story writing: Becomes a documentation in itself later
- #8 Main artifacts: Charts Reporting Goal: Sustainable pace Control Stakeholder expectance management
- #9 Main artifacts: Value creation map Not the same as a WBS (Work Break-down Structure), but a map showing all the top-level epics in a prioritized manner. Prioritized by value creation. The map served also as naming-conventions for tags as well in all epics and user stories, creating a easy-searchable catalog of the 1000+ stories that were created.
- #10 Example of Value Creation Map.
- #11 Main artifacts The wiki Extremely valueable Highly collaborative No “documents” All main stakeholders and user group was involved. In this project, no e-mails were allowed! All communication was to happen on the collaborative tools mentioned in the slide. Result: transparency a huge repository of knowledge of the product effective collaboration across the world.
- #12 Seremonies Sprint planning We always played planning poker. No exceptions (again: stick to the process). Moved from velocity-driven planning to commitment-driven planning at some point. (Read more about this here http://www.mountaingoatsoftware.com/blog/why-i-dont-use-story-points-for-sprint-planning - the blog is btw great to follow) Sprint demos Was presented for project group in Netherlands and Norway, and every month for user group. Also established at UAT (User Acceptance Testing) group prior to the user group demos.
- #13 Daily standup Again - no exception from the process. Though not «standup» due to people in upto 5 different locations, it was done. Every-single-morning.
- #14 Sprint retrospective Repeating myself here, but this is maybe the seremony that most people skip. Don’t. Keep it short and sweet, if necessary, but always write down some points. We used the wiki for this, and it is a valueable repository of learning points.
- #15 Handle the stakeholders! Identify them Make an analysis Have a communications strategy for them