Tag Archives: Software Improvement Group

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

How a Dutch SME is helping make software energy efficient

By David Bicknell

It may take a little time, but in the future organisations will be able to track the energy efficiency of their software and know how much it is costing them to run.

It follows an idea developed by a Dutch SME that specialises in the quality of software. Amsterdam-based Software Improvement Group (SIG) has partnered with the nearby Hogeschool van Amsterdam (Amsterdam University of Applied Sciences)  to create the Software Energy Footprint Lab (SEFLab).

SEFLab is now setting out to establish how the quality of organisations’ software code affects their energy consumption. The work will couple SIG’s knowledge and expertise in software monitoring  with the enthusiasm and technical expertise of the local university students.

Campaign4Change asked Dr Joost Visser, SIG’s Head of Research how it is going about tackling the energy efficiency of software, and what elements of the problem it needs to examine.

Joost Visser: There are basically two types of this problem that you can break this down and look into. One is across the software lifecycle. So just as with software defects where the later you find them the more expensive they are, so with energy efficiency, if you try to optimise your software once it’s already in production, you may have to make an explicit investment that might not provide an adequate payback. But if you already know what requirements you need to keep in mind at the design stage for energy efficiency, then, for example, you might actually choose a different communication protocol which can improve your efficiency. At each of the development process, there are things to do: in requirements, in the coding and in the testing.

Another issue is the hierarchical level of software. The thing you might see as the consumer is the application. But actually that’s not the first level that impacts energy efficiency. The first level is the user themselves. In a car, the person that is actually touching the accelerator has a lot of influence on how much fuel you would use. To reduce your fuel usage, you may need to change your (driving) behaviour. The same thing applies with users of software. If they know what the consequences are of clicking here and searching there, they might behave slightly differently and it might have an impact on energy efficiency. If you give people feedback, they will behave differently.

C4C: What sort of user feedback have you had?

JV: We did a survey around 9 months ago where we asked a lot of users about these types of things and the overwhelming conclusion of that survey was that, ‘Yes, we would like to change our behaviour but at the moment we have nothing to go on. We don’t know how to make that change.’

There is a premium on green products. People want to be green – but they have to be able to make a meaningful choice. There are various elements to consider. First there is the application layer. Then we have the various components from which the software application is built: a database; a runtime environment framework, and Java as a virtual machine. Then underneath there’s the operating system. Microsoft has made a big effort in its operating system to take energy efficiency into account but I think there are many more steps to be made there. Then there is communication. You have to think about your mobile device uses radio to communicate when you’re browsing. You may have to make an explicit switch to a Wi-Fi network which might be more energy efficient. Is it more energy efficient than 3G? We don’t know yet. That is one of the things we’re going to find out.

C4C: One of the areas that many organisations are talking about is the impact of consumerisation and the use of touch devices creating a new user interface that organisations’ applications will have to be rewritten for. What does than mean from an energy efficiency perspective?

JV: One of the very very real challenges now is that we want to go to those new devices with mobile strategies but time to market dictates how we think about energy efficiency. So you might choose to do develop once on different devices but on many devices, there’s no accounting for the energy consumption. You might go to HTML5, for instance, but it might consume much more energy than when you create a native application. I think by making the choices visible, we will enable people to choose. We will take away the time-to-market issue and people will be able to say,’ OK, we can have this a couple of weeks later and still make things provably more energy efficient’, which consumers will appreciate.

C4C: Will we get to a stage where the consumer will think about the energy efficiency, or are they really only going to be thinking about the coolness of the product i.e. I want an iPad and I don’t really care what the energy efficiency is?

JV: Let’s be realistic about this. Consumers want to get hold of new things. They’re right – they’re consumers. So the coolness of the device has to incorporate the energy efficiency. It’s a lifestyle product. If you offer that, they’ll want it.

C4C: But in the corporate world previously, the IT department would buy the product. Now the user, the consumer, is buying the product and he or she wants a cool devices and they don’t really know about the energy efficiency side of things.

JV: If you compare it to other types of products, fridges, for instance, suppliers do compete on energy efficiency. They all want to be rated A, and that’s partly to do with regulation and partly to do with the demands of the customer. But an essential thing to make that work is that there is a measurement, a consumable rating, that’s meaningful. And now with software, we are developing the science behind it.

Is it about green hardware? Or is it using an energy efficient battery? Or just using a bigger battery? It gives you as a consumer the incentive to use it.  There is also the recycling of the batteries to be taken into account, of course.

C4C: Going back to the way the user is using the software. If you take the car analogy, ultimately there is a cost for you if you’re not driving efficiently. How do we portray those costs in terms of energy efficiency of software?

JV: Maybe you should get feedback about your consumption, not in terms of the litre of fuel you used, but in terms of euros. You want to make that last step. Similarly in software there is a lot of knowledge about CPU cycles and megabytes. But in the end you want to know what is the calorific value of what you’re doing. And that has to be put into some perspective.

C4C: If you were to take it to the nth degree, would you be able to get an idea of how much electricity or energy you had used in your browsing session?

JV: If you keep all your tabs open, do you as a user know if that has any impact, or is that negligible? If you knew it was consuming energy, maybe you’d take the trouble of closing them because it has value for you. Energy consumption goes further than simply your own device. If you’re browsing, you’re pulling information in, and the server starts doing things for you and data starts being generated. It might be stored, consuming energy, for the next 50 years. And it makes a difference how it gets archived or stored. All of this has to be made simple for the consumer to comprehend. Then there’s the organisational side, those organisations that have bespoke software built for them.

They might be interested in ‘green’ from the idealistic point of view. Their clients are interested too and they want to be socially responsible. But those organisations are also very much interested in the cost aspect. Energy costs are rising and it’s not just costs, but scarcity too. If more work implies more energy, at some point you may not be able to get it as easily as before. Either you will get it back in higher energy costs or it just won’t be there.

C4C: Is there any way you can create a benchmark or figure that talks about how much inefficient software usage can cost?

JV: Not yet. For data centre efficiency, there is the PUE. It has lots of drawbacks as well. But is has had a good impact and made choices more clear. We are working on it. We have some development of KPIs. But it’s hard. There’s a real research challenge here. One reason is the mapping of software applications to hardware. It’s not one to one. We may have one software application running on many pieces of hardware and due to virtualisation and other techniques, we have many applications running on the same hardware. With the hardware you can map how much energy goes through it. But how do you map that to the consumer of the energy i.e. the software? That’s a very difficult puzzle.

Another thing is that we’d all like to have a benchmark. To have a benchmark, you need comparable things. But think about it. You have online payments for a bank versus using a browser. The type of work you do with the software, the user transactions, so to speak, is completely different.  If one consumes a certain amount of energy and the other consumes double that, what does that mean? Does that mean the one that consumes more is worse? Not necessarily. It may simply be doing more work. So we have to develop KPIs that allow meaningful comparison. One suggestion is to how much energy per function point. That sounds good, but actually it’s completely wrong, because a function point is about functional size and how many features you offer.  Yet it doesn’t have anything about the workload in it. You have to involve the workload into the KPI otherwise it cannot work.

Now workload is something that’s completely different between different vendors and operations systems and end users. Comparing an operating system to an end user application will not work. That’s why we’re trying to build these up through the lab.

C4C: You could end up having two years of discussions between vendors over what would be an appropriate standard for energy efficient software, couldn’t you?

JV: The way to make these protracted processes shorter is to have people with lots of initiative who just go for it in their own sphere of influence, and show that it can be done, and create a reality that others can follow. International standardisation processes take a long time, but you shouldn’t wait for it. You should go for it.

Links

Software Energy Footprint Lab

8 ways to make your software more energy efficient

How the Dutch are taking a closer look at the energy efficiency of software

By David Bicknell

I am in Amsterdam to speak with a Dutch SME about its work examining the energy efficiency of software.

The Software Improvement Group (SIG) and the Hogeschool van Amsterdam (HvA) have come together to create the Software Energy Footprint Lab (SEFL).

The lab will enable researchers to examine such questions as:

  • How do different database management systems compare with each other in terms of energy consumption?
  • How do different programing languages/compilers compare in terms of energy consumption?
  • How do asynchronous requests compare to synchronous requests in terms of energy consumption?
  • How do unsigned integer arithmetic operations compare with signed arithmetic operations in terms of energy consumption?
  • How accurate are software energy profiling tools?

The laboratory will have computers rigged with sensors to measure the flow of electric current into each of the computer’s components. Specially crafted programs or generic benchmarks are then run with the sensors reporting on where the current is flowing to and how much of it is flowing to each component.

The relationship, which I’ll learn more about today, builds on the knowledge of electronics from the HvA together with SIG’s work into the technical quality of software which provides insight into the quality of organisations’ software projects, and therefore, the quality of their software suppliers.

8 ways to make your software more energy-efficient

By David Bicknell

I recently came across the Software Improvement Group, a Dutch company specialising in corporate software quality, which has produced some advice on how to make your software applications more energy-efficient. 

Its ‘quick wins’ include the following:

  • Reduce resolution of images and/or send them less frequently
  • Run multiple applications on shared servers
  • Reduce data translation between components
  • Log less
  • Delete historic data
  • Compile interpreted languages
  • Refrain from frivolous features
  • Avoid chatty protocols

The group points out that quick wins do not always apply and are only a first step towards energy efficiency. To create truly energy-efficient software applications requires attention during all phases of the development lifecycle, starting from requirements and design, through coding and testing, and finally on to deployment and operation.

Users do want efficient software