10 Ways to Eliminate Waste in Your Agile Process
I think if you asked most people where does Lean show up in their agile process, they’d have some intuitive idea that it was there somewhere but maybe not where specifically. Lean, of course, is a foundational element of the XP Values and Principles and is baked into the six Core Practices of Kanban. And yet the word “lean” isn’t in either. Nor does the word show up much in the Scrum Guide, though it is in the first paragraph of the “Scrum Theory” portion:
“Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. Lean thinking reduces waste and focuses on the essentials.”
And most people will relate to that last sentence when they think of Lean. Lean reduces waste. Lean is a drive to simplify. Lean, as it turns out, is perhaps one of the most important things that makes agile work because I think it is the core of what inspires the behaviors of an iterative mindset. Build the smallest thing that adds value, and then get feedback before doing what’s next. This iterative approach to solving problems enables us to change our minds quite frequently based on feedback.
Personally, when I think of Lean I also think of Jack Skellington from The Nightmare Before Christmas. Silly? Yes. But it makes for a really nice blog post image, forgive me.
So, what are ways that you and your team can eliminate waste? There are many things you might try to inspire your team’s focus on continuous improvement and being lean.
Here are 10 sources of waste and things to consider in no particular order:
1. Partially Done Work
It’s no surprise that the act of prioritizing diligently is critical to success in agile. But the reason is because by not blindly following a plan, we are avoiding working on things that don’t matter! If you ever find yourself working on a big feature that was not vetted or verified by your customers somehow, there is a possibility that all of your time there will be wasted.
Occasionally, even when using an agile process, we will find out in the middle of working on something that we need to abandon it. In the spirit of embracing failure as learning, you should celebrate that you didn’t spend more time on it and happily move on to something that is more valuable.
2. Extra Features
In software development, we use the term “gold plating” when an engineer does a bunch of extra stuff to jazz up a feature, spending time and energy on small things they think will be wanted by the customer (or just because they think they’re cool). Sometimes, quite frequently if we’re all being honest, teams build things based on a hunch or based on their understanding of what their end users want. Either way, anything we do that is not driven by data and ultimately customer need, that is also not reflecting the product vision and direction of Product Management is quite possibly going to lead to waste.
The best story along these lines that I know is told by Des Traynor in the video “Product Strategy is About Saying No”. He says that products become a smashed up collection of only tangentially useful things if you don’t say no to things. “If I pulled this out in the middle of a knife fight, you’d laugh at me right?” (So many great product tips in this video, btw!)
3. Knowledge Lost and/or Re-learning
Everyone knows that if you have one critical piece of knowledge about your solution in one individual that it’s a big risk. We say “I hope s/he doesn’t get hit by a bus!” or hopefully less morbidly “Hope s/he doesn’t win the lottery!”
That same concern should be present when there is any unique source of knowledge in any single team member. Easy ways to mitigate this challenge is to explore Pair Programming or just to implement a learning backlog and find opportunities to share skills and knowledge on your team opportunistically. Some teams will dedicate Friday afternoons to skillshare sessions. Someone shares knowledge or a skill they have from the learning backlog and other team members join in just to learn something new.
Another source of knowledge and time being lost from having to re-learn things is when teams don’t properly document things that need to be documented. Some people believe the myth or too stringently abide by the Agile Manifesto value “Working software over comprehensive documentation”. Remember, even the Manifesto says “it’s not that the things on the right have NO value…” so we need to be prudent about documenting intricate architectural solutions, complex designs, hard to remember bug fixing procedures and the like. Maybe even things you just don’t do that often like year-end procedures that you yourself may even forget by the next time you need to do it. Preserve knowledge by documenting what matters.
4. Under-utilizing People
As was proven in the Psychological Safety study called Project Aristotle by Google, the best teams and most productive teams are ones where everyone speaks and contributes evenly. We have all probably been guilty of letting the person on the team who is strongest in a particular task to keep bailing us out with that specialized skillset. If we rely on experts to always do the hard stuff, we end up lopsided and, equally important, our most junior team members miss out on opportunities to learn.
By relying on experts to solve these specialized problems, we make some well worn ruts deeper. And while there may be a short term gain of having one task done quicker, we inevitably don’t see the time where some team members are sitting idle both now and in the future. Where, if we share knowledge, our teams become more nimble and more flexible and have less bottlenecks causing unbalanced work, wait times, and skill mismatches.
I like to say that the ideal team (albeit an unrealistic ideal) is where every single team member has all of the skills and can do any of the work. This is the most infinitely flexible team, which I know is impossible for many reasons. But, if you make even small strides to getting closer to that ideal, the benefits will become obvious and even grow over time.
5. Handoffs
As much as we (agile coaches, anyway), like to think that every agile team should be designed to have all of the necessary skills to innovate, design, build, deploy, and support their product; the reality is that in most organizations we have complexities that do not allow this to be the case. So we ultimately end up needing handoffs between teams. Hopefully, you don’t have old-school handoffs to testing teams, but instead you may have separate API or Infrastructure or Operations or Production Support teams. Whatever the case may be, anytime our end-to-end flow is interrupted by needing multiple teams to deliver an idea all the way from inception to delivery to the customer, we will need to deal with handoffs.
So, what to do? The best we can do is build relationships with those teams, be familiar with their cadence and schedule, and meet frequently enough to be able to anticipate the flow upstream and accept work more seamlessly and handoff work more seamlessly to teams downstream.
As organizations mature and evolve, some of these dependencies can be removed by better spreading or sharing skills, even as part-time team members if necessary, in order to reduce some of the handoffs. For example, could you put a part-time DevOps engineer on your team to let the team own their own pushes to production?
6. Context Switching
The science is clear that we’re not good at multitasking (no matter what we might believe) and there is a measurable cost to productivity when we context switch. This is true of individuals, teams, teams of teams, as well as companies. When you try to do too many things at once, you don’t do any of them well. This is why work-in-progress limits are so important in agile.
We tend to ignore the spin-up time it takes us to re-read that long email we were in the middle of writing or unwind the complexities of the spreadsheet we were working on. Meanwhile, without the interruption or distraction we wouldn’t need to do that repeatedly and we’d be much more efficient.
Sometimes we don’t even realize the impact we have on others. When a manager taps on the shoulder of a developer (figuratively or literally), for “just a few seconds to ask a question” it can easily kill 30 minutes of productivity. If you’ve been a developer, you know what I mean. 17 tabs open with complex code, hunting down a difficult to solve problem, keeping dozens of facts and variables and functions in your mind at once in order to think through what might be happening in the code. It’s like a house of cards of information built up in your mind and when someone taps on your shoulder even to ask a quick question, the entire house of cards comes crashing down and might take another 30+ minutes to spin-up again that kind of context.
7. Defects
Everyone knows that bugs get in the way of delivering value. You may even have heard the analogy that a bug found in an environment downstream causes 10x the disruption than if it were found sooner (in pre-production, in regression testing, in unit testing, in development, or in the design itself…)
XP introduced and inspired a few common practices centered around quality in test driven development, behavior driven development, and pair programming designed to be coupled with strong engineering practices to help focus on quality as part of the software development process.
It may sound shocking, but if you focus diligently on quality up-front in the form of peer code reviews, pair programming, and a thorough set of testing strategies in your definition of done, your team can and will achieve zero production bugs, eliminating a lot of waste and allowing you to deliver more value to your customers.
8. Psychological Distress
I don’t think we can talk enough about this topic. Clearly, if you are unable to bring your best self to work, you will be unable to do your best work. Whether you are trying to work while fighting a cold or just not doing a great job of taking care of yourself, your psychological state will impact you and your team, leading to potential waste. It’s better to focus on the right self-care, take the day off, or find a job that helps you better manage your stress.
Small things can have a big impact here. Ask your colleagues genuinely how they are doing. Make small changes to your routine to reduce your stress and allow yourself time (even permit yourself) to take time to take care of yourself. Working from home blurs the line between work and play, between work and family. And while you may find ways to fold laundry or run errands during daytime hours, be mindful of your total hours actually working so you don’t accidentally slip into 50… 60… 80… hour work weeks. Take frequent breaks. Take a walk. Unplug during lunch. Block off your family time. Whatever you need to do to help yourself find balance.
9. Ineffective Communication
How many times have you wasted time at work because of a misunderstanding? Probably all too often. Words get misinterpreted in emails and jokes are taken wrong over the phone. Now that most of us have worked remotely for almost a year, you likely miss your in-person conversations. Even when we turn our video on (and OMG why can’t we all just do that more, right?) it’s still hard to read body language. Were they being sarcastic? Do they understand what I’m saying? Is my mute button on? So much time is wasted because of inefficient communication, it may just be the largest culprit of time-suckage on every single project. We probably never realized how much information was being conveyed besides our words when we were in person.
We have to try harder while working remotely to make sure our messages are heard and understood. If we use clean communication and develop habits to verify and provide acknowledgement, our teams will gain greater efficiencies. Other obvious improvements are making sure the wording of our user stories and their desired outcomes are well understood with clear acceptance critera.
10. Doing a thing manually that could have been automated
As a general rule of thumb, if you find yourself doing something very repetitive, you should consider some way to automate it. This is true of very basic things like copying files, promoting code, and running many different kinds of tests.
Software developers know the acronym DRY (Don’t Repeat Yourself) and the principle is simple, if you find yourself writing the same exact code twice, see if you can instead re-use that work so it can simplify and improve your code’s reliability and maintainability.
Fortunately today, there are many tools that can automate even fairly complex things. Chances are, your company has some of those tools but it takes someone to lift their head up and say “hey can we automate this?” And if the answer is yes, then put that work in the backlog and prioritize it like everything else as the investment may help eliminate future waste and create the opportunity to deliver more value over time.
Thanks for reading. If you enjoyed this, please share or consider subscribing to The Practical Agilist Newsletter.
Hi, I’m Brian Link, an Enterprise Agile Coach who loves his job helping people. I call myself and my company the “Practical Agilist” because I pride myself on helping others distill down the practices and frameworks of the agile universe into easy to understand and simple common sense. I offer fractional agile coaching services to help teams improve affordably. See more at FractionalAgileCoach.com
How well is your team “being agile”? Our self-assessment tool focuses on 24 topics of modern ways of working including the Agile Manifesto and Modern Agile basics, XP, Design Thinking, Lean, DevOps, and Systems Thinking. It comes with deep links into the Practical Agilist Guidebook to aid continuous improvement in teams of any kind. Learn more at MakeTeamsAwesome.com
The Practical Agilist Guidebook is a reference guide that gives easy to understand advice as if you had an agile coach showing you why the topic is important, what you can start doing about it, scrum master tips, AI prompts to dig deeper, and tons of third party references describing similar perspectives. Learn more at PracticalAgilistGuidebook.com
Follow me here on Medium, subscribe, or find me on LinkedIn, or Twitter.
