The Rhythm Wheel (aka product wheel) is an innovative concept for lean production planning and scheduling. It leads to leveled capacity utilization, inventory savings, and better customer service level. The Rhythm Wheel concept allows more flexibility due to shorter throughput times and leads to lower cost of goods sold by learning curve effects through a repetitive production pattern.
Whereas this official definition can be found on the website http://www.rhythm-wheel.com, it only talks about production processes. As mentioned a couple of times in my earlier posts about Lean and Six Sigma, although the LSS system was originally developed for production processes, a lot of it can be applied to service processes and even IT processes. The same goes for the production rhythm wheels, but with a twist.
What does a rhythm wheel do?
A rhythm wheel is an iterative system that defines your process, your cycle times and inventory levels to be able to fulfill a fluctuating demand. Think away the supply chain connection and you can apply this principle to a software development team as well. The demand is still the customer (both internal and external) wanting some feature or bug fix applied. The inventory can be seen as the feature requests or bug reports that haven’t been handled yet. The process is of course your development cycle.
With this in mind, there is a constant process which, for the sake of simplicity, I’ll describe in big steps:
- Decide whether something is a bug or a feature request
- Perform a technical analysis
- Get an approval for the estimate (in case of a feature request)
- Execute the change
- Test, test, test!
- User acceptance testing
- Move to production
In essence, this is also an iterative process for a fluctuating demand, but the problem is that the development cycle times cannot be adjusted. I mean, a task takes a certain amount of time. There are a few things you can do to increase the speed of development, for example training to become a better programmer or applying some of the lean concepts that I talked about in an earlier post to eliminate the waste in your development process, but once your have the process more or less optimized, a fluctuating demand can still bite you in the ass.
How to apply rhythm wheels to software development
When I faced this challenge in my current project as a team manager, I remembered my wife talking about her job as laboratory analyst at a very big pharmaceutical company, where they have been using Lean Six Sigma for quite some time now. I also remembered that they were applying the same rhythm wheel principle to a laboratory environment and for her it included a number of rotating roles (tasks) and that got me thinking.
In the team I’m managing, we don’t have a separate role for technical analysis. It is in fact one of the developers that is doing the technical analysis. That means that consequently, doing a technical analysis takes away a development resource. With a team of 4-5 developers for a specific product, that takes away 20-25% of your development capacity on the one hand, but on the other hand, having a fixed technical analyst will result in problems when he’s sick or on holidays. The knowledge of the product lies with one single person, which becomes a single point of failure in the system.
So, I decided to create a derivative of a derivative, meaning I interpreted the role-based rhythm wheel and applied it to my team. Practically, it comes down to defining several roles for the different types of tasks:
- Technical analysis
- Development
- Code read (QA)
- Quick fixes / hotfixes
Each role would then be applied to a specific person each week in a rotating system, hence the rhythm wheel: one developer would perform technical analyses, another would do nothing but development, a third one would do development as well as the code read QA step, and the fourth would be the guy to take up the small quick fixes and the hot fixes. So, every 4 weeks he would perform the same role, but every week in between, he would take up another role. Although when I explained this system to the team there was a lot of concern about additional complexity (and people are generally reluctant to change anyway ;-)), the team started working in this system and gradually everyone was capable of doing technical analysis, everyone understood the product and roles could be switched between team members in case someone fell ill or took some time off.
The best byproduct of this system is the fact that it automatically shares the product knowledge and it doesn’t really matter anymore who takes up which tasks, because that used to be the case before and tasks were waiting to be handled because they had to be done by a specific developer, because he was the only one with the proper knowledge of that part of the application. This in turn results in a more efficient handling of the tasks and the priorities. But knowledge sharing isn’t the only benefit of this system. As mentioned before in this blog post, setup time reduction is a big factor and having people focus on a specific type of task for an entire week, greatly reduces the amount of setup time. The only guy who is really affected by the setup time would be the one doing the quick fix / hotfix role, because he will have to switch many times between different tasks. The other can focus on the bigger tasks and aren’t interrupted in the process, making the team more efficient.
After all, whether we use Lean Six Sigma or other methodologies, process cycle efficiency is what we’re all after and this is one of the tools that has helped me and my team to take another step in the right direction!