Using Scrum to empower your team during BAU (business as usual) development and maintenance. presentation at the #LAST Conference Melbourne 27 Jul 2012 #LAST (Lean, Agile, Systems Thinking)

1. "The Power to say No" - Using Scrum to empower your
team during development and maintenance.

2. “No” is such a simple word
• Only 2 letters
• Every two year old knows and uses it well

3. “No” is such a simple word
• Yet saying "No" out loud now is harder for me
than saying:
– "I'll be glad to..." (eleven letters)
– "When do you need me to..." (seventeen letters)
– “Ok I will fit it in…..” (fourteen letters)
• Why?

4. Struggling to say No
• I am a recovering “people pleaser”
• My first reaction is to try to please
• Saying "yes" was my default, to show either
support or to avoid conflict
• Felt compelled to say yes but, after making the
commitment, realised the potential to negatively
affect me was very real
• I needed to learn how to say No again

5. Noooooooooooooo!

6. Saw an opportunity
• Manager saw an opportunity to give Team a
unified processes to say no, maybe and yes
• Intranet project
• Short timeframes
• Needed an implementation strategy
• The transparency and collaboration he saw
emerging out of the intranet project was very
appealing to him
• Decided it might be adaptable to BAU

7. The Power to say No
• How many times a week does a co-worker,
manager or stakeholder ask you to do
something that is inconvenient, distracting, or
just ill-timed?
• How often have you dropped other work to get
it done only to find it wasn’t important or urgent
after all?
• Did you even feel you could say No?

8. The Team
• Information Management Services Team
• Small team of 8 within three areas:
– Information Lifecycle – recordkeeping
– Information Applications – application maintenance
and enhancements
– Business Intelligence – corporate reporting
• Geographically dispersed

9. What was the situation for the Team?
• Always seemed to have a “backlog” of work
that never got done
• No collective process for them to process
business user requests
– New work coming constantly coming in from the
business
– Team not sure of which work was important, urgent
or ranked higher
• No collective processes to handle BAU as well
as project work
– Started a bit of each project but never quite got
anything finished

10. Psychology based learning model
Month 0 Month 1 Month 2 Month 3

11. Month 0
UNCONSCIOUS INCOMPETENCE

12. Started with a Workshop - Scrum 101
• Taught the rules
• Useful as stakeholders hadn’t used Scrum before

13. Scenario based approach to learning
• Established the ground rules of
scrum, its roles, its controls, and its
processes by:
– showing how Scrum works
– giving team a practical lesson based
on a real case study
– ensured everyone was speaking the
same language, terminology
– set expectations of using Scrum

14. Our Approach to Scrum

15. Month 1
CONSCIOUS INCOMPETENCE

16. Creating the Product Backlog
• Thrown straight into developing user stories
• Prioritising of stories in backlog
• Estimating stories – based on anology

17. Did all the Scrum basics
• Collocation for most of the team
• Teleconferencing on desktop (linc) for those who
were interstate -good for stand-ups
• Video conferencing for Review and Sprint
planning (if couldn’t be held face-to-face)
• Big visual Kanban Board

18. Always chasing our tails….
• DoD either absent or incomplete
• PO often writing DOD in Sprint Planning
• PO thinking in terms of assigning products to his staff
• 3 different teams still based on the old functional silos
• Felt rushed and busy
• Still not completely moved away from their old ways of
working
• Still working on project issues from before the sprint to
'please everyone and keep them happy'
– "But we're part of a bigger team"
– "We don't have the luxury of working on just these projects"
– "We have to keep everything running"

19. What we did in reaction to this as their Coach
• Changed 2 week sprints to 3 week sprints
– 2 weeks too hectic
– 4 weeks too long to tell business stakeholders to wait
for a change
– 3 weeks 'felt right', but would be tested and
examined in retrospectives
• Pressed the PO to dedicate time to the backlog
• Pressed the Team to move everything not yet
complete into the product backlog

20. Moved the Kanban board to Jira
• Solved many of the non-collocation issues
• Shared desktop to help drive the stand-ups, planning
and review sessions
• Lost the high visual representation outside the PO
(manager's) office

21. Team mood
• Chaos
• Uncertainty
• Not depressing, they were on a high!
• Why?

22. Permission to say NO
• Projects that had been sitting around for ages
were actually getting done!
• One of the streams had their first understanding
of their permission to say "no" and pass on
new requests to the product owner
– they LIKED this :)
– first sense of empowerment and self-management

23. Month 2
CONSCIOUS COMPETENCE

24. Emerging issues
• Stories not being Done because they were
contingent on actions from outside the team
• Team not coming to ceremonies prepared
• PO still not having sufficient DoD and writing them
in the planning meeting
• PO chairing and controlling the meetings
– almost like status reports to the manager
– sprint review had replaced their traditional team meeting
– this meant the old behaviours just moved to the ceremony
• This was an issue for strong resolution for us as
coach

25. Mood of the team
• Improved
• Starting to understand they didn't have to
compromise and do BOTH old work and the
scrum-focussed products
• Still over committing
– taking on more stories 'just in case' stories outside
their control didn't get done
• Still working in their own streams
• Still playing catch up a bit in getting into the
cadence of the ceremonies
• Recognised need to break stories down further

26. Breaking down stories
• Stories too complex and not being completed
within the Sprint
• Many ways to break down the stories:
– Workflow
– Business rules
– Non functional requirements
– UI complexity
– Core first then add value

27. Story hierarchy
• The product backlog was built up using a
hierarchy of themes, epics, stories and tasks
• Traceability from the lowest to the highest level
helped team members understand where their
work fits into the bigger picture

28. Defining the Product Backlog
Business Intelligence
Community Broadcasting
Section want new reports to
be developed, because they
value meeting their KPIs
Consult with business to
determine complexity of
reports
Send final cost estimate to
business

29. Organised Product backlog
• Anyone can add stories
Do in Future sprints • Team can move stories to Proposed priorities
• Product owner can move stories to Known priorities
60%
• Team add stories they believe should be actioned next
• If accepted, product owner moves to Known Priorities
Do Next sprint • Medium grain user stories (weeks of work)
20% • Product owner adds stories and writes Definition of Done
• Team review stories & estimate effort as part of grooming
Do Now • Fine grain user stories (3-4 days of work)
• During sprint planning, Known Priorities are accepted by team
20% based on capacity for delivery
• Team work to achieve Definition of Done for each story

30. What we did as their Coach to highlight the CC
• Kept stories and DOD to things the Team could
commit to deliver in the timeframes themselves
• Moved to Fibonacci scale (1, 3, 5,8, 13…)
• Team gained an understanding of capacity of the
team and individuals - helped with sprint
planning and commitment
• Moved chairing meetings/ceremonies to the SM
to avoid controlling behaviour by the PO (who
was their manager)

31. Succession planning
• We put in behaviours so that ceremonies could
continue even if people weren't present
• Started putting in succession planning - people had
to arrange for another team member to act on their
behalf for demo/retro/sprint planning
• Started to combine standups when there were only a
few team members available
– first opportunities to hear about other stream work-in-
progress
– first opportunity to identify areas for cross-collaboration
across their old silos for work-in-progress
– first heads up of product backlog pipeline and
transparency of work in other silos

32. Outcome
• At the end of the second month they felt
empowered to say NO to the business

33. It’s not what you say but how you say it
• Saying no isn’t the same as being selfish; it’s
about establishing boundaries and balancing
prioritises (ordered)
• Team learnt best approach was to be direct,
honest, and tactful in their decline
• Used the 1-2-3 method

34. 1-2-3 Method
1. Understand what is being asked and put it in the
context of everything else on your "to do" list this
Sprint. Unless it is a “Break/Fix”, don’t say “yes"
2. Know how to respond, and do respond.
1. Be clear, concise, and direct
2. Be assertive, not apologetic
3. Offer alternatives ("I can't complete it this Sprint but will
put it in the product backlog for consideration).
• Negotiate if needed. Remind business that you are
working on projects identified as top priorities and
ask if the new task has rank order over the others

35. Month 3
UNCONSCIOUS COMPETENCE

36. Issues at the beginning of the month
Left over story points
•People feeling that story points are about
reward/signal of effort
•Stories were being 'rolled over' to the next sprint
automatically so that they could account for their
overall effort

37. When a User Story is Undone
• Put it back into the Product Backlog
– The User Story doesn’t get allocated to the next Sprint
• Don’t reap the Story Points for this Sprint
– As the User Story was not completed, the Team simply doesn’t
gain any of the Story Points. No partial-credit as can lend itself
(consciously or otherwise) to gaming the numbers
• Re-estimate the remainder of the complexity of the
User Story
– Why the User Story was left undone
– The new things they’ve learned about the User Story
– The new tasks and/or requirements of the User Story
– The remaining complexity, not the whole story including what
was Done
• Ensures that the Team’s velocity isn’t skewed by the
inflation of effort already spent.

38. Action and Successes
• As a result of the single stand-ups in month 2 we
now achieve radical visibility
– Opportunities to be involved across silos
– “I'd like to be involved in that"
– Emerging of pairing across silos on work
• PO was getting more input into products and
DOD
• Finally getting into formalised backlog grooming
• Team and individual members scheduling time to
break down the product backlog with the PO

39. Truly empowered
• Know what's coming up from conversations in
standups
• Know to groom the backlog with the PO in order
to establish the DOD, estimations and tasks
• Ask to be involved in work across old silos
• PO comfortable to move to only stating the
WHAT and not nominally delegate it to team
members
• In essence, team could now say NO to the PO

40. Outcome of being empowered to say NO
• Better understanding of commitment to take on
a product/story in a Sprint
• Collaboration and pairing across old silos
occurred to complete tasks
• Not silos of 3 streams -- a single team with a
single, shared vision of how to get their work
done

41. Month 4 - Setting them free
• Rotating the SM role
• One team
• Keeping to their rule of 3
• Seen as achieving outcomes
– people have noticed that they get stuff done -
enhanced reputation amongst their business users
– increased trust in the team
– increased transparency amongst the business of how
the team work
• that's empowerment
• that's the ability to say "NO"

42. Thank you
Mia Horrigan
@miahorri
zenexmachina.wordpress.com
Mia Horrigan
Mia.Horrigan@zenexmachina.com
http://www.slideshare.net/miahorri