Agility: get to know 5 flow management practices to boost your teams’ performance

In one of our most recent jobs,  a long-term customer headquartered in the USA asked us for help. The target team was in charge of building a cutting-edge enterprise PaaS tailored for their flagship digital experience product. 

Challenge

Our mission was to contribute to the creation of a flow management method that was simple, and easy to replicate, thus the team itself could use it without depending on the project managers or any other external agent.

Before we jump into the practices we developed, let’s talk a little bit about the results that have been achieved in over 6 months of work.

Outcomes

Just to set the bar, at this stage of the agile transformation process, the teams had a time-to-market of 4 to 5 weeks, and after the suggested flow management practices adoption, here’s the result we got:

When we compare the performance of the teams that have fully adopted the proposed practices with the rest, the gap is quite relevant.

The numbers don’t lie, so we can say that those selected practices have paid off and brought consistent and repeatable results, considerably improving the team’s efficiency. Besides that, we could notice that team’s predictability increased a lot because the likelihood of having outliers has been reduced, making it easier to answer a question that is made on a day-to-day basis to every software engineer team: when is it going to be shipped to the customers?

And what the customer says about the results? Here you go:

“I’ve had the opportunity to see Objective Group Inc’s guidelines and recommendations have benefitted our team and facilitated progress. Since working with them, we’ve experienced an improvement in overall performance, motivation, and satisfaction.” (Senior Project Manager, based in Canada).

Solution

Finally, which practices have contributed to achieving the results above? Below we describe some of them.

1. Foster product delivery time awareness

The first step was to enable teams so they could understand and measure their value streams and establish a service level expectation (aka SLE). From the moment I know my SLE, I can have a good grasp of how long it takes to deliver new demands that I pull from my backlog. We have defined the lead time as the ultimate KPI for all the teams, and this new consciousness and awareness by itself have unfolded great benefits. The teams could now make cause-and-effect relationships easily, reducing the space for decisions that could harm the flow.

2. Different teams. Tailored KPIs

Having all the teams monitor their lead time was the first step to having a good tool in place to understand if we were improving on average or not. However, each team was on a different maturity level and facing different challenges, so, it would be important also that they could be capable to look into their own flows and detect improvement opportunities/bottlenecks, define hypotheses on how to improve, and create a KPI that measures if they were moving towards the right direction or not. 

This phase was pretty intense and interesting as it required a lot of training effort in partnership with the leadership. In the end, each team lead had their own KPIs designed as improvement drivers for their own reality. As a quick example, I can mention that one of the teams was intrigued when realized that most of the alpha bugs took a long time to be retested after the fix because they were aging for quite some time in the queue. Other teams have realized that they had a huge bottleneck to review PRs. A fourth team noticed that there was an opportunity for improving their release process. Long story short, each improvement opportunity had its KPI, now it was a matter of working and measuring the results.

3. Prevent items from aging above your SLE 

Given that all the teams at this point knew their lead time, a very interesting practice would be to proactively monitor the aging of in-progress items to prevent them from aging above their SLE. The immediate result of this practice is that most likely the lead would stabilize, or luckily decrease. In order to perform this work, we were using the Actionable Agile tool and its Aging Work In-Progress chart (dummy data) that we can see below:

Each blue dot in the chart represents an in-progress item currently in your flow. The idea is that the team works proactively and takes action every time one of them crosses the 70% dotted line. The actions that can be taken must be adapted to the team’s context, but I’d like to share some ideas of what could be done in this case:

• Reduce scope
• Breakdown items into smaller pieces 
• Include the item into a watch list so blockers are removed asap 

Be creative! The idea is never letting anything age above the average of everything you deliver. Please notice that this framework can be applied to any item on your workflow. For teams that break down the work into more granular pieces, using epics, stories, and subtasks, each work type can and should have its aging closely monitored. The difference is how often we put this checkpoint in place. Epics should be monitored on a monthly basis, stories more or less on a bi-weekly basis, and finally, subtasks on a weekly basis.

4. Learn from the past

If you were able to reach this point, you already got the idea and realized that your process prevents your SLE from increasing any further. The next step would be to increase the chances that a drastic lead time reduction takes place by using your historical data. If you can detect all the outliers your flow produces it’s very likely that you’ll find patterns that are shared across them, which can represent improvement opportunities to be implemented. A list of common things to look into:

• Specific knowledge domain (specific product module?)
• Reporter (specific team or role?)
• Refinement level (items without specification, acceptance criteria, etc?)
• Item type (story, bug, or another type?)
• Classe of service (it only happens with expedites or any other class of service?)

This work phase is always rewarded with awesome insights and improvement opportunities, so I am certain that it’s worth a try. In order to support this analysis, we use the Actionable Agile scatterplot chart (dummy data) as demonstrated below:

5. Consistently repeat the process

Who does that once, does twice. Who does twice, can do it continuously. The secret is the recurrence and the continuous improvement mindset. Just like we don’t know which features will please and amaze our customers, choosing which improvements will boost our productivity becomes a guessing game without the proper KPIs to guide us. Therefore, make small incremental changes, measure the results, keep what works fine and discard what’s just overhead. Repeat that process consistently and watch your lead time drastically reduce.

I hope you guys enjoyed this success story, and in case you want to know more about it I invite you to reach out to me via this link. We’ll be pleased to help you!

Best regards!