Requirements, people, and monsters (part 3)

The second major system in a development effort is the team. The key distinguishing characteristic of the team is: it is composed of people. People in all of their irrational, emotional, egocentric, and goofy glory.

People are not parts. People are not resources. People do not equate simply to developer hours.

You can’t even get along with the people in your family. How are you ever going to get along with the people on your development team?

For some the answer is a stern “professionalism” that pursues an illusion of the lack of any kind of emotion and requires team members to do the same. Thus sweeping their people-ness under the rug.

For others the solution is a harsh command-and-control environment. “I am the boss, you will do what I say. I don’t care about your personal issues.”

The stereotype of computer guys is that we like “hard science”: numbers, code, engineering. Not soft things like: psychology and people and emotions. Then one day you realize the people around you form the most complex system you will ever have to work with. People are the ultimate computers. People are the most complex software system we will ever deal with. The interactions between people form the most complex systems we will ever see.

But more than that, people are the most significant things we will encounter in our computer careers.

When you realize these things you will be driven out of your computer science hole and into the field of learning about and trying to understand people. Here are some key lessons about people.

People are all the same

Everyone else is just like you. We look at another person. We have a natural tendency to think we are categorically different than they. The stupid manager who has no idea what the code is doing. Our first thought is that they are a different type of person than us. The reality is they are the same type of person as us. The fact that they look stupid to us is more about where the two of us happened to meet. We meet after the manager had gone down his management path and I down my coder path. The difference between us is based on relation to each other, not fundamental differences in the kind of person he is and the kind of person I am. In your future you will go down a similar path and be viewed in a similar light.

But, even if you never become a manager, someone will accuse you of being a stupid manager some day. In the same way that politics works. Someone is a staunch liberal all of their life. Then they say something vaguely pro-business. Suddenly they are labeled a right-wing conservative.

With that in mind, consider:

The idiot programmer who can’t figure out the API. That is you.

The slacker who quits working and leaves you hanging when the deadline arrives. That is you.

The stupid manager who is blind to what is really happening. That is you.

The hotshot kid who thinks he knows everything. That is you.

The inept programmer who created an unmaintainable mess. That is you.

The clueless project manager who is completely. That is you.

Those are all you in the sense that they are people like you who are dealing with their circumstances and trying to get through the day as best they can. Someday you will look like them to someone else.

People are all different

You learn a bit about people and you start to categorize them. People hate to be categorized (at least I do!).

People hate to be labeled.

People hate to be psycho-analyzed.

People hate to feel like someone else has them “figured out”.

It is dehumanizing. Like reducing a person down to a “database administrator”. When you pigeon-hole someone you don’t pay due respect to their people-ness.

We are all unique and must be dealt with as individuals, not just as members of some categories.

The agile movement also brought these issues to the fore.

…we have come to value: Individuals and interactions over processes and tools…

Agile brought us daily meetings where you talk to each other. Agile brought us the idea of developers estimating their own work and signing up for their own tasks. Humanizing ideas.

To summarize then:

• People are the core of the development process
• People are the most complicated and unpredictable system in the process
• People are the most significant things we deal with
• (Oh.. and we all are one)

So go learn about people. Maybe read a classic like Peopleware. Or learn from a master like Jerry Weinberg and books like:

• The Secrets of Consulting
• Becoming a Technical Leader
• More Secrets of Consulting

WARNING: These are not your typical computer books. They may take you far outside of your comfort zone.

Requirements, people, and monsters (part 2)

Requirements. There is an ever growing, massive pile of requirements. This pile threatens to crush the development team under its weight. The agile movement taught us how to deal with this. Well… before that life taught us how to deal with this… one step at a time. The key to dealing with the pile of requirements is focus.

Planning Game

The planning game is one of the main ways to tame the requirements. First it does this by breaking the pile down into a few piles. Talk with the project sponsor about the requirements. Divide them into three buckets:

• items essential for launch

• items that are very important

• items that can be postponed

The names of these buckets are adjusted to accommodate your current project sponsor. The only important thing is that roughly two-thirds of the requirements are moved into a category of things “not to work on”.

Now apply this process iteratively. Take the remaining pile of “essential” items and continue breaking it down into sets of three buckets until the remaining items is small enough that you feel your sanity restored. This should be a couple of months worth of work.

That is the first key to the planning game, it is a form of triage that allows the team to focus on the essentials. The second aspect is related. Divide the essential elements into a series of very small releases, or iterations. Choose an iteration length of one to two weeks and layout the essential requirements into a series of iterations.

As much as possible have the project sponsor make the decisions about what features go in which iterations. The most important aspect of this part is to have the project sponsor make the changes to the iteration schedule. Give them a quota for how much can be in each iteration and then place the burden on them to arrange the requirements such that there is not too much in any one iteration. This is key because it creates a mechanism for the painful truth to be communicated directly to the sponsor. The truth is that 6 days of work cannot be crammed into 5 days.

If the game is setup correctly the sponsor feels this truth as a direct consequence of their actions, not as some arbitrary bad news that the development team has to tell them. So if the sponsor puts five more requirements into the next iteration then they should see that they need to remove five requirements in order to “make it fit”.

Iterations

Regardless of whether you can make the planning game work, iterations are essential for dealing with the pile. Take a tiny set of features from the pile and focus exclusively on them for a week or two and get them done. That is the essence of surviving and conquering the pile. (If you have a steady stream of support issues then leave room for this in your iteration plans.)

Successfully completing each iteration becomes the defining rhythm of the team. It is the basic stroke of the development engine.

Checklists

Completing iterations provides vital motivation to the team. But we frail humans need to be rewarded more often than once every week or two. We need daily reinforcement. So break the features for an iteration down into smaller steps that can be completed in a few hours. Get these listed for all of the team to see. Now developers can feel the satisfaction of crossing something off the list every day. Crossing items off of the list assures the team that the pile is being conquered.

So the team can survive the crush of the pile by dodging it. Don’t try and carry the weight of all of the requirements. Let the weight rest on the ground. Instead take on small parts of the pile at a time. Always take an amount that you can do and you build a pattern of success day after day, week after week.

Requirements, people, and monsters

Software development projects are dominated by three complex systems. First there are the requirements. Not just a few requirements but a massive mountain of requirements:

And it is a dangerous mountain that threatens to come tumbling down as an avalanche:

Crushing the development team. The second system: the team. A group of people. And that is their distinguishing characteristic. They are people. Weird people, creative people, confused people, confusing people, thinking people. That is the source of both their great annoyance and their charm… they are people:

But the people are not alone, they have built an application. They have created a monster:

A monster that requires constant care and feeding. A monster that occasionally goes on rampages threatening life and limb and demanding immediate attention.

That is the dangerous world we live in. A bunch of people under threat of being crushed in an avalanche of requirements and living with a monster. Sounds like fun, eh?

Assume the best

Gerald Weinberg gives the wise advice “regardless of how it looks, people are trying to be helpful”. You assume the best and give others the benefit of the doubt.

We need to apply a similar concept to communication. Communication is so faulty that any statement can be interpreted as true of false in some respect. Two people can say the exact same thing and you agree with one person and disagree with another. How can that be? Because a statement is just a token that represents a mountain full of assumptions and shared context.

When someone makes a statement to you, that statement is incomplete and open to interpretation. This is where you come in. You could assume the worst and make up all kinds of absurd notions behind the statement, or you could assume the best and make up valid assumptions behind the statement.

The way this difference is shown is what comes out of your mouth first. It will be either “no” or “yes”. It could be “no”, followed by your statement of how to make the statement correct. Or it could be “yes” followed by your statement of conditions that make the statement correct.

I am not suggesting that you say something false is true, merely that you give the benefit of the doubt, assume the best of the person, and seek the truth in their statement.

This is particularly important for leaders on projects. Often the leader is the leader because many of their ideas are good. This can easily lead to a syndrome in which the leader just sees the bad in everyone else’s ideas and repeatedly says “no” to everyone’s contributions.

So, after hearing someone else’s idea, listen for the first word out of your mouth.

There is no tomorrow

You know what needs to be done. But, the continuous press of crises prevents you from doing it. If you continually allow yourself to be carried along by urgent items and neglect the important ones, then you will fail. If you cannot make time to do the important things today, if you tell yourself that you will do them tomorrow, then you will fail because there is no tomorrow. Tomorrow will never come.

So make time each week and make time each day to do the important things.

This applies to you personally. This applies to your development work. Don’t say that you will clean up the code tomorrow, don’t say you will write some tests for your code tomorrow, do those things today.

This also applies to your development planning. As you schedule work to be done, make explicit plans for “strategic” items. These typically will not be part of delivering an immediate feature in a product, but they will enable future features. For example, hiring more developers, implementing an automated build server, or adopting a new development tool.

NOTE: Don’t allow these important items to keep you from delivering new features each week.