Continuous improvement is the name we give to the practice of making sure our ways of working keep evolving, leading us to be more effective and our work to have more quality. That effectiveness translates into the way we do things of course, but it also translates into how good we become at detecting what is not working.
The Lean methodology, or more accurately, the Toyota 3M, has an interesting approach for continuous improvement, which is looking at 3 categories of things to improve:
- Muda: waste, useless stuff, quality issues, etc.
- Muri: overburden, too much work in progress.
- Mura: unevenness, inconsistency, too much variability.
Ideally you want to pick a category and concentrate there for a while to improve it. How to know which one to choose? One of the best ways to understand how we perform and what could be better is by measuring how we do things. Measurement does not need precision, just accuracy. So, gauging with ranges, with questions, is just about right!
The second thing is to make sure that you select improvements on a cadence, a periodicity. That is important to allow you time to put improvement experiments in practice, to collect data, to limit your observations, and only then decide what to do next.
Let’s look into each with a little more depth in the context of teams.
Muda – waste
Here we are talking about any activity that consumes resources without creating value for the customer. A lot of things can fall into this category. Bugs, defects, is one of them. While no one creates bugs on purpose, it adds no value to the client to spend time correcting something that should not be there in the first place. It is thankless: it needs to be fixed, yet we gain nothing by fixing it. Some teams can be forgiving and complacent of bugs, but the fact is that they rob the team time to work on useful things for the client. They are beyond a quality issue: they are a team performance issue.
A lot of the ecosystem of the team can add to the pile of waste and Toyota 3M speaks of 7 types of waste, which we will not detail in here. Manually doing tests that could be automated, having countless meetings, systems unavailability and over-delivering are also waste. Yes, over-delivering hurts the agile principle of Simplicity, the art of maximizing the amount of work not done. Also, over-delivering does not always guarantee client satisfaction. Plus that piece of unexpected feature might just sit there, with the client not using it… and later on even making it difficult for system changes. More waste? Not having a proper knowledge base share in place: having to repeat and rush to find out information that has already been gathered. Waiting for blockers to be solved is another big waste of time. The list of waste can be huge. What would you add to this list?
A team looking for reduction of waste is on the constant lookout for transparency and organization.
Mura -unevenness
I can think of two big categories of unevenness under the lens of a team:
1. Operation and/or practice
There is a reason why tools for static code analysis are in place: if left unchecked everybody would write code in a very particular way. Some people write more tests than others, hence the need of defining a minimum acceptable percentage of test coverage. Hours for starting and ending the day is also a preference hence the concept of core hours.
To make it short: anything that you can imagine entering team agreements, Definition of Ready and Definition of Done helps to even out practices and ways of working.
2. Inconsistency or variability in work pace
Suppose in a sprint or a cycle a team delivers twice or half of the volume of work when compared to the last one. While it is great when the team is forming and finding their perfect pace, at some point we want to even out team performance related to delivery rate. Everybody wants to work a decent amount of hours every day, and not have days of 10 hours of work and others just 7.
For the most part, that is the category in which we are calling out the Agile principle of Sustainable pace. A big help in here is diligence in the refinement of the backlog. Can we streamline it to have the most uniform work decomposition possible? No, it is not simple and a team that is persistent has a bigger advantage, because they can get more easily to a point where they master their sizing of work and understanding of their infrastructure.
A team looking for evenness takes very good care of their work backlog and is big on measuring. The easiest measurements to take ate cycle and lead time and velocity (when using story points).
Muri – overburden
Overburdening a team is the good old too much WIP (work in progress). This can come from accepting more work than the team is capable of handling, but also inability of chunking down work in small, consumable sizes. Have you ever been part of a team that keeps “discovering” things in the middle of the sprint? That’s one example. Another example is when a team cannot have a clear point of commitment and work just keeps coming in, while the delivery date does not change.
I find overburden one of the hardest types of improvement to tackle, because in my experience a lot of that stem from poor scope and stakeholder management, which is usually beyond the team’s control. It is probably one that requires the biggest change when combining skills and mindset. And to add to that difficulty, sometimes there is even some team members accepting the role of hero and staying overnight, delivering more and heroically. Usually because the company offer benefits to those actions, so the reinforcing system is not to work decent hours in a disciplined fashion, but rather to accept anything and chaotically reach delivery. It is usually a company dealing with a deep rooted misunderstanding that high output does not equal great outcomes.
A team fighting overburden is in the constant search for focus. And who isn’t these days?
Combination and Overlap
As a final word, those elements of improvement can happen in a combination or overlap: one leading to another. Here are two examples:
- Variable team composition: I’m not debating that teams cannot change composition but changing it does come with several challenges. A team that is not stable will suffer the 3 types. Onboarding the new colleagues adds work to everybody’s plate (overburden) and creates ad-hoc work that should not exist in the first place (waste). The new team member usually spends more time waiting and scrambling at first (waste) and everybody end up having a hard time keeping up with the pace of work until the new team member is settled (unevenness). Being new, chances are the new team member might generate defects (waste) more easily or just produce lower quality deliverables overall (unevenness).
- Work or systemic blockers also hit the mark on the 3 types of improvement. Blockers make teams wait (waste), make the team have days of little work and days or a lot of work (unevenness) and might generate significant overburden, with all blockers getting solved at similar times and final dates not changing.
In the end, we will always have improvements to make. That is why the theme is continuous improvement. Every team knows where it is hurting more, be it by quantitative or just qualitative measurements. The Agile lead (Scrum Master, Coach, manager, etc.) can help the team by trying and making them understand:
- which of those is happening more often?
- how much time, quality and morale we seem to lose with each?
- which one is an easy fix?
- which ones can we fix, versus just minimize the impact?
- are they happening in combo?
If you look at your team right now, do you have more Muda, Muri or Mura happening? Or are you plagued with combo? What are some of you ideas for improvement?
