The power to Say NO - Using Scrum in a BAU Team

"The Power to say No" - Using Scrum to empower yourteam 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: – "Ill 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 1 Month 2 Month 3

Month 0UNCONSCIOUS INCOMPETENCE

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

Month 1CONSCIOUS INCOMPETENCE

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 were part of a bigger team" – "We dont 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 (managers) 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

Month 2CONSCIOUS COMPETENCE

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 didnt 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 didnt 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 storiesDo in Future sprints • Team can move stories to Proposed priorities • Product owner can move stories to Known priorities60% • Team add stories they believe should be actioned next • If accepted, product owner moves to Known PrioritiesDo 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

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 werent 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 Method1. 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 cant 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

Month 3UNCONSCIOUS COMPETENCE

Issues at the beginning of the monthLeft over story points•People feeling that story points are aboutreward/signal of effort•Stories were being rolled over to the next sprintautomatically so that they could account for theiroverall 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 – “Id 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 whats 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• thats empowerment• thats the ability to say "NO"

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

http://zenexmachina.wordpress.com	1481
http://lanyrd.com	34
http://www.linkedin.com	6
http://us-w1.rockmelt.com	2
http://translate.googleusercontent.com	2
http://feeds.feedburner.com	1
https://si0.twimg.com	1

The power to Say NO - Using Scrum in a BAU Team

by Mia Horrigan on Jul 29, 2012

Accessibility

Categories

Upload Details

Usage Rights

7 Embeds 1,527

Statistics

The power to Say NO - Using Scrum in a BAU Team Presentation Transcript