Dividing up tasks on software development teams

In that fuzzy state between sleeping and waking the other day, I had a revelation. Not an earth-shattering revelation: as revelations go, it’s about as insightful as the time I realised Maltesers are named the way they are because they contain malt. To 90% of people around me it was boringly self-evident. However, my more recent revelation relates to a blog post about software development teams that sparked a lot of discussion, so I thought I’d share it.

How to successfully set tasks for a development team?

Here goes…

The unresolved question

I recently posted an article with a summary of opinions about who should write the words in software user interfaces. In collecting the ideas that went into that article, and in the discussions that it kicked off, what struck me was how absolutely convinced everyone was of their way being the best way – sometimes even the only right way – of getting the right person doing the job of choosing the words for the UI – in spite of hearing that other teams did it completely differently, with great success:

How could so many successful teams be so absolutely convinced that their way of dividing the tasks in software UI development was the only right one, though they knew other companies were equally successful with an entirely different approach?

The revelation

Here it comes…

I think the reason the post was so popular is the same as the reason everyone was so convinced they had the only right way of getting the UI done well: we think of software development teams as abstract sets of people in specific roles, with each role having responsibilities associated with it, whereas in reality, teams are actually made up of specific different people, each with various sets of skills.

I warned you: as revelations go, this is not at the earth-shattering end of the scale. It got me thinking, though.

Here’s a bit more about what I mean:

How we tend to see teams

A typical software team includes people with various roles: developers and testers, perhaps also project manager, technical author, user experience designer, product manager, product support specialist, systems architect, and so on, depending on the size and maturity of the team, and the nature of the product.

With each of those roles comes an expectation of which jobs the person will do. From my experience on smallish software teams, something along these lines is fairly common:

Building a new software development team?

Well, we know how a software development team works, from previous experience: we’ll need a few developers, a couple of testers, and a technical author (Something like that). We know what things each of those will do, because we know what those roles did in previous teams, so we’ll recruit people who can do those roles. This might be hard – e.g. finding developers who can design UIs is sometimes tricky (but developers design UIs, so that’s who we’ll look for to do the job).

This is the school of team-development that believes that if, say, a developer leaves their team, they can be replaced seamlessly and with no delay other than the time it takes for the new developer to get the required knowledge in place – because all people of a particular role are more or less equivalent in their range of skills.

How it could be: starting from scratch…

Here’s an alternative scenario. You’re building an entirely new sort of software, something so radically different that you’re not sure yet what roles you want on the team: all you do know is that you’re going to need people with these skills:

• finding out what users want
• finding out about the context that users work in
• designing visually attractive screens
• technical architecture design
• choosing words that people can understand
• creating video content to demonstrate features
• writing instructions
• coding UIs
• coding back-end functionality (engines)
• functional testing
• unit-testing
• usability testing
• communicating with users
• making decisions about the order of work
• communicating with the business
• help users get the most out of owning the software
• keeping other team members motivated
• providing biscuits in meetings

and so on…

If you were to go out and recruit people based on trying to find, say,  5 people who between them had this set of skills – regardless of their previous job role – I wonder what set of people you’d find you had on your team?

Obviously, this isn’t a scenario that software teams find themselves in – there’s really no such thing as a brand new fresh team with no history – even if you recruited according to a set of skills like this, you’d still find you had someone who was a project manager or technical author in a previous team, and had fixed ideas about what they should do, based on the similarities between the previous team and the present on. But I do think it could be an interesting exercise to try to look at teams with fresh eyes in this way – people aren’t interchangeable… and teams are nothing but collections of people working together towards a common goal, each with their own strengths and skills.

What does this mean for the question of who should write the words in the UI?

It turns out, this grand revelation is just an extension of something I rant about regularly – whenever questions come up about who should write the words in a UI, whether developers should write product help or design UIs, whether technical authors can project-manage software development projects … and so on:

Who should do what task depends on the situation and the person!

Theoretically, there’s no reason why a developer can’t design a visually appealing and highly usable GUI … but whether a specific developer in a specific team can do it is going to depend on their particular skill-set and the other demands on their time.

This reminds me of an example that Karen Mardahl shared with me recently, of the difference between general questions and questions about specifics (I think this came from Karen’s involvement in a workshop on “Statistics without maths”):

Quite different questions! In a similar vein:

“Who should write the words in the UI?”
“Who should write the words in this UI, for this product, on this team?”

The interest that my recent blog post got suggested that the first question was very compelling … and yet it’s only by answering the second question that you get an answer that you can really act on with a strong hope of success. And the answers aren’t going to be the same: people are at least as varied as revels, aren’t they?

Originally published 18.10.11