Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Agile software development: Rapid growth & Distributed scrum

•
•
Maite Wetters
Maite Wetters

Three scrum teams were quickly scaled up across multiple locations as part of a distributed scrum project. This led to growing pains around talent acquisition, communication costs, onboarding new hires, and creating a sense of ownership among distributed teams. To address these, standardized hiring and onboarding processes were implemented, communication tools were improved, local team leads took on more responsibility to foster ownership, and initiatives like hackathons and transparency into career growth were used to promote bottom-up innovation. While distributed scrum brought challenges, focus on ownership among teams helped improve productivity and motivation.

1 of 26
Download to read offline
Think business ● Build Software
Rapid growth & Distributed scrum. Experience of quickly growing multiple distributed scrum teams and the lessons learned David Sampimon, Project Manager
ABOUT ME ● Project manager for GlobalOrange for the last 3 years ● Before GlobalOrange I worked as a videogame producer (mobile and browser based) ● Now mostly working on SaaS applications for various clients (real estate, health, events, local government) ● Over the past 1,5 years working on a distributed scrum project where we had to quickly scale the team
Smart sourcing.
Case. ● Formed a partnership with GlobalOrange for IT development in 2012 ● Back then a single scrum team ● Landed an investment in 2014 ● Over the period we grew from 6 to 20 people on our end (and the client themselves also grew the IT team with about 15 people) ● distributed scrum
● Product team ● DevOps team ● QA team ● 2 scrum teams ● Scrum Masters ● Team leads ● Scrum teams and team QA ● Scrum teams and team QA
Model in numbers. ● Four scrum teams ● Four Product Owners working in NL (client) ● One lead developer in NL per team ● Half scrum master in NL per team ● Five dev’s per team in EE ● One QA per team in EE
WITH RAPID GROWTH YOU WILL GET GROWTH PAINS. (but we know this already)
Risks. ● Talent management ● New hires ● On boarding ● (team) Motivation ● Communication ● Tooling ● Vision Sharing ● Bureaucracy ● Cost control ● Company culture ● Architecture ● Quality ● Maturity (process) ● Management feedback ● and more...
OFTEN UPFRONT MANAGING OF ALL RISKS RESULTS IN MICROMANAGEMENT.
….OR DON'T FIX IT IF IT AIN’T BROKEN (YET).
So which pain points did we experience? ● New hires ● Cost of communication ● Onboarding ● Friction between POs and team ● Spoon fed teams ○ Loss of bottom up innovation
New hires. ● Amsterdam, Romanian and Ukrainian IT labor market very competitive ● Aligned HR departments for a continuous talent acquisition, we were always searching for new talent and never replacements ● Invested in standardized CV format and assessments ● Introduced the same hiring process everywhere: ○ Local HR interview => local tech assessment => interview with PM and same role team member
Cost of communication. ● n(n − 1) / 2 ○ Team of 6 = 15 lines of communication ○ Team of 40 = 780 lines of communication ● The team spread out over four locations wasn’t helping. ● Downsized distributed operations in Ukraine in favor of Romania
Onboarding. ● Good onboarding process is crucial for maintaining motivated and performing team members or “You only get one chance to make a first impression” ● Standardize onboarding procedure with clear documentation into business case, workflow, company values, who is who, first day exercises and personal introduction
Friction between POs and dev team. ● Normal scrum process creates friction between POs and Dev, which is good. However, distributed scrum can push this friction too far ● Roadmap becomes crucial as an internal communications tool for alignment ● As a PO, don’t underestimate your expert knowledge of the system (too afraid to ask) ○ Write business case articles in confluence (wiki) ○ Invest in regular team presentations about the inner workings of your business
Agile software development: Rapid growth & Distributed scrum
Spoon fed teams.
Spoon fed teams. ● As a result of an unclear roadmap (internally) and the vision mostly living in the POs head, we experienced spoon fed teams ● Spoon feeding is killing the team in many ways ● We needed to get a mindset of ownership in the distributed teams
Micro Management Macro Management Co Ownership Followship X
Ownership. ● Promoted a local developer to team lead, the Dutch team leads became more (architecture) consultants ● Invested in more frequent visits (team leads to NL, quarterly presentations in Romania) ● Introduced a more BDD approach and involved the team lead or QA in the user story writing process (scenario’s) ● Promoted bottom up innovation
Bottom up innovation. ● One of the most valuable activities - for any tech project - is developer driven innovation ● Difficult to balance with bigger teams, especially distributed teams. Real risk of spoon feeding your team members ● Hackathons ● Allowance for refactoring on their own initiative
And also. ● Think about physical evidence amongst your outsourced team, it is cheap to just ship some cool banners and create a dedicated team room in their office ● Be transparent with your team members, talk about personal ambitions and growth. If you want over achieving outsourced teams you need to treat them as internal staff
What didn’t work. ● There is a trend to give the scrum master responsibilities to the team lead. In our case this didn’t work (match of personality) and was causing frustration in the teams. We now are back to having separate scrum master roles in the teams ● Scrum of scrum sessions worked great as a way of achievement sharing, but not so much for spotting cross team dependancies
Conclusion. ● Rapid growth and the distributed model can put a lot of pressure on productivity and motivation ● Pay special attention to whom you hire and how you onboard them ● Ownership with distributed teams makes everything better ● If you want super performance from your distributed team, be transparent and talk about their ambitions as if it is your own staff
Questions?

More Related Content

Agile software development: Rapid growth & Distributed scrum

  • 1. Think business ● Build Software
  • 2. Rapid growth & Distributed scrum. Experience of quickly growing multiple distributed scrum teams and the lessons learned David Sampimon, Project Manager
  • 3. ABOUT ME ● Project manager for GlobalOrange for the last 3 years ● Before GlobalOrange I worked as a videogame producer (mobile and browser based) ● Now mostly working on SaaS applications for various clients (real estate, health, events, local government) ● Over the past 1,5 years working on a distributed scrum project where we had to quickly scale the team
  • 5. Case. ● Formed a partnership with GlobalOrange for IT development in 2012 ● Back then a single scrum team ● Landed an investment in 2014 ● Over the period we grew from 6 to 20 people on our end (and the client themselves also grew the IT team with about 15 people) ● distributed scrum
  • 6. ● Product team ● DevOps team ● QA team ● 2 scrum teams ● Scrum Masters ● Team leads ● Scrum teams and team QA ● Scrum teams and team QA
  • 7. Model in numbers. ● Four scrum teams ● Four Product Owners working in NL (client) ● One lead developer in NL per team ● Half scrum master in NL per team ● Five dev’s per team in EE ● One QA per team in EE
  • 8. WITH RAPID GROWTH YOU WILL GET GROWTH PAINS. (but we know this already)
  • 9. Risks. ● Talent management ● New hires ● On boarding ● (team) Motivation ● Communication ● Tooling ● Vision Sharing ● Bureaucracy ● Cost control ● Company culture ● Architecture ● Quality ● Maturity (process) ● Management feedback ● and more...
  • 10. OFTEN UPFRONT MANAGING OF ALL RISKS RESULTS IN MICROMANAGEMENT.
  • 11. ….OR DON'T FIX IT IF IT AIN’T BROKEN (YET).
  • 12. So which pain points did we experience? ● New hires ● Cost of communication ● Onboarding ● Friction between POs and team ● Spoon fed teams ○ Loss of bottom up innovation
  • 13. New hires. ● Amsterdam, Romanian and Ukrainian IT labor market very competitive ● Aligned HR departments for a continuous talent acquisition, we were always searching for new talent and never replacements ● Invested in standardized CV format and assessments ● Introduced the same hiring process everywhere: ○ Local HR interview => local tech assessment => interview with PM and same role team member
  • 14. Cost of communication. ● n(n − 1) / 2 ○ Team of 6 = 15 lines of communication ○ Team of 40 = 780 lines of communication ● The team spread out over four locations wasn’t helping. ● Downsized distributed operations in Ukraine in favor of Romania
  • 15. Onboarding. ● Good onboarding process is crucial for maintaining motivated and performing team members or “You only get one chance to make a first impression” ● Standardize onboarding procedure with clear documentation into business case, workflow, company values, who is who, first day exercises and personal introduction
  • 16. Friction between POs and dev team. ● Normal scrum process creates friction between POs and Dev, which is good. However, distributed scrum can push this friction too far ● Roadmap becomes crucial as an internal communications tool for alignment ● As a PO, don’t underestimate your expert knowledge of the system (too afraid to ask) ○ Write business case articles in confluence (wiki) ○ Invest in regular team presentations about the inner workings of your business
  • 19. Spoon fed teams. ● As a result of an unclear roadmap (internally) and the vision mostly living in the POs head, we experienced spoon fed teams ● Spoon feeding is killing the team in many ways ● We needed to get a mindset of ownership in the distributed teams
  • 21. Ownership. ● Promoted a local developer to team lead, the Dutch team leads became more (architecture) consultants ● Invested in more frequent visits (team leads to NL, quarterly presentations in Romania) ● Introduced a more BDD approach and involved the team lead or QA in the user story writing process (scenario’s) ● Promoted bottom up innovation
  • 22. Bottom up innovation. ● One of the most valuable activities - for any tech project - is developer driven innovation ● Difficult to balance with bigger teams, especially distributed teams. Real risk of spoon feeding your team members ● Hackathons ● Allowance for refactoring on their own initiative
  • 23. And also. ● Think about physical evidence amongst your outsourced team, it is cheap to just ship some cool banners and create a dedicated team room in their office ● Be transparent with your team members, talk about personal ambitions and growth. If you want over achieving outsourced teams you need to treat them as internal staff
  • 24. What didn’t work. ● There is a trend to give the scrum master responsibilities to the team lead. In our case this didn’t work (match of personality) and was causing frustration in the teams. We now are back to having separate scrum master roles in the teams ● Scrum of scrum sessions worked great as a way of achievement sharing, but not so much for spotting cross team dependancies
  • 25. Conclusion. ● Rapid growth and the distributed model can put a lot of pressure on productivity and motivation ● Pay special attention to whom you hire and how you onboard them ● Ownership with distributed teams makes everything better ● If you want super performance from your distributed team, be transparent and talk about their ambitions as if it is your own staff