Wasted efforts in software development are common, difficult to solve and quietly sapping your revenue stream. So how do you identify waste, and just as important, what do you do about it? Eliminating waste can feel overwhelming, right? 

We pulled together three engineering leaders for a live discussion to offer their expert views on how to find waste in your workflow, and what steps to take when you find them so you can create a more agile software development environment. The panel featured industry veterans, including senior manager of software engineering at Jamf, Jan Trojanowski; development director at Electronic Arts (EA), Brian Pang and agile coach Kimbaly St. Matthew-Daniel.

On to the questions (and answers).

Jan Trojanowski:
If you have a lot of engineering waste, your effectiveness and efficiency as a team and organization are going to be slowed down. At the same time, your customers are going to be impacted. If your struggling to deliver customer value because you have a lot of waste inside your company, it's going to make your customers question your product and the confidence they have in your ability to deliver. For example, if there's a critical hotfix that you have to deliver or a security vulnerability that you have to patch and your customers have to wait a long time for it, that’s not a good thing. 

Kimbaly St. Matthew-Daniel:
I think it's just really important because you want to have those conversations so that you can identify things early and often. And if you don't, then a lot of things will fall through the cracks. I'm constantly coaching teams on the importance of communicating. When people ask what my role is, I say, “I try to encourage people to talk in meetings.” We're in the business to please our customers and continue to drive value. If we're not doing that, then what's the problem? It all just goes back to engineering waste at the onset. The importance is to ensure that we're communicating about it and being transparent about issues, raising them to make sure that they have a place on our backlogs. We just want to have the conversations about how we can resolve issues, and I think it's really on the engineering team to ensure that they're talking about that. And it's discussing ways to resolve that. 

Brian Pang:
Waste comes in many different forms, from inefficiencies and contexts switching to extra to unnecessary steps in the workflows—even things like scope creep. I think everyone's favorite is bugs, and development time lost to bug fixing. As engineering managers and team leads or leaders in any field, it is our job to clear the path for our teams to walk through. We should be actively and continuously finding pathways for our developers and software engineers to operate as unencumbered as possible.

I would say the topic of engineering waste has always been a hot topic. As teams are becoming more nimble and agile, those who are able to minimize waste and inefficiencies, while continuously improving are realizing competitive advantages. I think some of those advantages include faster time to market, shorter and cleaner dev cycles and happier team members who don't need to crunch to meet their deadlines.

Jan Trojanowski:
I believe that it's a bit of a paradox. If you're a larger company, you can create the waste by eliminating waste. An example would be, let's say you have 30 different dev teams and most of them are struggling with the same thing. The problem might be that you don't really collaborate enough, and don’t really align or share what you’re doing. So, by creating more ways to communicate to try to solve the problem, you may end up creating new kinds of waste unintentionally. 

With online meetings, we’ve been experimenting with something we call the “one button rule.” If the meeting is not providing value for you or you are not going to contribute value to the meeting, there's just this one red button at the bottom right corner of the meeting screen, and you can leave the meeting. I had situations where people left the meetings that I was hosting, and it didn't really make me sad or mad or angry or anything like that. It can help you reflect on the value of the meeting. It made me think, “Did I really need to invite every person that was on the meeting? Did I send the right agenda?”

Kimbaly St. Matthew-Daniel:
It really doesn't require a lot to create waste. There's a lot of opportunity for teams to work on the same thing and create a lot of the duplicate effort. What I have found to be successful was open communication. For example: in stand-ups I’d have the team communicate about what they're working on, and talk about if there are opportunities for them to connect with another developer. Even if it’s just to look at their code, they can probably leverage some of it. The goal is to get them to work faster. I would just encourage constant conversation within the team. 

Brian Pang:
As the leaders it's on us, right? We're the ones with the 10,000, the 20,000 and the 50,000 foot view. So, through our networks and our communications across the organizations, we should be able to see there's a similar project spinning up over here in this department. We're doing something like that too. Let's get everyone connected. The onus is very much on us, the leaders of the organizations to spot that and connect the right people.

Jan Trojanowski: 
From my experience, everyone that I've worked with always was striving to be better or always striving to improve, and to master their craft. I think also as individuals we want to be recognized and we want our hard work to be also seen and recognized. Sometimes, unfortunately, that engineering waste can just creep in, or sneak into our teams, and it doesn't need to be something necessarily that we did as a team. It can be a new process. It can be a new standard way of working that the company, for example, would like to propose. Because of that, people aren't very happy that they have to spend a lot of hours weekly on unproductive meetings, or they have to do a lot of manual repetitive work each week. No one really wants to do the things that don't matter. 

Kimbaly St. Matthew-Daniel:
We're supposed to be satisfying the customer. If the customer is unhappy, that's going to upset a lot of what we're doing, especially when we want to make sure that we're consistently driving value. If we're not doing that, why are we in business? I think also on the dev team, we need to make sure that we're investing in our people and making sure that they're happy. If they are introducing waste into the process, it could be because they're burnt out. We're all a part of the process and we all contribute in a way. 

Brian Pang:
Low team morale is one, and that morale would progressively lower over time. Another one is low confidence in leadership. So if leadership isn't active in driving improvements and efficiencies the confidence in the team, and then the leaders of the team will start to erode. So as our competitors are actively driving efficiencies on their own and eliminating waste, they're gaining competitive advantages, not just with their products, but also in hiring and retention of their talent.

Jan Trojanowski: 
It's a good practice to work in short iterations. So to break the stories into as small of pieces as they can be, rather than take huge stories to avoid big poll requests that are going to cause everything to slow down. It is engineering waste if you have to struggle with huge if you have to pull requests. Sometimes of course this happens. However, if it's possible, I would recommend focusing on splitting the stories and delivering small incremental changes.

Kimbaly St. Matthew-Daniel:
Waste comes in many different forms, so I would encourage my teams to identify that something is happening in the form of an impediment. Your progress is going to slow down. You’re going to feel it and start to see it. It's going to affect your sprint. We want to ensure that we're talking about it and escalating it to the leaders, whether it's our scrum master, agile coach, product owner, dev lead or tech lead. The team needs to know what this small or large waste is to ensure that it's visible on our backlog. 

I'm coming from a place of making sure that we're communicating about it. And we know what that disruption feels like making sure that it's visible in our backlog and making sure that we're having effective conversations on how to resolve it. 

Brian Pang:
I know many teams who won't make changes until they can create that real silver bullet solution. The one that will solve all the problems, but what happens there is a lot of those seams become paralyzed because it takes too long to implement. Or there are too many stakeholders or it's too daunting of an initiative to take on. With a continuous improvement mindset, you can actually make small incremental changes and, and tackle micro wastes, which a series of those would end up resolving a macro waste.

Kimbaly St. Matthew-Daniel:
There are varying insights of technical debt. Some that can be beneficial and add value to what you're doing, and some that may not drive value. Something that I try to coach on is that if the team feels like there's some small wins in recouping some tech debt, have that conversation with the product owner, because the product owner may already have a value in mind,or priority for the next couple of sprints that are direction they want to take their product in. 

It’s important to clearly identify good tech debt and bad tech debt, and have conversations with the person who is ultimately driving the direction for the product.

Brian Pang:
It’s important to make changes in bite size chunks, then inspect frequently. Did the small change result in a positive trend? If not, should the change be reverted or should a new small change be layered on top of it? The continuous cycle of inspecting then adapting is key to change management with minimal waste. The continuous rolling improvements will allow for course correction, a more frequent stream of feedback and ultimately you can fail fast and cheap. You’ll know sooner when to pivot and course correct. In lean, I believe there's a concept called plan, Do, Check and Act. So that's something we should all live by.

I'd also point folks to look at an author named Martin Fowler who writes a lot about refactoring, tech debt in general, different techniques and situational solutions.

Jan Trojanowski:
I do have one metric that I just love, and I think this is the best metric ever and it's cycle time. So the cycle time is the time it takes from when your dev team picks up the work until it's done and delivered. It’s a very powerful metric. I really love using it. First of all, I think cycle time is able to encourage good practices. Everything that we are talking about today, in every single waste that we see, if you are going to be able to focus on trying to lower the cycle time, you're going to see that you are in fact solving the problem of engineering waste. It's a metric that directly benefits your customers. Better cycle time means that you are able to deliver value to the customer frequently. The last thing I want to say about cycle time is please keep in mind to pair it with quality metrics, because focusing only on cycle time might lead to a situation where you're going to throw low quality work out, and that's bad for business. 

Kimbaly St. Matthew-Daniel:
It's really important to ask the team what can be done to better support them. Where can we change the process? So I am working with a team where we're constantly updating and working with our JIRA admin, putting in different flags, ensuring that we're doing audits, auto-testing on where it needs to be, tightening up our test driven development processes. But it’s important to go back to the team to understand their needs. Where can we work? Can we get better?

Brian Pang:
It's important to understand impact assessment and the return on investment assessment. So for example, if something is compromised and if you eliminate that piece or step in the workflow, will something else be compromised? If it results in more bugs, will some metric be missed, and is that acceptable? Once you have the ROI of the initiatives and understand the efficiencies and cost savings, et cetera, then you map that against the effort and the impact of the change and the costs required to implement the change. Then you prioritize it.

Jan Trojanowski: 
Manual repetitive work is not something that we should be doing. It’s 2021, and I think the opportunities for automation right now are extremely huge. It's not a rocket science anymore. We can automate our regression. We can automate our tests, we can automate our builds. We can automate our deployments, we can automate the entire CI/CD pipeline. So I think focusing on automation, focusing on these types of practices are going to help you take action on reducing waste.

I really wanted to put some more spotlight on cycle time. I think that for many teams in many organizations velocity is something that we focus on a lot. This is the first metric that developers usually focus on, but cycle time is still something that I feel like has not been adopted. Try to understand more about cycle time, what cycle time your teams and the product have, and to be able to analyze what's happening there.

Kimbaly St. Matthew-Daniel:
We have to communicate with the team often to ensure that they have the necessary processes, or if they need any support so they can be successful. Part of my job is to ensure that the teams understand what the goal is, and I'm here to support them. 

We want to empower the team to have those needed conversations. Waste is constantly creeping up, and especially being virtual. It's something that we're trying to control a lot more because before the wave of work from home, a lot of companies were a little bit more reserved about the process and thinking waste is going to find its ugly way back into our process. Now we just have to be more on top of identifying waste where it is and ensuring that our engineering teams are having the conversations whereby we can remove it early and often.

Brian Pang:
Eliminating waste and automating as much as possible frees our teams to be able to up-skill and re-skill. In today's world with many generations in the workforce companies and industries are rapidly evolving. New business models are popping up, especially in the tech space and certainly in the gaming space. Any debt takes people away from a capacity standpoint, but also a willingness standpoint to up-skill and re-skill. So this is why eliminating waste is so critical to free people up, and it’s up to us as leaders to create that environment and enable that space for people.

There is so much happening in the world with mental health and wellness at the forefront and physical health, not just within your workforce, but with team members, families, and loved ones. All that will absolutely have an impact on your team's productivity, and how effective your team is on eliminating waste and driving efficiencies. So for all the leaders, please don't pretend or demand that our teammates can operate without emotion or be a hundred percent consistent every single day. If performance is dipping or inefficiencies are piling up, let's not automatically default to adding processes. Have that discussion with your team, really get to know them and what's happening in their lives, which may be indirectly contributing to the team's performance. 

Normalize the fact that life will happen and will impact your team's output. If your people feel supported and are attaining realistic project goals, and know that you the leader have their backs and will protect them during these extreme times, your team will build resilience, generally be more happy and your teams will be more stable. Then your productivity and competitive advantages will bounce back. But I think if you lose your team members, then forget about engineering waste, you could have way bigger problems on your hands.

Every organization is as unique as the people that they’re composed of. Likewise, your waste may feel different than your neighbor’s, or your competitor’s. The key is to start by paying attention to the data and formulating your own objective assumptions, asking the right questions from your team and listening to their responses. Then, working collaboratively with your team, you can begin drawing your own conclusions and drafting up your own game plan. Remember, it’s important to think of eliminating waste as a continuous effort, rather than an occasional reboot. It takes a long term mentality and a focus on what’s best for the good of the team, beyond delivering more code.

Need help extracting and understanding the right data? Pluralsight Flow is built for that. From live data and customizable reports on things like cycle time and impact to the code base, you and your team will be equipped with the tools to empower individual engineers, while giving you a clear understanding of how to help them eliminate waste.