Is your organisation starting to feel out of date, making you slow and ineffective? Do you need to evaluate what type of organisation you should have instead to speed up your development? Then you probably want to continue and read the full article. This post also contains Workshop agenda & Free Templates.
The three amigos of Agile coaches on the set is so much better than one 😀
Thank you Viktor and Stefan!
Many companies and organisations who are working in a complex fast moving domain find themselves growing out of their existing organization and ways of working. These organisations may suffer from problems like long lead times, inability to innovate or quality issues. Feeling left behind when new companies move faster. People in these organizations often find themselves being stressed out, attending too many meetings, communicating to everyone and no one about everything, and often little or even no time to be creative, collaborate with team members and stakeholders or to do the actual work.
To become great product organisations fit for people and enable innovation, short lead times and high quality we apply Agile and Lean thinking and ways of working in order to solve existing problems step by step – also called Agile Change Management. We believe that change has to happen on an individual level, as well as a system level, and it can only be sustainable and successful if it comes from intrinsic motivation.
To enable organizations to improve and reorganize as easy as possible we needed a collaborative way to evaluate the existing organization, what works well and what not, and at the same time learn how it could work instead in the future. We also wanted to build on intrinsic motivation and enable people to make the decisions needed based on actual knowledge. That’s why we created this product organisation evaluation workshop and method. It worked really well and we would love to share it with the Agile community to see if it might could be of use to more people.
Outlines of the workshop
This workshop is:
- Experienced based
- Data driven
- Probe, sense, respond – prototype based
Who to invite?
The client wanted to make sure every part of the organization were involved and heard in this change. So they invited about 30 people from product, development and marketing. Bringing in the different competences needed to evaluate based on different perspectives creating cross functional groups of 4 – 5 people.
This is how the agenda was planned and executed
The workshop was made in one and a half day. The agenda had two different parts, the goal of the first part was to find out how they would like the organization to work, what was the 6 most prioritized principles that they could agree on. The second part was to evaluate how different organisation would fit their purpose based on principles and their deliveries.
1 – Looking back at the problems they wanted to solve doing this change.
2 – Experience based training and theory.
3 – Collaboratively create the basis for the evaluation, 6 principles and 3 different type of projects.
The different types of product organisations we evaluated
- Component Team Based Organisation
- Value Stream Based Organisation
- Customer Journey Based Organisation
- Their current Organisation
For each type of organization we wanted to evaluate
4 – Theory of that particular organization, connecting to the experience based training
5 – Practical work, evaluating the type of organization in each group (getting 5 different teams view).
6 – Analyze – Looking at all visual of evaluations on the walls, each person wrote down their own analyze of each product organization.
7 – One person from each group came up and created a aggregated evaluation for the total of the group presenting it to everyone.
8 – Management presented the next steps after this.
Day one – Principles for an Agile product organisation
Experienced based training to learn about cross-functional teams and T-shaped people
To give everyone in the room the same basic understanding about how different types of teams really work, no matter what type of organization you have, we did some experience based exercises.
Exercise 1 – Team Shapes
What we focused on was the difference between Component teams, with teams consisting of experts, and cross functional Feature teams. This is crucial to be able to build efficient Agile teams. The exercise showed that x-functional teams was about 10 (!!) times more efficient and delivering with much higher quality than teams with experts who only did their part and then delivered to the next team.
This is a great warm up, a lot of fun, quite quick and creative. It´s also a safe way to help people to see how badly they are working today (if they have components teams). It takes about 45 min including reflection.
Here you find the exercise for experience based learning on the difference between component teams and Feature teams called “Team Shapes”>
Exercise 2 – X-team Silos Game for Cross functional and T-shaped teams
As a second exercise we did right after that was the “X-team Silos Game” to experience the difference in the team when the team collaborate or not. The exercise is based on x-functional teams who in the first round are experts and not T-shaped, and in the second round they are T-shaped and can collaborate help out with more tasks. The experience is that in the first round the team don’t deliver what they should, it is also quite boring just doing your task, in the second round the teams can deliver much more and they can play tactics engaging the whole team.
This exercise is a good team exercise for any x-functional team, it takes about 30 min including reflection, also it includes lego – and lego is always fun 🙂
The combined experience from these two training sessions was discussed and set the basic needed to be able to decide on the principles moving forward.
Deciding on what principles they value the most
This was perhaps the most challenging and also interesting part of the workshop, it created a lot of energy when the different groups discussed and prioritized by themselves first, and then having them present it to the big group and pitching their prioritization. It was obvious this really needed to be discussed, why did some groups find it obvious that “short feedback loops” was more important than “being able to deliver end to end”, and what did they put into those different concepts. The basis for this part was a pre-made print out of about 15 different principles for product development. They were also allowed to add their own, and they ended up making adjustments and adding some words to make it more clear what they meant.
Based on the fact that leadership was firm on only wanting to focus on customer value, these were the principles they were given as a starting point:
- Teams should be able to to deliver customer value end 2 end
- Teams should be able to to take ownership for what they deliver
- The organisation has the ability to innovate
- The organisation are delivering with high quality
- Teams have the ability to short feedback loops and learnings
- The organisation has short lead times
- The organisation has low inventory (ideas are not piled up waiting to be delivered to customer)
- Teams have fun
- There are few or no handovers from start to end
- Teams have the ability to deliver
- Teams are focused on one goal at a time
After really great discussions and some additional clarifications they agreed on 7 different principles. I as a facilitator said “it’s not about choosing exactly 6 principles, it’s about the discussions and agreeing what you think is most important. So it’s ok if we end up with 7 as well”. If I wouldn’t have said that, they might never would have left the room thats how intense the discussions were. When this was done we said goodbye for that day, and it was such a great energy.
Day two – Evaluation of different Product Organisations
Evaluation of the different organisations based on what they are planning on delivering.
The following day we evaluated the 4 different type of typical digital product development organisations based on these 7 principles, and three different typical type of deliveries that they had had the last year that everyone felt comfortable with.
These were the templates we were using in this exercise, you can download them for free here.
The evaluation was made one organisation type after another, going through some theory of component based teams and organisation, value stream based organisation, customer journey based organisation and their current (see below), and connecting to the exercises made day one learning about the difference between component teams and feature teams as well as cross functional teams where people are T-shaped and work together. With everyone having discussions in their group and made their own evaluation using green sticky note if it was working good based on the principle to deliver delivery X, yellow if it was pretty ok, and red if it was bad. This gave a very clear visual understanding what was working or not.
When all teams were done with all four evaluations we put them up grouped by type and se did a gallery walk quietly, everyone making their own notes on their analysis. Combining all teams visuals made a great impact on everyone with the bright colours and clear united message.
The group shared their analysis with everyone and it was clear that they were on the same page, they all wanted to change from their current organisation and instead start to work cross functional and T-shaped in a customer journey type of organisation.
The four different types of product development organisations we evaluated
(included in the template you can download below)
1. Component Team Based Organisation
Component teams are created around software components with the same type of specialists grouped together. This usually works ok in smaller organizations, but when the organization grows dependencies between the teams creates a growing need for sync between the teams, It is also often very difficult to deliver value since none of the teams can deliver end to end value by themselves. Systems usually have owners and they have their budget. Budgets are based on projects involving one or many systems as well as many teams. Focus is on optimizing resource utilization. Budgets are made on projects.
2. Value Stream Based Organisation
Value stream based organizations focuses on shortening lead time end 2 end along the total value chain. It puts the people needed to go from business idea to delivered customer value within the same product organization with the same focus enabling teams to make tactical decisions and focus on what’s most important now. Budgets are made funding teams and the products instead of projects.
3. Customer Journey Based Organisation
Customer journey based organisation puts the user and the total customer journey in focus. In this type of organisation teams take ownership of parts of the customer journey to make it as good as possible to one or several types of customers. Focus is on delivering customer and business value in an experiential manner, keeping a 360 product and customer view within each team, as well as along the full customer journey for the product. Budgets are made funding teams and products and you measure customer centric KPIs based on behavioral change and long term value based business goals. This type of organisations demands cross functional feature teams – or as we call them, Lean Teams.
4. Current Organisation
This is the client’s current organisation. It’s great to show some kind of image to align people on the workshop here as well.
Of course any of these types can be combined as well. This workshop gave them the knowledge as an organisation to chose wisely daring to move away from what they already had, enabling them to make experiments and make changes knowing what they were looking for.
The product organisation evaluation template
Download the Organisation Evaluation Matris here >
Co-facilitating is key – You’re no better than your team!
We (Stefan Lindbohm, Viktor Cessan, and I) created this workshop together and then facilitated it together. During the workshop Stefan and I were the main facilitators and Viktor observed to help individuals and groups that got stuck or risked being left behind. Having several Agile coaches on the set was a great way to make sure the workshop really paid off for the client. Thank you guys for such a great collaboration and two really fun days! Also, I had great help from my Dandy colleague Joel Ståhl creating the awesome exercise and templates for how to visualize the efficiency of the different organisations!
Thank you guys!
And thank you for reading this far 🙂 Hope you enjoyed the post and that it might have given you some ideas on how you can help to improve your organisation. Feel free to use the setup and material if you like and please let us know what experiences you have and let us know if you need a hand in doing this, we would love to join forces with you 😀