“That it is people who write software is terribly obvious . . . and ignored.” So quotes Alistair Cockburn, himself quoting Gerald Weinberg, in his book Agile Software Development. It’s easy to see the people in your project as mere commodities – not helped by MS Project’s insistence on labelling them as “resources” – hot-swappable units that may be switched in and out of different roles or different projects, with no loss in productivity, creativity or morale.
Of course, the reality is different. The teamwork, communication and interpersonal aspects of software development are fundamental to software agility. Selecting the right people to work on your project can mean the difference between a failed project and a successful one, before it’s really even started.
Naturally, it helps to find developers skilled in the right technology (Java, C#, etc.), but it isn’t nearly as important as some job agencies would have us believe. A good software developer will relish the opportunity to learn new skills on the job, and given the chance will do so quickly – they may even bring a fresh perspective to the table. And besides, demanding specific skills up-front only increases the danger that job candidates will simply exaggerate their achievements on their CVs, then try to blag their way through the interview.
Non-core skills are arguably more important than prior experience with specific technologies. Do some team members need to be able to write well; or to have a good understanding of testing; or be able to present ideas clearly? Do they need good questioning skills: the innate dogged persistence required to keep asking the hard questions until the real requirements are arrived at, or to create a design that matches those requirements? Having a good head for design – the ability to design an elegant solution to some complex and multi-faceted requirements – is an inestimably crucial quality for an effective developer.
Give me one such quality developer over twenty rubbish code-cutters who happen to have the right skills on their CV any day.
On the team dynamics front, it’s important to get a mixture of personality types and behavioural styles. A good team is like a good diet: well balanced (with apologies to Atkins devotees). One team member may be disciplined but inflexible; another may be co-operative and a good listener, but indecisive. If you’re interested in team-player classification, a useful system was developed by Dr. R. Meredith Belbin. It identifies various roles and highlights their strengths and weaknesses.
So you’ve selected your dream team of intelligent and able developers. The formidable aura of competency and sheer ability permeates the room like the purring of a shiny new eight-cylinder BMW. Now how do you harness their perfectly balanced mesh of skills? With strict procedures and sign-off gateways to keep their pesky “prima donna” attitudes in check? Iron-clad design specs rattled off by a part-time architectural consultant? Uh-huh. If you try to dictate every decision to them, you may as well have not bothered in the first place. For a team to work effectively, it must feel a sense of ownership of the work it undertakes. Most people are prepared to give things a try if they believe their feedback is going to be taken into account.
Human factors are fundamental to software agility, and different processes put different amounts of emphasis on them. We explore the human factors, and compare the major agile processes, in Agile Development with ICONIX Process< (co-written with Doug Rosenberg and Mark Collins-Cope). Plus, I’ll return to these human factors often in future “Agile Iconoclast” articles. ®