(Originally published by Lv Yi on June 3, 2018)

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.

Some elements are more equal than others

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%.

This is a cross-post from AgiliX blog post.

This is a cross-post from Evolve Agility blog post.

A Systems modeling technique to visualize and act on deeply entrenched systemic issues.

Everyone carries a model, fuzzy as it may be, a map of sorts to navigate reality as perceived. As team members we have expectations from each other. This internal picture of our expectations, and reasons, and emotions, and all the mess that is being human is our mental model. The differences between what actually happens and what we expected it to be, reinforces our mental models or alters it. Learners are able to update their mental models more often, and thus adjust their actions and expectations with ever emerging reality.

I find that curiosity is the doorway to learning. Accumulation of knowledge on the other hand is founded on the mistaken belief that knowing about a thing is the same as knowing the thing.

By learning, I do not mean accumulation of knowledge or a collection of jargon to impress your colleagues. By learning, I mean understanding that enables you to take actionable steps in a very real practical sense.

Virtually every Team in their first Sprint is confronted with the problem of single-specialization causing work imbalance. What happens? The Product Owner orders the Product Backlog to maximize value. But when the team members are specialized in a single dimension - such as QA, Java development, front-end development - some team members regularly will find themselves with no work related to their area of specialization. Single-specialization inevitably causes work imbalance.