Getting customer feedback quickly is vital to the success of any development team. The days of spending months building features before the customer sees the product is a thing of the past. The waterfall has long since dried up. Getting the product into our customer’s hands as early as possible allows users to give us feedback that may adjust how we are building the product, may impact when the work is done, or may even change what problem we are solving.
The truth is a lot of companies struggle to get the product into their customer’s hands early. There are many possible reasons this is hard. The cost of testing or deployment may be too high to release often. Worse, the architecture may not support iterative development, leaving engineers with larger items to work on in an all-or-nothing scenario.
The risks with not solving these issues are that poor design will go unnoticed for a long time. An entire team could have spent weeks building a feature the customer doesn’t even want. A developer may be struggling to complete their part of the work for weeks with no one noticing or offering help. Other engineers may even be blocked waiting on code from another engineer.
The software engineering discipline is riddled with inefficiencies, while customer needs and requirements are always evolving. To confront this, we’re required to continuously eliminate waste from our processes so that our work doesn’t become irrelevant before we even release it!
At Realtracs, we focus on two key principles as part of our process to solve these issues head-on: reducing batch size and decreasing cycle time.
Batch Size
Batch Size is a simple concept: only work on one thing until completed. Many people claim to be great multi-taskers — quickly switching from thinking / working on one thing to another. In reality, it doesn’t matter how “good” someone is at context switching… it takes time to “switch” and that “switching time” is wasteful.
This may seem impossible because a feature could take weeks to complete. However, the longer you work on something the more likely something different will arise that needs your attention. This brings us to our next core value.
Cycle Time
Cycle time simply means keeping the amount of time you are working on an individual task to a minimum. At Realtracs we target one to two days for a task. The way to achieve this is not to work faster but to break your work down into chunks of work that can be achieved in one to two days. The work you can achieve in one to two days may not be a full feature but it should be some complete amount of code that can be tested and deployed. You could build one of the backend web services first and deploy it before you build the front-end. You could build one section of a new piece of UI and hide it behind a feature flag in production until the whole feature is ready. Feature flags are an important part of this process to Realtracs. They allow us to deploy parts of code to production and control which users can see them until we are ready for everyone to see it.
Tracking Cycle Time
New engineers often have a misunderstanding that cycle time is used to measure individual performance. It is not intended to be. We do not monitor cycle time per individual. When a task is in the same part of our development process for three days, it’s a flag for everyone that the cycle time is longer on that task. It then becomes a topic of discussion for squad mates to reach out and offer help. Things occasionally take longer and that is expected. Sometimes the smallest bit we can work on will take three days and that’s okay.
The whole team’s cycle time is included in our daily scorecard. We use this as one monitor of the health of our team processes.
We have learned a lot of lessons over the years focusing on batch size and cycle time. There have been several common themes that we have had to address as team to improve our overall team cycle time.
Stop Starting, Start Finishing
Engineers are achievers. They get one task to the testing phase and immediately jump into their next task. They want to keep knocking out work back-to-back. What happens when the testers find a big issue? Now we have put both our cycle time and batch size at risk. We are working on more than one thing at a time (batch size) and since we started the new task the cycle time for the other task is now increasing (despite no work occurring).
There are plenty of other things to do while waiting for a ticket to make it through the process. We can look at pull requests (to help other engineers move their features along); there is always documentation that can be written; there are always more unit tests that can be added. In my case I’m sharing knowledge by writing this awesome blog article!
Selfish vs Serving
When a new engineer first starts learning batch size and cycle time, they may attempt to cut corners to keep “their” cycle time low. This is being selfish with their cycle time, can be detrimental to the system as a whole, and is one of the reasons we don’t track cycle time per person. Engineers in the early stage of learning these practices may do several of these things to keep their cycle time low: not designing up front with their team, skipping writing tests, not thinking through all the edge cases, not testing all the edge cases, not reworking the code into a better pattern, not retesting after peer review feedback, or putting in “hacks.”
All of the above things end up increasing cycle time for the team. When bugs occur, rework has to be done – modifying the original code – and someone else on the team ends up having to invest the additional time. Most likely, that engineer isn’t going to be pleased with the original engineer.
We want our engineers to be serving with their cycle time. If it takes one more day to do something correctly, then take the extra day. That extra day may eliminate multiple days of rework. Another way to serve others while decreasing the cycle time of work is by reviewing pull requests (PRs). The sooner a PR request gets looked at, the sooner the work will be finished. Engineers should focus on the teams’ cycle time (and delivering value to the customer) rather than how much work they are getting done on their own.
Testing and Deployment
It’s important to note that iterating quickly can put a strain on the teams’ processes. There are many ways to ease the strain when deploying multiple times a day, including:
- Ensure that the whole process is automated, so you’re not spending a lot of time pushing buttons to deploy code.
- Adopt a production environment like an A / B stack (also known as a blue/green stack) to make rolling back easy when there are issues.
- Prevent issues early by writing automated tests that run automatically on every commit.
- Silo code as much as possible with micro-service patterns to eliminate risk of issues bleeding over into other parts of the system.
Reducing batch size and decreasing cycle time keeps the release train moving, allows us to shift design when discovering new requirements, reduces our risk when deploying, and enables quick adjustments to changing priorities. The end result is that customers get more of what they want faster.
