Tag Archives: teams

How do you create successful software development teams? (Part 2: Outsourcing)

By David Bicknell

I recently reported on a roundtable organised by the Dutch software specialist Software Improvement Group (SIG) which set out to determine 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.

In Part One of the discussion, which focused on creating excellent teams in software development, we examined teamwork, Agile empowerment, a commitment to quality, remote working and getting the right level of teamwork.

In this part of the discussion, we focused on managing multi-disciplinary teams, structure, reducing waste, and outsourcing.

Managing multi-disciplinary teams

Kevan Hall pointed out that when you’re working in a multi-disciplinary environment – for example, if you’re building a very complex piece of kit with tens of thousands of bits – there is a point at which you need to have some co-ordination.

But he added, “There is also a big part of the work where I’m an engineer off doing actual work or I’m somewhere writing code. And that’s not teamwork.  If we have this mentality that everything we do is a team, then we can’t make a decision until the next meeting. I distinguish between a team, which is kind of truly interdependent i.e. if you’ve got multi-disciplinary skills, R&D etc,  you really need to work collaboratively, tightly, and you can’t do it on your own, you need teamwork. But most work isn’t like that: most work is me doing my stuff.

“And therefore a simple hub and spoke group of organisations might be much simpler to do that. When you’re working globally, or virtually, that’s much, much easier because in a hub and spoke structure, if I want to talk to you, I just pick up the phone.  If I’m in a team, I have to go into all your Outlook diaries and hope that in the next month, you’ve got some time where we can at least all get on the phone.

“So hub and spoke is much simpler for virtual teams and for remoteness and those kind of things. So when we are  working collaboratively that’s when we really need to focus because it’s really expensive and quite hard to do.”

Waste reduction and communication

Andrew de la Haye from RIPE explained the need for what he describes as ‘waste reduction.’

“One of the things we do as standard culture in our software teams is every three to four months we do waste reduction sessions. So in the old methodology, you do retrospectives. You start a sprint – a sprint is two weeks – you deliver to the business, and after that, the team sits together and then they discuss what went well and what should be improved in the next sprint. And as a larger group in the whole department, we get them together once every four months for an hour or two at the most and we say, ‘OK. Where is waste? Where do we see waste?”

“And most of the time it is not coding or the real work they do, most of the time it is in the communications area.  And we try to get rid of it. So we changed the team from 2 x 6 to 3 x 4 people. It’s just part of our being to look at the waste we created after the last period and where can we improve. And they became  much more efficient and effective.”

According to Kevan Hall, one of the things you often see with teams is the ‘community decay curve’.

“When you have a team, virtual or not, you have a kick off and everyone’s very enthusiastic. And then you start doing the work, and it’s quite hard. And then you come to the end of something and you’ve succeeded and you have a celebration. Successful virtual teams create a rhythm. For our teams, it’s a year. You have a long old slog and there is a ‘periodicity’ of communication. A software team is perfect because you have a closure, a learning opportunity, a celebration and then you go and do it again. If it’s longer than that, then you have to think about other things that are going to have an impact, like a conference call or a coaching call.

“Even worse, if you’re managing a remote organisation or a remote supplier, the risk is that you only call them when you need something or you’ve got a problem. So they don’t really look forward to your next call. ‘Oh, no. Look who’s on the phone.’ You demotivate people just by your number coming up. It’s about keeping that rhythm. It’s a bit like an ECG. You’ve got to create those peaks to keep motivation high.

“Social media has a very powerful role to play in virtual teams, because it’s much easier to share the other things that I’m doing rather than just project updates. I also like Instant Messenger because if you have people in Asia you can see that they’re ‘on’ and to me it’s just like passing someone in the corridor. It’s the virtual coffee machine. Occasionally, people will see say, ‘If you’re there, can we have a quick call?’ And it’s another part of the rhythm for me – like keeping the heartbeat going.”

Outsourcing

“I used to sell a lot of outsourcing,” said Andrew de la Haye. “But I haven’t seen it really working (teamwise). One of the issues with outsourcing is the commitment bit, which is very important in my teams. My people are committed to me because they know me, and they know what the company stands for. If you outsource to somebody, who are they committed to? You hope that they are committed to the organisation they’re working for, but they’re certainly not committed to you. And they are probably more committed to themselves, especially in India because people move around like crazy.

“So one of the issues with outsourcing is the lack of commitment, I think. I don’t see a solution to that. There are two ways of outsourcing: outsourcing commodity items, where there is a new version of SAP and people need to upgrade. That kind of stuff. That’s good enough – it will work fine. But if you truly need to build applications and you need to work together with a company to create business value, and that’s what a lot of outsourcing is about as well, I haven’t seen it working.

“I tried it again last year, and I gave a company a chance. I had a really good relationship with this consulting firm and they told me that they had an excellent team in India, and ‘Let’s try this project just for a three-month trial.’ And it was more or less the only project in the last five years that went belly-up.”

As Kevan Hall pointed out, when you’re managing across distance, culture, time zones, working through technology, and commercial considerations, outsourcing is so much more complex.

“One of the things we see a lot with clients who have outsourced is what I call the balance of trust and control. Because I don’t know you and I don’t trust you, I tend to control you. And so we go out to India and we have these incredibly heavy processes which we beat you up to make sure you follow without any sense of initiative or change, and then you start complaining that the Indians don’t have any initiative and don’t innovate.

“Well, you’ve told them not to and they’ve very smart people, albeit with higher turnover, and then you’re finding that problem of ‘how do we build trust?’ So many organisations outsource processes and spend an enormous amount of time on process, but they don’t have the travel budget to even go and meet the people who are doing a service for them.

“So how are you ever going to build a relationship? You wouldn’t do it in your own business. So doing it in an even more complex environment…how’s that going to work?”

“You have to look at the type of activity being outsourced,” said Dr Joost Visser, SIG’s Head of Research . “There is a lot of success in outsourcing in all sort of activities. In software application development where you are trying to create business value and where people are being creative, like in the automotive industry, thinking of the next engine or concept car, I think that by basically taking the team you need and pulling it out over locations and over time zones, you’re creating a challenge for the teamwork you need for that activity.”

There is another factor: the customer, suggested Kevan Hall.

“If you decided that you’re going to bring your development team into one place and therefore take away one barrier to complexity, which is distance, which makes a lot of sense, then aren’t you just exporting that level of complexity to the customer? Because they still have to manage with the fact that they still have stakeholders spread around the world in different time zones and different cultures. And they’ve got complex needs. It’s OK for you now. But is that the right thing to do for the customer?

“Human Resources has done that. They’ve gone to specialist centres and business partners. And all that’s done is that the business partner has to manage all the complexity rather than the organisation.”

How do you create successful software development teams? (Part 1)

How do you create successful software development teams? (Part 1)

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.”