Embed Size (px)
Citation preview
What They Didn't Tell You in CSM Class
Camille Bell
Twi5er @agilecamille
Agile DC 2016 October 24, 2016
Issue: Scrum Team Missing Key People What:
• Delivery team does not include UX designer, DBA, DevOps, etc. – Company/OrganizaFon silos key skills into separate teams
– Handoffs to outside overworked teams
Impact:
• Development team not cross-‐funcFonal => DELAYS/LATE PRODUCT/
Why:
• Company doesn't really understand or implement Scrum
• Company trying to opFmize locally instead of globally • Company can't hire enough UX, DBA, Ops folks
• Company won't delegate responsibiliFes to delivery team
Company doesn't really understand or implement Scrum: • Educate upper management on the value of cross-‐funcFonal teams
Company trying to op0mize locally instead of globally: • Educate upper management on Lean principles • Conduct Value Stream Map to quanFfy cost of handoffs
Company can't hire enough UX, DBA, Ops folks: • Stop building non-‐essenFal low payoff products
• Reduce manual load on DBA, Testers, Ops with automaFon • Imbed key people (at least part Fme) into Development Team
• Cross-‐train members of Development Team in key skills
Company won't delegate responsibili0es to delivery team: • Demonstrate improved repeatability, Fme to market and governance
and reduced risk from automaFon and cross-‐funcFonality [email protected] 3
MiFgaFon: Scrum Team Missing Key People
Issue: Scrum a Mismatch for Team What:
• Scrum expects delivery teams to have work with a predictable, backlog that can be well esFmated and can be completed within a sprint
Impact:
• Most delivery teams slowly become be[er at esFmaFng and working within a sprint
• But a few teams never do
Why:
• Scrum is designed for teams that deliver new features • Some teams have a different cadence
• Some teams cannot effecFvely esFmate their work beforehand [email protected] 4
Recognize that Scrum wasn't designed for some types of work • Examples include:
– Maintenance Teams
– System Engineering Teams
– Network Engineering Teams – Dedicated Research and Development Teams
Maintenance / Bug Fix Teams Can't Es0mate work: • ~ 90 % of the Fme required to fix legacy or complex bugs is spent
researching and understanding the bug
• UnFl a bug is understood, it can't be esFmated
• Use Kanban instead of Scrum for planning and tracking progress • Daily standups and regular retrospecFves are sFll useful
MiFgaFon: Scrum a Mismatch for Team
Delivery Teams That Also Fix Pre-‐exis0ng Bugs: • EsFmaFng bugs is a waste of Fme
• Instead dedicate a percentage of the team's capacity to bug fixes – Only applies to pre-‐exisFng bugs
– Fixing new feature bugs is part of regular new feature work
• Delete that capacity from the total capacity when planning new feature work
• Plan and track bug fixes in a dedicated Scrumban Swim Lane, creaFng two input queues, one the standard new feature backlog and a second of bug fixes
• Use first-‐in first out, Naked Planning, etc. to prioriFze work items in the maintenance input queue
MiFgaFon: Scrum a Mismatch for Team
Kanban Board with Swim Lanes (2 feature sets, 1 bug fix)
Features
Maintenance & Improvement
System Engineering and Networking Teams:
• These teams support other teams, so other delivery teams are effecFvely their Product Owners, but since they support mulFple teams they have compeFng prioriFes
• Also while some work can be anFcipated, much of their work is and should be ad-‐hoc
• EsFmaFon is less of an issue (e.g. standing up a new server or creaFng a network alias takes a predictable amount of Fme)
MiFgaFon: Scrum a Mismatch for Team
OpFon 1: System Engineering and Networking Teams incorporated into delivery teams
– Creates a truly cross-‐funcFonal team
– Requires restructuring your organizaFon – System Engineering and Networking tasks become part of user
stories and are planned, esFmated and tracked accordingly
OpFon 2: System Engineering and Networking Teams remain separate teams
– Use Kanban instead of Scrum for planning and tracking progress
– Use first-‐in first out, Naked Planning, etc. to prioriFze work items in the input queue
– Daily standups and regular retrospecFves are sFll useful
MiFgaFon: Scrum a Mismatch for Team
Research and Development Teams:
• These teams by their nature are oeen ad-‐hoc and exploratory
• But some discipline is helpful to provide technical focus, avoid lengthy excursions down rat holes and provide business value
• Less bleeding edge R&D teams can use Kanban and someFmes Scrum structure with addiFonal Spikes (Fme-‐boxed research)
• More bleeding edge R& D teams probably only use Kanban containing Spikes with a very small input queue/backlog since priority will oeen change as a result of completed research
• Standups will be much more technical in these teams
• Periodic retrospecFves promote new perspecFves
• Demos may be less regular, but important to keep business stakeholders engaged
MiFgaFon: Scrum a Mismatch for Team
Issue: User Stories Missing Clarity What:
• You are wriFng User Stories to avoid requirements bloat • You even ask the customer quesFons as you go
• But when you demo, you discover you are way off the mark
Impact:
• Incorrect funcFonality, Fme wasted correcFng => WRONG PRODUCT and/or LATE PRODUCT
Why: • User Stories didn’t provide detail to implement
unambiguously
MiFgaFon: User Stories Missing Clarity User Stories didn’t provide enough detail to implement: • Cards aren’t enough: Need Jeffries 3 Cs*
– Card: the User Story itself
– ConversaFon: talk, repeat what the customer said in different words, get feedback, ask clarifying quesFons for more details, challenge your assumpFons
– ConfirmaFon: automated tests
• Automated tests demand precision – Given, When, Then Cucumber tests are very good for high level
ATDD, BDD
– If possible sit down with customer to as you write tests
– Show the Cucumber tests to customer – Get test data input and expected results from customer
• Run the tests and show results to the customer – Customer may think of something he forgot
[email protected] 12 Ref: Ron Jeffries 3 Cs of User Stories
CollaboraFvely (Spec it/define tests) • SomeFmes called
the 3 Amigos (test, dev, business)
• ConversaFon based
• Focus on value
• Specific examples
• Concrete data
• Outside in (business focus drives development)
Acceptance Criteria will become our specs when they have details
Feature: Cash Withdrawal
In order to get money when the bank is closed
As a bank customer
I want to withdraw cash at the ATM
• Successful Withdrawal • Less than balance • Equal to balance
• Withdrawal Failed Due to Insufficient Funds
• Withdrawal Failed Because Cash Dispenser Doesn’t Dispense One Dollar Bills
• Withdrawal Failed Because Account Closed
First Cut Acceptance Criteria for several tests [email protected] 14
• Successful Withdrawal (less than balance)
Given my account has starting balance of $1000
When I withdraw $200
Then $200 should be dispensed
And the ending balance of my account should be $800
Given, When, Then format – Business language with unambiguous detail
Detailed Acceptance Criteria
These detailed acceptance criteria are acceptance tests that are executable specs
Issue: Scrum PrioriFzaFon Not CreaFng MPV What:
• You product owners are prioriFzing your backlog 1, 2, 3 … • You are developing stories in that order
• But needed pieces are missing for a Minimal Viable Product (MVP)
• And some completed stories aren't needed for a MVP
Impact:
Not delivering Fmely releasable product => IMPORTANT FEATURES NEGLECTED while
=> WASTING TIME and MONEY
Why: • Stories were created independent of one another, including
unessenFal features, while omipng less obvious but needed ones
Issue: Scrum PrioriFzaFon Not CreaFng MPV Stories were created independent of one another:
• User Story Workshops etc. are oeen unstructured – Product Owners create stories off the top of their heads
– Stories produce somewhat randomly
– Big picture lost
Releases, if thought of, are too large, not MVP: • Triage missing or applied inconsistently
– Nice to have features slip in
Include unessen0al features: • Triage missing or applied inconsistently
– Nice to have features slip in
– Features that belong in subsequent MVP releases slip in
Lack of MVP structure misses less obvious but needed features
MiFgaFon: Scrum PrioriFzaFon Not CreaFng MPV
Create Personas: • Named in depth profiles • What is this user like? -‐ What does she care about?
Hold Story Mapping sessions: • Keep the big picture
• Tell stories instead of write stories
• Elaborate what goes into a releasable feature, step by step • IdenFfy missing pieces
– Invisible, but essenFal background components
– CriFcal external systems , Product Owner may be unaware of
• Keep MVP as small as possible – Brutally eliminate stores or features that could wait for next MVP as
a mini-‐release
MiFgaFon: Scrum PrioriFzaFon Not CreaFng MPV Story Mapping
System System
NarraFve Flow
Andy Admin
Be[y Buyer
Audrey Audit
MiFgaFon: Scrum PrioriFzaFon Not CreaFng MPV Story Mapping
System System
NarraFve Flow
Andy Admin
Be[y Buyer
Audrey Audit
MVP1
MVP2
Issue: RetrospecFves Aren't Helping What: • Although held regularly retrospecFves aren't effecFve
Impact: • Team is wasFng Fme and stagnaFng instead of improving
Why: • Some team members never speak up in the retro
• Not possible for team to implement recommended changes • Lots of changes come out of the retro, which aren't implemented
• A few changes come out of the retro, which aren't implemented
• Recommended changes missing underlying problems
MiFgaFon: RetrospecFves Aren't Helping
Some team members never speak up in the retro: • Team members feel inhibited
– Ensure retro is held in completely private space
– Exclude anyone not working member of delivery team (no managers or observers)
– Establish safety ground rules (e.g. all discussions stay private)
• Extroverts and introverts communicate best in different ways – Write down retro ideas ahead of Fme on sFckies
– Take a few minutes at beginning of retro to write down more ideas
– Discuss verbally and capture more ideas on sFckies – Use strong facilitaFon if needed to prevent extroverts overpowering
introverts
MiFgaFon: RetrospecFves Aren't Helping
Not possible for team to implement recommended changes: • Retro has become a gripe session about other teams
– Acknowledge teams' unhappiness (don't pretend it doesn't exist)
– Refocus team on how they can improve themselves
–
• Recommended changes have external dependencies – If improved collaboraFon and cooperaFon with another team is a
legiFmate concern, focus team on how they can improve their side (providing earlier heads up, creaFng a liaison, etc.)
– If not, refocus team on how they can improve themselves
Lots of recommenda0ons which aren't implemented: • Cluster similar recommendaFons into sFcky groups
• Choose one sFcky to represent the group • Use dot voFng to choose or or at most two recommendaFons
MiFgaFon: RetrospecFves Aren't Helping
A couple recommenda0ons but none implemented: • Track implementaFon of recommendaFon on a sFcky clearly
viewable in team room
• At the beginning of each retro ask team if they implemented the recommendaFon using fist of 5
• If every team member votes a 3 or above mark a plus on the sFcky
• Otherwise mark a minus • Aeer four pluses, throw away the sFcky (Team's internalized it)
• Aeer four minuses, throw away the sFcky (Team's not going to do it)
• Aeer four Fmes with a mix, team discusses
Team pair programs at least 2 hrs a day
++
MiFgaFon: RetrospecFves Aren't Helping Recommended changes missing underlying problems: • Stop using simplis0c retro techniques, like the quesFons below
– What went well during the sprint cycle?
– What went wrong during the sprint cycle? – What could we do differently to improve?
• Instead go much deeper, when needed – Provide more Fme for a deeper retro
– Hold retros that cover a longer period of Fme, like a release
– Use "Timeline" to gather data and reveal pa[ers
– Use "5 whys" to dig deeper into issues
– Use "SMART" goals • Specific
• Measurable
• A[ainable
• Relevant
• Time Bound [email protected] 25
Issue: No Story Burndown Till Last Day What: • Hour burndowns may have a downward slope as they should
• But stories aren't completed unFl end of Sprint • End of Sprint is chaoFc
Impact: • Some stories rollover into the next Sprint
• Completed stories have lower quality
• Team feels stressed at the end of the Sprint
Why: • Stories are too big • Team members are task switching
• Team members are focusing on starFng work instead of compleFng work
• Team members aren't helping each other
0
2
4
6
8
10
12
1 2 3 4 5 6 7 8 9 10
Stories
Sprint Day
Hockey S0ck Burndown
To Do Done
Why is so li[le gepng done? Too many stories in flight! Task switching ! Handoffs! No cooperaFon!
Jim
Mary
Mark
Paul
Jim
Ken
Sue
Sue
Ken
Ken
Paul
Mark
Sue
Mark
Sue
Scrum doesn’t have WIP Limits. Without WIP Limits Scrum can be dysfunctional. Consider adding WIP Limits to Scrum.
Doing
FLOW
Mary
Mary
Switching between three one week tasks means none of them get done in three weeks.
Week 1 Week 2 Week 3 Week 4
Task A
Task B
Task C
Dev completes task before starFng next one
Dev switches between tasks
Ref: Mary and Tom Poppendieck on Lean [email protected] 28
MiFgaFon: No Story Burndown Till Last Day Stories are too big: • Size stories to finish in 1/3 or less of the Sprint length
Task switching: • Set strict Work in Progress Limits to prevent task switching
– Recommended Max WIP limit = Team Size / # Team Members per Story
Not Focused on Finishing: • Sign up for fewer stories (can always add one if others finish early) • No team member starts new story, if other's stories not finished
(help others finish instead) • Use project board to show story progress and talk about stories
closest to done in standup, before talking about other stories
Not Helping Each Other: • InsFtute Pair Programming
• Use Mob Programming [email protected] 29
To Do Done
Jim
Mark Paul
Sue Ken
WIP Limit = 3 Doing
FLOW
Mary
Story Board with WIP Limits
Issue: Scrum Provides No Technical PracFces
What: • Scrum is used extensively for soeware development • Scrum provides only guidance for management and organizaFon of
soeware development teams
Impact: • Only using Scrum pracFces may build the right product, but its built
the wrong way => SW IS HARD TO TEST
=> SW IS HARD TO MODIFY => SW IS BUGGY
=> COSTS EXTRA TIME and MONEY
Why: • Scrum is missing guidance to build working, tested, maintainable
soeware
MiFgaFon: Scrum Provides No Technical PracFces Scrum is missing guidance to build working, tested, maintainable soeware: • Add Extreme Programming pracFces to Scrum
– Acceptance Tests – see "User Stories Missing Clarity" MiFgaFon
– Test Driven Development improves code design, reduces bugs and eliminates gold plaFng
– Refactoring and design improvement ensures maintainability and speeds addiFon of new features
– Pair Programming provides conFnuous inspecFon, cross training and distributed knowledge of codebase
– Con0nuous Integra0on produces solid builds and ensures team is all working on the same version of the soeware
– Etc.
[email protected] 32 http://www.extremeprogramming.org/
MiFgaFon: Scrum Provides No Technical PracFces Scrum is missing guidance to build working, tested, maintainable Soeware (con0nued):
• Incorporate Con0nuous Delivery – Modern Dev Ops movement goal
• Always be ready to release
• Every change could be deployed if desired
– Ferrets outs problems in development and release processes and systems
– Follow on to ConFnuous IntegraFons with automaFc staging and tesFng of security, performance, etc.
– Reliant on pracFces like Extreme Programming
https://en.wikipedia.org/wiki/Continuous_delivery/
MiFgaFon: Scrum Provides No Technical PracFces Scrum is missing guidance to build working, tested, maintainable Soeware (con0nued): • PracFce, pracFce, pracFce
– Like learning to play an instrument learning new ways of development requires lots of pracFce and reinforcement
– Becoming proficient in Test Driven Development, Refactoring, etc. requires more Fme and effort than learning Scrum – be paFent
– Provide technical training to help developers get started
– PracFce Pair Programming • Having a buddy to work with reinforces TDD, Refactoring and CI
• Without a partner its too easy to fall back onto old habits
– PracFce Mob Programming
– Run Code Katas to pracFce Test Driven Development and refactoring
– A[end Code Retreats
– Get the team technical coaching
globalday.coderetreat.org http://coderetreat.org/
https://www.youtube.com/watch?v=p_pvslS4gEI
Issue: Scrum of Scrum Isn't EffecFve What: • The Scrum of Scrums worked alright with four teams
• But when more teams were added, problems slipped through the cracks
Impact: • Unneeded working is being done
• Needed work is not being done
• Delivery teams find themselves blocked by other teams or external factors
Why: • Complex technical architecture with lots of different languages and 3rd party
soeware
• Technical teams are siloed and over specialized • There are lots inter-‐team dependencies
• Many inter-‐team dependencies are not obvious
• Scrum of Scrums doesn't scale well [email protected] 35
MiFgaFon: Scrum of Scrum Isn't EffecFve Complex technical architecture with lots of different languages and 3rd party soeware: • Simplify the architecture to reduce dependencies and complexity • Simply the architecture step by step, not all at once
• Architecture simplificaFon can takes years
Technical teams are siloed and over specialized:
There are lots inter-‐team dependencies:
Many inter-‐team dependencies are not obvious: • Create cross-‐funcFonal teams – see "Scrum Team Missing Key
People" • Cross train team members – pairing really helps
• Proac0vely look for dependencies and impediments; don't assume team members will always know about their dependencies on non-‐team soeware, architecture or schedules
MiFgaFon: Scrum of Scrum Isn't EffecFve?
Scrum of Scrums doesn't scale well: • Scrum of Scrum works pre[y well with four teams
– Even with four teams, it helps if members of those teams interact with each other regularly outside of the Scrum of Scrums
• The the more teams in a Scrum of Scrums, the less well it works, so the first step is to reduce the number of teams – Ensure that all teams are working to build the same product
• If not remove those teams from the Scrum of Scrums (they are just adding noise to the Scrum of Scrums)
• The removed teams may belong in another product's Scrum of Scrums
– CreaFng true cross-‐funcFonal teams and cross training will reduce the number of teams needed
– Simplifying the technical architecture will reduce the variety of skills needed and so the number of teams needed
MiFgaFon: Scrum of Scrum Isn't EffecFve?
Scrum of Scrums doesn't scale well (con0nued): • If aeer applying all the bullets on reducing the number of teams and
there are sFll more than four or five teams or Scrum of Scrums isn't effecFve even with a few teams, replace Scrum of Scrums – Use Kanban instead of Scrum of Scrums – Focus on the product's need for inter-‐team planning and coordinaFon
not "what did your team do yesterday?"
– Focus on longer term issues across Sprints
– Assign a very technical agile manger/facilitator who proac0vely looks for dependencies, impediments and product wide issues
– Create a backlog for this 2nd Fer Kanban containing work items needed for the product itself and the product teams
– Scale across the organizaFon and mulFple products with a 3rd Fer Kanban with an organizaFonal backlog
Don’t Go It Alone Become ac0ve in local user groups (find on Meetup.com):
• Agile, Scrum and Kanban Groups
• Soeware Craesmanship Groups (Code Kata groups and Code Retreats)
• Technology Specific Groups (languages, pla}orms, DevOps, etc.)
Read about several agile prac0ces: • Lean & Kanban
• Scrum
• eXtreme Programming
A5end conferences and training
Bring in consultants, where appropriate
Share your knowledge and experience
Camille Bell
Agile Coaching & ConsulFng RetrospecFves
Agile Boot Camps Agile Training Updated Slides
or just to chat about things agile
