Human Factors

That it is people who write software is terribly obvious … and ignored.^[4.]

So quotes Alistair Cockburn (himself quoting Gerald Weinberg) in his book Agile Software Development. While it is beyond the scope of this book to give the full coverage to the teamwork, communication, and interpersonal aspects of software development, we would be doing a disservice to our readers if we didn’t touch on these topics to some degree. That is the purpose of this section.

Choosing the Right Team

Probably the most important decisions you will make—if charged with running a project—relate to selecting the people to work on the project. Getting this right requires matching the people to the technology and skill roles, while also making sure you get the right team dynamics.

From a technology point of view, getting skills in the right technology (Java, C#, etc.) is important, but it’s perhaps overstated (in job advertisements, at least). A good software developer will be able to learn a lot on the job given the opportunity. Noncore skills may also be important. Do some team members need to be able to write well? Do they need a good understanding of testing? Do they need to be able to present ideas clearly? Do they need good questioning skills? A good understanding of the broader skill needs of your project is important in selecting the right team.

On the team dynamics front, it’s important to get a mixture of personality types and behavioral styles. A good team is like a good diet: well balanced (with apologies to Atkins devotees). In particular, having too many people who want to occupy the same “space” can cause conflicts.

One particular system of team-player classification that we’ve found useful was developed by Dr. R. Meredith Belbin. It identifies various roles and highlights their strengths and weaknesses (see www.belbin.com/belbin-team-roles.htm).

Team Buy-in

If you select a group of intelligent and able people, and then 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, be that with respect to the development process or any other aspects of the project. This applies equally to the development approach.

Having said that, most people are prepared to give things a try if they believe their feedback is going to be taken into account. By holding well-chaired (increment-based) regular reviews of major working practices, you can maintain a sense of ownership and self-determination. This approach will also have the not insubstantial side effect of actually improving the practices themselves!

One area of particular importance in software development is getting team buy-in on project timescales. We discuss the trade-off between scope and timescales in Chapter 9, but getting developers to estimate and monitor the time spent on their own work is particularly important if you want them to actually try to meet the estimates.

Motivation

Understanding what motivates people is a difficult topic; every person has different motivations.

Remuneration is obviously important, but as Alistair Cockburn discusses as some length in his book Agile Software Development, developers are also motivated by contributing something of value and having that contribution recognized. This illustrates that software developers are, perhaps counter to some perceptions, human beings with feelings after all! Failure to give feedback that clearly demonstrates the developers’ value can often lead to an unmotivated team.

On a more individual level, if you take the time to understand how each team member sees himself progressing in his career, it will be possible to harness his desires to the benefit of the project as a whole. By understanding the skills the team members will need to fulfill their envisaged future roles, and matching these against the needs of the current project, you can create a win-win situation that benefits all. Most people want to learn and progress, and doing the thing they already know best can sometimes be tedious. So giving people the opportunity to learn something new can be the right move (bearing in mind, of course, the risk associated with the activity in question).

Levels of Ability

In Agile Software Development, Cockburn discusses three distinct “levels” at which people may work:^[5.]

• Following (early stages of learning, often accompanied by step-by-step guidance)

• Detaching (trying out new ways of doing things)

• Transcending (fluency)

A not dissimilar classification has four stages of learning:

• Unconsciously unconscious stage (you don’t know it, and you don’t know you don’t know it)

• Consciously unconscious stage (you’ve at least worked out what you don’t know)

• Consciously conscious stage (you’re learning and doing, but you’re actively having to think about it)

• Unconsciously conscious stage (you know it, and you don’t really even have to think about it)

Both approaches are useful in determining who is best suited to undertake a particular role and the level of support, guidance, and mentoring she’ll need to do so.

Feedback

A simple rule to follow is to always give as much positive feedback as you do negative. It is all too easy to give a misleading impression of your opinion of someone by only pointing out mistakes.

Communication

A couple of years ago, one of the authors chaired a conference panel session made up of the great and the good from both industry and academia. The session was entitled “What Is Software Architecture?” Surely, there could be no disagreement over the meaning of “software architecture,” a fundamental term in our industry. Wrong! Definitions varied between “the components and their interrelationships that make up a system” to “the runtime deployment structure of a system” to “the patterns and styles of development that are used in the development of a system.” We passed a happy hour discussing the pros and cons of these various alternative definitions—without, of course, coming to any concrete conclusion at the end.

The fact is that miscommunication is rife in the software development industry. Given the invisible and abstract nature of the things we have to communicate about (e.g., threads, processes, classes, control flows, etc.), and that we often have to delve into domains of which we have no previous experience (e.g., finance, healthcare), this is perhaps not so difficult to understand. Almost every term we use is loaded with multiple meanings, and if you ever have to visit different companies on a consultancy basis, one of the first challenges you’ll face is reconciling your understanding of a term with your client’s (potentially multiple) uses of the same term.

Misunderstandings and miscommunication can occur on a daily basis within teams if team members are not on their guard. On many occasions, we’ve seen people discuss an issue and apparently agree on a resolution, only to come back to each other later saying, “But we agreed to do this…”—the only problem being that the “this” in question was misinterpreted by the parties involved.

We all carry our own baggage with us (this is often called “experience”) and our perceptions of what we think is important. Our understanding of terminology or what someone else is saying is inevitably clouded by this “baggage.” Unfortunately (or perhaps fortunately), we all have different experiences, so faced with the inevitable holes in what we actually “say” to each other (be that verbally—face to face—or in writing), it is our differing experiences that may well fill the gaps.

The only thing we can do to rectify these types of misunderstandings is establish a culture of communication in our project teams and encourage everyone to accept responsibility for avoiding miscommunication. The sections that follow present some techniques that can help in establishing this type of culture.

Establish a Common Vocabulary

Developing the domain model and use cases in Agile ICONIX gives us an opportunity to establish a common and well-understood set of problem domain terms. During the development of these artifacts, working hard to be as concise and consistent as possible will reduce miscommunication down the line.

Display Major Artifacts Visibly

To encourage a common understanding of what you’re doing, you should display major ICONIX artifacts visibly in your development area (on a bulletin board on the wall, if possible). In particular, these are all ideal candidates for public display:

• Domain model diagrams

• Use case summary diagrams

• Subsystem/package decompositions and dependencies (not, per se, ICONIX, but…)

• Key interaction diagrams/class model fragments (e.g., a typical persistence subsystem interaction)

Drive Your Development Based on Feedback

Being feedback driven is at the heart of Agile ICONIX, and for good reason: nothing reveals misunderstandings as dramatically as having to round-trip the whole development process at regular intervals. Doing this will bring any communication issues—be they within the team (analyst to developer, developer to developer) or between the customer and the team—sharply into focus. Identifying and actively reducing miscommunication will help you deliver the right working software to your clients.

Get Test-Driven Requirements Feedback

Another useful technique is to have one developer generate tests for a particular part of a system and another developer implement that part of the system. The chances of two developers both misunderstanding requirements in the same way are fairly remote, so miscommunication is likely to manifest itself as a divergence between expected and actual test results. We discuss Test-Driven Development (TDD) further in Chapters Chapter 12).

Review Misunderstandings

ICONIX Process encourages reviews at regular intervals, and particular attention should be paid to potential miscommunication during these.

Ask and Answer

Be willing to both ask questions of others and answer their questions. It’s very easy when developing software to get into “head-down” mode; sometimes the silence of development teams can be quite overwhelming! But remember, software development is most often a team-based activity, and that means members must be willing to ask questions of others when necessary and answer questions when asked. RTFM isn’t the desired response in a high-communication environment.

The following are some further tips for communicating effectively in a team environment:

When you’re listening

• Be careful when making assumptions about what a person is saying to you.

• Restate what has been said to you in your own words.

• Demonstrate your understanding by stating the logical consequences of what has been said, and request confirmation that these consequences are correct.

• Ask questions that probe the point(s) being raised in such a manner as to confirm your understanding (and to keep you interested in what is being said).

• Most of all, don’t be afraid to say you don’t understand!

When you’re speaking

• Check understanding by weaving questions into your dialogue that require thought and comprehension to answer correctly.

• Be interactive to keep your listeners interested.

• Look for visual cues that your listeners have (or haven’t) understood correctly.

• Use diagrams, analogies, and so forth to clarify your points.

When you’re writing

• Say it in as few words as possible (but not too few). Avoid obfuscatory scrivenery.

• Directly address any misunderstandings you’ve encountered before (say, during increment reviews).

• Use terms consistently, to an agreed standard (e.g., domain model). Writing prose and writing technical specs are different things—don’t use another word just for the sake of doing so when talking about technical items.

• Do try and keep your readers’ interest (the odd enticing forward reference or bit of humor can sometimes help here).

When you’re reading

• Expect to read it twice—the first time to raise questions, and the second time to look for answers to those questions.

• Build a list of questions that come to mind as you read during the first pass.

• Look for answers to unanswered questions during the second pass.

• If it is a very long, dry text, take regular coffee breaks!

^[4.]Alistair Cockburn, Agile Software Development (New York: Addison-Wesley, 2001).

^[5.]Ibid.