084 - Eliminating waste with Jan Trojanowski, Brian Pang and Kimbaly St. Matthew-Daniel

Join Pluralsight author, Jeremy Morgan, as he discusses the steps to identifying and eliminating waste in software production with senior manager of software engineering at Jamf, Jan Trojanowski; development director at Electronic Arts (EA), Brian Pang and agile coach Kimbaly St. Matthew-Daniel.

If you enjoy this episode, please consider leaving a review on Apple Podcasts or wherever you listen.

Please send any questions or comments to podcast@pluralsight.com.

Josh Ruggles:

Hello, and welcome to All Hands on Tech. I'm Josh Ruggles. Today's episode features our recent engineering leadership panel on eliminating waste in your development process. Jeremy Morgan chats with Jan Trojanowski, senior manager of software engineering at Jamf, Brian Pang, development director at Electronic Arts and Agile coach, Kimbaly St. Matthew-Daniel, about how to identify and stop wasteful processes in your development. Let's take a listen.

Jeremy Morgan:

Welcome to today's panel on eliminating waste in your development process. Let's get started. We have with us Jan Trojanowski, who's a senior manager of software engineering at Jamf, Kimbaly St. Matthew Daniel, an Agile coach and Brian Pang, development director at Electronic Arts. My first question is for Jan, why is it important to identify engineering waste and why is it such a hot topic right now?

Jan Trojanowski:

Yeah, great question. I think I have a feeling that this is one of these questions like why is it important that your company is doing well? There's a very obvious reason for it. So the engineering waste is definitely hindering or slowing down our ability to deliver value to our customers. If you have a lot of engineering waste, it's going to mean in the same time that your effectiveness and your efficiency of the organization is going to be slowed down. And in the same time, it's going to mean that your customers are going to be impacted by this, which means that from a customer perspective, if your company is struggling to deliver my customer value, if you have a lot of waste inside your company, it's going to make your customers question your product, [inaudible 00:01:59] question your company. It's also going to question the confidence that they have in your ability to deliver.

So for example, if there's a critical hot fix 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, of course it's not a good thing. Also from a more of a business perspective, your competitors are [inaudible 00:02:32]. So if you have a lot of waste and you're struggling to deliver, and you're struggling to deliver other goods, high base, your competition is just going to out run you.

Jeremy Morgan:

Yeah, absolutely. And the competitive landscape is so much higher pace now than it ever was before. And welcome Kimbaly to the conversation here. The question that I just asked Jan was why it's important to identify engineering waste and why it's such a hot topic right now.

Kimbaly St. Matthew-Daniel:

Yeah, no, thank you. And I really do apologize and I'm happy to be here. And 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 even talked to people about how when they ask what my role is, and I say I try to encourage people to talk. In many meetings, either the stakeholders don't provide a lot of buy-in to say whether something doesn't meet their definition of ready status, or it can't be released. And once it's introduced it breaks something and the customer by this time they see it and they're not happy because we're in the business to please our customers, to continue to drive value. And if we're not doing that, then what's the problem.

And it all just goes back to engineering waste and at the onset, how is that happening. The importance is to ensure that we're communicating about and being transparent about it, raising it up, make sure that it has a place on our backlogs. And we just, we want to have the conversations about how we can resolve it 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. Whether it's in their daily stand-ups or... No ceremony I think, or events is off the table, but definitely a stand-ups because that's where they're engaging more often. The responsibilities to somebody like me, but mainly the team too. We want to empower them to have those conversations. Waste is constantly creeping up and especially like 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 like, oh, waste is going to find its ugly way back into our process. And now we just have to be more than ever on top of identifying waste, where it is and ensuring that our engineering teams are having the conversations whereby that we can remove it early and often.

Jeremy Morgan:

Yeah, absolutely. And Brian, did you have anything to add to that? 

Brian Pang:

Yeah, I do. First of all, thank you Jeremy, for hosting this panel and to Jan and Kimbaly sharing the stage with me here and to all of you in the audience too, for hearing what we have to share. I do agree with what Jan and Kimbaly said waste does come in many different forms from inefficiencies and context switching, extra and unnecessary steps in the workflows. Miscommunication is another one and technical debt and processed debt the piles up. Even things like scope creep, and I think everyone's favorite is bugs and development time lost to bug fixing.

What I would add is 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. So we should be actively and continuously finding pathways for our developers and software engineers to operate as unencumbered as possible. 

And I would say the topic of engineering waste has always been a hot topic. Jan touched on the competitive advantages of teams and organizations that are good at eliminating waste and Kimbaly touched on the fact that now we're in this pandemic, work from home situation. So as teams are becoming more nimble and agile, those who are able to minimize waste and inefficiencies, but then also continuously improving and actively driving efficiencies are realizing those competitive advantages. And I think some of those advantages include faster time to market, shorter and cleaner dev cycles and a happier team members who don't need to crunch to meet their deadlines or deal with production issues. So yeah, especially this year, I agree with Kimbaly, people's lives have really been up-ended and our capacity to absorb inefficiencies is much smaller these days.

Jeremy Morgan:

Yeah, absolutely. So, Kimbaly, my next question is for you. What impacts does engineering waste have beyond engineering?

Kimbaly St. Matthew-Daniel:

Yeah, let's go into the actual product and mentioning some of the things that I said before on how we're supposed to be satisfying the customer. And on that side of things, if the customer is unhappy, then that's going to upset a lot of what we're doing and we want to make sure that we're consistently driving value. And if we're not doing that, then why are we in business? And I would just like to go back to again if the customer isn't happy, I think ultimately that's where it is for me. And I think also on the dev team, just mentioning something that Brian said, we need to make sure that we're investing in our resources, making sure that they're happy and if they are introducing waste into the process, it could be because they're burnt out and we have to kind of communicate with them often to ensure that they have the necessary the processes or any just support that they need to ensure that they're doing what they can so they can offset some of those things because at the end of the day, a part of my job is to ensure that they understand what that goal is and I'm here to support them. 

And on that back end, the ultimate goal is the customer and for everybody, no matter what business you're in. And we want to make sure that we're doing everything that we can in alignment with the goal. And in our stakeholders too, they have buy-in into that process, so everybody is a part of that team. So it was really interesting to have Brian and Jan and their backgrounds. We want to make sure that we have that support from dev managers from tech leads, and because we're all a part of the process and we all contribute in a way. And so ultimately if the customer is the prize and we can do whatever we can to make sure that we're supporting the customer, ensuring that we're delivering value, ensure that we're communicating. 

And I'd like to, I use this term once, whenever I was working with, when I was a scrum master, I said that, they're the honey bees. My dev team, they're the honey bees. They do all the work and the heavy lifting so that they can ship something off for somebody to see just go pecking away at it. And they really understood the concept. And so we want to, again, just at the onset, support our teams so that they understand what they're doing and what the end goal is. And our customers, we have to ensure that we're satisfying them.

Jan Trojanowski:

Everything Kimbaly said, I totally agree. I think we're looking at the perspective of a customer, we're looking at the perspective of our competitors. It's also important to look at the perspective, or the internal perspective. So if we are struggling with a lot of waste, our department, our teams are going to be perceived us as unproductive, as slow as maybe poorly managed. So this is also something that I wanted to do add.

Brian Pang:

And I'll pile onto that topic as well. The key impact here is team health and how happy people are working in the environments. And that has many downstream impacts. So I feel that really letting waste creep up and not actively working to reduce it, just end up in a vicious cycle of doom. So if people are unhappy, the debt starts to pile up, the waste starts to pile up and it's going to be harder and harder to get out of it. So that's what I like to refer to as the vicious cycle of doom.

Jeremy Morgan:

And I think we've all seen that at one point or another. So, Brian, my next question is for you. What are some of the pitfalls you've seen or experienced by letting waste creep into to the process?

Brian Pang:

Yeah, I touched on it a little bit earlier, actually just now. So low team morale is one and that morale would progressively lower over time. Another one I thought of is a low confidence in leadership. So if leadership isn't active right in driving improvements and efficiencies, the confidence in the team and then the leaders of the team will start to erode. And then Jan talked about this also is the competitors. So as our competitors are actively driving efficiencies on their own and eliminating waste, they're gaining competitive advantages and not just with their products, but also in hiring and retention of their talent.

Jeremy Morgan:

Yeah, absolutely.

Kimbaly St. Matthew-Daniel:

Yeah. I would agree. Team health will suffer, confidence in leadership will suffer. I think even before that, your earlier response when you mentioned bug fixes and things of that nature, like there's so many different things that are impacted that, I mean, you just have to constantly stay on top of the process and be creative and always engage the team and just going back to team health, because it's really important here. Ask them what can be done to better support them, like where can we change the process? So I'm working with a team where we're just, we're constantly updating Jira and working with our Jira admin, putting in different flags, ensuring that we're doing audit testing on where it needs to be, tightening up our test driven development processes, engaging them to ensure that our unit tests required at every step. Like where can we get better? And having these sometimes icky conversations because they may feel that they're doing everything right, but we know there's always opportunity for improvement and we don't want to see them get into an opportunity where it's hard for them to pivot away because they're spending so much time refactoring or recovering from tech debt. So yeah, that's my ad. I think Brian's response was great.

Jeremy Morgan:

Yeah, absolutely. And Jan, have you seen any instances where waste has impacted team morale?

Jan Trojanowski:

Of course, of course. So I think everyone, I don't want to generalize of course, but from my experience, everyone that I worked with always was striving to be better or always was striving to gain your skills, to improve, to master their craft. And I think also individuals want their teams to reflect that. We want to be seen, we want to be recognized and we want our hard work to be also seen and recognized. Sometimes unfortunately the waste, 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 doesn't need to be something that we also had influence on. So it can be a new process, it can be a new standard way of working that the company, for example, would like to propose.

And 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. I think people, no one really wants to do the things that don't matter. Engineers, again, not generalizing the engineers that I had privileged to work with, I found that they would much rather focus on building great products and gaining new skills. So we have, of course, engineering ways to answer your question and engineering ways can cause frustration, can cause irritation and can demotivate people and teams.

Jeremy Morgan:

That's another factor of it that sometimes isn't talked about. And I don't want to generalize either, but most engineers I know, and myself included, need to be challenged frequently.  It's not one of those jobs where if everything's easy, they're happy. They want to be challenged and move forward. So that is an excellent point that you bring up if you have a wasteful environment where things aren't going well. Sure, they might be closing tickets and they might be fixing bugs, but they're not being challenged or motivated to go farther and might start looking elsewhere just based on that.

Kimbaly St. Matthew-Daniel:

Yeah, no. I'm actually writing that down. I'm going to add that to a retrospective, like how can I challenge you to go further? I think that's a really powerful question. And I have had to ask those really target questions, like where can we improve? How do you see us growing?  I've phrased it that way. And yeah, I think it's just really hard to engage somebody who's behind the screen as it is. Whenever you're in person, it's like, "Hey, I'm a cool kid, you're a cool kid. Let's go on and talk about how we can enhance our process and eliminate waste or whatever." But I've seen it in various stages. I think what Jan was just mentioning was different from how I was originally coining some of my introductions to engineering waste. And I think it's worth mentioning that process, like the number of meetings, it could really play on or impact negatively the team's health.

What the agenda is, I was even asked recently to go back and update the agenda for my meetings, like make it really pointed, what is this meeting called because sometimes I can get really colorful in the titles of my meetings. There was one I wanted to say, it was just yesterday, Big Bang Theory because I felt like there was some new requirements coming up and I'm like, "Wow, this is just really great. Let me spin up a call, called the Big Bang Theory and we're just going to jump on it and know what it's for."

For some people they're jumping on that call like, "What is this? It's a waste of my time." And so I've had a couple of different experiences. I've always tried to pivot and learn from those and so it comes in a lot of different forms. And I think my experiences, they have been very challenging from different groups. And I'm always open to learning from them.

Jeremy Morgan:

[crosstalk 00:17:36]

Jan Trojanowski:

[inaudible 00:17:36] if we can jump in, if I may, since we're already discussing the topic of the teams. I want to share a quick story, we've been experimenting with something called, we've called it, say a "one button" rule. So it means that if you're you see that the meeting is not providing value to you or you are not going to contribute the value to the meeting, there is just this one red button in the bottom right corner and you can leave the meeting. And I had situations where people left the meetings that I was hosting and it didn't really make me, I don't know, sad or mad or angry or anything like that, it made me reflect on what I did wrong. It maybe made me think, did I really need to invite every person that was on the meeting? Did I send the right agenda and so on?

Brian Pang:

One thing I'll add on to is waste is inevitable, especially in industries that are innovative, which I think every industry is, and especially in code bases that are relatively mature or immature. So we should be celebrating folks and initiatives that are driving out waste. I think we need to do that a lot more. And what I would say as well to that point is if waste is completely eliminated, then we're not doing it right. There's room for innovation. Yeah, I'll leave it there for now.

Jeremy Morgan:

That's great. So I do have another question for you, Brian, actually. So many software engineers and leaders are familiar with the work from Mary and Tom Poppendieck, on Lean Software Development and the seven types of engineering waste. Is that a framework that you have used or considered in your team structures?

Brian Pang:

Yes, absolutely. I'm familiar with that. And I would add another dynamic here, is assumptions and miscommunication. And those things are very much exacerbated with everyone working from home, everyone being distributed versus being co-located. All our communication now needs to be very intentional, requires scheduling. And in the before times, before the pandemic, team members would bump into each other in the hallway or be able to walk over to their teammates tasks or cubes to align in person, but now it's typically via a Zoom call or a Slack message and those channels have minimal nonverbal communication. And so we all know how important nonverbal communication is. But yes, absolutely. And I would say all those types of wastes are prevalent in my teams. It's something we all deal with, as I mentioned earlier. 

And once you've driven complete efficiency in one place, something else in your environment will usually change, like a platform upgrade or a change in personnel typically because they did such a great job driving efficiencies, or your project shifts or changes in your tools and workflows. So it is a little bit like playing the game of whack-a-mole, but as I said earlier, it's not necessarily a bad thing. In a lot of ways, it's a cost of doing business and driving innovation.

Jeremy Morgan:

Absolutely. Does anyone else have anything to add to that?

Kimbaly St. Matthew-Daniel:

I can say that I'm not familiar with the process, but just one thing on the non-verbal thing, I was recently coaching a product owner and a couple of BAs because there was this friction whereby one wanted to identify the roles and responsibilities what the other was doing because they were overstepping each other and the product owner felt like she wasn't being given the opportunities to lead as a product owner. Just on that, and kind of related, I had to coach them just to remember that you're dealing with the person on the other side of the screen whereby you can't get up and walk to their cubicle. You can pick up the phone to talk. And I just encourage, again, like when I introduce myself and I encourage people to have those early and often conversations so that if the waste turns out to be an emotional explosion, at least for prepare for it, and we can again, just recognize that we're dealing with people at the end of the day and we have a job to get done. And that's the best way to do it, just to recognize that we're all in it to win it at the same time.

Jeremy Morgan:

Jan, so we've been in this kind of remote structure for over a year now here in the United States and all over the place. And so now we're starting to, in the beginning it was like everybody worked together like you've mentioned, talking in the hallways, things like that and then all of a sudden they had to go remote, so there was that shift. But now a year later, we're having shift where we're onboarding new employees who have never met anybody else in the company in person, or people that have just they've spent a year in this world and so there's a little bit of a disconnect. Is that something that you all have seen and have you dealt with it in any particular way?

Kimbaly St. Matthew-Daniel:

Yes.

Jan Trojanowski:

More meetings?

Kimbaly St. Matthew-Daniel:

Yeah, no. [inaudible 00:23:26] to have those, but I do try to leverage, say person comes on, maybe it's the standup, the first thing that they're going to join, say, "Hey, I'm rolling out the red carpet for you. Everyone here knows each other, let's spotlight you. Tell us about yourself. I'm going to have a spreadsheet that I populate with none work-related things, is all personal. What's your favorite hobby? What do you like to do? How can I best support you? What's the best way to contact you? Do you prefer email or do you want to be slacked or do you prefer Teams?" Because that's really important to people. And sometimes like I will Slack somebody, but they really prefer me to contact them by email and they will not check their Slack and I'm like, "Okay, well what's going on?" Then I'm like, "Mother hen, answer me."

So whenever I have a new person that's onboarded, I really try to really make them feel like the world is there's. I want to really make sure that we are here to service you, want to make it really comfortable for you. It's already difficult, because we're on the computer. But again, just finding out what you like, what you don't like, the best way that I can communicate with you and touch base with you and how I can help raise issues for you. So that's been really effective for me with new team members in every time, because I have a couple of teams that there's a constant change in staff members and it's worked. I can say that.

Brian Pang:

I'll add one too. It might sound a bit counterintuitive, but when we start our stand-ups and recurring meetings, we'll actually take a couple minutes just to chit chat at the top. And this is a way for us to, I guess, replace the water cooler and the bumping into each other in the hallway type of interactions that we don't have now. So just, it sounds counter-intuitive, but taking that time and having people get to know each other and how we communicate with each other and what we mean when we say certain things, that actually pays off in the long run. So taking a couple minutes per meeting to do that would actually save time down the road and eliminate waste.

Jeremy Morgan:

Yeah, absolutely.

Jan Trojanowski:

Yeah. I want to add a comment too. So our IT [inaudible 00:25:54] has done just an amazing job when we were transitioning to working from home, working remotely. And also development teams, whenever we have a team member, they are extremely open, they are extremely happy to have someone join us, we all are. So we're making sure that everyone is on board the property [inaudible 00:26:17] despite the fact that we were not in the same office, that people just feel like a family. 

I personally don't really see a lot of a lot of changes in the terms of engineering waste when it comes to working remotely or working in the office. I want to give you an example of where I personally, and Jeremy you've mentioned the work from Mary and Tom and the seven levels or seven waste types, sorry, of engineering waste. So I personally by far have seen that the waiting state, one of the things that you mentioned, the waiting state is something that's happening a lot in the things that I was working with. 

And as an example, let's imagine a situation where we have an international team and it's spread across multiple locations. And I don't want to go into details and say whether it's a good thing or bad thing, it's probably a huge topic for this, another panel that we can have. I just want to say that, imagine a situation where you as an engineer, you're opening up for requests, [inaudible 00:27:45] opening, a merge request during your morning. And then there's an overlap time with your colleagues from another time zone. And maybe we just didn't have enough time. We just didn't have enough time to chat or to catch up. So someone from the other team or, sorry, the other time zone is going to review the code during the afternoon or during the day. And you're going to wake up in the morning, and like 24 hours has passed since you've opened the poll request. And you're going to see, there's a question, I'm not sure what you were trying to do here. And then this can go on and go on and go on. So what I'm trying to say here is good practices in teams is something that we really need to establish we need to couch and help the teams to establish them by themselves of course [inaudible 00:28:55].

Kimbaly St. Matthew-Daniel:

I was just going to say you're speaking the gospel there. Going back to communication [inaudible 00:29:02] the call, I set up dev sync like peoples set fires in California. It's like, I will start a call, like hey, you guys really need to jump on a call. There needs to be some cross-pollination here. We're going back to waiting. They're spending too much time making comments. And I think that if... Because I have some teams that just start early enough that they can catch those off shore team members because I have some Egyptian contacts. So we have calls at 8:00 in the morning so that they can just get on just to talk about what did you see that I didn't see. I can't pass this, move this over into SMI review column where it can't QAed. It doesn't satisfy the definition of done because I tested and it works for me, but you tested it five times and it doesn't work for you. And so I shortened those cycles a little bit when I noticed that those conversations are happening too many times. Maybe after that second standup, I'm ready to pull those guys in. So I think you really touched on something there. 

Jan Trojanowski:

Okay. If I may, I want to add another story. So I used to actively code a few years back, and I remember situations where after a week or we can have two weeks or even more, someone has opened a pull requests. And you get an email notification, you've been invited as a reviewer to review the pull request. And you open it and there is like a few thousand lines of code of changes. And the first thing I always did was I just went to grab a coffee because I knew that this is going to be a nightmare to review.

So yeah, this leads to a situation where are you going to have a lot of comments, a lot of [inaudible 00:30:47] back where you're going to have additional comments, just added to the initial pull request and the work is just going to drag for a long time. And of course it's going to affect our ability to deliver it to the customers quicker, so our cycle time. It's also going through create risks. When we're going to be delivering something that big, definitely we're going to run into problems. So again, going back to just establishing this good practices for your dev team.

Jeremy Morgan:

Jan, I used to manage a team in Egypt and so I feel you can [inaudible 00:31:26]. And one of the things in the beginning, I was also a contributor. We had teams here on the West Coast, in the United States and we had to split up into shifts because we were... In the beginning we had the exact same problem with [inaudible 00:31:41] this long cycle where we put in a pull request and two days later the problem gets resolved and it's not fast enough for any engineering organization. So one thing that we did was we'd have one person that would go on a call at 10:00 at night, another person at 7:00 in the morning, just to get that before and after and say is there anything that you folks are going to be working on that we should be paying attention to, or here, let me explain this thing to you. It's 8:00 in the morning for you, so I know you're tackling this today. I'm getting ready to go to bed, but here's the thing, and just that extra communication can go so much farther.

Brian Pang:

One thing I'll quickly add to is for teams that are working with that type of distribution, as leaders, we need to prepare our team members for that eventuality. So I think typically the routine is a programmer will come into work, grab their coffee, check their emails, and then start programming. But now in that environment, it's different. You might have to check your email first, respond to a code review and then grab your coffee.

Jeremy Morgan:

So we do have some good questions here in the Q&A that I would like to share here. The first one is from [Pioche 00:32:54] and I hope I'm pronouncing that correctly. Waste means duplicate efforts. How can we identify waste when we have development spanned across many teams?

Jan Trojanowski:

I believe there's this paradox that if you're a big company, if you're a larger company, you can create the waste while eliminating waste. So an example would be, let's say you have 30 different dev teams and they are all, or most of them are struggling with the same thing. But then you don't really collaborate. You don't really align. You don't really share what you're doing. So you're able to create more waste while trying to solve the problem. I'm not sure if I'm answering the question, but I wanted to share that.

Kimbaly St. Matthew-Daniel:

I can say, like I had a team that was working on... they're building a watch app. And the effort for those kinds of things, it really doesn't require a lot, but there's a lot of opportunity for the teams to work on the same thing and create a lot of the duplicate effort. And so really just what I have found to be successful was in just in stand-ups, have them communicate about what they're working on and talk about if there are opportunities for them to connect with another dev, just to look at their code so that they can probably leverage some of that. And any way, the goal is to get them to work faster so that they can move that issue over for QA to test it. And so that's how I've resolved it and that's how the opportunity with that particular instance has presented itself in my experience. And so I would just encourage constant conversation within the team. 

Brian Pang:

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

Kimbaly St. Matthew-Daniel:

Yeah. I would agree.

Jeremy Morgan:

And so the next question we have, micro and macro wastes. How do you identify and eliminate them and can you share some insights?

Kimbaly St. Matthew-Daniel:

The way I'm going to look at that is from my perspective, because we all know that waste comes in many different forms, and so how I would encourage my teams to identify it is first notice that is happening in the form of an impediment, something is slowing you down. That's the way that you're going to feel it and start to see it, and it's going to affect your sprint. Your progress is going to slow down, your velocity is going to slow down. How we want to make sure that we're representing that is ensuring that we're talking about it and escalating it on the leaders, whether it's our scrum master or Agile coach or product owner. Dev lead, tech lead, somebody needs to know what this small or large waste is. Ensure that it's visible on our backlog, whether it's represented in the form of a Jira ticket, it's in the backlog, it's in a blocked column, and clearly just make it so that it's transparent. 

And so 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. Yeah, that's how I feel like how you will identify knowing how it's affecting your sprint velocity or your progress that day.

Brian Pang:

So I'll add too, identification. So it's important to do the impact assessment and the return-on investment assessment. So for example, is something compromised? And if you eliminate that piece or step in the workflow, will something be compromised? And if you [inaudible 00:36:56], will it results in more bugs? Will some metric be missed and is that acceptable? And then if you've identified the micro or macro waste, understand is the juice worth the squeeze? Is it worth eliminating that for keeping it there and focusing on something else? So it's a bit like tasks and stories. So once you have the ROI of the initiatives, the business value, understand the efficiencies and cost savings, et cetera, et cetera and then you map that against the efforts and the impact of the change and the costs required to implement the change then you prioritize it into a tech or process backlog. 

I'm a huge fan of the construct of a tech story or a team story, which is something that won't be shipped or seen by our product users. But these are internal serving work, which drives business value or savings within the team. And I personally 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 teams 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. It's that old adage, "Are you too busy to improve?" And so with a continuous improvement mindset, you can actually make small incremental changes and tackle micro wastes, which a series of those would end up resolving a macro waste.

But it's important to do that too, make changes in bite size chunks, and then inspect frequently. Did this small change results in a positive trend? If not, should the change be reverted or should a new small change be layered on top of it? So the continuous cycle of inspecting then adapting is key to change management with minimal waste.

Oh, and sorry, one more thing, the continuous rolling improvements will allow for course correction, a more frequent stream of feedback and ultimately you can fail fast and cheap or no sooner when to pivot and course correct. And [inaudible 00:39:05] I believe there's a concept called Plan-Do-Check-Act. So that's something we should all live by.

Kimbaly St. Matthew-Daniel:

Yeah.

Jeremy Morgan:

Do you have another question here from me. It says, I agree that certain wastes are unavoidable. I think the question is if every role has clear responsibilities, do they all know what they're supposed to do? Who's the main contact person for these questions and areas?

Kimbaly St. Matthew-Daniel:

I think everyone should be accountable, but that's why you have RACIs in my organization. I'm a big fan of developing a RACI, so I can clearly call out who's responsible and accountable, or who's contributing to certain areas of this topic, in particular waste, how to identify it, resolve it, escalate it. Everybody has a part in it. If you're a part of the business, if you're a tech lead, if you're a developer, if you're a product owner, agile coach, everybody has a part in it. But my way of speaking to that and trying to resolve that is develop a RACI, clearly make it known where everybody falls.

And then I like to hold people accountable. Like I mentioned that, I will go to you and say, "This is what you're supposed to be doing so let's get with it." That's my response over to you guys.

Jan Trojanowski:

I agree with Kimbaly. I just want to add the there's a concept of self organizing teams, of course. And the self organizing teams are taking responsibility [inaudible 00:40:39] ownership of how they are performing. So if there is an engineering waste that's happening then I think the team should acknowledge it. And I think we should treat the team as the smallest unit where we shouldn't go to individuals, but work with them, the team.

Brian Pang:

Yeah. Personally, I'm a fan of rotating the responsibility, but in essence, the entire team is responsible. And I would also say it's important to show your progress. So if you have a clear goal on here's the target or key performance indicator, show that. Show the team's scorecard to your team members. Most people like to see the progress towards the goal and understand if the team's moving closer or farther from it. And in my experience, both inputs will help galvanize people into action. And I mentioned this earlier, but celebrate. If you're eliminating some waste, celebrate it. It's important and we need to recognize that it's important and people should be rewarded for driving efficiencies and that work matters.

Jeremy Morgan:

So this next question is directed towards Jan. Would you characterize dealing with that large pull request as a form of waste?

Jan Trojanowski:

Yeah. I think what I wanted to say, and what I'm going to try to say right now is it's a good practice to work in short iterations. So to split the stories into as small as they can be, not to take huge stories, not to create extremely big pull requests that are going to cause everything that I was describing previously. So I think, well, it is kind of an engineering waste if you have to struggle with huge pull request. Sometimes of course this happens. However, if it's possible, I would recommend to focus on splitting the stories and deliver small incremental changes. 

Brian Pang:

Don't boil the ocean.

Jeremy Morgan:

Yeah. And the next question is what is the best way and strategy to handle technical debt on an agile dev team?

Brian Pang:

I think I mentioned a few things there. So it's understanding the return on investment... Sorry, understanding the impact assessment first. So how does this debt impact our operations and our business. And then doing the ROI assessments is if we removed it, what would it take, what are the benefits and then determining whether it's worth doing or not.

Kimbaly St. Matthew-Daniel:

Yeah, totally agree. Just on that, there are varying insights with technical debt. Some that can be beneficial to what you're doing and some that may not. And so you have to do that assessment and just know where are you going to drive value and where you want to make that have that conversation. And so what that looks like from a product owner and a development perspective, and something that I try to coach on is that if the team feels 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 or direction or goal they want to take their product in. And so for me, the team needs to leverage like this is where we see us adding more value, again to the customer satisfying them and making life easier for them. And they have to clearly identify like good tech debt and bad tech debt and ensure that they have [inaudible 00:44:21] conversations with the person who was ultimately driving the direction for the product.

Brian Pang:

I would add one thing too. I'd point folks here who are interested in that topic to look at an author named Martin Fowler who writes a lot about refactoring and tech debt in general and different techniques and situational solutions. So Martin Fowler, he's brilliant. 

Jeremy Morgan:

And so the next question here, when it comes to process waste, I use lots of data from Jira and try to identify the trends then the team can try to see where the issues might be. Do you have any favorite metrics that help you identify issues?

Jan Trojanowski:

I'd love to answer that because I do have one metric that I just extremely love, and I think this is the best metric ever to use and it's cycle time. So the cycle time is the time it takes from when your dev team picks up the work till it's done, so it's delivered [inaudible 00:45:24]. It is a very powerful metric. I really love using it and there's a lot of different explanations that I could give you why I do, but I'm going to try to summarize it in just few words.

So first of all, I think cycle time is able to encourage good practices. So everything that we are talking about today, every single waste that we see, if you're going to be able to focus on trying to minimize or trying to lower the cycle time, you're going to see that you are in fact solve the problem of engineering waste. Things like huge pull requests that we were talking about, things like lack of automation, for example, which we didn't really talk about yet today. 

So there's also a term called Toil. It's coming from site reliability engineering, and toil stands for manual repetitive work. The more we do it, the... Well, let me back up. The manual repetitive work is not something that we should be doing. It's 2021, I think the opportunities for automation right now are extremely huge. It's not 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 pipelines. So I think focusing on automation, focusing on other good practices are going to... When focusing on cycle time, you are going to take action on reducing these things. 

I also want to say that cycle time, why I personally love it so much is it's a metric that benefits directly your customers. So low cycle time means that you are able to deliver customer value frequently and on a very good pace. Last thing I want to say about cycle time is please keep in mind to pair that with a quality metric because focusing only on cycle time might lead to a situation where you're just going to throw low quality work outside.

Brian Pang:

That's bad for business. There's one point I wanted to raise earlier, but then I lost my train of thought, now it came back, is everything Jan said is relevant and eliminating waste and automating as much as possible frees up our team to be able to upscale and re-skill. And 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, 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. And so what happens there is many downstream impacts. If the company needs to shift direction or pivot can they rely on the existing task force workforce to adapt or do the need to go and hire externally? So this is why eliminating waste is so critical. [inaudible 00:49:18] free people up and our leaders, like it's up to us to create that environment and enable that space for people to upscale and rescale. 

Jeremy Morgan:

Absolutely. And is cycle time, is that a report in Jira or is that something that you've created custom, Jan?

Jan Trojanowski:

I think there is some data that you can see connected with cycle time in Jira. I'm personally using Pluralsight Flow. I decided that I really love your product. So in Flow I'm able to configure Q time. So I have a custom configuration for each project that I can do. And I'm able to say which states of the tickets are indicating that this is a waiting state. And then Flow is able to generate a report for me connected with Q time, but also with cycle time. I really love that I have an ability to generate a report every sprint and I or scrum master that I work with, we're able to approach the team and talk about data, talk about what's happening and then together with the team, try to figure out [inaudible 00:50:42] waste. What happened that we have encountered, that kind of Q time. 

Flow is also offering me a list of top 10 tickets that had the highest Q time and highest cycle time. So this is definitely something that we are working with and we are we're working with our teams connected with these reports.

Kimbaly St. Matthew-Daniel:

Yeah, I think that's a really great tool because you can customize it however you want. Efficiency, I go for the one that's in Jira.

Jeremy Morgan:

Awesome. So we are just about out of time here. I was wondering if each of you wanted to give some final thoughts to everybody on eliminating engineering waste and we could start with Jan, if you want to start. 

Jan Trojanowski:

Yeah sure. First of all, thanks for being able to tolerate my Polish English. 

Brian Pang:

It's great. It was great, Jan.

Jeremy Morgan:

Yeah.

Jan Trojanowski:

Thank you. Thank you. My closing are going to be... I really wanted to put some spotlight on cycle time. I think that in many teams, in many organizations, velocity is something that we focus on a lot. This is the first metric that [inaudible 00:52:02]. This is the first metric that usually agile and agile teams focus on and learn. Cycle time is still something that I feel like this is not yet adopted too also. So if I can have any wish from myself to everyone who's listening to us, just cycle time. Yeah. Think about that. Try to see what cycle time your teams and product has to be able to analyze what's happening there.

The only last word that I want to say is there's there's a book called Accelerate. I think this is just a must read for anyone that's in software engineering and not only for engineers, not only for engineering managers, leaders, but also for agile coaches, scrum masters, product managers, product owners. It's a great book that that tells a lot about how can we build effective organizations. That's it, thank you.

Jeremy Morgan:

Yeah. Huge plus one to that book and follow Dr. Forsgren on Twitter also, this constant stream of great information. So Kimbaly, you have some final thoughts for us?

Kimbaly St. Matthew-Daniel:

For me, it's just key focuses on change management. I think that's happening a lot. I know from the organizations that I've been involved in, but there are some whereby team members are currently being shifted over to work on other products just to better support them. And I think Brian may have mentioned that we have to be comfortable with that transition and just looking at our ROI, and if there are some products that are going to release more value, just understanding from a business perspective and at that leadership level, what impact does that have on our teams? And just going back down to the team health, that there is some ways that we want to inspect and ensure that we are communicating with everyone who's going to be impacted so that we can eliminate that as much as possible. 

Jeremy Morgan:

Absolutely. And last, not least, Brian. 

Brian Pang:

Yeah. Thank you so much. I just want to say it's been a privilege to be on the stage with all of the panelists here. And my one last thought is I would encourage all the leaders here to be human about things, especially throughout this work from home pandemic situation. Hopefully we're at the end of it. But with so much happening in the world here with mental health and wellness at the forefront and physical health, not just within your workforce, but within your workforces, your team members, families, and 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 100% consistent every single day. And if performance is dipping or inefficiencies are piling up, let's not automatically default to adding process. 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. Go beyond your sprint retros and your agile ceremonies. Normalize that life will happen and will impact your team's output. 

So during these times plan for routine's productivity to be a little bit lower. Set good expectations at all levels. And if your people feel supported and are retaining 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 and 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.

Speaker 6:

Thanks for listening to All Hands on Tech. To see the show notes and more info, visit pluralsight.com/podcast.