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.

Be ready to ship at a moment’s notice

The software game is unpredictable. The customer might decide they need the software today instead of next week. Or the priorities might change and you will be called off of your current task. To ensure that your work is not wasted it has to be ready to ship at all times.

Do your work in such a way that is is always done. Not that it is completely done, but it is always partially done. The key is that it must be ready to ship at a moments notice.

How do you do that? You first implement features as thin, end-to-end strands. Then you bulk it up one additional strand at a time. To put it another way: first get a rough version of the feature working, then add the bells and whistles, one-by-one.

Software game

Think of software development as a game like Alistair Cockburn describes. Not a “game” in the sense of people playing games to manipulate others; but a game as a metaphor for the process.

Think about the things you typically do, the moves that you make. Think about the moves that others make, and how you respond. Think of the moves that are mostly destructive versus those that are constructive and help move the process in a good direction.

Once you have been in this business long enough you will recognize the moves. Then you can take a step back from the daily pain of development and appreciate what is going on. For example, the project sponsor getting upset about the lack of progress and demanding more visibility into the process is not a new, unique event. Rather it is a standard move that sponsors make.