Recommended
Recommended
More Related Content
What's hot
What's hot (16)
Similar to Distributed teams maximising your chances of success
Similar to Distributed teams maximising your chances of success (20)
Recently uploaded
Recently uploaded (17)
Distributed teams maximising your chances of success
- 1. Distributed Teams Maximising Your Chances Of Success Tom Reynolds Copyright © 2015 The Agile Mindset Ltd
- 2. @tomjreynolds uk.linkedin.com/in/tomjreynolds Agile Coach & Trainer Organisational & Relationship Systems Coach International Conference Speaker 25+ years in software development Multi Certified Trainer Agile since 2007 © 2017 The Agile Mindset Ltd Tom Reynolds
- 3. Collaborating Co-Located Team 1 UK Poland Team 2 Images from Visual AGILExicon a trademark of Innolution LLC & Kenneth S Rubin
- 4. Deliberately Distributed Team 1 UK Team 1 Poland Team 2 UK Team 2 Poland Images from Visual AGILExicon a trademark of Innolution LLC & Kenneth S Rubin
- 5. Single Team Fully Distributed Images from Visual AGILExicon a trademark of Innolution LLC & Kenneth S Rubin
- 6. Our Goal A harmonious team that works as effectively as a co-located team delivering a single goal as one cohesive unit
- 7. In case you need to edit Start the right way Create shared working experiences Create shared social experiences Build trust Working Together On-Site
- 8. Create The ConditionsTeam Start Up’s Shared vision Expectations for high performance Working agreements Journey lines Start The Right Way
- 9. Career Building Trainee COBOL Developer Developer Analysis Testing Lead Developer PM Dickens UK Meningitis Vaccination Introduced Scrum to PCMS Scrum is a success Coaching & Training PCMS Agile Adoption - Cemented Deliberately Distributed Scrum My Own Business A Fantastic Partnership
- 11. Working Together Mentoring and pairing Delivering real work as a team – Early success Building technical skills as a team Empowered and self organising team culture Create Shared Working Experiences Creates Experiences
- 12. Creates Social CapitalPlaying Together Team lunches Know each other on a personal level Evening events Have fun Create Shared Social Experiences
- 14. Trust Built By Shared Experiences Allow teams to remain strong and together in stormy times Bind people together
- 15. Without Trust Built By Shared Experiences Communication breakdown Isolation Them and us Arguments
- 17. In case you need to edit Working agreements Impact on you and the practicalities Promoting culture and communication Sustainability Preparing To Work Off-Site
- 18. Who Team decides on what they are Team owns them Working Agreements
- 19. WhyWho Team decides on what they are Consider the difficulties they will face Team owns them Shared understanding of our responsibilities to one another Working Agreements
- 20. Working Agreements For Self Measurement 7 8 8 7 59 7 8 0 1 2 3 4 5 6 7 8 9 10 Appropriate use of technology Updating of online tool Voice communication over typed Maintenance of physical board Team meetings when off site Response times to emails Awareness of communication messages Maintaining our working culture Team average of our off site working agreements
- 21. The Daily Standup Voice communication Visual communication Impact On You And The Practicalities
- 22. WhyThe Daily Standup Voice communication One team who are in it together Visual communication Avoids isolation Impact On You And The Practicalities
- 23. Retrospectives Sprint Review & Planning How do people stay involved and engaged? How does it affect planning? How will people contribute? How do standard exercises work? Impact On You And The Practicalities
- 24. CommunicationCulture Take time to understand the different cultures Turn the uncomfortable into the comfortable Acknowledge significant cultural differences Self organization is increasingly important Promoting Culture And Communication
- 25. 35 89 66 35 25 68 60 64 93 32 77 48 56 40 61 49 65 63 49 Power Distance Index Individulaism Masculinity/Femininity Uncertainty Avoidance Index Long Term Orientation Cultural Differences UK Poland India South Africa Source – Geert Hofstede
- 26. 35 89 66 35 25 68 60 64 93 32 77 48 56 40 61 49 65 63 49 Power Distance Index Individulaism Masculinity/Femininity Uncertainty Avoidance Index Long Term Orientation Cultural Differences UK Poland India South Africa Source – Geert Hofstede PDI – Power Distance Index The extent to which the less powerful members of institutions and organisations within a country expect and accept that power is distributed unequally
- 27. 35 89 66 35 25 68 60 64 93 32 77 48 56 40 61 49 65 63 49 Power Distance Index Individulaism Masculinity/Femininity Uncertainty Avoidance Index Long Term Orientation Cultural Differences UK Poland India South Africa Source – Geert Hofstede IND – Individualism The degree of interdependence a society maintains amongst its members
- 28. 35 89 66 35 25 68 60 64 93 32 77 48 56 40 61 49 65 63 49 Power Distance Index Individulaism Masculinity/Femininity Uncertainty Avoidance Index Long Term Orientation Cultural Differences UK Poland India South Africa Source – Geert Hofstede MAS – Masculinity / Femininity The fundamental issue here is what motivates people, wanting to be the best (masculine) or liking what you do (feminine)
- 29. 35 89 66 35 25 68 60 64 93 32 77 48 56 40 61 49 65 63 49 Power Distance Index Individulaism Masculinity/Femininity Uncertainty Avoidance Index Long Term Orientation Cultural Differences UK Poland India South Africa Source – Geert Hofstede MAS – Masculinity / Femininity The fundamental issue here is what motivates people, wanting to be the best (masculine) or liking what you do (feminine) UAI – Uncertainty Avoidance Index The extent to which the members of a culture feel threatened by ambiguous or unknown situations and have created beliefs and institutions that try to avoid these
- 30. 35 89 66 35 25 68 60 64 93 32 77 48 56 40 61 49 65 63 49 Power Distance Index Individulaism Masculinity/Femininity Uncertainty Avoidance Index Long Term Orientation Cultural Differences UK Poland India South Africa LTO – Long Term Orientation The extent to which a society shows a pragmatic future- orientated perspective rather than a conventional historical short-term point of view Note – South Africa not measured
- 31. NurtureCultivate Re-seed the personal ties TrustRe-seed the shared experiences Relationships Sustainability
- 32. Conclusions Team 1 UK Team 1 Poland Can deliberately distributed teams work? Does it require additional effort? Do you have to constantly work at it? Is it easy? If you don’t put the effort in will it work? If the team are not highly self organising will it work? Can deliberately distributed teams work? Yes Does it require additional effort? Yes Do you have to constantly work at it? Yes Is it easy? No If you don’t put the effort in will it work? No If the team are not highly self organising will it work? No Images from Visual AGILExicon a trademark of Innolution LLC & Kenneth S Rubin
Editor's Notes
- Connections After explanation of distributed models Everyone standup Sit down if you have never worked in a distributed way Sit down if you have only worked in a collaborating co-located way Those remaining standing must have worked in a deliberately distributed way 30 seconds in pairs or triads to discuss and share experiences of what they think is required to make a deliberately distributed model work well. Concepts The presentation Concrete Practice Sketch out your own journey line or think about how your might look Conclusions In triads or pairs you have 30 seconds to discuss the most important concepts that you have just learned Q & A
- Typically 2 models for distributed teams Model 1 is collaborating co-located This is where you have multiple teams working on the same product or project But each team is a self contained SCRUM Team. They are self-organising within themselves They must however still communicate across teams using techniques such as Scrum of Scrums
- The second model is deliberately distributed In this model you have complete Scrum teams but they are split across different locations, in this example across countries Each team is self-organising within themselves There is of course much greater communication channels in this model as we can see and Scrum of Scrums will help However the area we will focus on with this talk is how we create strong teams when we have different team members in different locations and how we can make this work.
- The second model is deliberately distributed In this model you have complete Scrum teams but they are split across different locations, in this example across countries Each team is self-organising within themselves There is of course much greater communication channels in this model as we can see and Scrum of Scrums will help However the area we will focus on with this talk is how we create strong teams when we have different team members in different locations and how we can make this work.
- This talk is based on my learnings when I was asked to set up and implement an outsourcing model for a large UK based software house. The goal of our outsourcing model was this I decided to write this talk as I have been working with large banks recently who use distributed models but they do not invest the time or money to set up the right environment to make them work correctly, they then are puzzled by why the teams do not work as well as they expect
- We are going to start by looking at the 4 key areas that need to be considered when setting up teams in a deliberately distributed fashion. We must Start the right way Create shared working experiences Create shared social experiences And we must build trust amongst all team members These 4 ingredients are the bases of what is required to set your teams up to succeed
- Every new team that you put together must be built on solid foundations Team startup workshops create these solid foundations and set the containers for teams to work within For a team to self organize they must understand their container Where is it they can make decisions Where is it that they cannot make decisions Where do we want to get too How do we work together The team must have a Vision, they must understand what their destination is, what it is they are trying to achieve For example JFK “By the end of the decade we shall put a man on the moon” I like to build up a 3 level Vision for a team What is in it for me By the end of this project or my team with this team I would like to say that I have …………. Each person must feel that they can gain and grow by being part of this team What do we want to be as a team The team build this together, they decide on what it is they would like to be For example We are a creative group of people, bringing out the best in each other to create products that matter What is in it for our company What is it that you want the product to be, the hoped impact to your customers or users the Its important for the success of any product or project that everyone has a shared vision of where we want to get too. One of the drivers of motivation for knowledge workers is “Purpose” why are we here, what are we trying to achieve. You can earn more about this by looking up the work of Dan Pink Creating a common vision and purpose helps create a container, everything we do must take us towards our Vision A team must understand how they will work together, this is another container for the team. Commonly we refer to these as working agreements, or a designed alliance So during our team startup we develop a set of working agreements so that everyone will know our expectations for working together. It is each team members responsibility to follow the agreements and the job of the whole team to notice and bring it to the teams attention when an agreement is violated. The purpose of the agreement is to help them work effectively as a team. When I do this I split the team into small groups and ask each group to come up with 3 to 4 working agreements We then come back together and share what we have written For example Be on time for meetings No mobile Phones in meetings Allow everyone to have a say Be respectful If we have more than 7 agreements I ask the team to dot vote so we can bring the number down to about 7, we don’t want too many I then ask the team whether they agree with them Thumbs up – Agree with it Thumbs sideways – I will support the will of the group Thumbs down – I veto During them team start I would also get the team to agree Definition of done Sprint length Time and place of different scrum ceremonies All of these are containers for the team, they create the conditions for trust to form Now we have set our container we need to start to understand each other as human beings We are people not resources, so let us understand and respect each other as people I like to conduct some activities that allow people to share things about them selves, one example is journey lines This activity asks people to map out their life, or maybe career and show the ups and downs, where things were great and where things were not so great I ask each team member to do this, draw it up on a sheet of flip chart paper, they can start where it is that they want on their life journey. We draw a line down the middle of the sheet, this is a neutral line We then sketch out or journey with a wavy line up and down and write on key events When we are done each team member stands out front and talks through their journey You might be surprised at what happens and what you learn about people I had one person cry as they explained how their father was a shoe maker and had spent his little money on sending his son to University and now his son was a developer, and had achieved his ambition and his fathers dream had been realized Journey lines allows us to open up, I find that we can work with people and know little about them, journey lines opens us up as human beings and allows us to know each other, when we know each other at a personal level we are more likely to care and if we can create an environment of trust that allows us to be vulnerable then we create the conditions for healthy conflict, having conditions that allow healthy conflict to exist creates the conditions for high performance Set the expectations for high performance with a team I do this in a metaphorical way, you can look this up on the scrum alliance website in an article I wrote called “The quest for high performance” Setting expectations for high performance using a metaphor helps them see more clearly and setting expectations for high-performance allows the team to challenge themselves and to see a vision of what they can become together
- Once you have your solid foundations and have set out the path we need to create shared experiences Shared experiences really need to be created in person, we need to get to know each other in a physical and emotional way The first shared experiences we need to create to build strong teams is shared working experiences To do this we got the team together to work together, we did this for 12 weeks, this was 4 sprints of 3 weeks each. It was important to immerse the team in an empowered and self-organizing culture, if a team cannot do this when they are all together it will definitely not happen when they are separated. You must really ensure that self-organisiation happens during this period. The team must also deliver successfully early on, this should be real work, delivering work as a team together builds and enforces early trust and allows them to experience success as a team. Get team members to actually work together, use pairing and mentoring, allow each team member to show each other their skills and knowledge and allow them to learn from one another, allow them to grow as a team As they build technical knowledge and domain knowledge together, as they build success together and as they work together in an empowered and self-organizing way this build upon the trust already established. This doesn’t happen overnight though, it happens over time as these elements are re-inforced.
- It is not enough however to just build shared working experiences, we must build shared social experiences too. This is back to understanding and knowing each other on a personal level. Have some team lunches where people can relax and have some fun together and share things about themselves that are outside of work. Do the same with some evening events In my situation we had team members from the UK and Poland One evening we had a Vodka and Polish food evening We learned about Polish culture, we had fun together, we tried different vodka and different Polish sausage and other food We had a beer and curry night down the pub, curry being the most popular British food Again we shared things about the British culture WE HAD FUN WE GREW TO KNOW EACH OTHER ON A PERSONAL LEVEL, THIS WAS A MUCH MORE INTIMATE LEVEL THAT JUST WORK
- Without trust and shared experiences things will easily break Not in the good times but in the bad times A blame culture will emerge, a them and us attitude will prevail All of these things will happen and happen quickly
- When we have shared experiences that are built on trust WE SUPPORT EACH OTHER NO MATTER WHAT HAPPENS THROUGH THE GOOD AND THE BAD WE FIGHT FOR EACH OTHER WE WIN AND LOSE TOGETHER WE ARE ONE SHARED EXPERIENCES REALLY DO RULE
- So what happens when it comes time for team members to separate and go back to their home locations What do we do about our working agreements, how do they evolve, how can we use them to help What practicalities will you face as a team and a Scrum Master by working in this way How do we continue to promote culture and good communication How do we sustain what we have built
- We should already have developed our working agreements The team have decided them and the team own them
- We have them so we have a shared understanding of our responsibilities to one another However we are now going to be working remotely and as such we need to consider what difficulties we may face It is now time to re-visit our working agreements in light of the new situation we will be in During the last retrospective before the team separated this is what I posed to them We reviewed our working agreements in this light and added to them considering the new challenges that we would face Some new agreements that we added were Use voice communication over typed, our priority would be video call, phone, IM and lastly email Put a read receipt on emails so the team would know that you had at least read it Reply to an email within an hour, even if just to say I have got it but cant look at it yet All team meeting would always involve remote team members Be aware that English is not everyone's first language
- Use your working agreements as a team self-assessment tool during retrospectives
- What about the practicalities The daily standup for example How will you maintain voice and visual communication We managed this by the use of webcams and a wireless conference phone with wireless microphones Each day we would have the standup in a circle around a physical board in the UK office A chair with a laptop and webcam was placed in the circle as if it was another person The laptop would have the camera on so the off-site team could see the rest of the team and physical board The guys in Poland were on webcam so we could see them We conducted the standup as normal We introduced other tools such as online backlog management tools and yes, online task boards too, we used both a physical and online board Online planning poker tools IM tools
- This allowed us to avoid any feeling of isolation Everyone could see each other and hear each other It created an environment of one team who were in it together Tell story of moving laptop back (1000 Miles)
- Sprint reviews and retrospectives, how will these change For Sprint reviews you will need to use technology, again VC’s and phones, or tools such as Webex to broadcast the review You need to ensure all of the team are part of it, to hold team accountable and keep foundations solid then all of the team must be present to be able to celebrate success of a sprint and acknowledge when a sprint didn’t go so well, everyone has equal responsibility Retrospectives, do you use Post-it note activities? How do you use post-it notes remotely Again use tools I used lino a Post-it note sharing app We also made extensive use of Video conferencing. As a Scrum Master it will take you longer to prepare for your retrospective, standard exercises will no longer be quite as standard. For example when doing the team self measurement in our working agreements this was conducted by an anonymous vote for each team member. For the on-site team they wrote the number on a post-it and folded it over and added it to a pile For the off-site members I had a number of lino sessions running so they could give me their vote, I would then write that onto a post-it and place it into the pile This took much more preparation on my part and more creativity to make these activities work However you do it you must include everyone and give everyone equal voice
- When working with people from different cultures it is important to understand to some level the different cultures Behavior is often driven by culture, this is what people know, this is how they have been educated and brought up We must acknowledge significant cultural differences and understand them so we can cope with them and understand behavior Working in a deliberately distributed team model puts extra emphasis on communication, communication alone though is not enough. If you want a high performing team that works well together then self-organization is all important, without this teams will grind to a halt Everything about working in this way needs to be comfortable and normal, it will not however start out like that OUT OF SIGHT OUT OF MIND IS VERY EASY
- Understanding culture Geert Hofstede conducted a study into cultural differences and measured differences on 5 factors Here we can see it mapped out for the UK, Poland, India and South Africa Power distance Index The higher the number the more they accept it India expect that power lies with hierchy for example, they will rarely challenge authority This is very different to the UK The result of this could be that a Indian team member may not tell a Scrum Master that work is not going as planned as they may see the SM as more powerful and therefore may not want to declare bad news. I have seen this personally Individualism The UK like to be seen more as individuals, this can make it more difficult when wanting people to work really well in teams s they get concerned about how they get individually noticed, this is less so in India they would be more happy with team recognition. Again I see the individualism come out a lot qhen working with UK teams Masculinity/Femininity Pretty even match here A good balance of wanting to be the best (Dan Pinks Mastery) and liking what you do (Purpose) Uncertainty Avoidance Index Wow Poland is almost off the scale, they hate ambiguity and unknown situations The UK and Poland are pretty much OK with reasonable levels of ambiguity and unknowns Long term orientation India are very pragmatic they take a long term approach The UK very short term, again I see this a lot in the UK, maybe that’s why we have so much technical debt in our code Its good to be aware of this and it gives us some good pointers and clues
- Understanding culture Geert Hofstede conducted a study into cultural differences and measured differences on 5 factors Here we can see it mapped out for the UK, Poland, India and South Africa Power distance Index The higher the number the more they accept it India expect that power lies with hierchy for example, they will rarely challenge authority This is very different to the UK The result of this could be that a Indian team member may not tell a Scrum Master that work is not going as planned as they may see the SM as more powerful and therefore may not want to declare bad news. I have seen this personally Individualism The UK like to be seen more as individuals, this can make it more difficult when wanting people to work really well in teams s they get concerned about how they get individually noticed, this is less so in India they would be more happy with team recognition. Again I see the individualism come out a lot qhen working with UK teams Masculinity/Femininity Pretty even match here A good balance of wanting to be the best (Dan Pinks Mastery) and liking what you do (Purpose) Uncertainty Avoidance Index Wow Poland is almost off the scale, they hate ambiguity and unknown situations The UK and Poland are pretty much OK with reasonable levels of ambiguity and unknowns Long term orientation India are very pragmatic they take a long term approach The UK very short term, again I see this a lot in the UK, maybe that’s why we have so much technical debt in our code Its good to be aware of this and it gives us some good pointers and clues
- Understanding culture Geert Hofstede conducted a study into cultural differences and measured differences on 5 factors Here we can see it mapped out for the UK, Poland, India and South Africa Power distance Index The higher the number the more they accept it India expect that power lies with hierchy for example, they will rarely challenge authority This is very different to the UK The result of this could be that a Indian team member may not tell a Scrum Master that work is not going as planned as they may see the SM as more powerful and therefore may not want to declare bad news. I have seen this personally Individualism The UK like to be seen more as individuals, this can make it more difficult when wanting people to work really well in teams s they get concerned about how they get individually noticed, this is less so in India they would be more happy with team recognition. Again I see the individualism come out a lot qhen working with UK teams Masculinity/Femininity Pretty even match here A good balance of wanting to be the best (Dan Pinks Mastery) and liking what you do (Purpose) Uncertainty Avoidance Index Wow Poland is almost off the scale, they hate ambiguity and unknown situations The UK and Poland are pretty much OK with reasonable levels of ambiguity and unknowns Long term orientation India are very pragmatic they take a long term approach The UK very short term, again I see this a lot in the UK, maybe that’s why we have so much technical debt in our code Its good to be aware of this and it gives us some good pointers and clues
- Understanding culture Geert Hofstede conducted a study into cultural differences and measured differences on 5 factors Here we can see it mapped out for the UK, Poland, India and South Africa Power distance Index The higher the number the more they accept it India expect that power lies with hierchy for example, they will rarely challenge authority This is very different to the UK The result of this could be that a Indian team member may not tell a Scrum Master that work is not going as planned as they may see the SM as more powerful and therefore may not want to declare bad news. I have seen this personally Individualism The UK like to be seen more as individuals, this can make it more difficult when wanting people to work really well in teams s they get concerned about how they get individually noticed, this is less so in India they would be more happy with team recognition. Again I see the individualism come out a lot qhen working with UK teams Masculinity/Femininity Pretty even match here A good balance of wanting to be the best (Dan Pinks Mastery) and liking what you do (Purpose) Uncertainty Avoidance Index Wow Poland is almost off the scale, they hate ambiguity and unknown situations The UK and Poland are pretty much OK with reasonable levels of ambiguity and unknowns Long term orientation India are very pragmatic they take a long term approach The UK very short term, again I see this a lot in the UK, maybe that’s why we have so much technical debt in our code Its good to be aware of this and it gives us some good pointers and clues
- Understanding culture Geert Hofstede conducted a study into cultural differences and measured differences on 5 factors Here we can see it mapped out for the UK, Poland, India and South Africa Power distance Index The higher the number the more they accept it India expect that power lies with hierchy for example, they will rarely challenge authority This is very different to the UK The result of this could be that a Indian team member may not tell a Scrum Master that work is not going as planned as they may see the SM as more powerful and therefore may not want to declare bad news. I have seen this personally Individualism The UK like to be seen more as individuals, this can make it more difficult when wanting people to work really well in teams s they get concerned about how they get individually noticed, this is less so in India they would be more happy with team recognition. Again I see the individualism come out a lot qhen working with UK teams Masculinity/Femininity Pretty even match here A good balance of wanting to be the best (Dan Pinks Mastery) and liking what you do (Purpose) Uncertainty Avoidance Index Wow Poland is almost off the scale, they hate ambiguity and unknown situations The UK and Poland are pretty much OK with reasonable levels of ambiguity and unknowns Long term orientation India are very pragmatic they take a long term approach The UK very short term, again I see this a lot in the UK, maybe that’s why we have so much technical debt in our code Its good to be aware of this and it gives us some good pointers and clues
- Understanding culture Geert Hofstede conducted a study into cultural differences and measured differences on 5 factors Here we can see it mapped out for the UK, Poland, India and South Africa Power distance Index The higher the number the more they accept it India expect that power lies with hierchy for example, they will rarely challenge authority This is very different to the UK The result of this could be that a Indian team member may not tell a Scrum Master that work is not going as planned as they may see the SM as more powerful and therefore may not want to declare bad news. I have seen this personally Individualism The UK like to be seen more as individuals, this can make it more difficult when wanting people to work really well in teams s they get concerned about how they get individually noticed, this is less so in India they would be more happy with team recognition. Again I see the individualism come out a lot qhen working with UK teams Masculinity/Femininity Pretty even match here A good balance of wanting to be the best (Dan Pinks Mastery) and liking what you do (Purpose) Uncertainty Avoidance Index Wow Poland is almost off the scale, they hate ambiguity and unknown situations The UK and Poland are pretty much OK with reasonable levels of ambiguity and unknowns Long term orientation India are very pragmatic they take a long term approach The UK very short term, again I see this a lot in the UK, maybe that’s why we have so much technical debt in our code Its good to be aware of this and it gives us some good pointers and clues
- For deliberately distributed teams to be sustainable we need to cultivate and nurture them. Treat them like a plant, build strong roots, give them good soil to grow in Water that soil and give them plant food Prune the plant This is what we need to do Keep re-seeding the personal ties and shared experiences This nurtures the relationships and trusts In our situation we had teams visit each other every 6 weeks, less will probably work but not doing it at all won’t they need to be at a reasonably frequent interval. People may complain it costs a lot of money BUT WHAT IS THE COST OF NOT DOING IT TEAM BREAKDOWN IN-FIGHTING LESS WORK BEING PRODUCED LACK OF CARING If we don’t do this we get team dysfunctions PATRICK LENCEONIO 5 DYDFUNCTIONS OF A TEAM ABSCENE OF TRUST LEADS TO A FEAR OF CONFLICT THAT LEADS TO LACK OF COMMITTMENT THAT LEADS TO AVOIDANCE OF ACCOUNTABILITY THAT LEADS TO INATTENTION TO RESULTD