Broken Requirements Ecosystem

throwing away

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.

3 thoughts on “Broken Requirements Ecosystem

  1. There’s one more factor that McDonald’s can use… if someone ignores all of the training and positive help and continues to do things against the ‘spec’… they’ll probably be disciplined, perhaps fired.

    Now, I’m not advocating that developers be fired the first time they ignore a spec… and the spec certainly has to make sense, etc. But if the spec has been done well, with customer input and internal input then you cannot allow developers to ignore it or do what they want simply isn’t tenable. Sure, allow feedback, be willing to incorporate new ideas… but that the end of the day, developers need to understand that they’re part of the team. For too long most companies have reinforced the message that developers are special and tolerated things that we’d not tolerate from other other skilled professionals. If a developer persistently ignores the spec or implements things that they think would be cool but that aren’t in the spec they need to be disciplined. If they keep it up, they should be fired – just as you’d fire a sales person who didn’t sell, an accountant who wouldn’t balance the books or a program manager who refused to track project details.

  2. If we suppose that a spec is good and describe accurately a specific requirement, it should be the main concern of the developer. In fact, the ultimate measure of success of a project is having all of related requirements satisfied but working software, of course within a not to monstrous budget scope. So why this is not happening ?

    I agree with rick, part of the problem come from how expectations are set for developer. There was a time where a good developer was the one who align 70 hours a week. After some evolution we ended up with the good developer being the one who are close to or on budget. The feature of the requirement was, and often still is, assume to be satisfied. It’s like if it’s obvious: the developer worked on the requirement and job is done, so requirement is satisfy. Simple. But how many projects have its requirements partially satisfy: most of them.

    It’s that the requirement satisfaction must be the first element to take into account. Budget and delivery time is very important…but second to requirement satisfaction. At McDonald, I’m sure you can be fired for serving a Big Mac that does not taste ‘Big Mac’. On the other side, if you are expected to deliver it in 5.5 minutes to drive-thru, you may not be fired for making it in 7 or 8 minutes. They will train you and give you some tricks to improve the delivery time or worst but you’ll have a chance.

    I think software should also be like this: first, deliver a requirement that taste as expected. But it’s not just the responsibility of the developer. Project management, design, QA etc.. must all be aligned on the same and ultimate measure of success: working software that satisfy the requirement.

  3. I agree that well written requirements, combined with setting the expectation that they be followed is critical. Andre also raises very valid points about timely delivery. On projects that I have worked on, developers have been responsible for creating (and defending) their estimates – and then have been responsible for meeting them.

    When a developer’s estimate is “too high”, the product manager and developer work together to determine what can be accomplished in an acceptable time-frame. Balancing need with practicality.

    You wouldn’t pay a carpenter who ignored the plans and built what he wanted to build. And I remember my own food-service experiences in high school and college – the expectation was that you stuck to the recipe. If you thought you had a better recipe, you worked to get that changed – you did NOT just do it your own way.

Leave a Reply

Your email address will not be published. Required fields are marked *