4. What works?
Most of the role aspects:
Single P.O. who owns backlog, priority and releases
P.O. clearly expresses PBIs/test criteria, and is final accepter
Product team owns estimates and sprint commitment
Scrum Master is servant-leader, coach, process enforcer
And in particular:
Small team
Small batch sizes
Iterative/Incremental everything
Definition of Done
4
5. What doesn’t work?
Co-located team
Self-organizing team
Flat, cross-functional team
Neutral Scrum Master
5
7. About Us
Mark Sawers
20+ years in Software Engineering
Dev Mgr @ Starwood Hotels (Marriott), CTO @ WebomateS
Certified ScrumMaster, practicing Scrum ~2 yrs
https://linkedin.com/in/marksawers
mark at sawers dot com
Alexandra Ramin
20 years in Marketing Operations and Project Management
Marketing Operations Mgr @ Starwood Hotels (Marriott)
Certified Scrum Product Owner, practicing Scrum ~2 yrs
https://www.linkedin.com/in/alexandraramin/
alexandra dot ramin at starwoodhotels at com
7
8. Context
Product used daily by all Starwood guests, on property
associates and Marketing staff representing 1K+ properties
~20 person product development team, split into 3 teams
Adopted Scrum ~2 years ago
Outsource partner staffs 100% of talent
80% IST, 2 US EST locations
Results
Doubled release freq., Halved defect density, Integrated releases
Challenges
Predictability, Staff turnover (not new)
8
10. Small Teams, Big Wins
Small batch sizes, narrower focus
Bridge teams with epic-level grooming, pre-planning
and scrum of scrums
Have one ScrumMaster lead coordinated activities, e.g.
tax cycle
10
11. Right People, Right Attitude
Engaged business owner
Developers/Testers that work well without detailed
requirements
For each location, a senior developer and tester to lead
juniors
Engaged product technical manager
Disciplined, principle-focused and product-
knowledgeable Scrum Master
11
13. Story != Task
The project-oriented planning habit is very hard to kick
Decomposition preference, in order:
1. By user-visible function
2. By architectural component
3. By activity
13
14. How to Miss Commitments
If there isn’t enough information on a user story, don't add details or acceptance criteria
during grooming
Develop first, then ask questions
Assume an existing feature was broken by some story and raise a defect
“Good enough” is never ok, make it perfect
Change stories mid-sprint
Add stories mid-sprint without removing comparable ones that have not been started
Finish the story regardless of a change in business context
Keep to the sprint commitment, regardless of business or technical impediments or
changes
If it's not working, keep doing it
Run experiments but ignore feedback
14
15. Iterate and Increment each story
Grooming - medium sized stories, reviewed by team,
good acceptance criteria
Acceptance Criteria early, Test Plan reviews early (day
1-3) and with whole team
Iterative business previews for early feedback
Spikes for uncertainty
Spikes to realize dependencies, e.g. on a shared
services team
15
16. Over-plan your sprint
Prevent team overloading by mapping the story points to a schedule
Dates for each story: dev complete, test plan complete, test exec start,
UAT start
Aim for UAT start at the latest day 9
Stagger test execution and UAT start
Lightweight tasks: dev, test plan, test exec, uat start with day #
If a team is over capacity and one is underutilized, split the work, but
assign a lead
Limit change to sprint scope mid-sprint. If you need to add, then
reprioritize and move items, don’t just add work.
16
17. Reality check the release
Go-no-go meeting on day 8 of last implementation
sprint
Only promote those that are QA complete and can
reasonably be UAT complete by day 10
Be realistic about what can make it into the release so
that code doesn’t have to be backed out
Stick to your decisions after the go-no-go and don't
squeeze in more stories when they are completed
17
18. Keep retros fresh
Change up the format / tools periodically
Actively engage team members that are not
participating
18
19. Over-communicate process
Operating Agreements: Release patterns, Tooling,
Entry/exit criteria, PBI types, states, usage
Docs, Presentations, KTs
Reinforce process during daily standups (e.g. is the
capacity correct, are task hours estimated and spent
updated, is the task/story status correct, was definition
of done met)
Publish schedules for multi-day efforts
19
20. Schedule carefully
Find best available slots for all time zones, and perhaps
revisit twice a year on daylight savings switches
Line up meetings so as many can attend as possible
(P.O., tech mgr, tech leads, BA, etc.)
Prioritize if there are conflicts
For each ceremony type, keep the start times the same
20
21. Use multiple information radiators
Agile planning tool
Daily email with per story, sprint and release status
Objective status measures/colors: Green-Yellow-Red
Daily email during tax cycle
21
23. Automate to reduce cycle times
No one should lift a finger to get code from their IDE to a
server
Automate the hell out of your regression suite – reduce tax
cycle
You can’t test everything
Use business input to test the most important / most used
features. Preferably using product usage data, not guesses
Periodically review these, since your product usage typically
changes over time.
23
24. Design in product agility
Flexibility: Feature toggles for staggered multi-
subsystem releases
Configurability: DB-stored app properties
Extensibility: Data driven business rules
24
25. Thank you
mark at sawers dot com
alexandra dot ramin at starwoodhotels at com
25