Tuesday, September 4, 2018

Done Theater

How done is done?

To me, done means (at the very least) there are no more engineering tasks required for deployment. In other words, as a developer, you can put the software in a customer's hands right this second and the only thing stopping you is some external force.

There might be, for instance, a marketing date for which you must wait. Maybe there's some paperwork that needs to clear in the app store before you can roll out the new version to all your customers. Regardless, you are able to demonstrate real working software and get real feedback on that software, right now.

Not after the build is done. Not after you merge to master. Now and without any additional work on your part.

Is that the level of done you wait for before you claim credit? For a lot of teams, it's not.

Many teams are under intense pressure to report progress and demonstrate speed. Specifically, they are under pressure to maintain the perception of speed.

So we put on a little show for the brass. Like magicians, we perform accounting sleight of hand. "I want you to check both my sleeves, ma'am, and make sure there's nothing up there. Now watch closely as one story becomes two. ...and did you even notice that the original story is closed, now?"

That's not done. That's done theater.

It's part of a very self-destructive cycle I see in a lot of organizations: Managers want a group to go faster. The group spends more of their effort making it look like they are going faster. Because more energy is going into theater, less energy is spent actually accomplishing goals. So management ends up more dissatisfied and places even greater pressure on the group.

Either side can break this cycle. Managers can track only that which is truly done or developers can just stop putting on the show in the first place.

If you're looking for a recommendation, I'd suggest both.