Process and People

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.

However, many modern software development efforts are simply too large to be attempted by two or three people and 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, or heavily over-specified, or simply does not fit with the company culture or maturity level. Combine it with a poorly-motivated team missing key technical skills required, 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.

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.

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 that is more than simply sending individuals on a range of technical training courses.

Individual Productivity

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.

People vs. Resources

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, and some simply do not function well at all on Tuesdays, or Monday morning, for example.

Software development processes that consistently deliver results have had a large dose of psychology applied in their creation. They are also flexible enough to adapt to a teams' particular strengths and weaknesses.