This is a cross-post from AgiliX blog post.
This blog is part of a series of peek previews from my upcoming book Coaching Agile Organisations.
In the first part of this blog series, I explained how to identify the organizational elements to include in your product definition. In this blog, I explain how you can refine your product definition to organize into effective cross-functional teams.
Below you can see a simplified view of the organizational elements at one of my customers.
We discovered that some organizational elements are required more than others to develop product features. The more often a particular element is required, the stronger the dependency. We visualised the strength of the dependencies with a heat map – see the figure below for an anonymised simplified example.
The y-axis shows product features. The x-axis shows the organizational elements. A green area indicates an element that is needed to deliver the feature
The elements that heat up the most indicate the strength of the dependency – these are the hotspots. Note that the WEB element is needed in 28% of the time to develop product features, the APP 20% of the time, while Legal is required only 7%.
NOTE: Avoid focusing too much on the percentages. This is not exact science, but rather a guide to help you move forward. Other than percentages I have also successfully used categories to estimate the strength of the dependencies like: Seldom, Now and Then, Frequent.
When all the teams can pick up any work that comes in and deliver it completely to “done”, you have maximum adaptability. That would mean that each team has the skills to cover the whole heat map. Unfortunately, this was not the case for us. There were just too many technologies and domain knowledge for the teams to comprehend. Also, there is value in team specialisation. The solution was for teams to specialise in the customer domain first, and then to learn about other product domains as needed.
Learning can take many months or even years, and in the meantime, we needed to determine how to start. Which organisational elements should the teams cover first and which shall we add later? This decision depends upon the strength and type of the dependencies.
When a team can work on all components but only one feature, a team covers a complete row, as drawn in the figure below. Such a team has no external dependencies; hence they probably deliver fast. On the other hand, when a team covers all features but only one component, it covers a complete column in the heatmap. Such a team can work on all feature-parts; hence they can adapt to all work that comes in, but cannot deliver end-to-end.
Therefore, the size of the heat map area that a team covers strongly determines its
Our challenge was to find the optimal balance between speed and adaptability in our 11 team context, and that depended upon several variables:
Our product was a large insurance system. We used interviews and questionnaires to determine where users spend most of their time when using the product. It turned out that there were a couple of main groups of users. (For this blog, I just use 2 groups: “Claims” and “Evaluation” and call them “red” and “yellow”.) Some users mostly used the red-colored features – red area – while the other group primarily used the yellow-colored features – yellow area. The orange features were used by both groups of users – they overlap or intersect both red and yellow areas.
The red and yellow areas let the teams specialize in a customer domain – see Requirement Areas in LeSS and Value Area Scrum pattern. This reduces the cognitive demand on the teams.
The next step was to find the most significant heat map area that the teams could cover.
We used the following rules to decide which elements to include from the beginning and which to add later.
Below you can see an example result for the red Value Area.
The Web, App, Siebel, Portal components are used often together and their interdependencies are reciprocal. The teams in the red area decided that they would need to cover at least these elements.
Furthermore, you can see that the area has a pooled interdependency with Legal, and that it is a relatively strong dependency of 14%. The weakest interdependency is with the Sales Force. We choose not to include Sales Force initially and only add it when the teams mastered the other elements. Legal was also not included because it was a pooled dependency.
The yellow Value Area below has a different set of dependencies.
The teams decided that they needed to cover at least the APP, Sales Force, Siebel and WEB components.
For this area, Legal is not needed at all. And there is a weak sequential dependency on Portal. We decided to not include Portal in the first step. In the exceptional case that a feature needed a change in Portal the teams would coordinate with the red-area to get it done. We also used these as opportunities to learn more about Portal.
How to handle features in the intersecting orange area? A solution is to decide based on the feature itself.
For example, F10 could be picked up by either the red or yellow area. F18 requires only APP and can be picked up by the yellow area. The only complicated feature is F11. It requires knowledge of both Sales Force and Portal which neither the red or yellow area possess. So, how to handle this one? Well…, remember the golden rule of Scrum Mastership: “Always ask the team.”
The product definition includes all elements, but we choose to not include Legal skills in any of the teams from the start. Why? Because it is a pooled and weak dependency. Also, the teams felt they were not yet able to cover more skills right from the start. Instead, Legal became the next activity to include in their Definition Of Done.
In the infrequent case when a feature requiring Legal skills would appear on top of the Product Backlog, we would plan for that by working together with Legal in refinement events and during the Sprint.
During Sprint Planning, the team that selected that feature would then coordinate to work together with someone from Legal to get the feature done. Preferably, the Legal person(s) would also use the opportunity to teach the team so that they understood a little bit more about Legal at the end of the Sprint. When a team keeps selecting to work on features with the Legal part, eventually they would learn enough to add Legal to their Definition Of Done. Bas Vodde calls this accidental specialization.
NOTE: Not all teams need to know everything about all elements in the Product Definition right from the start. Teams can have their own speciality as long as all teams as a group can pick up any element from the top of the Product Backlog.
RSS feed