Extreme product development

Andrew Hughes

Extreme programming won. Its once-extreme practices have gone mainstream: user stories, solution spikes, pair programming, unit tests, and frequent releases. Since then, new extreme practices have emerged.

Sometimes I’ve believed as many as six impossible things before breakfast

- Alice, Through the Looking-Glass

We call these practices extreme, not because nobody applies them, but because not enough people believe ‘impossible’ things.

Remote-first

Remote-first means extreme fully-remote work: all staff, all business processes, by default. It creates organisation-building flexibility, but requires reinventing internal practices, and abandoning office-based status symbols. For this, teams must communicate transparently and effectively with colleagues outside the room, company-wide.

Part-time employment

Working part-time creates team-composition and work-assignment flexibility. Attitudes and legislation vary by country: some find part-time work as extreme as remote work, while others benefit from base on the most work that a single person can do in a week. For this, teams must collaborate effectively and share roles, without escalating coordination costs.

Asynchronous work

Asynchronous work that replaces face-to-face daily stand-up meetings with asynchronous updates unlocks daily planning flexibility, but requires more literacy. Employees read and write more, using more modern tools, and have fewer synchronous meetings. For this, teams must also know what will work on, for the coming week, instead of daily task drip-feeding.

Short backlog

Short product backlogs, limited to 1-3 week’s development work, free teams from wasteful discussions and backlog management, for months’ worth of work that no-one will never start. For this, teams need a high-level understanding of what they will work on, for the coming months, and a way to quickly resolve questions about the work.

Quarterly OKRs

Objectives and key results (OKRs) can replace the need to spend significant effort continuously estimating development effort. Focusing on what matters enables the actual delivery that reduces demand for predictions. For this, teams also need quick answers to questions, while making progress without drowning in troubleshooting.

Available product manager

Available product managers can focus on high-level objectives instead of requirements and specifications, but only if they can grant teams greater autonomy. For this, product managers need to build trust with teams, and an environment that won’t punish anyone who does become blocked.

Zero bug target

Zero-bug targets reduce waste (like short backlogs do). More importantly, they reduce quality surprises that make delivery less predictable and bugs that invalidate negative product outcomes. For this, teams require the autonomy to define their objectives, and must fix any bug quickly, without getting stuck.

Team programming

Team programming resolves development tasks quickly, without a single stuck developer blocking progress, but requires total teamwork. Like part-time work, this needs teams to avoid relying on a single person. This requires enough trust, for example, to share recognition for the work.

Trustful relationships

Trust relationships let people work well together and more productively, but require organisations to understand what that means, and actively coach teams to continuously build and maintain trust. For this, teams need an environment where they can build these relationships.

Psychological safety

Psychological safety, when understood as a prerequisite for teams, may represent the biggest advancement in software development since Extreme Programming, and other agile methods. Safety needs the most extreme thing of all: enough executive team humility to value product development built on trust and safety, instead of offices, meetings, backlogs and management-by-fear.