By David Bicknell
Campaign4Change recently took part in a software development roundtable organised by the Dutch software specialist Software Improvement Group (SIG) to find what makes successful teams in software development.
The roundtable featured two specialists in creating specialist teams: Andrew de la Haye, chief operating officer, at RIPE Network Co-ordination Centre (RIPE NCC), one of five Regional Internet Registries (RIRs) providing Internet resource allocations, registration services and coordination activities that support the operation of the Internet globally; and author and management expert Kevan Hall, chief executive of Global Integration.
The event discussed the process in the creation of excellent teams in software development, the qualities shared by successful teams, the role that management plays in their creation, while highighting some of the factors that help create productive teams, and the issues faced by the people managing them.
Teamwork
Arguably, great development teams typically demonstrate a lot of very tight teamwork, with small groups that all know and understand each other working intensively together.
According to Andrew de la Haye, what makes effective teams is a mix of strategy, team dynamics, communication, and multifunctional commitment.
“Clarity on the company’s strategy is extremely important in creating an effective team. Very high level strrategies are very difficult to comprehend in regards to the work. Communication is very important: it is the alignment between what we say and what we do. We have to reinforce and embody the goals we have,” says de la Haye.
“Where I used to work, people might say ‘We were going to the factory today. And that meant the developers sitting in a big room. But the word factory is a bit misleading. These guys are not blue-collar workers. They are highly educated and they are much more intelligent than I am. They are intelligent individuals with lots of ideas, which I want to nourish.
Agile Empowerment
“With communication in mind, what we are also doing is lots of measurement and making it very visible,” says de la Haye. “For example in our room, I have a chart showing the quality of our software to the team, showing how they’re doing. That contributes to the notion of quality and effectiveness in the team.
“Then there are the dynamics of the group. We use Agile development, which means that we deliver every second week to the business side. The business side may say, ‘We don’t like the feature. We don’t like the colour.’ I don’t care what they say as long as what we produce fits their needs. And because the iterations are very short, it’s very easy to change it.
“Another key factor is empowerment of the team with Scrum. We have a huge board with sticky notes and colours. It might say that a particular feature is required, at a very high level. And then they decide who’s doing what. I’m not even part of that discussion. These guys are very bright and know what they’re good at. I do have some control mechanisms in place. We measure quality and I measure the amount of what they deliver. I don’t ask my developers, ‘Can you tell me how many hours you were working?’ because they are not very good at predicting the amount of hours. But what they are very good at is predicting the complexity based on complexity points. And the complexity points tell me how much time something will take.
“I had this phrase, ‘Quality is cheap,’ and I had some arguments with people over its meaning. What is says that ‘If you do really really good work, the rework that you have to do, which is really more than doing it properly in the first instance, you will be able to reduce that rework.’ And that has to be reinforced. If we hire people, we hire people who like quality and are quality driven and that’s very important as well.
Commitment to quality
“We have multidisciplinary teams. And we have expertise areas, but we don’t have experts. An expert is someone you put on a pedestal and nurture. Someone with an expertise area is willing to broaden that knowledge but also is able to pick up other knowledge. In the Scrum team, we have developers and senior developers. That’s it – no architects, senior architects, enterprise architects. And a healthy turnover is very important as well. For us, it’s about 10-15%. You need new blood in your team once in a while. We are not consultants, so we are not doing cutting edge stuff. But we’re not lagging behind either. So you need to replenish your team with the knowledge that’s available, and that’s very important to the team.
“The final area is the commitment. If you have all these areas well in place, you have a team that is very committed. Committed to quality; committed to our overall goals as a company. They all understand why our company is there. And it’s not to make money. They are empowered and result-oriented. And one of the things that gets me lots of credit is that I give them lots of learning opportunities. We have a budget for our developers and what we used to do was send them away to the US, to California to a conference, that kind of stuff. And the value that came back was not that much. They may have had a great time, but that’s not the commitment I’m looking for.
“So now I say, ‘Take two weeks in the office. Come in whenever you like. Leave whenever you like and do something you think is interesting for yourself. And after those two weeks, show the team what you have been doing. Hopefully it’s innovative and hopefully people learn from it. It’s not something we need to apply. We might; we might not. But it should be a learning experience for you.’
“At RIPE NCC, we’re not top heavy on mobile applications. And it’s not an area that we need to go into. But we had this guy whose ambition is to work for a mobile operator in a couple of years’ time. And so he created a mobile app for us. I’m not scared of losing him because I expect that turnover anyway. The guy is very committed to his job because I take him very seriously. I help him get to the next level. So he might stay for the next six months and if I really need him he will come back. It’s all about collaboration with my teams.
“My strategy director said ‘I keep going to these strategy conferences and I’ll see the same people the same time over and over again. And they tell me stuff that I already know about because of publications etc, and there’s not much value.’ So then he went to a conference for surgeons which he admitted was way beyond his league. And he said it was so interesting to see this different world, that he actually took away more from a conference with surgeons than those strategy meetings he went to for years and years. And that gave me the idea of just letting these people do what they want to do. It’s not a done deal that they have to spend their two weeks in-house. But most of them do. It’s not that we don’t send them to conferences. I might send them anyway.
“There is a correlation between value delivered and the commitment to what they do and feeling part of what they deliver in Agile development. They have these regular check-ups with the busines and it’s very nice if you build something for two weeks and ou present it to a business person and they are sitting there with a big smile on their face, because he has exactly what he wanted and he never had that before. There is a correlation between happiness, commitment and Agile development.”
SIG pointed that three of its clients which all delivered four or five star software quality had followed a Scrum-like approach or had adopted Agile principles. Scrum teams tend to be more cohesive because they are empowered: they have to do it themselves. They decide amongst themselves what to do to deliver the right product.
Remote working or co-location
In contrast to other IT working environments, there is little or no remote working in RIPE NCC’s software development, says Haye.
“We have everyone here in one environment, which helps create some trust, and understand who in the team does what. Then once they understood each other, then perhaps there’s some leeway for remote working.But first they had to establish the trust.”
“I think it depends what type of work you do,” says Kevan Hall. “I’m a big corporate person. The only area where I see the big global multinationals moving back to co-location is in very intensive R&D groups, such as the auto industry, because they seem to be unable to manage distributed R&D. One of the big challenges in distributed research teams is serendipity. It’s the bouncing off and the ideas and those kinds of things. You can do that when you get people together and you can to a certain extent do it through a conference call, and videoconferencing and WebEx and things like that.
“But even in an open-plan office, if you look at how far apart people’s desks are, that affects how often they just spontaneously talk. Anything up to ten metres, you talk. Anything beyond ten metres, forget it.”
Too much teamwork
“It may be shocking, but I actually spend quite a bit of my time trying to discourage teamwork, because one of the things in the kind of organisation that is distributed or global is that teamwork is really expensive. It requires people to be accessible in the same time, if not the same place. and for global teams, there isn’t a right time to do that. It’s also very expensive.
“So when the cost of something goes up, the demand for it should come down. But because we’ve got this almost unthinking attachment to teams for everything, it hasn’t. And when we ask people how they’re spending their time, they tell us they’re spending two days a week in meetings, and they get 60 emails a day, 85% of which is irrelevant. We’re just sharing too much stuff.
“I used to be in manufacturing and if somebody told me we were producing 50% scrap, we’d have had a really sharp discussion about the future of that factory. But we routinely accept 50% waste in collaboration. We have to be much more selective about when we use teams.”
Campaign4Change 