SDLC – Productive development teams.

Since I started running and managing teams, about 10 years ago, I’ve been trying to put my finger on what it is that makes a productive development team. Of all the teams I’ve worked with, what makes one team perform better than the others if we consider that both teams are filled with equally capable members. Now, I’m not asking what makes the developers more productive as in what characteristics do they have personally, I’m asking what do we, as management, put in place in terms of environment and culture that allows one team to succeed more than another.

Over the years I’ve identified, read, and learned about a number of things that motivate technical teams, but I think there are two aspects that are the most crucial. We must provide technical teams with;

• A quiet place to work with less interruption.
• Authority and ownership of their work.

A quiet place to work
I’ve known this for 18 years, since I first became a developer - developers need a quiet place to work, with few interruptions. This fact is by far, THE most important thing we need to put in place to get the best out of a development team. These days I spend around half of my time doing non-development work; meetings, design sessions, writing specs, planning and all that kind of stuff, but the other half of my time I’ve usually got my head in visual studio, writing code, and I can tell you that a noisy working environment is still the primary thing that stops me from getting things done. All developers find it difficult to work when sat next to the call centre, or sat across from Jean from accounting who can’t stop telling everyone about how her two cats have wonderfully expressive expressions and how they smell divine when they’ve just been given a kitty bath – nice!

When a developer is writing code, they have in their head a plethora of details about what they are doing – class names, method names they need to call, variables they need to populate, and sequences they need to follow. They are thinking about the layer they are presently working in, the UI lets say, but are contemplating changes up the stack into repositories, domain objects and/or the database – all of this is being worked out, real time, in their heads.

Now, think about it, you’ve got this big jenga stack of information in your grey matter when Jean decides to tell you again about how Fuddles can smile when she says kitty kat – see what happens, your concentration is shattered, the jenga bricks all fall down and you now need to spend 5 or 10 minutes picking them up again – you essentially stall and get thrown out of  “The Zone” and it takes time to get back into it.

Joel Spolsky articulates this, and some of the math behind getting into and out of the Zone, in a much better way than I ever could, so I encourage you to read his articles or book  “Joel on software”.

So how can management address this quiet place to work issue? This is the tricky part – ideally you want each developer in their own office, with a door they can close when they want no interruptions, but this unfortunately usually results in laughter with the board who just don’t understand how a developer does their job. You can convey with explicit detail why but 9 times out of 10, they won’t put the partitions up.

At the very least, get your development team insulated from the rest of the business. One partition to create a “development office” will go a long way to reducing the noise distraction from the rest of the business in the open plan environment but this is only a 15% step in the right direction. You’re still going to have in-team distraction, where developer A decides it’s quicker to ask developer B a question rather than spend 2 minutes hunting down the email that gives him the answer and the partition will only be a minor deterrent from Dave from support waltzing in and interrupting everyone at the same time, but a 15% step in the right direction is still better than Joan and her cats.

Moral of the story – you might not be able to go the whole hog and get every developer into a private office, but do something.

Authority and ownership
In my current role, I’m assigned a project to take on, I get a briefing and then I’m left to it. Sure there are governance reviews every few months, we usually have a project manager assigned to interface the client commercially and do the paper pushing such as weekly status reports back to the businesses (ours and the clients) to keep everyone happy, but from a technical design, development and team management perspective, I’m on my own – I take full ownership and responsibility for everything we do, and that my friend is empowerment which breeds motivation!

Now consider Kevin. Kevin works for the antithesis of my company and they are total control freaks, they need to micro manage the soul out of Kevin so that they know he’s doing exactly what they want him to do – even if they are the one’s in the worst position to be making technical decisions! Kevin gets on with code, line by line, writing to specification exactly what the management team are looking for, they check up on him hourly, tell him to change his code to work slightly differently and eventually Kevin either quits or comes into work with an AK47 and mows down the management team.

That’s an extreme example, but I have honestly seen that – well, not the AK47 part. I’ve been in more than one organisation before where the developers and architects are micro managed from up on high, told which technologies to use because the On-High-Manager had a conversation with someone the day before and decided that Service-Orientated-Entity-Hibernate was the up and coming technology that is the silver bullet for all their problems – the development team protest but are shot down and told to just get on with it and what do you know, 2 months later, they call in someone like me to help them work out what their problems are.

Developers need to own their work. Sure, architects and SDMs can put in place frameworks and prescribed approaches, but ultimately developers are a creative breed and so let them be creative, don’t confine them to a hell of micro management, give them a task, set some boundaries (the general architecture) and let them get on with it.

Now, I can hear some of those micro managers screaming now “what about the slackers” and the “people that take the proverbial”. Well, there’s three things I’d say to that. Firstly your recruitment process is wrong, Second, the reason they are slacking is more likely because of their lack of motivation due to being brow beaten daily and Three, your lightweight management process will weed out those who just, bluntly, aren’t up to standard.

Recruitment process
I say your recruitment process is wrong because if you have slackers or proverbial takers on your team, your process wasn’t good enough to weed them out. Did a couple of technical and highly motivated, passionate people interview them? Were they given a technical test to test their programming skills? Were they given a logical test to test their thought and reasoning? If not, your recruitment process is wrong and you’re going to let through some people who should be doing something else with their time, but shouldn’t be writing code for a living.

Brow beaten
When you’re running your development team in micro management mode, developers, who are creative by nature, start to lose motivation. When they have a spec that says, write some code, like this, that is so detailed that they have no creative input, they would probably sooner spend a day on facebook than actually write that stinking code you’ve told them to write. This is not the fault of the developer, this is poor management – it’s your job to remove things from their path that stop them doing their job and motivate them to do their best work whilst their job is to write beautiful code.

Lightweight management process to weed out the useless
So whilst I’m saying have more of a hands-off approach to management, you will still have a management method that will allow you to compare apples with apples. SCRUM is obviously one of my favourite approaches to running iterative development and it’s this that I think gives you a good tool to be able to monitor the performance of all developers and identify those who are struggling.

By working out what work was delivered by each individual in each sprint, you get not only a team velocity (how much work a team can generally carry out in each iteration), but also a velocity per team member. Now if Dave and John are hitting 40 points in a 2 week sprint but Alan is only hitting 10, you’ve got to ask why Alan’s productivity is so low – you don’t need to be all “up’in’Alan’s’Bizniss'” and micro manage him, you just need to identify his velocity slump and then ask what the problem is – if it’s because his cat died this week and so couldn’t get in the Zone, then fine, send him to grief counselling, but if it’s because he just can’t do the job, give him some opportunities to skill up but then I’m afraid it’s time to weed him out – you only want people on your team who get things done.

Conclusion
I’m not saying these are the only two things that you need to do to motivate a development team, but I am saying they are the two most important out of a long list. There’s more to the list, but others smarter than I have already covered this in detail (comfy chairs, large monitors, powerful pc’s, interesting work, the best tools and so on). If you can do only two things to motivate your team, I strongly urge you to do the two things above.