Making the invisible visible lets you inspect and adapt

Your team is cranking through stories and hits a wall. Perhaps you’ve hit an area of technical or UX debt. Or you’ve encountered a learning void and the customer need is unclear. The going gets tougher. This is perfectly normal … we’ve all been there.

A single story can involve a good deal of “work”: rework, working around technical debt, research, usability testing, and experimentation. These tasks exist on a customer-value spectrum. Research very much contributes to customer value (your customers would be psyched to see you learning more about their needs). Working around technical debt that you’ve continuously kicked down the road … not so much. What we DON’T work on is also important. Suppose you cut some corners to deliver early, all the while knowing you’ve delivered something brittle and in need of eventual improvement?

Again, all of this is perfectly normal. We intuitively know we’re adding risk, cutting corners, and working in less than ideal ways. Trouble starts to brew when you stop reflecting and learning (see my post Cutting Corners and Electric Fences). The trick is to visualize the impact.

1. If an engineer is battling technical debt to finish a story, then cut a ticket for that work 2. If you ship a feature with obvious UX debt, then cut a ticket for this debt 3. If research is required because no data existed, cut a ticket 4. Is the work not contributing to customer value, but needs to happen? Cut a ticket 5. Did you rush to get a story out and then need to play whack-a-mole with bugs? Cut a ticket 6. Have you failed to validate the impact of a story? Cut a ticket for the research 7. You get the idea. You’re creating more work, doing rework, cutting corners, punting, working around something …. doing something feels a little less than awesome. Cut a ticket. I know, I know … that’s a ton of tickets. But without the ability to visualize the work, waste, and rework, it can be difficult to reflect on that work, waste, and rework. In my experience, this is inherently uncomfortable for teams. We’re used to managers bullying us for estimates, measuring teams by looking at velocity (not outcomes), getting scoffed at for mentioning technical and UX debt, and being told to “be a team player” and accept shoddy work. That’s NOT ok, and it insults teams. Our gut response is “no more tickets”.

True story. I remember talking to a CTO who did a lot of rework / refactoring “out of band” (not represented by tickets) just to avoid the scrutiny of the product team and CEO. Meanwhile, the CEO was wondering why progress was so slow. How dysfunctional!

Turn it around….

Instead, consider a radical approach for quantifying impact. More tickets. More details. More awareness on the part of the team. More diligence in documenting areas of debt. More safety, trust, and reflection. Less low level “why doesn’t anyone see what I see” stress. At the end of the day, most knowledge workers have a good radar. Engage that to make the invisible visible.