Notes by Stephen R. Palmer
Jeff De Luca says his first law of information technology is, "IT is 80% psychology and 20% technology". Although I agree wholeheartedly, I find this somewhat annoying because it means the greater part of software development is actually about learning to communicate and work with other people rather than just designing and writing source code.
It wouldn't be too bad if all software projects were small enough to be designed and built by one or two developers working closely with a customer or other domain expert. Then it is relatively easy to agree informally how to work best together.
Unfortunately, many modern software development efforts are simply too large to be attempted by two or three people. The only option is to use a larger team of people (or multiple, coordinated, small teams). These teams need some formal rules and guidelines about who does what and when if the effort is to stand any chance of success. These rules and guidelines form the project's process.
I have worked on projects of different
sizes in different industries in different parts of the world. No two of these projects have had
exactly the same ways of doing things even when they are supposedly
following the same process. This is simply because no
two projects have had exactly the same people working on them or
faced exactly the same challenges.
More recently, the projects I have worked on have used agile approaches like eXtreme Programming, Scrum, and Feature-Driven Development (FDD). Several of the others were significant projects that successfully delivered using more traditional approaches. The projects that have delivered successfully did not have a particular process in common. What they did have in common was a good team of people.
Good teams have people with the right mix of technical skills, experience, motivation, and personalities. Motivated people that can work well together are as important, if not more important, than technical skills and experience.
Training, coaching and consultancy can help fill gaps in skills and experience but it is largely a waste of time for people that are not motivated or that have no real desire to learn. Improving the morale and motivation of a team requires skilled leadership and management.
Take a poor process, one that is either too abstract, incomplete, heavily over-specified, or simply does not fit with the company culture or maturity level. Combine it with a poorly-motivated team missing key required technical skills, short on experience, and whose members have not learned to work well together. Now there is a great recipe for failure!
In cases like this, fixing the process is only a part of the
answer and not the most important part. In fact, a poor team
by definition will find it very hard to fix the way they work.
Speaking from experience, they may not even be able to agree on
what areas the process should cover or at what level of detail to
stop defining rules and guidelines. Process never makes up for
poor people.
In contrast, a good team of people
will usually find ways to work around problems and fill in the gaps
in a poor or incomplete process. It is part of what makes them a good
team.
On the whole, I have been fortunate to work on good teams, some very good. This has largely been due to the project managers and technical leads on those teams working very hard with their managers and HR departments to ensure they have good people assigned to or hired for the project.
The bottom line is that process
improvement is much more effective when the people side of things
is also addressed, and this is more than simply sending individuals
on a range of technical training courses.
Some software analysts, designers, and developers are more productive than others, sometimes as much as ten or twenty times more productive. [Brooks, De Marco, Weinberg]
Even if the best were only twice as good as the rest, it still makes financial sense to pay twice as much to employ them due to savings made in office space, equipment, and other facilities. When they might be ten or even twenty times better, the financial argument for paying more to employ them makes even more sense.
The trick of course, is attracting the best software people to your organisation, recognising them, and then keeping them. This, of course, takes considerable effort. It is far easier for a software development organisation to peg the salaries they offer to the industry average and base hiring decisions on little more than the general appearance and contents of a candidate's resume.
Unfortunately, as the old saying goes, 'You get what you pay for!'. If you pay industry average salaries you will generally get industry average analysts, designers, and developers, and need to hire far more of them to reach the same productivity levels that hiring well above the industry average would.
It is not even as if attracting and keeping good people means paying disproportionately more for them. A good office environment, professional development opportunities, feeling part of something special, working with other good people, and so on, are often as important. Using good software processes is part of that but the amount of time and money some organisations spend on their software development processes compared to the amount of time and money spent on their human resources processes is disproportionate.
The reality for many software team leads and project managers is that they have a team of mixed abilities, varying amounts experience, with different personalities. The trick is to find effective ways of working together that get the most out of the team, taking advantage of particular strengths and mitigating any particular weaknesses.
Unfortunately many software development processes and supporting project management tools seem to be written as if people are interchangeable, consistent, logical, software-producing machines. This is ridiculous.
People are emotional and fallible. They can be inspired and motivated one day, and frustrated and demoralised the next. They can be highly creative and resourceful but they also get tired and fall sick. Some work better in the morning, others in the afternoon, some simply do not function well at all on Tuesdays for some strange reason, and some hate Monday mornings, for example.
Software development processes that consistently deliver results
have had a large dose of psychology applied in their creation. They are
not simply lists of roles, tasks and artifact templates. They
are flexible enough to adapt to a teams' particular strengths
and weaknesses. This is why I like Feature-Driven
Development so much and dislike process improvement programs that
do little more than throw products like the Rational Unified Process at
software teams and expect productivity to improve.
More on Software Development Process...