Harnessing Passkeys in the Battle Against AI-Powered Cyber Threats.pptx
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
15. Lessons learned:
1. Stick to the method
2. Trust your team
3. Educate your stakeholders
4. Be agile in your collaboration & communication
5. Deliver!
Agenda:
How we organised a cross-national Scrum project
How we used the artifacts of Scrum
How we managed the seremonies of Scrum
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.
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
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.
Main artifacts:
Product backlog.
Has to bee DEEP:
Detailed appropriately
Estimated
Emergent
Prioritized
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
Main artifacts:
Charts
Reporting
Goal:
Sustainable pace
Control
Stakeholder expectance management
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.
Example of Value Creation Map.
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.
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.
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.
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.
Handle the stakeholders!
Identify them
Make an analysis
Have a communications strategy for them