Lessons Learned from
Managing a Distributed Agile
Team
Dean Legatski
Sr. Director, Systems Development
PGi
ABOUT ME
• Leader in implementation of Agile development
for the Global IT group at PGi.
• Also leading a longer term continuous
integration/continuous delivery strategy
• Lead 5 development and test groups in 3
countries, 7 states and 11 cities.
ABOUT PGi
• PGi is the world's largest dedicated provider of
collaboration software and services.
4
THE HISTORY
• Current systems have evolved over 15+ years
• Significant technical debt
• Inability to pivot with the market
• Innovative culture with little patience for process
• Great ideas with little execution
• Poor relationship between IT and our business
5
THE CHALLENGE
New Program
Director
New CIO
• Overhaul our back office
• Replace our billing system
• Create an integrated ecosystem of
systems
• Build a world-class delivery
framework to get it all done
• Create speed, accuracy, and agility
in all of our business processes
3 things a new
CIO should
“never” do
BETS FOR THE FUTURE OF IT TEAMS
• Remote teams and workers will continue to grow
• Millennials will change the “office” paradigm – Less focus
on workspace ownership
• Always on tools – Presence, chat, video, content
Why agile?
• Rapid pace of learning
• Focus on the work at hand
• Discipline
• It was a step in the right direction
• Sustainable pace
• Easier Sell
• More fun!
WHY DISTRIBUTED AGILE?
• A-Players are not always co-
located
• Our customers (internal and
external) are distributed
• An in-place global workforce
• We are a global business
• Capturing resources from
acquisitions
9
COMPLICATIONS WITH DISTRIBUTED AGILE
• Time zones
• Low resource
engagement
• Lack of focus
• Difficult to build
transparency
• Challenges with
space & time
• Lack of visibility
• Difficult to build
trust
• Fear of change
• Cultural
differences
10
WHY SCRUM?
• New team
• Limited resources
• Broad application
• Small teams
• Better resource engagement
• Focus on current work (Sprint)
• Transparency is built in
• Proven success
• Well documented framework
• Continuous learning
• Definition of done
11
INTEGRATING THE HEART, HEAD, AND HANDS
Heart
Philosophy
Hands
Skilled People
Head
Methodology
Success!
12
Heart
Philosophy
Hands
Skilled
People
Head
Methodology
Success!
WITHOUT 360º COLLABORATION
13
COLLABORATION ENABLES DISTRIBUTED AGILE
Heart
Philosophy
Hands
Skilled People
Head
Methodology
Success!
14
LESSON 1: EVERYONE HAS TO PLAY BY THE SAME RULES
• If 1 person is not co-located, then everyone has
to “dial in”.
• Use video cameras in order to increase
engagement and reduce multi-tasking.
15
DESKTOP VIDEO
16
DESKTOP VIDEO “PLEASE STAND-UP!”
17
LESSON 2: ARTIFACTS HAVE TO BE ACCESSIBLE
• Everything that is agreed to should be written and
shared.
• This covers whole life cycle of intake, planning,
working, and retrospectives.
18
SPRINT BOARD AND BACKLOG ACCESSIBLE
19
DEMO RECORDINGS AND RETROSPECTIVES
STATUS
21
INTAKE PROCESS
22
LESSON 3: NEED A STRONG SM AND BA
• If the Scrum Master doesn’t see movement on a
story, they need to be reaching out to see what is
going on.
• There is no way you can succeed if your stories
are not well defined with explicit acceptance
criteria.
23
DETAILED DATA IN STORIES
24
LESSON 4: STILL GOOD TO HAVE TOGETHERNESS
• When possible, it is beneficial to bring group
together for kick-offs or major milestones.
• Not only important for team, but for stakeholders
as well.
25
FACE TIME AND SOCIAL GRAZING
26
LESSON 5: NO EASY WAY TO FIND GOOD HELP
• True if everyone together as well, but much
harder if trying remotely.
• Some luck with senior developers and
recommendations.
• More success if they had at least one other
person working close to them.
27
VIDEO INTERVIEWS
28
CANDIDATE “PIT” SESSION
29
CONCLUSION
Remote Agile is not impossible, but that does not
make it easy. If you have skilled people, hopefully
who have worked together before, you still can
have an efficient Scrum Team. You still have all
the same challenges that you would have with
other Agile teams, but it expands your possible
options!
30
NEXT STEPS
Connect with me on LinkedIn
31
Q&A……

Lessons learned from managing a distributed agile team

  • 1.
    Lessons Learned from Managinga Distributed Agile Team Dean Legatski Sr. Director, Systems Development PGi
  • 2.
    ABOUT ME • Leaderin implementation of Agile development for the Global IT group at PGi. • Also leading a longer term continuous integration/continuous delivery strategy • Lead 5 development and test groups in 3 countries, 7 states and 11 cities.
  • 3.
    ABOUT PGi • PGiis the world's largest dedicated provider of collaboration software and services.
  • 4.
    4 THE HISTORY • Currentsystems have evolved over 15+ years • Significant technical debt • Inability to pivot with the market • Innovative culture with little patience for process • Great ideas with little execution • Poor relationship between IT and our business
  • 5.
    5 THE CHALLENGE New Program Director NewCIO • Overhaul our back office • Replace our billing system • Create an integrated ecosystem of systems • Build a world-class delivery framework to get it all done • Create speed, accuracy, and agility in all of our business processes 3 things a new CIO should “never” do
  • 6.
    BETS FOR THEFUTURE OF IT TEAMS • Remote teams and workers will continue to grow • Millennials will change the “office” paradigm – Less focus on workspace ownership • Always on tools – Presence, chat, video, content
  • 7.
    Why agile? • Rapidpace of learning • Focus on the work at hand • Discipline • It was a step in the right direction • Sustainable pace • Easier Sell • More fun!
  • 8.
    WHY DISTRIBUTED AGILE? •A-Players are not always co- located • Our customers (internal and external) are distributed • An in-place global workforce • We are a global business • Capturing resources from acquisitions
  • 9.
    9 COMPLICATIONS WITH DISTRIBUTEDAGILE • Time zones • Low resource engagement • Lack of focus • Difficult to build transparency • Challenges with space & time • Lack of visibility • Difficult to build trust • Fear of change • Cultural differences
  • 10.
    10 WHY SCRUM? • Newteam • Limited resources • Broad application • Small teams • Better resource engagement • Focus on current work (Sprint) • Transparency is built in • Proven success • Well documented framework • Continuous learning • Definition of done
  • 11.
    11 INTEGRATING THE HEART,HEAD, AND HANDS Heart Philosophy Hands Skilled People Head Methodology Success!
  • 12.
  • 13.
    13 COLLABORATION ENABLES DISTRIBUTEDAGILE Heart Philosophy Hands Skilled People Head Methodology Success!
  • 14.
    14 LESSON 1: EVERYONEHAS TO PLAY BY THE SAME RULES • If 1 person is not co-located, then everyone has to “dial in”. • Use video cameras in order to increase engagement and reduce multi-tasking.
  • 15.
  • 16.
  • 17.
    17 LESSON 2: ARTIFACTSHAVE TO BE ACCESSIBLE • Everything that is agreed to should be written and shared. • This covers whole life cycle of intake, planning, working, and retrospectives.
  • 18.
    18 SPRINT BOARD ANDBACKLOG ACCESSIBLE
  • 19.
    19 DEMO RECORDINGS ANDRETROSPECTIVES
  • 20.
  • 21.
  • 22.
    22 LESSON 3: NEEDA STRONG SM AND BA • If the Scrum Master doesn’t see movement on a story, they need to be reaching out to see what is going on. • There is no way you can succeed if your stories are not well defined with explicit acceptance criteria.
  • 23.
  • 24.
    24 LESSON 4: STILLGOOD TO HAVE TOGETHERNESS • When possible, it is beneficial to bring group together for kick-offs or major milestones. • Not only important for team, but for stakeholders as well.
  • 25.
    25 FACE TIME ANDSOCIAL GRAZING
  • 26.
    26 LESSON 5: NOEASY WAY TO FIND GOOD HELP • True if everyone together as well, but much harder if trying remotely. • Some luck with senior developers and recommendations. • More success if they had at least one other person working close to them.
  • 27.
  • 28.
  • 29.
    29 CONCLUSION Remote Agile isnot impossible, but that does not make it easy. If you have skilled people, hopefully who have worked together before, you still can have an efficient Scrum Team. You still have all the same challenges that you would have with other Agile teams, but it expands your possible options!
  • 30.
  • 31.

Editor's Notes

  • #3 More certifications than I know what to do with: PMP, CSM, SFDC Admin, TOGAF Architect Come from a waterfall background. First experience with Agile was a company that basically renamed all their waterfall processes with agile names and called it good. Agile never took off.
  • #4 We created iMeet®, an expanding portfolio of purpose-built applications including: Web, video and audio conferencing Smart calendar management Webcasting Project management Sales acceleration I’m explaining this now so you’ll understand the irony of us working for a collaboration company and not adopting virtual tools sooner in our process.
  • #5 Everything is an event Ideas are easy execution is hard Enterprise changes that should take minutes take days or even months
  • #6 Program Director told new CIO about problems with systems that needed fixing in order for the company to grow, so the CIO put him in charge of making it happen! Went through a lot of thought before making the decision to do Distributed Agile.
  • #7 More remote workers – companies need to meet the employees where they are
  • #8  When you are doing the impossible you should “do agile” It’s like saying “cloud” as an answer to high hardware cost This is rarely ever the case. We had to implement a philosophy and drive a cultural shift. Need focus and discipline and a well documented and trainable framework – so we used SCRUM and called it Pgility. Presentation is based on our implementation of Agile, so if you have questions regarding specific ceremonies or processes, please ask.
  • #10 Cultural Time zones Lack of visibility Low resource engagement Lack of focus Difficult to build trust and therefor transparency Fear of change Collaboration over distance and time is not easy (space and time) Resource churn
  • #11 We knew we would eventually evolve but we had to start with a very rigid framework. There are many other useful approaches XP, Lean, Kanban. Well documented framework Follow the guidelines Ceremonies Sacred Sprint
  • #15 Always hate having meetings where everyone else is in a room having side conversations. Do not create Us v. Them
  • #18 No more storing everything on Scrum Master’s desktop, or using sticky notes on a wall! Not just team is remote, but often stakeholders are as well.
  • #19 No more boards with sticky notes. Good news is, can get a lot more information on the soft boards than on a sticky note!
  • #21 Stand-ups are not status reports. Need place for management and stakeholders to go to know what is going on. No longer send status to email distro and know that everyone is covered.
  • #22 Project Intake became HUGE! Nothing was getting done in legacy groups since everyone was supporting legacy users. With intake, we have a way to direct people to make requests, let them know what we expect for them to get worked and where they are in the queue (if they are accepted).
  • #23 Active Scrum Master vs. Passive. Not just running the ceremonies, but has to push for the developers in order to remove roadblocks. Being a good cheerleader doesn’t hurt!
  • #24 You can never have too much information in the description, comments or acceptance criteria.
  • #25 Difficult to establish relationships remotely, but possible to maintain them. Much like real life!
  • #26 As part of our transformation, we developed a framework we call PGility. As part of the framework, we brought all of the teams to Atlanta for their first sprints together (sprint 0) and used it as a training sprint. After spending that much time working together, they developed trust in each other.
  • #27 No way to bring a new person up to speed if they are remote and don’t know organization’s people and processes. Person needs to be a good communicator, and willing to say if they need help.
  • #28 Tried doing interviews using video. Developed a better feel for candidates, but still superficial
  • #29 Definitely weed out the weak with a pit interview to show technical skills. Only helpful if they can come into an office, though.