Is your team co-located? It's funny that we needed a new word for a way of working where people are in the same place. Not so long ago, the new words were offshoring, outsourcing and remote. Now it's co-located, meaning in the same location.
As I mentioned in part one, my first Agile project was with a team that was not co-located. Not only was the team not co-located with the product owner, the team was not co-located with itself.
Three quarters of the team were Chinese. They lived and worked in Tianjin, in China. The rest of the team and the product owner, me, were British. We worked in London, in the UK. Although the project started with no marketing involvement, see part one, there was soon a marketing stakeholder, who was American. He worked in Redwood Shores, on the West Coast.
The sun never set on our project. Tianjin to London is eight hours, in time zone difference. London to Redwood Shores is also eight hours. Deduct those from the twenty-four hours that there are in a day, and you'll find that it's also eight hours from Redwood Shores to Tianjin. We were about as widely distributed as a team could be.
Many proponents of Agile seem to have a blind spot about distributed teams. I put that down to nostalgia. Let's look at that before we get stuck in to how to work with a distributed Scrum team.
Nostalgia
There seems to be a widespread misconception that Agile is a return to the old ways of programming, and that returning to the old ways of programming is a good thing. Firstly, it is not a return, and second, returning would not be a good thing.
Back in the old days, programming was not well understood by those given the job of its management. A colleague of mine was once told by his manager: “The program runs too slowly. Can't you put in more if-tests?”
Back in those days, when asked why everything took so much longer than estimated, we would explain that programming was a very young form of engineering, when compared with, say, building bridges or pyramids.
Despite our facetious attitudes to authority, programmers continued to be employed. This was because the world needed software. What the world needs, the world gets. But what the world needs, it also tries to get efficiently, and in a controlled manner.
The first attempt at controlling the delivery of software was to use what are now known as waterfall methods. Waterfall methods are so called because they start at the top, then descend in an unstoppable way until they reach the bottom. At the top of the waterfall are the marketing requirements, at the bottom is the executable software. It sounds simple, but there is one problem: Waterfall doesn't work.
Even so, waterfall methods were widespread. This is because, as stated above, the world needs software. Waterfall gave the world software, albeit often the wrong software, and inefficiently produced. That is why we now have Agile methods; because Agile methods are better and more efficient than waterfall methods at giving the world the software it needs.
Incidentally, the idea that Agile represents progress is not heard often. More popular seems to be the view that we have Agile methods because programmers have risen up and thrown off the yoke of management and the market. Well, programmers do tend towards romantic narcissism, so it's understandable that this view has been expounded. I'm happy to let my coders live in the fantasy that they gone back to the good old days, so long as they code what we need, code it well, and code it efficiently.
The drive for efficiency is the reason we now have Agile methods. The drive for efficiency is also the reason that American and British companies are now working with software developers in China and India.
China and India
It is apparently cheaper to live in China, and India, than in the UK, and USA. This means that it is cheaper to employ coders that live in those countries. How much cheaper is a matter for conjecture. I've been told that the ratio of what a coder in the UK costs to what a coder in China costs used to be three times. I've also been told that the ratio is now nearer two and a half times. I don't care what the correct ratio is. I also don't care about whether and why it is cheaper to live in China and India.
This brings me to a commandment that you must follow if you want to work well with a distributed Scrum team. As you'll see if you continue reading, this is not my only commandment. This is the first of five commandments, and the most important.
Commandment one
The first commandment of working with a distributed team is: Get over it.
Chances are, if you are working with a distributed team, you are not the person who decided that a distributed team would be a good idea. The chances are that the decision was made by somebody else in your company. That other person did their maths and worked out that a team all in the US or UK would cost more than a team partly in China or India.
The maths may have been wrong. The decision may be wrong. Get over it.
(This may be being read by somebody who did make the decision, or did do the maths. The commandment still applies. You may have made a mistake. Now get over it.)
However you have ended up working with a distributed team, it is not your job to complain. It is your job to make software happen.
Following the next commandment will help you to do that.
Commandment two: Reply today
When you are the product owner for a distributed team, you must reply to every e-mail today. If you cannot reply properly today, at least reply today with an apology and a commitment to get a proper reply.
No member of the team is going to drop by your desk to chat about the issue, nor will they see you in the corridor. This is because they are in a different continent. That might seem obvious, but I have worked with people who very clearly didn't get it.
Your team won't wait for you. They are mailing you a question because they need an answer. If you don't provide an answer, they will go elsewhere. Think of them as nodes on an intelligent network. Think probe, not process.
The structure of the modern corporation is fundamentally opaque. Workers within that structure cannot rely on process to tell them by whom questions should be answered. Hence, they probe. If your team asks you a question, and you do not answer, they will conclude that the question should not have been addressed to you. They will then ask somebody else.
The top candidates for that somebody else are: the Scrum Master, and line management. In a small organisation, those may even be the same person. Designing software products is fun. More fun than doing burn-down charts or annual reviews certainly. Bored Scrum Masters and line managers will be happy to step in and pick up the fun when the product owner slacks off.
Keep the design fun for yourself, and answer every mail from your team today. If that seems like a tall order, remember commandment one. Anyway, answering e-mail properly is not only a good habit, it is also an example of following the next commandment.
Commandment three: Use the written word
A few years ago, I used to work in a technical support department. One day a fax came through (that'll give you an idea of how many years ago) from my employer's Japanese reseller.
The reseller was pretty much a one-man operation. Nevertheless, he was making good sales, including Nihon Keizai Shimbun. That's roughly the equivalent of the Economist and the FT in Japan, and is the source of the Nikkei index that they tell us about in the news. He sent a fax about a problem he was having with the software.
He had tried our recommended troubleshooting steps but had been unable to, in his words, “shoot the trouble”. My boss's boss, a director, took it upon herself to read that part of the fax out loud and mock the man's English. Ha ha, we don't say shoot the trouble, even though we do say troubleshooting. Personally I thought that this was quite a creative extension by him. I also thought that it was my job to solve his problems, not mock his English.
I had to read his fax slowly and twice before I understood what he was trying to do. Round about then is when I realised the value of written communication in scaling the language barrier. Understanding what another person says is a form of data processing.
In data processing terms, spoken conversation is real-time. If I didn't understand what you said when you said it, I'm unlikely to do so later. Fax, and now e-mail, is batch. If I didn't understand it when I read it first, I can read it again, and again, until I do understand it. Or at least until I understand part of it and send you back a request, also written, for clarification of the rest. (My request will contain evidence that I have read and understood part of what you wrote, and not just say “I don't understand; ask again.”)
I replied to my Japanese contact by fax. He then had the assistance that he needed, and which it was my job to provide. He may well have had to read my fax slowly and twice, but then he had time for that because I had used written communication.
If that story was happening now, the medium would not be fax. The medium would be e-mail, instant messaging or some other form of written communication. (Instant messaging? Yes, even IM gives the participants more time to work out what each other is trying to say than spoken conversation.)
But the written word is not only a ladder for scaling the language barrier. The written word is also a means to live by the next commandment.
Commandment four: Exploit time zones
Don't force people's working hours to overlap. Instead, make time zone differences work for you.
There is a time zone difference of eight hours between Tianjin and London. This means that there can be an easy overlap of one or two hours in their working days. That is enough for any necessary daily meetings, such as the stand-up that we have in Scrum, and is therefore all the overlap that you need. There's no need to fight the time zones for more overlap. It's better to exploit the lack of overlap.
Exploiting time zone differences is not difficult. All the team needs is a simple schedule, as follows:
- End of day in Tianjin:
- Summarise issues and tasks, by e-mail.
Hand over issues and tasks in the Scrum stand-up. - Start of day in London:
- Get to work on the issues and tasks.
- End of day in London:
- Summarise conclusions, by e-mail.
Summarise new issues and tasks, also by e-mail. - Start of next day in Tianjin:
- Get to work on the new issues and tasks.
- End of day in Tianjin:
- Here we are again.
In a twenty-four hour period, a single task could receive fifteen hours of programming effort, from two members of the distributed team. The co-located team could only contribute seven and a half hours in the same period. OK, I've assumed the task can only be worked on by one person at a time, but I believe many programming tasks are like that.
Example one: An engineer in London can do their day's work coding, and then have it tested by an engineer in Tianjin. “Get your code tested WHILE YOU SLEEP.”
Example two: The team in Tianjin might code all day but then hit a snag where they need a decision from the product owner, me. They give me the options at the end of their day, and I can take my day to get the answer right. If necessary, I can even pass the question up to my sponsor in Redwood Shores. I would do that at the end of my day. Even if the sponsor takes all of his day to answer, the team in Tianjin has not had to wait, because they were asleep or at home while we deliberated.
Both these tasks are less efficient in a co-located team: The tester has to wait for the coder to finish coding before they can start testing; The product owner has to make a snap decision, or “gate” the team.
(Now, there will be times when you need more interactive communication than the above and it has to be outside the overlap. The first thought may be to use the phone. The problem is that talking on the phone is quite intrusive. Picture an engineer sitting at home watching TV with their family. That engineer cannot take a phone call. Now add a laptop, or just a smartphone, to the picture. The engineer could quite easily write an e-mail or take an IM conversation, without disturbing their family's TV watching.)
Another time-zone exploit is what we called the off-line demo. This replaced the normal end-of-sprint demo. In a normal demo, the team and product owner get together and the team demonstrates the software to the product owner. In the off-line demo, the team provides a version of the software that the product owner can install and run themselves. So, I as product owner would run my own demo. I would check the completion criteria in the sprint's user stories, and give an official statement as to which stories were done, and which were not done.
Using the above exploits is particularly satisfying if, like me, you work with calendar data. If you work with calendar data, you hate time zones, and you really hate daylight saving time. Increasing productivity by using time zones is getting one back on them. It's also quite easy, unlike the next and final commandment.
Commandment five
The fifth commandment is: Don't body shop.
The members of the team in Tianjin had the same status as members of the London team: they were employees of the company. Now, legally, that may not be exactly true; I believe they actually worked for a joint venture between my employer and a local Chinese company. Technicalities aside, the point is that they were not working for an outsourcing company.
I am not a fan of outsourcing, be it co-located or offshore. When a company outsources, it creates a dependency on people that do not understand its business, and have no stake in its success.
I once worked at a company that had outsourced I.T. and outsourced facilities management. Both provided terrible service to their “customers”. Outsourcing of these functions was done, I suppose, in order to please the bean-counters. Did it please them? It may have, in the short term. In the long term, the bean-counters themselves were outsourced. I'm guessing that didn't please them.
Outsourcing I.T. support, facilities management and bean-counting are minor errors. It's shortsighted to remove those functions from your company, but not suicidal. Suicidal is going to a body shop for the people that create your product.
For some companies, this will be the most difficult commandment to observe. That's OK, it's not the most important of the five. To recap:
Commandments for successful distributed Scrum
- Most important: Get over it.
- Reply today.
- Use the written word.
- Exploit time zones.
- Don't body shop.
Those are my commandments, based on my own experience. Other people have different views, and some have made them available to the internet.
Response to the Distributed Scrum Primer
The Distributed Scrum Primer is professionally produced, thought-provoking, free to download and can be found here: http://www.goodagile.com/distributedscrumprimer/. It is well worth a look.
Read what follows as an incremental patch to the primer's content. By that, I mean I'm going to skip over the parts with which I agree, and focus on the parts with which I take issue.
Communication is too easy a scapegoat
“Communication is always the problem.” That's a true statement, but in some ways has the same utility as the statement that “Communication is never the problem.” Get me? No? What I'm saying is: There is no point in calling attention to a factor that is a constant.
One might as well call out that engineers need to sleep, eat and breathe. Communication will continue to be a problem until there is a planet-wide illumination and we merge into a single hive-minded entity. (Ewige Blumenkraft!)
But seriously, corporate failures are put down to communication far too often. Failure to communicate seems to be an acceptable failure. To test this on yourself, try reading the failures in column A and column B in the following table:
| A | B |
|---|---|
| Company strategy was not communicated. | Executives had no strategy, or the strategy that they did have was wrong. |
| Requirements were not communicated to coders. | Coders didn't bother to read user stories during the sprint. |
| Technical limitations of the operating platforms were not communicated. | Product designers didn't concern themselves with what is practical. |
| Test results were not communicated. | QA engineers did not test the whole product. |
But still, communication
If you promise you have read the previous section, and done the reflective exercise, then you can read this section.
Genuine communication problems exist; I admit it. I also admit that these will tend to be worse when the product owner and Scrum team are remote from each other and do not have the same native language.
The Distributed Scrum Primer says that the solution to these problems is high-quality video conferencing. I say that the solution to these problems is not hardware. I say that the solution is words.
Yes, you can make your communication effective at a distance by using words. Avoid subtle intonations, body language, and other non-verbal communication. Use words, and use the right words.
When communicating at a distance, the right words are the simple and direct ones. As reference points, I suggest Mr Spock from the original Star Trek, and the PostScript Language Reference Manual (the best technical documentation that I have ever read, by the way.)
You may be concerned that emotions and feelings cannot be conveyed when talking like Mr Spock explaining beta splines or colour spaces. Don't be. From experience, I can say that this communication style conveys emotions easily, and effectively. Here's an example. At one point in a project with a Chinese team, I was quite angry that a particular item of work had not been started. How did I communicate that? I sent an e-mail that said: I am quite angry. No body language, no subtle intonations, no need for a video conference.
As a side note, if you seem to need a high-end video conference for your daily stand-up, then you're doing your daily stand-up wrong. The team with which I worked used a basic conference call facility for the daily meetings. I joined the meeting from my mobile phone, usually when I was outside, walking across a busy city.
Sure, subtle intonations were probably lost in the aether. But remember that the daily stand-up is only supposed to highlight issues. It is not intended for detailed discussion. All we would resolve on the call was who was going to send an e-mail to whom in order to progress towards resolution of the issue. See above for the commandment about written communications.
Kick-off events
The Distributed Scrum Primer advocates a kick-off event of some kind, possibly including travel by the product owner to see the team. I have two objections to that.
First, big kick-off events seem to me to be fundamentally non-agile. Agile practises are all about doing whatever is most important now. They are not about committing to spending a long time on the project in question. And if there's no commitment to the project, there's no justification for spending money on a big party and trip abroad.
Second, and this applies to Agile and non-Agile projects, my observation is that the bigger the kick-off event, the less likely the project is to deliver anything of value. (I've observed a similar phenomenon with executive hire announcements. The longer the announcement, the lower the impact the person will have on the company.)
Having said that, there is one other consideration for the kick-off party. By the end of the project, everybody will hate each other. Have the project party before the hate starts.
See them as people without seeing them
If you cannot think of a colleague as a person until you've seen their face, then you will have a problem working in distributed Scrum. Actually, I can reduce the qualification of that statement. If you cannot think of a colleague as a person until you've seen their face, then you have a problem. I product-owned a successful 6 month effort without ever seeing the Scrum team.
If you cannot think of a colleague as a person unless you understand their culture, then you have a problem. Let me tell you, I don't always understand English culture, and I'm English.
The Distributed Scrum Primer suggests that I would need to immerse myself in Chinese culture in order to work with a Chinese team. My contact with Chinese culture has mainly been watching the films of Run Run Shaw and Liu Chia “Pops” Liang, reading Jademan English-language comics, and having trained in Chinese martial arts in my twenties. Hardly an immersion. (Should you wish to achieve the same level of culture as me, you could now start by watching the whole of the Shaw Brothers classic Five Element Ninjas on youtube, for free. In my day, you had to sit all night in a fleapit art-house cinema in one of the dodgier parts of London to do that.)
If you refer to your colleagues as resources, then you have a problem. Your desk is a resource, so is your computer, so is your budget. People are not resources, not since we abolished slavery. Read commandment five again.
If you have these problems, you need to change your attitude, not take an all-expenses-paid trip to wherever your team is located. Observe commandment one.
Conclusion
Nostalgia is almost an anagram of “is not agile”. Scrum and other Agile methods represent progress, not nostalgia. The distribution of teams across countries also represents progress. These forms of progress are compatible, if the product owner follows the distributed scrum commandments:
- Most important: Get over it.
- Reply today.
- Use the written word.
- Exploit time zones.
- Don't body shop.
Distributed scrum throws up a number of challenges, some more difficult than others. Getting your employer to pay for a business trip half way around the world is a challenge, but not as difficult a challenge as changing your communication style. Organising a kick-off party is a challenge, but not as difficult as changing how you think about your colleagues. Justifying a video-conferencing facility is a challenge, but not as difficult as changing your attitude. Overcoming the difficult challenges will have more positive impact on your projects. Get over it.
Copyright © Jim Hawkins, 2011
No comments:
Post a Comment