Process Principles refer to the foundational guidelines that shape the way an organisation approaches tasks and operations, especially in relation to product development. These principles are designed to ensure consistency, efficiency, and effectiveness in developing products.
Purpose
By identifying and articulating process principles, organisations can define best practices based on their current operating context. In addition, by articulating the foundational principles behind each practice, each Stream Team can decide which practices to adopt based on their individual context or whether a different approach is needed.
Core Principles
We don't know what our customers want
| Symptom | 90% of features fail to deliver the expected value. |
| Cause | We make assumptions about how customers will change their behaviour based on new features that we create but predicting behaviour reliably is impossible. |
| Solution | We need to validate our ideas with customers before we build them. |
We need quick feedback loops to validate our ideas
| Symptom | In many organisations it can take months to go from idea to production. |
| Cause | Work items spend an order of magnitude more time in backlogs than being worked on. |
| Solution | Reducing backlog sizes will have the greatest effect on reducing lead times. |
| Impact | We need to change the stage gate sign-off processes because the admin overhead is not sustainable if we reduce the size of the items being handed over each time. |
| Solution | We need to create cross-functional teams that work on items together instead of handing them over between specialisms. |
We need to reduce risk before we build
| Symptom | In many organisations, teams jump straight from idea to building without validating the idea. |
| Cause | There is a separation between "the business" (people who decide what to build) and "IT" (the people building the product). |
| Solution | Remove the sign off of features and instead empower teams to deliver outcomes instead of outputs. |
| Impact | The funding process is often built around approving outputs with associated costs and benefits and our governance processes track the delivery of the outputs against the allocated budget. |
| Solution | We need to fund teams instead of features and govern based on value delivered instead of outputs created. |
We need teams to take accountability for outcomes
| Symptom | In many organisations, people will only accept accountability for outputs. They will say "I delivered the feature, it's not my fault if it didn't work". But still 90% of features fail to deliver the expected value. |
| Cause | The separation of responsibility between different divisions and specialisms means that no one person is responsible for the whole product. |
| Solution | By creating cross-functional teams who are empowered to deliver outcomes, and are able to release their product independently of other teams, we can create a culture of accountability for outcomes. |
Context switching kills productivity
| Symptom | In many organisations, researchers work weeks or months ahead of designers, who work weeks or months ahead of developers, who work weeks or months ahead of testers. When issues arise the team members need to context switch back to the work they did a long time ago. And issues are constantly arising as products are being built. |
| Cause | To keep everyone busy all the time, there needs to be a backlog of work items for each specialism. |
| Solution | We need to limit the work in progress so that we can deliver each feature quicker the whole way from idea to production which will limit the time between when a person is working on an item and when they might have to resolve issues with it. |
| Impact | Some specialists may be underutilised because work items will not require their specialism all the time. |
| Solution | While people have a core area of specialisation, on cross-functional teams, everyone should be able to contribute to all areas of the product development process. |
| Symptom | In many organisations, burnout is a common problem. People work long hours to deliver outputs and then the outputs don't even deliver the expected value. |
| Cause | We ask people to estimate the time it will take to deliver outputs and then hold them accountable for delivering those outputs in that time. But given that they are creating something new, and work within a process that has unpredictable dependencies, they can't possibly know how long it will take. The high expectations, coupled with a lack of control, leads to burnout. |
| Solution | By putting teams in control of their destiny, by setting outcomes, instead of outputs, and removing the blocking dependencies that limit their ability to release their product independently we can actually increase the ambition levels without the risk of burnout. |
Anti-patterns
- Over-generalisation: Crafting principles that are too vague or broad, leading to interpretation conflicts and inconsistent application.
- Lack of Buy-in: Failing to involve key stakeholders in the development of the principles, resulting in a lack of commitment and adherence.
- Lack of Context: Presenting principles without adequate explanation, making it difficult for team members to understand their relevance or take action.