Do not constrain projects with detailed up front requirements

My prior post promised to look at the root causes of the obstacles that I mentioned in my July 25 post. So let’s do it!

The first “stumbling block” was, “Need to not constrain projects with detail level objectives.”

Have you seen this happen? For example, have you come across “agile” projects that were given a detailed requirements document and then told to “do it agile”? Have you been on “agile” projects in which there was a detailed feature list with hard dates for when those must be delivered? That’s what I am talking about here.

Direct Causes

Why does that happen? It depends. Sometimes it is the result of the project sponsor – typically a business area – that charters a consulting firm to research and document the system requirements. Other times it occurs because the organization has an SDLC that mandates that a requirements document be done up front. In US government agencies the SDLC is often rooted in procurement policy such as “CPIC” (see also this article), which treats software development as an “acquisition” as if the agency was buying a “thing” – but custom software development fits very poorly into an acquisition model.

Root Causes

Here is where we start to ask the “five whys”. Why do business areas ask consulting firms to perform an up front detailed requirements analysis? Some possible reasons are:

1.    That is how they have always done it.
2.    That puts them in control of the requirements – giving them a false feeling of confidence that all of their requirements will be met.
3.    When they initiated the requirements analysis, they did not know that they would be using agile methods.
4.    They just don’t know any better: they don’t understand agile well enough to know that an up front requirements analysis is wasteful.

Number 1 seems pretty straightforward: there is no root cause for it – or is there? The root cause has to do with human nature and might be somewhat spooky. Have you heard of the “five monkeys experiment”? Check it out here. Even though this experiment never actually happened, it gives you pause for thought.

For numbers 2 through 4, we do not yet seem to be at the root causes, so let’s ask,

2.    Why does a detailed requirements document make them feel more in control than the agile process does?
3.    Why did they not know that they would be using agile?
4.    Why do they not know agile well enough so that they understand how requirements are done using agile?

Before investing time to address each of these with an actual client, you should speak to the stakeholders – in this case the business areas that tend to create up front requirements – and ask them frankly why they do it. They might give you honest answers, but whether they do or not, you should be able to piece together the real reasons if you talk to enough people.

“The most dangerous phrase in the language is ‘we’ve always done it this way.’” – Real Admiral Grace Hopper

 Once you know what the real reasons are, you can plan to take action to address the root causes. For example, if it turns out that some business areas obtain a sense of control from having up front requirements, then you can endeavor to educate them on how agile puts them in control, by enabling them to evolve the requirements throughout development. Make sure that you work things at all of the levels or parts of the organization that are driving the behavior: in this case, it might be business area management and IT portfolio management.

While doing this, be sure to address the direct causes as well: the fact that business areas initiate up front requirements efforts. Try to intercept these efforts, perhaps by asking IT portfolio managers what business areas are planning new work. Become familiar with the pipeline of work, including the work that has not yet been funded or even requested.

Understanding root causes is an important step, but knowing what to do about them is not always so clear. For example, you might find that one root cause of some problems is that employees are not staying current with the latest techniques. What do you do? Some people are natural learners: they will read up on things – all you need to do it point them in the right direction (or even better, include them in your analysis process so that they help to figure out the root causes and what the “right” direction is!) On the other hand, some people are not as inclined to learn new things on their own. Thus, the right strategy depends on the personalities of the population that you are dealing with. In a future article I will talk about personality assessment, and more inclusive methods for finding root causes and defining solutions.

I have presented possible actions for root cause 2 – I’ll leave 3 and 4 for you.

We had another direct cause that we have not peeled apart into root causes: when an SDLC or procurement policy mandates that a requirements document be done up front. If there is no policy but the current SDLC defines a requirements phase, you need to work with IT management as well as business stakeholders to get the SDLC changed, possibly by defining an “agile version”. This might not even be necessary if agile projects can be granted exceptions from the SDLC. On the other hand, if policy defines a requirements phase, the task might be far more difficult, because you might need to involve senior management. In a government organization, this might require that the CIO “tailor” the applicable procurement policies.

Either way, you have an education task ahead of you. Simply defining new rules will not accomplish your goal of preventing business areas from defining requirements up front. You need to educate them. Business area managers and portfolio managers are generally very senior people, and they are not usually likely to attend a course that you create, so you will likely have to meet with them one on one or in small groups, and manage as a kind of discussion where you present key ideas and they get to ask questions about how it would for their teams, and how it would affect other things they are responsible such as their budgeting process. You will need to have answers for these questions: do not go in cold. By the time you sit down with these people you should have done your homework on what all of their challenges will be, by talking to their staff and by asking those who are on your side, such as your CIO.

In a future post I will talk about the need to assign team resources early – before work on a release begins!