Legacy product development (part 1)

Nick Fewings

1. Part 1 ←
2. Part 2

Extreme product development describes practices that sound extreme to most people in tech. More familiar practices make up a status quo that feels difficult to question, but which has started to change. Modern leaders have started to try new approaches, and employees have started jobs to join them, as they all see the following practices go the way of waterfall software development.

Toxic environments

Bad managers rarely change, retire slowly, and their workplaces continue to tolerate arseholes. They will continue to manage by fear, and fail to understand employee motivation. This will only change for leaders and organisations that learn to value and build psychological safety.

Command-and-control

Even good managers grew up with bad habits, and may think that Peter Drucker wrote the last word on management. Leaders who only know command-and-control management remain stuck in their assumptions that they hired lazy ‘workers’, and only need to pay more attention to what their told if they want to succeed. Good managers can improve, but only if they themselves have the psychological safety to start building trustful relationships.

Project management

A lot of people in tech complain about Jira, but don’t all realise that they don’t hate Jira, they hate project management. Ironically, while project management dictates a single assignee for each task, managers use techniques like RACI matrices to assign responsibilities across a group for their own work.

Project management focuses on defining tasks in advance, assigning each task to one person, and evaluating performance based on delivery within ‘planned’ time and budget. This translates badly to software development, where productivity requires teamwork, not individual efforts, and value accrues from impact, not predictable delivery. Also ironically, the same senior managers who do productive work together, in management team meetings, don’t see the parallels with team programming.

Bug trackers

Software development teams have always relied on two fundamental collaboration tools: version control systems and bug tracking systems. Perhaps, in a parallel universe, Scrum boards made the latter unnecessary, but this universe seems to have compelled teams to copy the sticky notes into tools designed to track thousands of bugs. Jira, for example. In practice, we didn’t visit another universe; bug management’s visible waste leads some teams to a zero-bug policy.

Requirements and specifications

In parallel to tracking bugs, the last century’s software industry responded to complexity with requirements analysis. The suggestion that as-yet unbuilt software has an objective set of requirements seems to reject the possibility of differences between two products with the same purpose. In legacy product development, requirements analysis tends to result in the most complex system a team can afford to build, like this:

1. capture all possible requirements
2. document requirements as specifications
3. prioritise requirements as must have, should have or nice to have (forgetting the won’t have category)
4. only deliver must have requirements before running out of time or budget.

Using step 4 to reduce scope wastes half the requirements analysis effort, and typically upsets people. Start-up companies, which can’t afford that kind of waste, use product management techniques instead. In particular, it turns out that teams don’t need to refer to detailed specifications when they have an available product manager.