It’s been a peculiar week, with things to process and changes. What it was going to be a slightly anti-Cucumber post—not the vegetable—with a mix of specification by example, has been delayed. Not to worry, cucumbers are healthy and delicious with humus or just salt, and the tool can also be okay, but there are devs that only see “that” when thinking about BDD/specification by example.

What now? Why, let’s make it personal, Michael Jordan style.

I got COVID-19 a week and a half ago, it wasn’t fun. I thought once was enough, and that I was on the way to beat my record of not getting sick, but the virus had other plans. Playing the side effects roulette wasn’t in the cards, as the more you play, the more you could lose, but, luckily, I’m back to normal.

Confidence

Confidence in our code is paramount, I don’t mean it in the narrow sense of just looking at the code and thinking that’s good, or writing a simple automated test and moving on. Confidence goes beyond the code and the developer, it includes reducing uncertainty, driving out fear, reducing feedback loops—as mentioned in part one—and understanding the impact of the code on the people that’ll use it.

If you were to push a code change straight to production, how would you feel? How you feel at that moment is tied to safety and confidence. Does the code behave the way it should? Will it break production or introduce bugs the second it’s live? How would I even know if something has gone wrong, do I have to wait for a customer to report it three months later? When things go wrong, do I have the proper support? Fear creeps if we don’t have a way to answer these questions and get fast feedback. If it hurts, we should bring the pain forward and do it more often.

The feeling of pushing changes without fear and frequently to production, any time of the week, getting fast feedback and observing how it behaves live, it’s priceless. We’re quick but under control, balanced.

Confidence in the code and systems is one of the most important aspects in a software team, but often underestimated or set aside for more “valuable priorities”. It’s that significant that, in my last roles, improving the team’s confidence has been a big part of what I’ve done. Why? Because a fearful team can’t be at its best, nor can it be nimble, healthy, or adaptable.

Fear is not an ideal driving force. It causes avoidance behaviours, pushes us to get away, creates a vicious cycle and erodes the developer's spirit and self-confidence. The vicious cycle will only make the feedback loop longer, reinforcing the behaviours:

• Fewer and bigger releases
• Long-lived branches
• Release freezes
• More gates
• More manual testing

With a longer feedback loop, there will be delayed discovery of defects, high rework, lack of visibility… The team can’t sense and respond fast enough, there’s a big delay between action and consequence.

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).

Many product meetings follow a similar pattern: from what we want and quantitative data, we come up with potential solutions that get us further to our goals.

In those meetings, what we want is usually to achieve a business or product outcome or, if the outcome’s not clear, by default we’ll move some metrics up or down. Increase activation by X%, reduce churn by Y% are typical examples. This is an oversimplification, but it’s not that far off from the truth.

As an example, we’re trying to increase something around activation, we want to see people being onboarded into the product and taking the desired actions, like wishlisting items or asking a seller for a quote. Suppose that we have data that shows clicks, page visits and the like. We sit down and start to come up with solutions: add a button, reorder the UI, create a new onboarding flow, etc. Eventually, we’ll take some of those solutions and implement them.

Where does the person who experiences the product fit into the process? Nowhere. People using the product exist in the ethereal concept known as “the user”, and when they pass through the product they leave clues behind in the form of clicks, page visits, actions… Then we analyse these clues in an attempt to understand their behaviour so that—hopefully—we can get them to do what we want. It’s as if we treated product development as a puzzle, in which the only inputs are the analytics and the financial state of the company, and we win if our metrics improve and, above all, money goes up.