(Originally published by Lv Yi on May 7, 2020)

I often get this question – what do you measure while adopting Agile?

The conversation usually goes like this:

[me] What is it about adopting Agile?
[him] … doing Scrum.
[me] What effect do you expect after adopting Agile?
[him] higher efficiency.
[me] How would you define higher efficiency?
[him] … finishing more tasks.
[me] Why would adopting Agile lead to higher efficiency?
[him] Agile means higher efficiency, doesn’t it?!

The thinking is fuzzy, to say the least. I suggest to focus on reasoning before measuring.

(Originally published by Lv Yi on June 8, 2020)

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