Succeeding With Agile-Software Development Using Scrum

Succeeding With Agile: Software Development Using Scrum
Outside Development Affects
Human Resources
Performance Reviews
Eliminate individual factors
how did the individual effectively manage
tasks within budget and timeline
Include teamwork factors
Helps the team finish tasks within the timeline
effectively applies retrospective items and helps
others do the same
Review more frequently than anually
Career Paths
Scrum masters may rotate through different
teams of importance
Development team members may also rotate
through different teams to share technical
knowledge
Role may also change on the team and initial
tester/designer may rotate to bigger
architectural inputs and implementation later
on in the team
Distributed Teams
Create Coherence
Acknowledge Significant Cultural Differences
Power Distance Index (PDI)
Individualism (IND)
Achievement Orientation (ACH)
Uncertainty Avoidance Index (UAI)
Long-Term Orientation (LTO)
Acknowledge the Small Cultural Differences
Strengthen Funcationl and Team Subcultures
Communicate and Establish a Shared Vision
Reach Agreements
Build trust by emphasizing early progress
Focus on tasks first
After learning about eachother with task
progress and completion focus on relationship
building
Get Together in person
Seeding Visits
Maybe even seeding the first sprint
Contact Visits
Focus around a task but the goal is relationship
building
One week visit for every couple of months
Traveling Ambassadoors
Semi Permanent team member
Stays for several months
Rarely used this way so settle for shorter but
more often visits
Communicates Gossip
Not malicious rumors
Personal details that which aren't discussed in
formal meetings
'Fernando's baby took her first steps last night'
Communicate lessons learned
Change How You Communicate
User Stories
Supplement with some more detail
&Send a long a test&
Add a high level test case that indicates if the
story is complete
Encourage Lateral Conversion
Combats the 'mum' effect
Include time for small talk
Start telecons with chit chat
Encourages culture and a better mood for the
call
Telecons
Share the pain
Change meeting times monthly to make it fair
among team members
Have some meetings all by telecon, even the
local members to show how difficult the phone
call can be to stay engaged
Tell Everyone who is talking
State your name before speaking
Have low-fidelity video conferencing
Have pictures with names and have someone
hold it up when they recognize the persons
voice
Sprint Planning
The Long Phone Call
Two Calls
Scaling Scrum
Scaling the Product Owner
Keep a PO responsible for no more than 2
teams
Scaled Roles
Chief Product Owner
Product Line Owners
Product Owners
Working w/ a Large Product Backlog
One Product, One Product Backlog
Keep to a Reasonable Size
100-150 responsible items
Robin Dunbar research
Use eipcs and themes
Use different views
Can have more than 150 but not in a single
responsible view
Proactively Manage Dependencies
Do Rolling Lookahead Planning
At the end of Sprint Planning
Spend a few minutes discussing what each team
will do in the next couple of sprints
Help identify dependencies early
Hold a Release Kickoff Meeting
Roughly plan 3 months out and discuss those
goals with all teams so that everyone starts out
on the same page
Share Team Members
Part time team members
Use an Integration Team
Best on projects with ten or more teams
First goal is to analyze nightly build and solve
any nightly build problems with the teams
involved
Integration Team Member at every other teams
standard meetings
Coordinate Work Among Teams
Scrum of Scrums Meeting
1 team member chosen by the team
if small # of teams perhaps 2 from each team
chosen members can rotate
Recursive; multiple levels of scrum of scrums
Frequency
Don't need to be daily
Dont need to be timeboxed to 15min
15 min may often be sufficient but block off 30-60m
Are problem-solving meetings
If the right people are in the meeting solve the
problem then and there
Agenda
What has my team done since we last met that
could affect other teams?
What will my team do before we meet again that
could affect other teams?
What problems is my team having with which it
could use help from other teams?
No personal names used during this part
As needed: Resolve problems and discuss items
on an issues backlog
Names can be used here to solve the problems
Synchronize Sprints
Staggering sprints are a horrible idea
Never a time when all teams are done
difficult to actually release the product
difficult to share team members or even just ask
others for help
2 or 3 day stagger is acceptable on a large
project
Allows members to attend multiple meetings
Remote members can attend all potentially
useful meetings
Scaling Sprint Planning
Stagger by a Day
Works for projects up to 9 teams
The Big Room
Big room with all teams split into their own
'corners' and have normal individual sprint
planning meetings
Use nautical singaling flags for communication
Need architect
Need PO
Time to order Lunch
On a Break
Cultivate Communities of Practice
'Test Community', 'programming community'
'ScrumMaster community', 'UI Community'
Virtual Architecture Team (VAT)
Can span more than one project
Sprint
Keep Timeboxes
Teams benefit from a regular cadence
Sprint planning becomes easier
Release planning becomes easier
Never Extend
Discourages the commitment
Don't Plan on Overtime to Salvage a Plan
Leads to poor quality
Developers are forced to cut corners to meet
poor estimates
Work a Sustainable Pace
XP Rule:you can't work a second week of
overtime
If needed, the project has a big problem
The only acceptable overtime is team concluded
and desired overtime
If a commitment has too much focus the team
will not commit to what they can do but often
much less to confidently commit
Add Energy vs Overtime
Increase the passion around the project
Pomodoro technique
5 min breaks to every 25 min of work
Favor Scope Changes
Alternatives
Cut Quality
Add Resources
Extend the Schedule
Shrinking scope is often acceptable to everyone
and can have huge benefits and keep a project
productive
Product Backlog
Written Document Negatives
can make you suspend judgement
Leads to lack of conversation over meaning and
overuse of assumptions
decrease whole-team responsibility
Use User Stories
As a <type of user>, I want <some goal> so that <some reason>
Promise to have a future discussion; not every
detail required
Team should practice communication skills
w/ PO to speak about business not all
technical
Add detail over time
Conditions of Satisfaction
Acceptance Criteria
Emergent Requirements are encouraged
Iceberg
Tip is known
Everything under water we know is there and its
a lot but its not very detailed, we will get to it
later
Grooming
10% of effort in each sprint
Why progressively refine
Things will change
Priorities shift
New needs are discovered or solved
There's no need
Items may be obsolete or unnecessesary as the
project progresses
Time is scarce
Allows decisions to be made at the optimal time
Allows to make course changes
avoid falling into trap of believing our plans
Should be 'DEEP'
Detailed Appropriately
Estimated
Emergent
Prioritized
Team
Two Pizza Team
Smaller Teams
Less social loafing
Constructive interaction
Less time spent coordinating
Higher Participation
More satisfying to the team
Less chance for harmful over-specialization
Productivity
Small teams are much more productive
Large teams complete projects on average 12
days sooner than small teams
Costs a lot more money and has a lot more
defects
Favor Feature Teams
Feature Team Benefits
Better able to evaluate design decisions
Reduce waste
Ensures the right people are talking
Less risk to the schedule
Keeps focus on delivering features
Consider Component Teams ONLY if
Component team will build something that will
be used by multiple feature teams
Desire to reduce the sharing of specialists
Often feature teams run specialists thin they
can't really be utelized in code
Risk of multiple approaches outweighs
disadvantages of component teams
Multiple feature teams may need to solve the
same problems in a sprint and thats a big risk of
duplicated effort
You can see an end to the need for component
teams
Right People on the Team
Include all needed disciplines
Balance technical skill levels
Balance domain knowledge
Seek Diversity
Don't want teams that come to quick conclusions
Want teams that think through their conclusions
thoroughly
Consider Persistence
Try not to multitask teammembers
Total work decreases the more required to
multitask
Better to have a few members multitask a lot,
than have the whole team multitask a little
Don't start a new project until it can be fully
staffed
Technical Practices
Test Driven Development (TDD)
Evidence it takes 15% longer
Initial bugs reduced by over 25%
long term bugs reduced ~ infinte
Try 'gang programming' for training
4-8 devs, 1 laptop, projector, pass the
laptop every 15m
Refactoring
Objections
If written/designed well wouldn't need it
like saying if cars were made better, wouldn't
need an oil change
Opportunistic Refactoring
Always leave the code better off than you found
it
Collective Ownership
Ensure no dev becomes to specialized he can
contribute only in one area
Make certain that no area becomes so intricate
that it is understood only by one dev
Good ideas in one part of the application are
more quickly proagated to other areas
Objections
Development is faster if each person owns one
part of the system
in a very short term project probably
long term project not true at all
Continuous Integration
Nightly builds 100% essential
Continuous nearly a must have
no manual effort
Pair Programming
Objections
Costs two devs to do the job one one
Costs are deceiving
Lower defects and quicker to market outweigh
man hours cost
In a hurry, we can't pair
this is the most important time to pair then
You don't want to do the same job three times
Do the job once, right, you don't need to repeat
it
Studies prove your faster to market when pairing
Two team members at a single computer actively
working tasks
Can increase time to complete tasks by 10-15%
Number of bugs reduced by over 50%
Takes longer to do a task correctly than
incorrectly
Design: Intentional yet Emergent
Emerging design is more productive than
waterfall design
Requires rework often
With sound technical practices like TDD, rework
is easy and fast
Rework leads to a best design to the project
while upfront design can't successfully change
without rework
Quality/Testing
Why testing at the end doesn't work
It is hard to improve the quality of an existing
product
Mistakes continue unnoticed
State of the project is difficult to gauge
Feedback opportunities are lost
Testing is more likely to be cut
Test Automation Pyramid
UI
Brittle
Expensive to Write
Time Consuming
Service
Unit
Roles
Scrum Master
Personal Trainer Analogy
They have the authority to keep you on the right
track with the right exercises
Ultimately has no authority over you. You
make your own decisions on what to do
Keep team focused on goal
&we're supposed to deliver potentially shipable
software. What do we need to do next time to
get that?&
CAN'T tell the team what to do
Not &Tod reviews all code from now on&
Therefore is not responsible if the team fails
But should help them have the conversations to get them back on track
Attributes of Good Scrum Master
Responsible
Humble
Collaborative
Needs to create a collaborative environment
for the team
Almost like a good teacher
Be willing to do what is necessary to open the
team up and communicate effectively
Committed
Influential
Clever and effective influence to get a team to
try new things
Not a 'because I say so' style
Influence others outside the team to help
overcome roadblocks
Knowledgeabble
Tech leads != Scrum Master
teams should not have tech leads
tech leads often make better team members
Scrum Master does not have authority of the
team so don't try to keep that authority by
becoming the scrum master
&my way or the highway& leads are bad Scrum
Master candidates
Product Owner
Responsibilities
Providing Vision
Providing Boundaries
Need x by June
Needs to run at twice the speed
Focused on Return on Investment (ROI)
Represents the interests of the stakeholders
Each team needs exactly one product owner
Team of Product Owners for larger projects
Needs to be one person per team, not a
committe
If a PO team members feels uncomfortable
answering, there has to exist a PO lead to
make the decision, not a committe
Attributes of Good Product Owner
Available
Business-savvy
Communicative
Decisive
Empowered
Team Member / Programmer
'OK' to have specialists, best to have the team
work across the board
Need to become active participants in product
requirements
No longer being told what to do, need to
understand what needs to be done
Overcoming Resistance
Skeptics
Provide training
Solicit peer anecdotes
Appoint champion skeptic
Acknowledge the skeptic and go to him for
alternate views to further conversation and
tackle issues
Push the issue
Challenge the skeptic to come up with iterative
steps to solving the skeptic outlook
Let time run its course
Saboteur
Success
Prove success on diverse projects
Reiterate and reinforce the commitment
Move them
To a different project
To a different type of role
bye bye
Fire them
bye bye
Diehards
Align incentives
They are diehards for a reason use that
Create dissatisfaction with the status quo
Acknowledge and confront fear
Followers
Change the composition of the team
Praise the right behavior
Involve them
Identify the true barrier
Pilot Project
Pilot != to decide to do it
Pilot = forge the way to understand the
best approaches at the company
Picking best pilot project
Duration
Whatever is near the 'middle' of what is normal
Ideally ~3-4 months
Size
Single Collcoated Team
It may grow over time
Keep growth under 5 teams
Importance
Choose an important project
Gives it best chance to over come roadblocks
and not be called a unique/special case
Business sponsor engagement
A good sponsor can help overcome
external roadblocks
Can champion the successes across the
company
Manage Expectations
Most teams will over commit
Most teams will be more useful
Poor teams will get good fast
Good teams may slow down at first, and be
great in the end
Initial predictability will be poor
Estimates will start out poor
Teams take a few sprints to find a sustainable
pace
Level of involvement
PO and stakeholders have significant roles for
the team to be successful. Don't underplay
their need.
Iterate Toward Agility
Use Scrum to Apply/Adopt Scrum
Improvement(Product) Backlog
Example Items
Enable teams to implement CI
Create Awareness of Scrum on each Team
Figure out how to make sure each team has a
PO
Multiple backlogs for large companies
Enterprise Transition Community (ETC) (The
Team)
Daily Scrums encouraged, not as important as
development scrum teams
Responsiibilities
Articulate the context
Stimulate Conversation
Provide resources
Set appropriate aspirations
Engage everyone
Sponsor (PO)
Probably an experienced PO, this is new
Doesn't have to be the sole PO, the ETC can
help heavily
Does need to be committed and apply time
Needs to be senior management/partner/co
founder to help adoption
Form Improvement Communities
Like sub ETC teams where the/an ETC member
is the PO
Spreading Scrum
Split and Seed
Split a team after a few sprints into two teams,
mixing the new teams with 'other' (new or
otherwise) team members
Can add teams quickly
But destroys teams just starting to jell
Grow and Split
Grow a team into a large team, and then split
the team into two teams.
Continue to grow those teams and split again
Keeps teams together (mostly)
Most natural
This would happen as projects grow
Internal Coaching
Successful team member helps another team
while continuing to work on the original team
Keeps teams together entirely
Coaches can be hand selected
Can move from one team to another
Attends:
Sprint Planning
Review
Retrospective
1 Daily Scrum a Week
2 hours a week for other help
Becoming Agile is Hard
Why Transition is Hard
Successful change is not entirely top-down or
bottom-up
The end state is unpredicatable
Scrum is pervasive
Scrum is dramatically different
Emergent Design vs Waterfall
Change is coming more quickly than ever before
Best practices are dangerous
Each business has different needs, thus
different practices
Cannot plan every project with a rule book or
best practices
Why it's worth the effort
Higher Productivity and lower costs
Improved employee engagement and job
satisfaction
Faster time to market
Could go to market after every sprint if desired
Higher quality
Improved stakeholder satisfaction
What we've been doing no longer works
Leading a Self Organizing Team
Containers
Change containers
How does the team make decesions, change it
Phyiscal space of the team
Differences
Ensure teams are diverse amplify differences
Exchanges
Change how an exchange occurs
Add or remove people from exchange
Different meetings between different people
Influencing Evolution
Select the External Environment
Define Performance
Manage Meaning
Energize the System
Give clear and elevating goals
Crerate Project Charter
Write product review and eleveator statement
37