Make Sense of what is Happening at Scale
Need for Normalisation
With the popularisation in the adoption of agile ways of working, there has been a move to empower teams to work in the way that best makes sense within their context. To allow them to define their own workflows, to be able to use their own taxonomy and to utilise the work item types that best suits their ways of working.
At the same time, at the higher level, such as the business unit, tribe or portfolio level, they are trying to make better data-informed decisions. This however conflicts with the same teams who we have just empowered to define their own ways of working. They are now seeing hundreds of different work item types, with their own workflows, which just makes it extremely difficult to filter out the noise and make sense of.
What we commonly see as a response to this, is a top down push to standardise. A predefined list of work item types. A common workflow shared across all teams. Which goes against agile principles of empowering teams to work in a way that best suits their context.
With Flomatika, we allow teams and enterprises to have both. You can allow your teams to define the way they work which best suits their context, AND still be able to make sense from the data and make better data-informed decisions. We enable that through our normalisation engine.
This ‘scaling’ problem of agile teams each with their own ways of working is something we have committed to tackle here at Flomatika.
Demand Distribution Normalisation
Let’s use the normalisation of demands as an example. This is one of the normalisations we strongly recommend. We are able to group together multiple work item types across several teams into a common demand. So we can then conduct analysis across the normalised demand rather than across all the individual work item types.
Let’s use the ‘Defects & Incidents’ normalised demand (illustrated in red above) as an example. A feature team might call it a bug. For another team, it’s called a defect. For a support team, they might call it an incident. Another feature team has several work item types depending on where it was discovered: Bug, Story Bug, Incident. When conducting analysis across the teams and areas, it’s just noisy to see all the various work item types, you can combine them all together into a single Demand called ‘Defects & Incidents’.
“However you categorised your demands, we can support it via our normalisation.”
A more sophisticated example might be that we have two teams that use Tasks differently. One team uses it for their Management Activities. A different team also uses Tasks, but they use it to represent Technical Debt. They are differentiated based upon the properties of a custom field on the Epic they belong to. We can defined this accordingly:
- Management Activities: Work Item Type Task, who’s Epic has the Label of ‘Management’
- Enablers & Tech Debt: Work Item TypeTask, who’s Epic has the Label of ‘Tech’
Analysing Normalisation Distributions
With Flomatika, we show you the distribution of your normalisation across 3 different perspectives.
- Upcoming Work (Future) - Distribution of items in your inventory/backlog
- Work In Process (Present) - Distribution of items currently in process
- Completed Work (Past) - Distribution of items that were completed
You can also view these as Historical View, so you can see how the distribution has changed over time. In the example below we’re looking at a weekly aggregation.
You can see the distribution across all three perspectives and see if reality is meeting expectations.
We can see in Upcoming Work, half of the items are ‘Defects & Incidents’. Is this a concern for us? Is this a sign of a bigger quality issue?
For WIP, in recent weeks, about a third of the items have been ‘Management Activities’. Perhaps we have an expectation that no more than 10% of our items in progress should be allocated to management activities. In a few weeks before that, a third of our items have been on ‘Enablers & Tech Debt’. Are the teams working on the right things?
Looking at Completed Work, in the week of the 20th June, we only completed ‘Defects & Incidents’. Did something occur in that week that the team only focused on quality issues? In the most recent week, half of the items worked on were ‘Enablers & Tech Debt’. Is this the right time to be working on these?
From here we can navigate into Delivery Management to dive in deeper to conduct further analysis on the details.
How is our investment across these teams being utilised across the different demands? Are they working on the right things? Or is there some factor that is pulling them into other demands?
Do we have large spikes in the historical view? Are there for example, big spikes in defects and incidents being raised in the upcoming work across particular weeks indicating a quality issue? Or are the teams spending a lot of time on Technical Debt, when there should be focus on shipping Features for the upcoming release?
By observing trends and patterns, it may give us clues to conduct deeper analysis if teams are working on what we expect them to, or if reality not matching and an intervention might be required?
You can learn more by visiting these related links: