This is one of my best advises, if you’re working with self-organizing teams, such as agile Scrum teams. My advice is that you take a systems perspective and help the team consider the context in which they work. Way to often the focus is placed on whether the team is following processes, having the right tools and if we are having the right roles on board. All of that are important, but it really doesn’t matter if we don’t understand the system in which the team is functioning.
The systems perspective asks us to think of teams as part of a wider context of an organization or the community. By breaking down into components part, we can explain and characterize effective team-work processes.
The figure above suggests that a teamwork can be considered as a three-stage sequence. We view the team as a system which take in resources such as time, people, skills, requests (inputs) and through their daily work. We discover decision-making and different behaviors and activities that transform the inputs into outputs, such as products and updates to exiting products.
I would normally recommend that the analysis is made together with the whole team and with a dedicated and experienced facilitator. It’s also recommended to do this as a workshop with participants physically present. The quality of the workshops often depends on everybody’s ability to contribute with their own perspectives. Please don’t rush through the workshop!
“You would be surprised by how many new things are discovered, even with an old and experienced team”
On the workshop we work with inputs, throughputs, and outputs.
We will begin with the inputs, where we identify:
- Requesters
- Channels (formal and informal)
- Categories of requests
Then we analyze the expected outputs from the team. This is an extremely important part of the workshop. The team need to fully understand their interface to the rest of the organization.
We identify:
- Receivers / customers
- Channels
- Categories of deliverables
At this point the team understands inputs and expected output. Now the team should work on their own processes, policies, mandates, competences etc. When we open the “Throughput” box, the team will discover the activities and tasks, that will help them transform inputs to outputs. We will also discuss cricital dependencies from outside, eg. work done in shared service teams etc.
We identify:
- Tasks and activities
- Processes
- Team polices
- Communication
- Decision-making
- Mandate
- Maintenance activities
- Dependencies from outside
I have facilitated such workshops many times, and always with a remarkably good result. The time spend in helping the teams understand their own system and the system they are part of releases extreme amount of energy towards taking the right decisions and deliver their important part to the whole.
Sometimes I use a half-day and sometimes a full day. It depends on the maturity and complexity of the team.
If you want to know more about how you could use this approach in your own organization, please feel free to contact me here on LinkedIn or via my contact information at www.goodmorningapril.com