"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

Mia.Horrigan@zenexmachina.com