Structures and systems – do you need a process approach?
As organisations scale from startup, there are structures and systems that they rapidly need to develop. A startup may get things done, but rarely through any reproduceable approach. As the organisation scales, it needs to achieve a reproduceable delivery.
This means that scale-ups quickly need to understand what processes exist in the organisation and how these fit together to maximise the flow of value through to the customer. In other Plays I look at key areas such as:
- Focus – the ability to minimise work in progress and parallelism and to maximise value
- Flow – building an efficient way to manage work using small batch size and iteration
In this Play I am looking at something perhaps more surprising for an Agile Play – organisational systems.
What is a process?
A process is a set of activities which use organisational information to achieve a purpose. An example definition is shown below from ISO9001, the international standard for Quality Management Systems.
Process: set of interrelated or interacting activities that use inputs to deliver an intended result.
ISO9001:-2015
A process is a set of activities, and each process has inputs and outputs artefacts. The process takes the inputs, uses that data and generates some outputs which can be used. All processes can be represented in this form, even though sometimes the inputs and outputs are not always obvious. We can draw this as below.
Isn’t this rather non-Agile?
The idea of process modelling for an Agile organisation may sound a bit heavyweight. After all, doesn’t Agile favour “Individuals and interactions over processes and tools“? That word “process” is there on the “bad” right hand side.
Let’s recall when we introduced the Agile Values we pointed out that the Manifesto says, “there is value in the items on the right“.
More than just “value”, the items on the right tend to be fundamental items that we need to have in place before we can start to grow. By contrast, the items on the left are those which scale better as the team improve.
There needs to be some initial focus on systems and structures to underpin the benefits of Agile approaches. The same is true in development of the software itself. For example robust CI/CD good practice is a fundamental which underpins the creation of software functionality.
How do we describe a process?
For a small startup organisation, the processes are typically not well defined. The inputs and outputs will be unclear and likely informal. Different people may have different ideas about what these are. Teams using the process may do so in very varying ways.
How much do we even want to constrain processes? Traditionally there would have been a Work Instruction giving detailed information about how to run the process. In an Agile environment we want self-managing teams and so to maintain flexibility. We also want want to ensure that we can continuously improve the process and artefacts.
The key parameters for a process include:
- Who is involved?
- What triggers the process?
- What artefacts are used in the process?
- What artefacts are created from the process?
We can specify these without requiring each team to perform the process in exactly the same way. Different teams may take different approaches, but if we understand the process, we understand where the teams need to align their approach. We want to ensure each team has the same trigger and (typically) involves the same roles to ensure good decision making.
We want to ensure the inputs and outputs are consistent. For those familiar with software systems, this is effectively defining an API which allows the process to be refactored and improved, because we understand what it requires and what it creates.
Let’s look at an example. The “Sprint Planning” process is used (in Scrum) to create the Sprint Backlog for the next Sprint based on the overall Product Backlog. It occurs at the start of each Sprint and involves the whole team.
We can use this to define the process:
- Who is involved? – the Scrum team
- What triggers the process? – the start of a new Sprint
- What artefacts are used in the process? – one input, the Product Backlog
- What artefacts are created from the process? – two outputs, the Sprint Goal and Sprint Backlog
For the process itself we can point at good practices such as the Scrum Guide notes. This is one of the advantages we gain from starting with a defined process such as Scrum.
What is a process approach?
Processes do not exist in isolation. A “process approach” is representing a set of interacting processes as an organisational system.
The process approach includes establishing the organization’s processes to operate as an integrated and complete system
ISO9001:-2015
The key point is that (some of) the outputs of one process become (some of) the inputs of another process.
By building a process approach we show not only the processes, but also the data which is exchanged around the organisation. Each process has inputs and creates or updates outputs. Processes interact with each other through those inputs and outputs.
If we understand what each process creates and exchanges, then we can improve a single process without affecting other processes. Or we can improve an artefact knowing which processes are affected.
- No data connects directly to other data without a process in between. Data cannot be transformed without action.
- No process connects directly with another process without data in between. The format in which data is published and transferred needs to be agreed.
We can extend our example diagram to show more of the Scrum processes. Building our process diagram is easier because we are starting from the defined model of Scrum rather than building each process from scratch.
Good practices
Starting to take a process approach for an organisation which has had no defined processes can be a daunting step. However, with careful steps this is achievable.
Treat it as a change program. Before people will accept defined processes, they much be aware of the difficulties that the lack of definition is causing a small organisation, and desire to be involved in the change.
Don’t try and build a complete map of the organisation with all processes, data and associated formats from the start. It will be too big a task as these are probably not pre-existing but would all need to be defined and agreed. It take too long and likely be abandoned. If it completed, you inevitably would build in inflexibility when you need to support the organisation growing and changing.
Instead, start with a relatively well defined area. If I introduce Scrum as a model it becomes natural to agree how the Scrum processes work as part of that change. For each process agree the basics.
- Who participates
- What triggers the process
- What are the inputs, in what form and where are they stored?
- What are the outputs, in what form and where are they stored?
When you add a new process or find one is needed, work out how these fit in. Make sure you involve the people who use the existing approach, such as it is. Go to the Gemba and observe the existing processes in use. Agree how best to design this process and how it fits in to the organisation.
When we address a new improvement area or Play, we can work out how it fits in the existing process map. Backlog Refinement clearly takes Product Backlog as an input. And updates Product Backlog as an output. Who is involved? When does it run? Scheduled or ad-hoc?
What about taking decisions about new product features? Maybe this adds a Product Roadmap as an input. Is that just Backlog Refinement or will your organisation use a wider decision making process? If so, what inputs will it use? Who should be involved in proposing a new product feature?
Leave a Reply