Extreme product development (script)

Phil Shaw (cropped) CC BY-SA 3.0

See also: the full-length presentation - slides and video

After coding for more than twenty years, I changed role from developer to product manager. I still care about the joy of coding, because I don’t want to work with unhappy developers.

This talk isn’t about extreme sports. That’s when you’re sporty in mid-air. It’s also not about extreme ironing. I’ve taken inspiration from Extreme Programming, which was extreme 25 years ago. People got really upset about pair programming, among other practices. But not any more: Extreme Programming won.

If you don’t do any extreme practices that’s up to you. After all, they’re not easy. But you can’t tell me they’re not possible, because I experienced real examples.

Extreme product development practices

Working remote remains controversial, but I’ve worked for two remote-first companies now. Both were remote-first from the beginning, so I’m talking about start-ups. The most surprising thing I learned is how well working remote filters out arseholes.

Working part-time is common in the Netherlands, but comes with a lot of sexism. Fundamentally, it’s a happiness issue: life’s about more than your job. I’ve worked part-time for the last ten years, and even taken sabbaticals. I’m privileged, of course: I could afford to use a pay rise to work fewer hours.

Working asynchronously comes naturally to programmers, but not to normal people, unfortunately. Remote-first and part-time work depend on it - those are dependency arrows. Async more inclusive. It means more thinking and writing, and less showing off in meetings. The hard part is learning to communicate honestly in chat.

A short backlog is the opposite of waterfall project management. It radically simplifies planning and tooling. Short means fewer than ten tasks you haven’t started, and limited work-in-progress, which leaves space for new opportunities.

Objectives and key results organise those opportunities. OKRs made it possible for me to work with a short backlog, and no estimates. I plan problems to solve instead of features to build, and reduce stakeholder demand for feature release dates.

To use a short backlog and OKRs, I have to be an available product manager. My availability makes collaboration more continuous, increases quality, and reduces rework. For example, I expect to answer developers’ questions within minutes, and I respond to everything on Slack.

A manager once shouted at me for suggesting a zero-bug policy, so it’s definitely extreme. Open bugs waste time, and invalidate what you should be learning during development. So, instead of tracking bugs, you fix them. However, fixing tricky bugs requires proper team work.

Team programming dials pair programming up to 11. Just because you have fewer meetings doesn’t mean you don’t want to work together. Team programming lets you work in a group without having a meeting. To get started, you only need two people in a video callstart; FOMO does the rest.

Psychological safety

So here we have extreme development practices that depend on each other. What else? Extreme Programming was based on its technical practices.

I realised that all of these practices also depend on psychological safety. They depend on people believing that they will not be punished or humiliated for speaking up. Without psychological safety, these practices don’t work. Without psychological safety, you’re left with dysfunctional teams and toxic working environments.

In fact, all product development depends on psychological safety. You’d be surprised how rare this is. Or not, if you’ve worked in tech for a while. But like Juke said:

People are amazing in their creativity when they realise they have the power to change things.

- Juke Trabold, engineering leader