agile anywhere in the 21st century: setting up distributed teams to be effective
TRANSCRIPT
Agile Anywhere in the 21st Century
Setting Up Distributed Teams for Success
About the speaker
Name: Rose FanCompany: ThoughtWorksTitle: Lead consultantHats I Wear: - Delivery principal- Project manager- Scrum master- Business analyst
Location: DenverRecovering road warrior
Elevator pitch
For the practitioner who is already familiar with Agile, XP, and scrum practicesAnd who is currently working in or thinking about working in a distributed setting,This talk will cover real-world examples of distributed Agile software development teams and observed best practices within each variationIn hopes that the practitioner will walk away with an understanding of what an effective distributed Agile team looks like, and feels inspired to set one up him or herself.
My story6 years at ThoughtWorksTravel to client site Sunday through Thursday/Friday
→ This is so inefficient.→ We’re losing technical talent.
This is not a problem that is specific to consulting.Everywhere, there is fierce competition for technical talent.
Remote leaders
Terminology
Single-site/onshore/co-located team
Everyone on the team is in the same physical building or campus.
Ideal: everyone working in the same room. No cubes. Ancillary roles are a few steps away.
Multi-site
Two or more co-located groups at separate locations within a larger team, perhaps with sub-team boundaries and responsibilities.
Example: a development team that is split between Chicago and Dallas
Multi-site nearshore & offshore
Satellite work
Most of the team co-located, but a few members working remotely, either from home or in another office.
Remote
A working situation where an individual is physically located apart from others on the team.
Fully-remote/100% distributed
Everyone works in a separate location, usually from home, and all communication occurs online.Example: open-source projects
Distributed
Any style of working that is not single-site.
Distributed Agile - an oxymoron?
Distributed is not, in it of itself, an advantage
All else being equal, a single-site team will almost always work more effectively than a distributed team.
In-person conversations are best way to communicate among (most) teams, but cannot be prioritized unilaterally as the only way to enable individuals and interactions.
Intimacy Curve
Individuals and interactions
over processes and tools
Credit: Martin Fowler
prioritize getting the best people
helping them work well together
The turtle, the hare and the rocketAll else being equal, a given team will usually work more slowly when working in a distributed way.
But if distribution gives you access to more capable team members, they will be faster despite not being colocated.
Credit: Martin Fowler
Think about the best person you have ever worked with How did you feel when you interacted with them? Motivated, fortunate, inspired?
What would you do to keep working with them? Switch departments? Switch employers?
Would you want them on your team, even if you weren’t physically co-located?
People matter. Technical talent is scarce.The effect of even a single knowledgeable, capable team member - usually in some sort of team lead position - is contagious and can make or break the success of a project
- 10x programmer
Distributed teams are often used to minimize costs; what if they were used to maximize talent instead?
Three Examples
Example 1: Multi-site project
● Greenfield web app for Dallas-based Fortune 500 company
● Team of 8 in Chicago, 4 in Dallas + end-users and business stakeholders○ Same time zone
● Motivation for distribution: Tech lead in Chicago unable to travel
● Coaching/enablement was a desired outcome in addition to delivery○ Continuous integration, pair
programming, automated tests○ Sprint planning meetings,
retrospectives, prioritization
Tools used
Things that worked well
● Kicking off the project on-site together● Cross-location rotations (minimum 1 week/month)
○ Bi-directional travel● Core hours for pair programming● Not splitting up functionality by location● BAs and tech leads having at least daily check-ins● Demos of new features by person who anchored on its
development● Keeping a physical card wall in larger team location in
addition to a virtual wall● Coaching and enablement via pair programming and
lunch and learn sessions
Challenges and considerations
● Majority drowning out the minority● VPN, infrastructure blockers● Disagreements about tooling, tech
● Custom application for Fortune 50 organization based in Cincinnati, Ohio
● Team of 8 in Cincinnati, 12 in Bangalore● 10 ½ hour timezone difference● Motivator for distribution: drive down cost and access
talent that was not available locally● Delivery-focused; working to hit strict deadlines
Example 2: Multi-site offshore project
Tools used
Things that worked well
● Two daily stand-ups that were equally uncomfortable:○ 9 AM EST/7:30 PM IST○ 9 AM IST/10:30 PM EST
● Features divided by region● Some cross-location travel (>=2 weeks at a time)● Greater emphasis on documentation and
asynchronous hand-offs○ Wireframes, annotations○ JIRA comments ○ Confluence for feature wikis ○ Recording meetings
● Treating ourselves more like two teams collaborating very closely than one unified team○ Ran team-wide meetings mostly separately
Challenges and considerations
● Time zone/lack of overlap● English not everyone’s first language● Influencing client’s perception of offshore team
members as not just doers, but to also consider that team’s ideas and suggestions
● External barriers to travel (visas etc) ○ No luxury of spontaneous visits
● Creating cloud-native training material and workshops for client to run with their customers
● Team of 10 spread across→ SFO (4), ATL, JFK, DFW, DEN, ORD, ACC (Ghana)
● Motivator for distribution: access to SME talent
Example 3: remote-first project
Tools used
Things that worked well
● Weekly retros● Autonomy over tooling● Freedom to work from wherever
○ Lower commute time
Challenges and considerations
● Time zone● Motivation, learning of less experienced developers
○ Feelings of isolation● Decision-making/tie-breaking among SMEs
Platonic Ideal
People
Team size in any location does not exceed 9 members (2 pizza rule)
At least one business analyst, product owner or proxy who is empowered to make decisions in each location
One tech lead for the whole team; one dev lead for each location
Credit: Pat Sarnacke
Communications (hardware)
Basic infrastructure must be present: internet, VPN tunnels, etc
Videoconferencing screen (at least 32”) placed at eye level- Microphone muted, speakers left on
Desk phones with auto-programmed numbers
Dialing in via landline by default
Credit: Pat Sarnacke
Communications (digital)
Group chat with channels and integrations
E-mail, distributed groups, reply-all culture
Digital card wall with just enough documentation
Remote-first communication even among co-located parts of the team
Rotations
Rotations should happen regularly in both directions, with plenty of lead time and notice
Business analysts/product owners should rotate regularly between both locations
Other roles (QA, developers) should send a pair at a time, ideally at least 1x/month
Credit: Pat Sarnacke
Daily stand up/scrum
Stand up conducted via video conference, ideally with cordless microphone
Aim to keep to 15 minutes or less- Walk the wall- Informal tech updates and discussions happen after
stand up as technical huddle- For large teams, consider splitting stand ups and
having scrum of scrums
Credit: Pat Sarnacke
Sprint ceremonies
Backlog grooming sessions, iteration planning meetings over web conferencing
- Use screen sharing for the board/user stories and make it unmistakable what’s going on
- Add a quick note to the user story to describe changes or decisions
Showcases over video. Let both teams drive and let individual anchors talk about the story or feature, if they are willing.
Fun
Carve out time and budget for team events, especially on rotation
Bring back and forth local food, souvenirs, etc
Suggest attending conferences together
Common Mistakes
Abandoning pair programming
Ignoring satellite workers
Not budgeting for rotations
ahead of time
Staffing teams with individuals who do not
actively want to collaborate
Parting Thoughts
Comparison to single-site agile teams, distributed agile generally requires more...● scrum master and expert coordination & facilitation
skills● sharing by default
○ better to overshare and filter than leave parts of the team in the dark
● documentation● self-sufficiency and maturity
Mentorship to less experienced team members works best in-person
Consider Conway’s Law
Distributed motivators: autonomy, mastery, purpose
Empathy is crucial to the success of any distributed project
The Agile manifesto was written 15 years ago, when a lot of today’s tooling and technologies which enable distributed work did not exist.
Today, remote-friendly tooling is being developed and adopted faster than ever.
Distributed work will only get easier and more prevalent with time.
Further reading
The end - thanks!
P.S. ThoughtWorks is hiring!