Episode 23 – The productivity illusion
/
RSS Feed
A CEO wants to understand the value she is getting from the team whose salaries she is paying. A VP wishes to reward based on how individuals in his team are performing.
In some groups such as Sales, this seems so straightforward. Yet like Schrödinger’s cat, software development teams can seem to be both productive and non-productive, according to how they are observed. Attempts to measure developer performance seem inevitably to lead to conflict. Why is productivity such a challenging concept? And why specifically in software development?
This podcast is AI-generated based on material from the “Agile Plays” website and book .
Transcript
Welcome back everybody to the Deep Dive. This time, we're gonna tackle something that's always a bit of a headache, you know, figuring out how to actually measure productivity when it comes to software development. Yeah. It's one of those things everyone wants a clear answer on. But, It's not exactly like you can just, like, count lines of code and call it a day.
Right? Right. And it's tricky because well, software development, it's not just about, you know, cranking out code. It's a whole different animal. So then where do we even start trying to untangle this whole mess?
Well, I I think the first thing you gotta do is kinda step back and ask, what does productive even mean in this crazy world of software? Because, see, a lot the old school project management stuff, it kinda falls apart here. In what way? Well, they put so much emphasis on, like, predictability, you know, hitting those deadlines, always sticking to the plan. But with software, the real goal is the value you deliver in the end, and that that's a whole different ballgame.
So just measure lines of code or how many hours someone's logged, that doesn't actually tell us if we built something useful. Mhmm. Exactly. Imagine it like this. Building a bridge, that's all about predictable steps.
You know exactly how much concrete, how much steel you need, software. It's more like you're hacking your way through a jungle. Oh, I like that. So the path isn't always clear from the start. You got it.
You gotta constantly adapt. Sometimes you even gotta change where you're heading based on what you find along the way. Traditional metrics just don't capture that kind of flexibility. It's almost like sometimes the most productive thing a dev team can do is to say, woah. Hold up.
This ain't working. We gotta rethink this whole thing. That's exactly it. And that kinda throws a wrench in the whole traditional productivity idea. Right?
Big time. So we got this kinda clash between trying to be predictable and actually being productive in this, like, ever changing software landscape. Yeah. That's a great way to put it. Old school project management, it's like trying to sail a ship on a perfectly calm sea.
You got your course. You stick to it. But software, it's more like surfing. You know? You gotta ride that wave, adjust to the currents, be ready for anything.
Exactly. And that's where these ideas from agile lean, they start to make a lot of sense. Okay. Now you're talking my language. Yeah.
I'm always hearing about agile lean. Yeah. But, honestly, sometimes it feels like everyone's using these terms, but nobody really knows what they mean. Well, the core of it is they both kinda embrace this idea that change is gonna happen, and it's not something to fear. It's like roll with the punches, be ready to adapt, and in the end, deliver something truly valuable even if it's not exactly what you planned on at the start.
Exactly. It's about outcomes, not just output. And this brings us to some really cool tools for measuring all this, like, have you heard of the Dora Metrics or the concept of work in progress? Oh, yeah. DORA metrics ring a bell.
Isn't that the stuff about, like, how often you're deploying code and all that? You got it. DORA stands for DevOps Research and Assessment, and their metrics look at stuff like, how fast can you get changes live, how often do things break, and how quickly can you fix them if they do. So it's like taking the pulse of your whole development process, seeing how efficiently things are moving from idea to, like, actually being out there in the world. That's a perfect way to put it.
And then there's the whole work in progress thing or YP as some people call it. And having too much of that, well, that's a recipe for disaster. Too much work in progress is a bad thing. I feel like I'm always hearing, do more, do more. How can that be a problem?
Well, think about it like this. Okay? You're working on, I don't know, five different things at once. Coding this new feature, fixing that bug over there, trying to design something else. Your brain's jumping all over the place.
Oh, for sure. I know that feeling. It's like having a million tabs open in your browser. Eventually, everything just grinds to a halt. Exactly.
And in software development, that's what happens when you got too much YYP. It creates these bottlenecks, slows down the whole process. Like, everyone's stuck in traffic even though individually they could be speeding along. Yeah. Perfect analogy.
And that's why it's so important to focus on flow, like making sure work can move through the system smoothly without getting stuck. Okay. This is making sense. So we got these door r m metrics to keep an eye on the big picture, and we gotta be careful about not overloading things with too much YP. But how do we know where to focus our efforts?
Like, what are the specific areas that need the most attention? That's where this idea of a balanced scorecard comes in. Oh, right. You mentioned that earlier. It's like a dashboard for your team Alright.
Showing you how things are really going. Exactly. It helps you avoid getting tunnel vision. Because, see, if you only focus on one metric, well, you can run into some serious trouble. Like, well, give me an example.
Let's say you only care about speed. So you reward your team for pumping out code as fast as possible. What do you think happens? Well, I'm guessing quality is gonna take a hit. People start cutting corners just to meet those deadlines, and then you end up with a big old mess to clean up later.
You got it. Or let's say you only focus on fixing bugs. What about then? Wouldn't that stifle creativity? Like, everyone's so busy squashing bugs, they don't have time to come up with new ideas or build anything new.
Bingo. That's the problem with relying on just one metric. It gives you a really distorted view. It's like trying to judge a basketball player only by how many points they score. You're missing the whole picture.
Yeah. Totally. You gotta look at assists, rebounds, steals, all of it. A balanced scorecard for software development, that's kinda like looking at the whole stat sheet. Right?
Absolutely. You wanna track things like customer satisfaction, how good the code is, whether your team is happy and motivated. You need that holistic view to really understand how things are going. So we're not just looking at how MBCh code we're producing, but also, like, the quality of that code, how quickly we can get it into the hands of users, NDA, whether those users are actually happy with it. Nailed it.
And that helps you avoid this trap of gaming the system, you know, like, people trying to hit those metrics even if it means doing stuff that's actually harmful in the long run. Makes sense. You're encouraged in a more sustainable approach where everyone's working together towards a common goal. Mhmm. But I gotta ask, doesn't the very act of measuring something, doesn't that change how people behave?
Like, if you know you're being judged on something, you're gonna try to make that number look good even if it's not actually the most important thing. Oh, you're absolutely right. That's a huge e point. It's this thing called the Hawthorne effect, and it's pretty mind blowing, actually. Okay.
Tell me more. I'm hooked. Yeah. Hawthorne effect. It sounds kinda ominous.
So back in the day, these researchers were studying worker productivity at a factory. Pretty basic stuff. Right? They wanted to see if things like, I don't know, better lighting or more bricks would make people work harder. Yeah.
Seems logical. Optimize the work environment, everyone wins. And get this. No matter what they changed, productivity went UP. More light, productivity goes up.
Less light, still goes up. More breaks, same thing. Fewer breaks, same thing. It made no sense. Really?
That's wild. It turns out that people weren't responding to the changes. They were responding to the fact that they were being watched. So it's like they knew they were under the microscope, and they wanted to put on a good show. Exactly.
Just knowing you're being measured can change your behavior even if you don't realize it, and that's a big deal for how we measure productivity. Right? Yeah. Huge implications. Like, we gotta be sure our metrics are reflecting real improvement, not just this kind of performance for the sake of the measurement.
Precisely. We gotta constantly ask ourselves, are these metrics giving us an honest picture, or are they just telling us what people think we wanna hear? This is seriously deep stuff. So how do we avoid falling into that trap? How do we make sure our metrics are actually leading to real positive change?
Well, one of the biggest things is transparency. Everyone on the team needs to understand w I y certain things are being measured and how those metrics connect to the bigger goals. So no more secret formulas or metrics that only the managers understand. Right. Transparency builds trust, and it lets the team actually take ownership of their performance.
When everyone knows the w h y behind the numbers, they're more likely to buy in and actually care about improving. It also opens the door for feedback. Right? The team can say, hey. Maybe this metric isn't really working anymore.
Maybe we should try something else. It becomes this, like, ongoing conversation, constantly adjusting and refining the system. So it's not about finding that one perfect metric and sticking to it forever. Right? Exactly.
It's about creating this culture where improvement is just built into how the team operates. Measurement isn't a punishment. It's a way to learn and grow together. And, honestly, that's when things get really exciting. It's more about the journey than the destination.
Right? Constantly learning and improving, that's what really matters. You got it. That's where the real magic happens. When teams can, you know, look at their own work and say, okay.
What went well? What could we do better next time? They're not afraid to try new things, even if it means messing up sometimes. So it's about building that culture where learning is just part of the DNA. It's not something extra you gotta do.
Right. And they're excited about it. It's not like, another learning session. It's like, okay. How can we level up?
How can we be even better tomorrow than we are today? I love that. It's like the team's always growing and evolving together, but how do you actually create that kind of environment? Where do you even begin? Well, one thing that's super helpful is doing regular retrospectives.
Like a team debrief after a project? Kinda. Yeah. But the focus is really on what did we learn? What can we improve?
It's not about pointing fingers or playing the blame game. It's gotta be a sea of space for people, to be honest. Right? Absolutely. And the team needs to actually have the power to make those changes.
You know? Otherwise, it's just a bunch of talk, and nothing really gets better. Right. Actions speak louder than words. And we talked about psychological safety earlier.
That seems like a big part of this too, doesn't it? Oh, yeah. For sure. You gotta have that foundation of trust where people feel comfortable speaking up, sharing their ideas even if they're a little out there. Because sometimes the best ideas come from the most unexpected places.
Right? Exactly. And if people are afraid to make mistakes, they're never gonna try anything new. You gotta encourage that experimentation, that willingness to take risks. Man, this whole conversation has been so eye opening.
It's like measuring productivity in software development. It's not just about crunching numbers. It's about understanding the human element, the value, the need for flexibility. And remembering that the act of measure in itself can actually change how people behave, that Hawthorne effect in action. Right.
We gotta be careful that we're not just creating this kind of artificial reality where people are focusing on the wrong things. Exactly. So how do you know if you're on the right track? Well, here's a few things to watch for. Is your team actively looking for ways to improve even when nobody's telling them to?
Are they trying out new tools and techniques? Are they celebrating both their successes and their failures as learning opportunities? So it's more about the mindset, the attitude, the kind of shared commitment to always getting better. Yeah. You nailed it.
And if you see that, if you feel that energy within your team, well, that's a pretty good sign that you're heading in the right direction. I love that. It's about the journey, the progress, not just reaching some arbitrary finish line. Well, this has been an amazing deep dive. So much great stuff to think about.
We've learned that measuring software development productivity is a lot more nuanced than just tracking hours or count lines of code. It's about understanding the complexities of value, predictability, flow, and the impact of measurement itself. But most importantly, it's about fostering a culture of continuous learning and improvement. So keep experimenting, keep learning, and keep pushing the boundaries of what's possible. Thanks for joining us on the deep dive.
Until next time, keep digging deeper.
Leave a Reply