Brunel University's Business Class: Getting IT teams to work together better

From extreme programming to moving IT pros around the business and out of 'comfort zones', Brunel's Professor Robert Macredie and Dr Mark Lycett reckon there are various ways to get more out of staff, helping them develop an agile mindset. Is your organisation brave enough to try the following?

While the nature versus nurture argument may not yet be resolved, it’s fair to say that we’re largely moulded by our education and experience. As we progress through our professional lives, education and those around us shape our expertise - with this experience dictating a ‘framework’ of how we approach tasks.

In the world of software developers, as in any other discipline, this can create boundaries in the way we work – for example, choosing inappropriate technology for the job on the basis of familiarity. Approaching work with the baggage of experience is perhaps inevitable but reappraisal and learning in relation to context is vital to extend and improve the way we work.

For this to happen, the first step is to raise self-awareness. We have to recognise our very human tendency of sticking within comfort zones, understand the extent and limitations of these confines before we can break out of them.

Do I tend to always stick to one process? Should I challenge this process? Is it always the right one for the job or do I choose it simply out of familiarity? The longer questions like these are delayed, the harder the cycle is to break.

Breaking the mould

Once there is awareness of the constraints, the next step is to widen the sphere of experience. Working in an environment that constantly stimulates, where there is a high level of interaction between groups is a good starting point. Just as the true value of a training course is not drawn merely from the teaching, but from sharing experiences with peers, the more outside influences you meet, the more likely you are to go beyond the ‘accepted’ way of thinking within your current environment.

It’s this situation that has espoused the idea of ‘extreme programming’, which advocates small programming groups, high levels of communication and an agile approach to developing software. Extreme programming focuses on incremental development – a ‘get something started’ approach to building a product with continual testing and revision. It has its drawbacks but is a good way of ensuring constant communication with others (mandating exposure of assumptions and ideas), which helps people break out of traditional comfort zones.

Choosing the best

The next question to ask is how people are chosen to carry out certain tasks. A recent survey of around a hundred IT workers conducted by Brunel University looked into the factors rated as important in the development process. Development processes are seen to be flexible - they are tailored by most of the respondents. However, the human element is getting lost.

While 47 per cent of respondents valued human factors over those of cost, time and quality, this is not necessarily translated into reality - only 22 per cent of respondents take team skills into account during the tailoring process.

What these results show is that people have forgotten that developers are human: that, without support, they may not necessarily be able to adapt to any development situation. Resources and budgets tend to take priority over the common sense approach of choosing the best person for the job.

Stopping the conveyer belt

These are tough decisions to be made but it would be interesting to take the survey a step further and measure what effect the current decision procedure has on the eventual output.

Perhaps this ‘factory’ approach to development doesn’t just harm the quality of the software developed in the short term but also carries long term consequences. If decisions are made on cost and resource rather than personal experience, then no effort is made to challenge and improve developers’ skills by extending their knowledge – which takes us back to that comforting circle of experience. Without extending their knowledge, developers are likely to follow the same working practices as their peers.

Many companies have extensive graduate training schemes, which expose trainees to different parts of the business in order to improve their understanding and awareness. Perhaps it’s time this type of development ethos was extended to those already working within the IT department.

From the companies’ perspectives, there is a cost attached to encouraging development teams to ‘unlearn’ the familiar and venture into the unknown – as well as a cost to non-standardised approaches. Only recently, analyst house Forrester rekindled the discussion on standardisation, arguing that wide scale standardisation saves time and money, meaning that IT bosses can focus on emerging technology. However, the other side of the coin is that ‘unthinking practice’ could impair software quality.

It’s the IT bosses' job to assess the risks involved, balancing these two costs. If they decide that developers need to move beyond traditional comfort zones, organisations should provide encouragement, support and reward.

It may be that there’s no right and wrong answer to the risk conundrum. But we need to ask the questions.

Professor Robert Macredie and Dr Mark Lycett are leaders of ‘Fluid Business’, a groundbreaking research project within the Department of Information Systems and Computing at Brunel University. They will be writing for silicon.com on issues of technology and business over the coming months and can be contacted by emailing FluidBusinessTeam@fusepr.com. Or email us with your opinions at editorial@silicon.com.