Recognize Value Traps

As the team works on defining and delivering value, see if it encounters these traps:

• The product owner has feature-itis.
• People in the organization want detailed schedules, such as Gantt charts.
• People are unsure about an MVP or an MVE, so they think they can’t recognize any value until “all” of the work is done.

You have options for managing these traps.

Trap: The Product Owner Has Feature-itis

Product owners have feature-itis when they say things like this: “Gimme features. I don’t care about no stinkin’ framework. I don’t care about no technical debt. I don’t care that it’s going to make your work harder later. I only care about now. I’m short-sighted, focused on today, or this iteration, and that’s all I care about. Show me the features, baby. Show me the features!”

Now, I bet that you have never heard a product owner or customer say those precise words. But you have heard words like them. If you have, you are witnessing feature-itis. And you have some options.

1. Explain to the product owner that you are a professional team. Make sure that all your estimates include the necessary architectural, refactoring, and testing work—whatever your team needs to deliver finished value.
2. Explain the cost of not looking at the architecture, or at least the local design as you proceed, to the product owner. Explain that ​Technical Debt Is Not Unfinished Work​. The more you have unfinished work— incomplete refactoring to patterns, build or test automation—the more expensive it is to finish that work later. The team runs the risk of implementing Conway’s Law, where the design of the system reflects the organizational design.
3. Track velocity in a burnup chart. You will see if you start finishing fewer features over time.

You can placate the product owner, swallow your pride and your professionalism, and just do what the product owner asked for. Sometimes this is the right answer. But it’s often the wrong answer.

Feature-itis is a seductive disease common among relatively new product owners. For the first time in their careers, they actually see features coming out of the technical teams. It’s a heady feeling. No wonder they fall prey to the dark side.

But with that feeling of excitement must come a feeling of responsibility. Not only is the product owner responsible for the product features; the product owner is responsible for the business value of the product and knowing that the team is able to continue to develop the product. Without architecture, tests, and all of the necessary engineering practices that good software requires, a technical team cannot deliver.

Trap: Your Organization Wants Detailed Schedules, Such as Gantt Charts

I said before that agile approaches change the culture of the project. In addition, they change the organization’s culture. However, not everyone changes at the same time. If your managers are used to assessing project progress with detailed schedules or Gantt charts, they might want to continue seeing those artifacts.

I have had good results when I’ve offered people the different pictures of the roadmaps: the longer roadmaps covered in ​Plan at Several Levels​, and the shorter, more detailed roadmaps discussed in ​Create Rolling-Wave Roadmaps​. In addition, consider the tips in Chapter 14, ​Report Your Project State​.

What do you do if someone really wants a Gantt chart? Do what you think you must. I don’t advocate placating those people. I recommend you help them learn how to read the other measurements.

Trap: It’s Not Done Until Everything Is Done

Some people are concerned that they can’t release anything until “everything” is done. They say things such as this:

• “While I’m in there, I’ll do this, too.”
• “It will take longer to do it later. I’ll just finish it now.”
• “But no one can use it like this. I (or we) need to finish everything before we can release anything.”

There are several possibilities here:

• People are concerned they will look incompetent if they don’t finish “everything.”

• People might worry they can’t get to the rest of the value if they don’t do it now.

• People don’t understand what an MVP or an MVE is.

You might, as an organizational leader, show by example that it’s okay to release interim, not-yet-totally-finished work; that might help people see that you don’t suffer any ramifications. You can do this with code, tests, a project charter—anything.

These people might have managers who want them to finish “everything” for some reason. A manager who doesn’t understand agile thinks people should receive performance evaluations based on “their” features. See ​Managers Help with Team-Based Recognition​.

It’s possible a product owner or team member doesn’t understand how to slice and dice features so a team can release interim value. Review the MVP and MVE discussion.

Help people see that adding more work that’s not on the board (doing work while in a certain place in the code or tests) adds to the WIP and increases cycle time. That means the team has less idea of its estimates and when it might complete work.

Have a one-on-one with the team member or, if the team has sufficient safety, address this in a team meeting, such as a retrospective. You might also find that a backlog planning or refinement session is a good place to raise the issue.