Surviving 120% Team Churn

AuthorsTodd Sedano Paul Ralph Cécile Péraire

Surviving 120% Team ChurnSustainable Software Development through Overlapping Pair Rotation

(photos licensed or ©Todd Sedano)

2Newsletter Signup:http://sedano.org/research

Todd Sedano [email protected]

photos used with permission


Why?

4Todd Sedano [email protected]

Newsletter Signup:http://sedano.org/research


1. Team losing information

2. Learning curve for new developer






B

EA

C

D

F

Knowledge


A



B

E

C

D

F

Knowledge

Knowledge Leaving




B

E

C

D

F

Knowledge

New Employee


We want to spread knowledge throughout the team



Research Method

10

Constructivist Grounded Theory Iterative approach to data collection, coding, and analysis

Data Sources1) participant observations of five projects2) interviews with 21 software engineers, interaction designers,

and product managers

Interviews were transcribed, coded, and analyzed using constant comparison

Research Question: “How do the observed teams develop software effectively while overcoming team disruption?”



Research Context: Pivotal LabsMission: a) Deliver highly-crafted software b) Provide a transformative experience for client and combine client engineers with pivotal engineersProject team sizes: 2 to 28 devs (6 is common)Balanced team: interaction designer, product manager, devsMethod: Extreme Programming



Project Quattuor

13

Original Staffing Plan



Week # of the Project

Dev

elop

ers

Allo

cate

d

Actual Staffing Plan



Theory of Sustainable Software Development

16


Mitigates negative disruption effects by 1. Spreading knowledge around the team2. Writing “well-factored” code




Increases the ability of any pair to work on any story in the backlog



Sustainable Software Development3 Principles3 Policies3 Practices for Removing Knowledge Silos3 Practices for Caretaking the Code



ESEM 2016

PrinciplesEngendering Positive Attitudes Toward Team Disruption

“Team members go out of their way to make new teammates feel welcome and help ramp them up.”

Encouraging Knowledge Sharing and Continuity

“Everyone has context. Everyone is constantly communicating about the entire system.”

Caring about Code Quality

“Everyone is responsible for fixing issues.”



PoliciesTeam Code Ownership Increasing the ability to change any of the team’s code“I feel ownership of the code as a whole. I feel empowered to work on any part of the codebase.”

Shared Schedule Working the same hours whenever possible

Avoid Technical Debt “Thinking that someone else will fix it can be dangerous,because then nobody will do it.”



Removing Knowledge Silos PracticesContinuous Pair Programming Pairing whenever possibleIncreases Team Code Ownership

Overlapping Pair Rotation Rotating one partner on each track of work “This reduces knowledge silos and reduces the bus factor. We do not want the departure of one developer to cripple the project.”

Knowledge Pollination Sharing information in unstructured ways




Example: Removing Knowledge Silos



Individual Code Ownership



A B C D E F

Knowledge Gap

Knowledge Transfer

Continuous Pair Programming



A B C D E F

Knowledge Gap

Knowledge Transfer

Overlapping Pair Rotation



Knowledge Gap

Knowledge Transfer

A B

D

CF E

StrategiesOptimizing for people rotation Optimizing for personal preferences Optimizing for context sharing

Knowledge Pollination



Knowledge Gap

Knowledge Transfer

A B

D

CF E

Knowledge PollinationContributing to knowledge sharing in an un-structured way Daily stand-up meetingsWeekly retrospectivesWriting or sketching on whiteboardsOverhearing a conversationUsing the backlog to communicate current status about a storyCalling out an update to the entire teamSimply reaching out to team to ask a question



A B

D

CF E


Example: Strategies for Rotation



Four Tracks of Work



Track 1 Track 2 Track 3 Track 4

Icons designed by Freepik

Individual Ownership



Day 1 BobAlicea a

Day 2 BobAliceb b

Day 3 BobAlicec c

Day 4 BobAliced d

Alice Bob

b

aa

d

c

Generated KnowledgeAfter Four Days

c

d

b

Optimizing for Personal Preference



Day 1 BobAliceaa

bbDay 2 CarolAlice

ccDay 3 DanAlice

ddDay 4 ErinAlice

Alice Bob

a

b

a

d


c

d

c

bI’m enjoying this track

Optimizing for People Rotation



Day 1 BobAliceaa

bbDay 2 CarolBob

ccDay 3 AliceCarol

ddDay 4 ErinAlice

Alice Bob


a

c

d

b b

d

a

c

Bob Carol

bb

d

a a

cc


d

Optimizing for Knowledge Sharing



Day 1 BobAliceaa

bbDay 2 CarolBob

ccDay 3 DanCarol

ddDay 4 DanCarol

Has enough context been

shared?

YesYes

YesYes

YesNo


shared?


shared?

Example in Practice



Caretaking the Code Practices TDD / BDD Write unit tests before creating a design or writing code Creates a safety net“Allows me to change code without breaking everything”

Continuous Refactoring Systematic improvement of the code base Enables any pair to work on any part of the system

Supported by Live on Master “Use frequent commits and always rebase”



Sustainable Software Development


Principles Policies

Engendering Positive Attitudes Toward Team DisruptionEncouraging Knowledge Sharing and Continuity Caring about Code Quality

Team Code Ownership Shared ScheduleAvoid Technical Debt


Removing Knowledge Silos Practices Caretaking the Code Practices

Continuous Pair ProgrammingOverlapping Pair RotationKnowledge Pollination

TDD / BDDContinuous Refactoring Supported by Live on Master

ESEM 2016

Team Code Ownership

38

Team Code Ownership paperAvailable at ResearchGate.com



http://researchgate.com

Team Code Ownership Collective Ownership (Beck 2000)“Anyone can change any piece of code in the system at any time”

aka Shared Code (Beck 2004), Collective Code Ownership (Fowler 2006)

Team Code Ownership (Sedano 2016)“the ability for any developer on a team to change any of the

team’s code”



Team Code OwnershipIs more than a policy statementIs a complex interactionIs an emotional, qualitative attribute Eroded by some eventsBolstered by some practices Is a spectrum



Individual Team

Five Observed Factors Affecting Ownership

1. System Context2. Code Contribution3. Code Quality4. Product Fit5. Team Cohesion



LimitationsResearcher bias: With participant-observer, the researcher may

lose perspective and become biased by being a member of the team

Prior knowledge bias: may also blind the researcher to alternative explanations

We mitigated these risks by recording interviews and having the second and third authors review the coding process

External Validity: grounded theory is non-statistical sampling research (results might not apply to different software cultures)



Conclusion

44

Summary1. Introduce Sustainable Software Development Theory



Summary2. The theory extends our understanding of Extreme Programming

3. Mitigates the negative effects of major disruptions by i. Spreading knowledge around the teamii. Writing “well-factored” code



ConclusionPrimary benefits to the software developer Understand the team’s codeWork on any storyIncreased teaching opportunities

Primary benefit to the employer is business agility Team continues to deliver “quality software effectively” while

surviving disruptions





photos used with permission

Thank You!

49

Sustainable Software Development paper

50

Available at ResearchGate.com




http://researchgate.com

http://sedano.org/research

Discussion

51

Surviving 120% Team Churn

Technology

Transcript of Surviving 120% Team Churn