Getting Started, Agile Transformations,

& Multiple Teams

Benjamin Day
@benday | www.benday.com
Scrum & Agile doesn’t come out of nowhere.
A great process won’t appear
fully-formed.
You’ll have to work at it.
 Overview
 Why Scrum? Why Agile?

 Getting Scrum Started

 “Scrum Under a Waterfall”

 Agile Transformations

 Multi-team Scrum
 First up:
What’s and why’s of Agile & Scrum
 Why Agile? Why Scrum?
How are Scrum & Agile related?
 What’s Agile Mean?
 Agile Manifesto
 February 2001
 Grumpy about the state of the industry
 Wanted to focus on
- Individuals & interactions over processes & tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
 My Interpretation
 Software is a human endeavor
 Eliminate waste
 Focus on what matters
- Done, working software
 Recognize that you can't get the details right the first time
- You need to talk it out
- Software is complex
 Engaged customers & lots of feedback
 Why Agile?
 Do less stuff

 Do what you need

 Actually deliver working software that's DONE

 Give yourself the flexibility to change your mind

 Acknowledge that software is complex

Agile vs. Scrum?
Abstract base classes?
 Abstract Base Classes
 Java, C#, etc.

 Provide core logic

 Allows you to leave placeholders for later

 You can’t create an instance of an abstract class

 Shape, Circle, Square
public abstract class Shape
{
public abstract double CalculateArea();
public abstract double CalculateCircumference();
}

public class Circle : Shape { public class Square : Shape {

public int Radius { get; set; } public int LengthOfSide { get; set; }
public override double CalculateArea(){ public override double CalculateArea() {
return 3.14 * (Radius * Radius); return LengthOfSide * LengthOfSide;
}
}
public override double CalculateCircumference() {
public override double CalculateCircumference() {
return 2 * 3.14 * Radius;
return 4 * LengthOfSide;
}
}
}
}
 Scrum : Agile
public abstract class AgileSoftwareDevelopmentBase {
public abstract void DeliverSoftware();
}

public class ScrumSoftwareDevelopment : AgileSoftwareDevelopmentBase {

public override void DeliverSoftware() {
while (HasProductBacklogItems() == true) {
SprintPlanningMeeting();
DevelopAndTestSoftware();
SprintReviewMeeting();
SprintRetrospective();
}
}
}
 Agile vs. Scrum
 Agile is a set of values

 Scrum is the set of “dance steps” to help you use those values to deliver
done, working software
 Next up:
Getting Started with Scrum
The Blank Page.
 No Product Backlog. No Scrum Master.
No Product Owner. No Team. No Velocity.
No nuthin’.
 How Do You Get Going?
 Get a Product Owner

 Get a Scrum Master

 Get a Product Backlog, Part 1

 Get a Team

 Get a Product Backlog, Part 2

 Who’s Your Product Owner?
 Helps to identify what the Team is intended to do

 Should understand the product & market for the product

 Should understand the customers

 Have the organizational influence to make decisions

 Have enough time to spend with the team

 Who’s Your Scrum Master?
 (Required) Not the same person as the Product Owner

 (Desirable) Good people skills

- “Emotional intelligence”

 (Desirable) Confidence to say ‘No’

 (Optional) Have a solid understanding of the product

 Why Do QA People Often Make
Good Scrum Masters?
 Disclaimer: not always true

 Testers have a more expansive view of the software delivery process

 Testers are typically adjacent to…

- …requirements
- …development
- …database admin
- …deployment / operations / IT
 Get a Product Backlog, Part 1
 There’s no Team yet

 Start writing stuff down

- Post-It Notes or Excel

 If you get stuck, try to identify large sections of the app first

 Don’t worry about making PBIs small enough for a Sprint…yet

 Who’s on the Team?
 Everyone it takes to deliver the done, working software

 You'll need a mix of skills

 Business Analysts, Developers, Testers, Database Admins, IT people

 People might be partially allocated

 Ideally, everyone has equal skills

 Get a Product Backlog, Part 2
 You have the Product Owner, Scrum Master, & Development Team

 You have your “first attempt” Product Backlog

 Either do a Refinement Meeting or just do your Sprint Planning Meeting

 You only need enough work for Sprint 1

 Create more PBIs while the team is working in Sprint 1

 Your First Sprint Planning Meeting
 It’ll be a little rocky.

 Schedule a time for your Sprint Review

 Choose the PBIs for the Sprint

 Create individual Tasks for the PBIs

 Get a “good enough” plan for the Sprint

 The Rest of Sprint 1
 Go do work

 Do your Sprint Review

 Definitely do your Sprint Retrospective

 Try not to beat yourselves up about not being “perfect”

It’s not about how good your Scrum “dance” is.
It’s about done, working software.
Scrum Under Waterfall
Scrum Under a Waterfall
 What’s “Waterfall”?
 Plan-driven project management

 Gantt charts & Microsoft Project

 Start & end dates

 Project phases
- Requirements, Design, Development, Testing, Deployment
 Scrum Under Waterfall?
 Scrum used in a Waterfall-oriented organization

 Scrum + Plan-driven

 Not a great place to be

 Hopefully, it’s just a transitional form

 My Goals
 How to make the most of a non-ideal situation

 Be practical

 Try to see both sides

 Acknowledge that change takes time

 Waterfall vs. Scrum
Waterfall
 Requirements documents
 Resistant to change
- Change is a bug
 Limited "customer" involvement
 Start-to-finish Project Plan
 Potentially large team size
 Assigned Tasks
 Multiple phases  eventual delivery
 Contract driven
- Fixed feature set
Scrum
 Just-in-time requirements
 Embraces change
- Change is a feature
 Frequent "customer" involvement
 Plan for the Sprint. Product Backlog.
 Small teams (3 to 9 people)
 Assigned tasks are a bottleneck
 Working software every Sprint
 Contract is closer to T&E
- Likely not a fixed feature set
 Why Waterfall?
 Comes naturally

 Feels good to have a plan

 Tries to minimize uncertainty

 Pins down what's going to be build

 Helps manager manage

 Why Scrum / Agile?
 Comes naturally  "Forecast" vs. "Commitment"

 Embraces uncertainty  Estimation by the "do-ers"

 Empirical vs. Hope-driven  Self-organization by the "do-ers"

 Goal-based  Focuses on Done

Who’s Waterfall for?
Who likes Waterfall?
Ever seen a company that’s
Scrum at the top and
Waterfall at the bottom?
 Ben’s $0.02 Summary
 Waterfall doesn’t work
 Waterfall is based on a lack of trust
 Waterfall assumes incompetence &
laziness
 Waterfall assumes that you have to
drive or force your people to deliver
results
 The results are in: Scrum works
 Scrum assumes trust & collaboration
between “management” and the
team
 Scrum assumes competency
 Scrum assumes motivated people
who want to do a good job
 Why Do Waterfall People Think Agile-ists
Are Bonkers?
 Sandal-wearing anarchists  Developers are lazy

 Developer estimates are always  “The plan is flawless.”

wrong
 Developers write crummy,
 Developers are always late buggy code

“Too complex to not plan.”

 Why Do Agile-ists Think Waterfall People
Are Bonkers?
 Project plans tend to be imposed
- “Voluntold”

 Our estimates are probably wrong

- We have no idea

 There’s nothing to estimate anyway

“Too complex to plan.”

 Point of agreement #1:
Each side thinks the other is wrong.
Point of agreement #2:
The work is complex.
What’s going on here?
 Scrum vs. Waterfall:
Two different ways of managing complexity.
 Next up:
How do you make Scrum Under Waterfall work?
How to make Scrum Under Waterfall work?
How to make Scrum Under Waterfall
work good enough?
You know how people sometimes describe
two things that go together in
terms of food pairings?
 “That goes together like
chocolate and peanut butter.”
“Wine and cheese”
“Chips and salsa”
“Rice and rasam”
But then there are things that go together poorly.
“That goes together like cat food & garlic.”
Some things aren’t meant to go together.
“Romeo & Juliet”
 Scrum Under Waterfall is the
grumpy marriage of two processes.
Scrum Under Waterfall is everywhere.
How do you make the best of it?
 Why Does Scrum Under Waterfall Exist?
 It might not exist formally

 Required by contract?

 Required by law?

 Part of ‘The Agile Experiment’?

 Just because.
 Leverage the Strengths of Each
 Scrum for day-to-day dev/test activities

 Detect problems with Sprints

 Focus on DoD & working software

 Waterfall for multi-team coordination?

 Waterfall for release planning?

 What’s This Mean For Scrum?
Same Different
 Focus on ‘Definition of Done’  Backlog = Project Plan

 Daily Scrum  Less emphasis on Backlog

refinement
 Sprint Burndown
 Less emphasis on Sprint planning
 Sprint Review

 Less negotiation during Sprint

 Retrospective
 Things to Watch Out For
 Poor communication / misunderstandings

 Lack of transparency

 Detachment from reality

 Slow feedback / No feedback

 Nothing is Done
 Five Tips
 Work in Sprints

 Avoid 'earned value'

 Focus on Done

 Continuous Testing

 Invite Frequent Feedback

 Tip #1: Work in Sprints
 The Waterfall schedule might say 12 months

 Focus on Sprints of 30 days or less

 Take stock of where you are at the end of each Sprint

 Tip #2: Avoid ‘Earned Value’
 "I'm 72.6% done with my task."

 "The feature is 89.6% done."

 The first 80% takes 20% of the time.

 The remaining 20% takes 80% of the time.

 Tip #3: Focus on Done
 Create a Definition of Done (DoD)

 Work to DoD

 No earned value

 It's 'done' or it's 'not done'

 Tip #4: Continuous Testing
 Test throughout the virtual Sprints

 Build quality in from the start

 Don't leave testing until the end

 Tip #5: Invite Frequent Feedback
 Show off the Done software before it's actually due

 Gather feedback early

 Avoid the "feedback bomb at the end" syndrome

- Too late to change anything
 Remember that it’s two different processes.
Two different mindsets. Two different approaches.
 Next up:
Agile Transformations
Agile Transformation:
Not Scrum to Scrum
Corporate culture is hard to change.
“If it ain’t broke, don’t fix it.”
Don’t just go to Scrum because it’s cool.
Have a good reason.
 Growth & Maturity in Companies
 Phases of life just like people

 Childhood

 Adolescence

 Adult

 Middle-age

 Old age
 Change of Life  Scrum
 Startups  Mature Companies
- Done well - Done well
- Worked really hard - Been around for a long time
- Informal - They have process
- More employees - Ship big releases ever 12 – 24
- Growing pains months
- Not delivering anymore - New cheaper, faster competitors
- Need some process - Can’t adapt to market fast enough
Dr. John Kotter’s 8 Steps for Leading Change
 Kotter’s Process
1. Establish a Sense of Urgency
2. Create a Guiding Coalition
3. Develop a Vision & Strategy
4. Communicate the Vision for Change
5. Empower Employees to take action
6. Generate Short-Term Wins
7. Consolidate Gains
8. Anchor Changes into the Culture
 #1: Sense of Urgency
 Why do we need to change?

 Market realities

 Competitors

 Evidence
 #2: Guiding Coalition
 People with enough influence to lead the change

 Have them work as a team

 Scrum needs executive buy-in

 Scrum: Get a Product Owner and a Scrum Master (at least)

 #3: Vision for Change
 Create the vision

 Create strategies for achieving change

 Scrum: "Done working software in 30 days without requirements docs."

 #4: Communicate the Vision
 Evangelize the vision

 Tell stories

 Scrum: "Our vision is to build exactly the software that we need without the
waste."
 #5: Empower Employees to Take Action
 Remove obstacles to change

 Let the teams self-organize

 Help the teams to identify systems that are impeding change

 Scrum: Self-organization
 #6: Create Short-term Wins
 Reinforce that you're actually achieving something

 The wins motivate you towards new wins

 Scrum: "Whoa! We delivered real working software!"

 #7: Consolidate Gains
 Keep going!

 Recognize people who have made the improvements

 Reinforce the behaviors that brought the changes/improvements

 Scrum: more scrum; product backlog; sprint planning; more done, working
software; "wow…look at all that this team has accomplished!"
 #8: Anchor Changes into the Culture
 Help the changes to take root

 Make the changes part of the company's story

 Help make connections between the improvements and the successes of the
company
 Overall tip:
Don’t expect it to change overnight.
Keep working at it.
 Next up:
Scrum with Multiple Teams
Scrum says a team should be
3 to 9 people.
There’s only so much you can do with one team.
Sometimes you want or need to go faster
so you add more teams.
Multi-team Scrum.
Scaled Scrum.
 Challenges of Multi-team Scrum
 Coordination isn’t only on a single team anymore

 Plan around dependencies in the Product Backlog

 Manage around dependencies in the Sprint

 You have to integrate work from multiple teams

 Multiple Teams Add Complexity
 Are you 100% sure you need more than one team?

 If you have multiple teams now, are you 100% sure you need more teams?
- Could you do fewer teams?

 As you add teams, don’t expect to scale linearly

- One team with a velocity of 15
- Two teams probably not a velocity of 30

 You pay a “tax” for integration

 Done on One Team vs. Multiple Teams
 Single Team
- “It’s all about done, working software.”
- If it doesn’t meet the DoD, it’s not done.

 Multiple Teams
- “It’s all about done, working, integrated software.”
- If it doesn’t meet the DoD and if it isn’t integrated with the work of other teams,
it’s not done.
 Multi-team PBI Recommendations
 PBIs are done by one team in one Sprint

 Explicitly track dependencies between PBIs

 Create a team whose job is to make sure everything is integrated

 One Product Owner for all the teams

- One product  one Product Owner
 Integration Team
 Why? Because integration is its own
concern
Team 1 Team 2

 They supervise and advocate for the

integration Integration
Team

 They probably don’t do the integration

Team 3 Team 4

 They’ll have their own Daily Scrum

 Scrum Pretty Much Stays the Same

Sprint Sprint
Daily Scrum Sprint Review
Planning Retrospective
 Multi-team Sprint Planning
 All the teams or (at least) representatives from each team get together

 Product Owner shares the vision for the Sprint

 Representatives try to figure out dependencies

 Representatives try to figure out how to minimize cross-team dependencies

 Then full-teams go do their usual Sprint Planning meetings

 Integration Team’s Daily Scrum
 Not the same as a regular team’s Daily Scrum

 Not “3 Questions”

 Goal: Is the integration on track?

 “Did we have any trouble integrating yesterday?”

 “Are there any likely integration troubles facing us today?”

 This meeting is probably way less than 15 minutes long

 Multi-team Sprint Review
 Individual team Sprint Reviews are of diminished importance

 Show off the done, working, integrated software

 Gather feedback

 All the teams

 Multi-team Sprint Retrospectives
 Representatives from the teams come together

 Discuss and identify any cross-team problems and successes

 Representatives go into their regular Sprint Retrospectives

 Representatives meet again to discuss any additional findings that might

affect the next sprint
Next Sprint.
 Summary
 Be skeptical of adding more teams

 Explicitly track dependencies

 Create a team to advocate for the integration work

 Focus on done and integrated software

 Thanks!
www.benday.com
@benday