"The Power to say No" - Using Scrum to empower your team during development and maintenance.
Sep 14, 2014
"The Power to say No" - Using Scrum to empower your team during development and maintenance.
“No” is such a simple word
• Only 2 letters• Every two year old knows and uses it well
“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?
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
Noooooooooooooo!
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
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?
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
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
Psychology based learning model
Month 0 Month 3 Month 1 Month 2
UNCONSCIOUS INCOMPETENCE
Month 0
Started with a Workshop - Scrum 101
• Taught the rules• Useful as stakeholders hadn’t used Scrum
before
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
Our Approach to Scrum
CONSCIOUS INCOMPETENCE
Month 1
Creating the Product Backlog
• Thrown straight into developing user stories
• Prioritising of stories in backlog • Estimating stories – based on anology
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
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"
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
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
Team mood
• Chaos • Uncertainty• Not depressing, they were on a high!• Why?
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
CONSCIOUS COMPETENCE Month 2
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
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
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
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
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
Organised Product backlog
Anyone can add stories Team can move stories to Proposed priorities Product owner can move stories to Known priorities
Team add stories they believe should be actioned next If accepted, product owner moves to Known Priorities
Medium grain user stories (weeks of work) Product owner adds stories and writes Definition of Done Team review stories & estimate effort as part of grooming
Fine grain user stories (3-4 days of work) During sprint planning, Known Priorities are accepted by team based on capacity for delivery Team work to achieve Definition of Done for each story
Do in Future sprints 60%
Do Next sprint 20%
Do Now 20%
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)
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
Outcome
• At the end of the second month they felt empowered to say NO to the business
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
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 apologetic3.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
UNCONSCIOUS COMPETENCE
Month 3
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
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.
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
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
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
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"
Thank you
@miahorri
zenexmachina.wordpress.com
Mia Horrigan
Mia Horrigan
http://www.slideshare.net/miahorri