An experiential approach is what we are looking for there, it was taking people through actually working in a Distributed Team, it’s a wonderful opportunity to put people into a small microcosm where only had about a dozen people in the room and what we do at the beginning is a little bit of introduction and conversation and setting up goals and so forth, then we run a workshop or an activity where we take some of the group and I typically like to take the Scrum Masters and the Project Managers, and I put them, and in this particular case we put them behind the screen and they would be a remote team, the rest of the class stay local. Now remember we are in a single room so they just back in one corner but behind the screen, so they can’t see the rest of the class, the rest of the class can’t see them, they can’t overhear each other. But it’s wonderful to see all of the anti patterns and behaviors that Distributed Teams experience, actually happens in that microcosm in that classroom environment, and we give them a reasonably straight forward exercise, in this particular case, it was producing greeting cards.
This is a workshop that Johanna Rothman and I put together and the activity is to, the head offers group, they define the requirements and they send these requirements via email and as the instructor I’m the email carrier, that is written on posted notes, to the remote team to build greeting cards and it’s a set of criteria that a greeting card has to meet to actually be considered valuable. Now that’s a pretty straight forward thing to do, you would think. Well in 3-5 minutes iteration plus some planning time we got 2 and a half cards out. Then we examined and we use retrospective techniques and actually had a look at what it happened. So now we would taking, is taking away from the activity and looking what happens actually inside the Distributed Teams and we use that as the basis for the rest of the day where we looked at practices and psychology and interaction and how can we overcome the common challenges that Distributed Teams face. And by the end of the day we’d work through and come up with a whole lot of new ideas and things, and then we run the same exercise again but we give the team, giving them a little bit more autonomy and they figure out ways of working, and in the same time frame they produce 25 cards. So we saw a true order of magnitude improvement at factor of 10.
Ben: Within a day.
Within a single day. And this is what you can get when Distributed Teams are able to work effectively because Distributed Teams are the norm today. Organizations utilize skills from all around the world. Ignoring that is pointless and you want to be able to leverage those skills, so setting Distributed Teams up to be successful is really, really important but it doesn’t just happen. In fact left to its own without careful design of the team structure, without support for team cultures, without spending some money and some effort in enabling these things to happen, what you get is the 2.5 performance versus the potential of the 25. But you got to structure for that, you got to build for that and it was wonderful to see with this group of only 12 people, but we have a really great and intensive day looking at what can we do to enable Distributed Teams to be more successful.
3. Can you elaborate some of the problems that teams experienced in the workshop?
The first one was very simple asking them, those people over there who were behind the screen or from the people behind the screen, those people over there who were defining that requirement. In organizations it’s the simple naming of the two teams very often or the two groups, you got the head off of some of the branch office, you immediately create a part differential. Fix that, it’s bringing people together to get to know each other. One of the things that we looked at when Johanna and I would do a research for this, was we saw the importance of bringing people together at least once, and one of the most important things that we do as a species is share food. Giving people the opportunity to sit down together and share food creates inter human bonds. Teams are becoming teams when we build those bonds, there is a well known structure of team formation Form, Storm, Norm and Perform, you don’t get to norming and performing unless you actually know each other.
Most Distributed Teams or many Distributed Teams are never given the opportunity to get to know each other, so they don’t become teams, they are if you are lucky Distributed Workgroups, most often what they are is competing Workgroups and competing sets of individuals. You might have two tribes who truly do go to war with each other and you’ve seen this in organizations around the world. When set up to be successful Distributed Teams can be almost as productive as true colored headed face to face teams. There is always a cost to difference at two distance, if I take the same group of people and I collocate them or I work them as a Distributed Team, you will get better outcomes or at least slightly better outcomes from the collocated teams, there is no questions about that, but we chose to be distributed from many different reasons, people like to live with they live. Organizations don’t have skills in one area and I bring them in, so doing that is fine. If I look at InfoQ we are a globally distributed organization, hundred and forty something people in almost as many countries, but one of the great things about this organization is we get together.
At this conference we got 40 of the editors, of the InfoQ editors in the same place, so this helps us build those bonds, the C4Media people, the holding company of InfoQ, these are the full time employed staff, they come together at least twice a year, so Floyd who build and design the organization understood this stuff and brings all of these good ideas into the running of the organization here, and honestly InfoQ and C4Media is one of the most effective distributed groups that I’ve ever worked with, because we understand that stuff and it can be done, you can be highly successful but you got to put in the effort. Many organizations start from the point of view of you and you are in Mongolia and Boston, work together, you are a team now, you’ve never meet each other, you’ve never communicated, and by the way we haven’t got enough money, so your bandwidth is going to be really narrow, you can’t have a video channel between you, you can only have conferences called every third day. That setting the up to failure and then they wonder why they don’t get the value.
Ben's full question: I really recognize that and I think that organizations are not really prepared to do things well for teams to be able to collaborate, so that’s something that I think should be improved, I fully agree with you on that. Looking at InfoQ, I’ve been working with you for InfoQ for more than 2 years right now and actually here at QCon London is first time that we meet in person while we are still being collaborating very well with each other, so I’m convinced that remote working works but I think there are still a lot of people who are a bit anxious about that and are a bit afraid if this will really work, so what are the kind of things that you would suggest to convince them that remote working can work?
Let’s take an Agile Approach, do a small experiment, try it and see. We start from a point of view of trust, we set the team up, we set the group up to be successful, so we give them the tools, the capabilities that they need to be successful. So don’t start a team up by coupling it, bring them together, let people get to know each other because yes, it makes a huge difference, you are right this is the first time you and I have had the opportunity to share food together which we did last night. That builds the bonds, we have fairly regularly had contact, if we think about it, you and I have spoken at least every month or so and we use the video conferencing, we use Skype or we use one of those type of tools which gives us the breath of communication richness, and we have a shared passion so that really helps, we are able to have the characteristics of a team which is a group of people working together towards a shared goal and we have this shared goal, we have this shared passion so that really, really helps. Other things that organizations can do, give people the time to make collaboration a discipline.
When you are under time pressure, when you are feeling stressed, we focus, the narrowness of focus means we don’t have the opportunity to actually talk to each other as people and just give me a requirement, give me the product, give me this piece, give me that piece, there is no relationship there. Well actually stop, step back, if you are having a 30 minutes conference call, put aside 5 minutes at the beginning or the end where what you are doing is just talking social, what did you do on the weekend, how is your family, all of those things that make us treat each other as human beings and we move away from the transactional service provider customer into “Hey, we’ve got shared goals, we are real people”, so the first one definitely make collaboration a discipline and the second one and this is down to the individuals is, different is not wrong, different is just different, get to know each other to understand each other, take the time, again and it takes time to have the conversation about what is your norms and values, how do you like to be communicating with. We had a little chat early on about the meaning of the color red, just a simple thing, but in some societies red is the color of joy and in others is the color of danger.
So if the person who is on the other end of that Skype call has a different cultural interpretation of something to you, well that’s ok, learn about it. I’ve been spending a lot of time going to places in the Middle East, I’ve learned a phenomenal amount about elements of that culture and this is giving me, I hope, a level of tolerance and understanding, and as we learn more about each other we build that tolerance and understanding. So it’s giving people what Tom DeMarco calls The Slack Time, the capacity to think beyond the narrow focus and actually become real teams and then get that order of magnitude improvement.
Well my fundamental promise and I’m sure I’m going to be shut down all over the place, is the product owner role as it’s described in most of the branded Agile practices is broken. It is too complex, too large, too difficult for any single individual to tackle. You need a variety of skill sets, a variety of points of view to feed into this product ownership. Now product ownership is incredibly important that you need that variety of view points and skill sets. In the same way as in any other team you need diversity, you need skill sets and so forth, you need that in a product ownership team. But something people need to remember as well though, is that we are taking a sporting metaphor, every team has a captain, they needs to be an arbiter, a guide of decision making that within that if you think of the base soccer teams and so forth, these are in terms of the captain every time they pull they are going to kick the ball, but they are sending the guidance for the teams as a whole, but the individuals members of the team know where they are going, again they are a team, they have this common goal that they are working towards and that’s what for me effective product ownership is and that’s what the talks are very mature.
6. Ok, so how could this team look, what kind of rules would be in there in such a team?
Again it’s skills not roles, and really does, it’s context depending, it’s the main specific, if you were in an environment like Health Care for instance, you probably need some independent verification, validation, you might need to confirm stuff outside of the organization, compliance activities. In some you might need legal representation, we look at the variety of Stakeholder communities that we will be impacted by the initiative, we also need skill sets such as analysis and investigation, we definitely need leadership, this is also where, and again some of the Agile Brands don’t acknowledge the need for the role, but honestly in complex organizations project management, this is where the project management interfaces into the Agile team for instance. So it’s a tool also to move beyond that wonderful Cinderella project that, I'm not sure, Jennitta Andrea defined the Cinderella project, the six person, collocated team who’s going to be, who’s customers are sitting with them and the type of product that they are making has no interfaces and dependencies or another gather systems and so forth. If you are doing that, absolutely you can use the Core XP team and just those disciplines and you’ll be successful. Most of the projects of the organizations that we work with or that I deal with all the day-to-day bases, they are large, they are complex, they are parts of a multilevel programs of work with dependencies and in some cases there is hardware components, there is software components, there is organizational change that has to be rolled out in parallel, there is marketing departments that got to be kept up to date, all of those things, and they feed into this product ownership.
Ben's full question: I agree with you, I’ve seen teams actually where product owners, project managers, people from architecture work together collaboratively to guide teams, being each other backups in giving directions to the team and at the end if was a debate then the product owner was deciding this is how we wanted to go but together they would be much more supportive to the team and helping them, so I can see the benefit in collaboration in there. Can you give some examples of what this kind of product owner team can do and how they would collaborate with teams?
Ideally there is a very high overlap between the development, the people who got the development technical skills and the people with this product ownership skill, but what are the things that I found that enables us to do is also have a slightly difference cadence, is the prime responsibility of the product ownership team, is to get the, if we take an Agile Approach, to get user stories to a ready state, so the development subset, they are able to constantly focus on the next most important piece of business value and it is ready for them to work on, where as in the product ownership space we are having the debates about what is the next important piece of business value and how do we integrate user experience and what about the important architectural frameworks and so forth, so all of those decisions then can distract from the steady flower value in the delivery team. So you need that and it’s, one of the areas where I’ve seen it really work well is where there is a cadence of user experience design going just ahead as well, so that’s one example.
Well yes, we are looking what are the key skill sets that are needed, make sure that that team has a captain, that’s really important, they has to be, the language that I use is the concept of the value facilitator which I got from Ahmed Sidky. They has to be a captain of the team, but then you got to look at what is the other stuff that is needed from an organizational perspective, from a legislative and structural perspective, from a compliance perspective, from a governance perspective, all of those things, what are the skill sets? Bring those people together, make sure there is a quite a tight overlap with the delivery skill sets as well and then enable them.
9. Enable them in sense of just start doing it?
Yes and impound them. One of the most common anti patterns of product ownership is the product owner who has to go and get permission, got to go and talk to Mary, well then Mary should be part of this team, so they are trusted and empowered to make good decisions on behalf the organization, the organization’s best interest.
I was very, very privileged to be reelected as the director for another two years term in last year, so this will be my last term on the board of the Alliance and it’s been a wonderfully positive great experience working with a community of people who really are passionate about all things Agile. Over these two terms that I’ve been on the board we’ve had this very strong focus on internalization and we’ve seen the formation of the Agile Alliance in Brazil and that group, that organization is now picking up, they are running the Agile Brazil Conference and there is going to be an ongoing thing, obviously the Alliance itself runs the annual Agile 20XX and we are looking at where to next from an internalization perspective. We are also looking at how does the Alliance provide value to members around the world because initially there was a much more North American focus with the Agile Alliance and that has definitely change, we are looking to the rest of the world because Agile is a global phenomenon. One of the things that I personally get heavily involved in and that’s been really, really tremendously satisfying is the Agile Manifesto translation program, we're planning and maintaining the Wiki where translation teams translate the Manifesto into their home language and if you go to the website www.AgileManifesto.org there are over fifty languages publish them. And this is not a Google Translate activity, this is a group of people and we ask them to form a team and they deeply debate the meaning of the Manifesto in English and how that will translate not as a row word for word translation, but in a contextual and meaning way into their home language, and this is something that in many ways I wish every Agile team had to do because when you stop and you examine the words and the meaning in those 4 simple values and 12 principles, there is a huge depth of meaning and intent buying that. So I almost wish every English language team had to translate it into English just so that they could debate what is that really mean to us and the richness of the interactions now obviously I don’t speak all of those languages but I see the interaction that is going on and I get the unprivileged to talk to a number of the lead translators and the translation teams as they are going through the process and I see the outcome of that which is that deep understanding and very often the formation of a local Agile Community around this program, so it seems almost simple but as with all simple things you are getting this wonderfully complex behavior that comes as a result of the just translate the Manifesto.
Ben: Well I think it’s a great way then to spread the ideas behind the Agile Manifesto all around the world.
Very, very like so, and as I say, there are over 50 languages at the moment and I think we’ve got another, I stand it be great that I think it’s been 30 languages on the way. So if any of our listeners wants to pick up a language that hasn’t been translated yet, well please do and it’s very easy translate and www.AgileAlliance.org.
Ben: Great, so thank you very much Shane for this interview, was great talking to you!
Thanks Ben, it’s been really good!