Do you need processes at team level?
At the heart of an agile organization is a deep understanding of how we work together. In an agile team, the constant collaboration between the members help doing so. Retrospective meetings are the institutionalised forum for talking about “how we work”. In reality, every time people talk together there is a little bit of “how” in the conversation. How many conversations end with “you do this, then I do that”.
There is little need to formalise processes in too much details at a team level. This is compensated by clear and open communication between the members.
Do you need processes at an organisation level?
This gets more complicated when several teams are working together (team = sharing coffee machine). Such as procurement and production; or sales and accounting. Or Head office – regional offices.
At this level, the interactions are less regular, and, we do not systematically voice concerns or “just” change how things work. Processes change are often heavy and it’s easier to not do it.
This is where process definition gets critical to understand how things work. And this is where you need some sort of governance to make it right, especially around change.
What is process governance in an agile organization?
This post finishes with a list of open questions / thoughts because I don’t have a definitive answer (yet).
- Create a system that allows continuous improvement (CI) of processes (willingness to do so, and an approach to make it) at cross-functional level
- Create the incentive to do CI across several teams (incentive = people will find the time to do it)
- Have a common language to describe the work so that everyone can prepare in the best way (Hello, Skore)
- Process owner is key role to make that happen
- Middle management is a key role to make that happen
- Good understanding of outcomes of the process vs. outputs to be in the right context
The key seems to be to create “space” in the organisation for continuous improvement activities…
To be continued.