The Realtracs’ product development team applies the seven Lean principles to our software processes. These principles – based on the Toyota Production System and adapted for software by Mary and Tom Poppendieck in Lean Software Development – provide a common language for our entire team. They help us discover inefficiencies, improve continuously, and deliver better customer value.
Each of these principles is equally important and we recognize that we can’t be our best by only practicing some. It takes time, focus, and a lot of trust to successfully adopt and adapt to this agile mindset. We’ve been at it for a few years and can finally say we’re good enough at “being lean” to share our version. Oh, and we’ll continue to iterate!
Optimize the Whole
This principle means that we strive to ensure our organization works together to deliver as much value to our customers as quickly as possible. Rather than optimizing for each discreet group or process within any given team, we consider the entire flow of work. This“systems thinking” approach requires focus on various areas, including:
- Minimizing negative impact to upstream and downstream processes.
- Empathizing with both internal and external customer needs.
- Making our work visible to increase collaboration and trust.
To optimize the whole, we must sub-optimize the parts.
W. Edwards Deming
Eliminate Waste
This is another call to organize ourselves around our customers. We remember to ask this question when considering our work: “Will our customers benefit from it or pay for it?” If the answer is no, then there is the possibility we’re going to introduce waste. In our world waste takes on many forms, but the loss of precious time is the most common. Things we do to help avoid waste include:
- Evaluating the value of our work to ensure we’re building the right things.
- Helping one another minimize context switching.
- Practicing progress over perfection to stay away from over-engineered solutions.
- Giving and receiving feedback early and often.
Build Quality In
Often referred to as “error proofing,” this is a concept that means we prioritize work to eliminate system issues that will slow us down. Technical debt and defects are often unavoidable factors that work against the speed of value delivery. The slowdown comes in the form of deployment/testing/release friction, increased context switching or firefighting, and missed learning opportunities. Here are some of the ways we build quality into our product:
- Automate and standardize repeatable processes and components where possible.
- Prioritize fixing errors over building new features, as a general rule of thumb.
- Empower all team members to stop the line when there’s a potential problem.
- Ensure that every team member is accountable for quality, not just QA.
Don’t water your weeds.
Harvey McKay
Create Knowledge
Software development is a team sport, right? Yes! So helping one another grow is key to ensuring the whole team succeeds together. Not only is it uncool to leave a teammate hanging… it slows everyone down and chips away at trust. A culture of transparency and shared knowledge allows everyone to contribute, continuously improve, and work autonomously. To work better as a team, we focus on the following to create more knowledge:
- Defining and documenting development and design patterns to minimize the guesswork when it comes to tackling something new.
- Applying a “rule of three” to whether or not we need a shared pattern… if it’s happened three times then we’ve probably learned enough to standardize.
- Performing in-depth problem discovery prior to design to set ourselves up to experiment with solution options
Defer Commitment
This principle doesn’t mean it’s okay to be eternally non-committal at work. It does suggest that we wait for the “last responsible moment” to make decisions because committing to work too soon often robs teams of the flexibility needed to continuously delivery customer value. To retain that much needed flexibility, we ensure we have the most up-to-date, relevant information in hand prior to big decisions. Another way to say this: defer critical decisions. Here are some ways that we embrace this concept:
- Starting work to make progress and as a means of arriving at the solution rather than committing to a final solution before we start.
- Collaborating within our squads and across squads during discovery, quarterly goal setting, and as it’s pulled into the flow of work.
- Recognizing when we don’t have enough information, sharing that, and being intentional about researching/collecting data to help fill gaps in knowledge.
Deliver Fast (not frantic)
Customers – both internal and external – are ready to get the next update or check out the new feature. They need to see and interact with the changes we release in order to get any value. This means that our work becomes truly valuable when it’s in our customers hands. We try to work on ways that we can deliver value fast, which then allows for use/feedback cycles in the form of user input, usage metrics, and system performance. And all of that feedback leads to the next iteration/improvement until we can call the release good enough.
So how can you balance delivering value fast while also ensuring the right work is getting done and the pace isn’t so frantic that you’re introducing problems? This is a gigantic topic in the world of software development! Here are a few things we’re doing to strike a balance:
- Releasing updates frequently to minimize risk, enable fast feedback cycles, and allow for ongoing work prioritization.
- Limiting the amount of work that is in process (WIP) – across the entire team – to decrease the cycle time of any one piece of work.
- Pulling customers into the process as early as possible, e.g. including them in discovery and committing to early and/or targeted releases.
Continuous improvement is better than delayed perfection.
Mark Twain
Respect People
This principle is the last in our list here, but it’s definitely not the least important! It’s a fairly simple concept, but like anything that’s seemingly simple, it requires great focus to ensure we’re staying on track. The goal is to make certain we’re designing and delivering products that serve our internal and external customers. We try to put ourselves in their shoes to ensure we’re delivering value, not disruption.
- Limiting the number of changes we release at one time to minimize the downstream impact, including customers and our internal support teams.
- Balancing the amount of risk in process (RIP) by pulling low risk work when we already have high risk work in flight and swarming large issues as needed.
- Utilizing feature flags and implementing “escape hatches” that allow users to adopt the new way at their own pace
Embracing a Lean Mindset
The seven Lean principles outlined provide a glimpse into some foundational beliefs in the Realtracs engineering and product division. It’s taken time, patience, and senior leadership buy-in to get to this point. Where we are a year from now will (and should) look a little different as we continuously improve and evolve. After all, that’s the lean way to work. Do you have similar values or “rules” that you observe or examples of best practices that you’ve learned? Send us a note via engineering@realtracs.com — we’d love to hear and learn from you!
