One of the ideas that quickly comes up is the idea of showcasing what the team’s been working on the past few weeks at regular intervals.

From my experience, when this is suggested, it’s usually because there’s no visibility into the work. The team go radio silence and put their heads down, finally emerging from the cave with the promised feature after weeks or months. It’s not uncommon to discover that the delivered feature isn’t quite what the customer wanted or, if it’s a feature factory, what the boss wanted. Other teams, like marketing and sales, will be interested in knowing what’s going on, what the changes are, and, crucially, what the next features will be.

There’s no better way to improve confidence and trust in the team than to deliver value sooner, frequently, and demonstrate that progress is being made. Remember that to deliver value frequently, the team needs to move towards delivering continuously and without fear, deploying changes many times a day if possible. When the team begins to do so and shows frequent progress, the ball starts to roll.

What I’m not a fan of is when showing the work becomes a TV show, with beautifully crafted slides, a script, an elaborate cast, plenty of numbers showing impact… A performance that takes time and effort to impress the rest of the company. Moreover, my lack of love for this kind of TV show gets intensified when it gives the impression there’s a unified team when there isn’t, and most of the team don’t really know the impact of the work. If the team were to start and finish together, doing both discovery and delivery tasks, everyone would know what the work is, why they’re doing it, who’s the customer, what’s the impact, etc. It becomes easier to present the work, as they’re familiar with it and how it relates to the outcomes.

Doing a performance to show the work, with the involved effort, also increases the friction, and it can sometimes feel like the team's justifying its existence. Also, do we always need to have them synchronously—the “this could’ve been an email” situation—, do we need to cram everything in that meeting?

For me, showing the team’s work and giving everyone involved—specially the people doing the work—visibility and credit is important. On some occasions, I get the impression that it stops being something that the team wants to do, and becomes something else, maybe more sterile, distant from the team, McKinsey-ish.

Interesting links

• What is the cost of a bug? (Rafaela Azevedo). “Test early, test often. Prevention is better than the cure”.

• Evolution, Cupcakes, and Skeletons Changing Design (Bill Wake). It explores evolutionary design and provides different metaphors to think about it.

• Twelve Emerging Best practices for Adding UX Work to Agile Development (Jeff Patton).