Broken Requirements Ecosystem

There’s an interesting thread on Seilevel’s requirements forum about why developers don’t read the specs and how to fix this problem. Sometimes the developers throw away the requirements. And that’s bad. But it is a symptom. Something is broken at a higher level.

The Forum Conversation

In short, the conversation is asking why some developers don’t implement code that meets the specifications. There are several possibilities identified in the discussion:

• The developer is too busy to bother with specifications.
• The developer is too smart and knows better than the spec-writer.
• The developer doesn’t understand the specifications.
• The developer pre-judges that the specifications are probably bad.

Why Write Specifications?

Taking a step back to think about why we write specifications is like trying to understand what causes the common cold – instead of trying to prevent symptom X.

The philosophy of the five why’s is a problem solving approach designed to get to the root of a problem. We can twist it to force ourselves to look at the bigger picture – and maybe gain some insight from looking at this discussion in a broader context.

1. Why write specifications? So that the developers will know what to build – and testers know what to test.
2. Why does it matter what the developers build? So that we can deliver what we promised to our customers.
3. Why do our customers care what we deliver? Because we have promised to solve their problems.
4. Why is solving customer problems important? Because customers have goals, and problems thwart those goals.
5. Why are customer goals important? Because customers are in business for a reason – and those goals are an articulation of that reason.

OK – so we have some context – we are trying to solve a particular problem (or set of problems) for our customer(s). To keep the writing simpler, we’ll talk about one problem / goal for one customer. But the ideas apply to multiple customers and goals.

Our customer has a strategy (or reason) which drives the creation of a goal. Our customer chooses to use our software as a means of solving the problem that prevents them from otherwise achieving that goal. We make choices about how to solve that problem, and articulate that solution approach as a specification. And our team creates a solution that meets the specification – and tests to confirm that it meets the specification.

Software As Fast Food

Jonathan Babcock wrote a thought-provoking article about how McDonald’s is one of the highest quality restaurants. Without going off on a tangent about fast food, one conclusion we can draw is that McDonald’s does a fantastic job of implementing according to the specification. Their employees don’t ignore the procedures (the spec). People can debate about the quality of the spec, but you can’t argue with the execution of the teams in the restaurants. When I was in Kuala Lumpur a few years ago, the McDonald’s french fries tasted just like the ones here in Austin, and the ones in Paris, and the ones in Manhattan. They may even be zealous in how well they follow the spec.

Why don’t the people working in the restaurant ignore the spec? Chris the fry cook likes his french fries extra crispy – crispier than the spec calls for. He knows they are better this way. Why doesn’t he cook them a little bit longer? The customers would certainly be happier. Evan is a brand new cashier. He doesn’t know that the unsold hamburgers need to be thrown away after an hour of sitting under the heat lamp. How is it that Evan never gives me a two-hour-old burger?

McDonald’s has a working Ecosystem. You may argue that they are addressing the wrong customer goals – or have chosen a bad approach to meeting those goals. But you can’t argue that their execution is bad. They absolutely follow the spec.

Why Isn’t McDonald’s Ecosystem Broken?

Do they do an adequate job of training new hires? Is there sufficient oversight during the orientation period of those new hires? Do they properly set expectations for the employees? Do their employees understand the importance of their decisions? [As a side note – I have been yelled at about french fries when I worked at a restaurant in high school – but it wasn’t a McDonald’s – it was a 4-store private chain. A restaurant equivalent of a startup]

Maybe they’ve automated and constrained the process so much that a monkey could do it. They have definitely done some of that – the fry cook no longer eyeballs the amount of french fries to put in each basket – a robot dispenses the proper amount. And a timer determines the proper length of time to fry them – while a thermostat regulates grease temperature. But you still have to rely on the people to know when to drop the fries to meet demand. And you have to rely on the people to pull the fries out when the buzzer goes off (according to the spec). You have to rely on the employees to destroy excess food instead of selling it – even when that is more convenient. And do you know a teenager who prefers “the right way” to “the easy way?” And yet, it still seems to work.

I believe that the specs are good. And I suspect that the managers stress and reinforce the importance of following the specs. And I believe there is sufficient training to assure that people know how to follow the specs. And when someone doesn’t know how to do something, there is always someone there to help. It is a culture of “ask for help when you need it.”

What Can We Learn From McDonald’s?

There are two important elements, and they are addressed very differently. First, it is critical that the specs be good. Writing good requirements is important. Second, the culture must be such that people realize that they are required to follow the specs. How you deal with that will vary from team to team, and person to person.

If you don’t set the expectation that the specs be followed, why would you expect them to be followed? And if the specs are bad, that’s another problem entirely. But you should encourage people to help you fix the specs – not ignore them.