Technical Excellence, Team Productivity and Scrum Anti-Patterns

Transcript

Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture podcast. Today, I have the privilege of sitting down with Stefan Wolpers. I'm in Australia, Stefan's in Germany, so we're 10 hours apart this week, which is better than some and worse than others. Stefan, welcome. Thank you very much for taking the time to talk to us today.

Stefan Wolpers: Thank you very much for having me, Shane. It's a privilege to meet you finally.

Shane Hastie: Indeed, we've corresponded and been aware of each other for probably, most of the last couple of decades, but this is the first time we get to actually talk. So my normal starting point is, who's Stefan?

Introductions [00:45]

Stefan Wolpers: Well, I studied chemistry, so that's my background, but I spent my whole professional life in developing health and software. And with a fair share of ups and downs and failures and whatnot. And so I started using practices like XP and Scrum almost 10 years ago and I've been involved in them ever since.

So technically, at the moment I try to explain Scrum to other people and I still love to do that. Otherwise, I have a community that I support, with a newsletter and meetup and I write quite a lot and I hope that we will make progress as far as self-management and organization are concerned.

Shane Hastie: Let's talk a little bit first about that community newsletter. It's certainly one we appreciate, the fact that you regularly point people to some of the InfoQ articles. Thank you very much for that. When you dig into or find source content for your newsletter, what are you looking for and what are you bringing to the world?

Finding content for the Age of Product newsletter [01:48]

Stefan Wolpers: Interesting thoughts beyond the mainstream. So there are different areas that I'm really interested in. Of course, the Agile topic in general, but also product in the sense of figuring out what might be the next big thing and how to get there.

But then practices, tools, processes, how is that supposed to work? So for example, one of my pet topics is engineering productivity, for example, because I find it very, very hard to think about this and no one has yet come up with a decent system.

Of course, I delve into strange thoughts about how we build products, have this lemon category in my newsletter where I from time to time, point to article that totally not get it, I mean, it's totally off-topic, so just to provide other people with some thought how not to do this.

And yes, otherwise, I have a quite broad spectrum of topics that I'm interested in and I put them all together in a weekly newsletter. So get about 12, 14 recommendations and I hope people enjoy what I discovered over the week.

Shane Hastie: One of the InfoQ values is, we consider ourselves information Robin Hoods, finding ideas that are out there and sharing them and certainly, I see that value very much in your weekly newsletter. 440 editions of the newsletter, I think it is now. So been around for a while. What are some of the big trends? What are some of the key things that you are seeing mid-2024?

Trends in product management [03:22]

Stefan Wolpers: People seem to be tired of framework based Agile, let me put it this way. And now is there some sort of backlash, which I find very interesting because a year, one and a half years ago, everyone was frantically using for Agile practitioners no matter what kind of credentials they could show.

Nowadays, it's the complete opposite, so that's very interesting. Of course, certificates, I think, become less interesting to a lot of people, so we're finally getting to a point where people are more interested in what someone can actually contribute to an organization and a team, which I think is a good trend.

We're moving, I believe, more into product in a broader sense, how to do this. So prominent voices, for example, our Marty Cagan with his product operating model at the moment, but you can see this also in other fields. So there are quite a lot of people by now in the product field who have decently sized newsletters and actually make a living from it. So the classic creator economy breaks through in that part, which I find very interesting to observe. So Lenny Rachitsky, for example, will be a good example for that.

So it's a really exciting time. So on the one side, a lot of challenges, where's everything heading, is Agile obsolete, what about ChatGPT and all the other LLMs? How will those influence our jobs in the future? And then on the other side, you have hopefully, a trend towards being more honest with yourself. Maybe embrace that in a complex environment, things are not so easy and you can't just roll them out, like MacBoston tends to sell it to you. So maybe we are moving slowly but surely towards some home grown way of working. So I believe that is currently, might be an outcome of the further development.

Shane Hastie: So yes, certainly a lot happening in the product space. You mentioned engineering productivity, what's happening in that space? And you've said there's no good measurements yet, but what are you seeing? Where are we heading?

Qualitative approaches to engineering productivity [05:33]

Stefan Wolpers: I think we're moving away from a purely quantitative approach to start including more qualitative aspects too, for example. I mean, the problem is, if you're working on an assembly line and your refrigerators, it's quite obvious that if you produce two more refrigerators per shift and you have a good brand and people like to buy your refrigerators, you create more value. In our case, in our industry, this approach is complete nonsense. I have no idea whether adding a few lines of code will deliver any value, maybe on the contract, we don't know yet.

And so I think there are significantly other factors that influence productivity of a team, factors that are not so easy to detect by simple metrics. So simple example, I like to ask my teams at the end of a sprint with an anonymous survey, for example, "Okay, how do you think what kind of value we delivered, this sprint?" So classic like at scale, so NPS like zero to 10 or something like that. Another question I always like to ask is, "Okay, what about the technical health of our application of our platform here? How would you rate it again like at scale?" And then I like to also get into the more tacit field like, "Hey, would you recommend an open position in this organization to a good friend with an Agile mindset?" Again, like at scale. So a bit of employer NPS here, right? Despite the fact that NPS is such a flawed metric, but it's simple and it's quick, and everyone understands it.

And my last question always is, "Okay, professionally do you have the time of your life?" And again, people tend to cover the whole spectrum from "Yes, this is the best time of my life professionally, I totally love it," to "No, I already started looking for a new job." And if you collect that data over a period of time, you can very easily start spotting trends early. And if you combine this, for example, with some sort of team diary, what is happening when? Think of like a ship captain, you simply write down what happens. Then you can start actually making connections between trends and certain events that happened.

And all of that now deliver a better insight into how the "productivity," air quotes, from an organizational perspective or from a user perspective has developed. If you figure it out that your technical quality is deteriorating and it has been constantly for some time now, and at the same time you can deliver less and less, so maybe that provides you with the right interpretation that there might be a causation between the two. So maybe it's a good idea to actually improve the team productivity by putting more time into preserving the technical excellence of your platform and avoid shortcuts.

So that's what I like to explain as, in the complex environment, it's very difficult to figure out what real productivity is.

Shane Hastie: When you say technical excellence, we know it's one of the foundational principles of the Agile manifesto, but what do we really mean?

What do we mean by technical excellence? [08:39]

Stefan Wolpers: We always talk about we like to become agile as an organization, so business agility is a big goal of many organizations, achieving that level, and there are always two components that contribute to it. A, you need to be good at figuring out what the next big thing is, but B, you need to be also in a situation where you can actually deliver on your new information that you have. If you want to be agile as an organization, it basically means, you want to deliver faster than the competition. And this, in my experience, is only capable if you're really good at technology. This referring to the quality of your tech stack on the one side as well as to the expertise of the individual team members on the other side.

And you simply have to invest regularly and a significant part into preserving the health of your platform, maybe even improving it, and as well turn your team members up to the job and spread new knowledge, for example, figure things out that are new and exciting. So I believe it's mission-critical that you allocate significant parts of your capacity for every time unit to just help the team to become excellent; maybe, if it's not yet there, or to preserve the level of excellence they have achieved.

Shane Hastie: What gets in the way of technical excellence?

Things that hinder technical excellence [09:59]

Stefan Wolpers: So many things. Mostly, it's systemic issues like budgeting, for example, is really tricky. So if you have this class of stage gate approach and you need to accomplish something, maybe a milestone that was imposed on your team and by a certain date, and the only way that you actually have to move is to get sloppy with the workmanship and take shortcuts where you exactly know, we shouldn't be taking that shortcut and everyone said, "Okay, we have to do is otherwise the funding of the team will no longer be available, but when we get the new funding, we will come back and fix it," which of course, never happens. That is a very tricky aspect.

In a lot of organizations where the management is a bit more, I wouldn't say, old-fashioned, but more oriented regarding the industrial paradigm. It's very hard to explain to them, "Hey, we need 20% of our capacity to actually keep up running here," because they believe, no, you're supposed to create new features and whatnot, enhance revenues, and they come up with a lot of ideas, but the basic concept that you need to preserve what you have and so you have a long-term sustainability as an organization, as a team, never really occurs to them because most of them see engineering as a cost center and not as the foundation for being in the business five years down the road. They don't have this horizon.

That is the major part. It's less so an issue in my experience of the personal level. So yes, maybe a few people are a bit reserved when we talk about sharing knowledge and tips and tricks and something like that, but most of the time, it's never something that happens at the team level. It's mostly happening at the systems level.

Shane Hastie: So if I'm a technical influencer, a technical leader in the organization, how do I advocate?

Advocating for technical excellence [11:54]

Stefan Wolpers: That's a very good question. It really depends on the culture of the organization. I mean, often, working with teams where this was a no-go area, you simply couldn't voice your concerns because once you did it twice or thrice you had this label of complainer, and then no one would listen to you. So you just stopped doing that because it was a waste of your time. There are moments when people feel so psychologically unsafe that they just go on in the tracks other people created, until it no longer works. So the moment you figure out that, "Hey, we've been using gaffer tape for years now and we cannot use gaffer tape anymore, we just need to rebuild the stack completely, and it's really bad that we actually should meet a milestone for the next funding round, but we can't do so now." A lot of different issues.

I mean, this is the very hard way for everyone to learn that investing in technical excellence, it's not just spending, that investing in technical excellence is a very good way of preserving your long-term sustainability as an engineering organization. So I would say, steadily remind people of what is going to happen because it's not a question of "if," it's just a question of "when." There's this really fantastic sign that says, "If you do not schedule time for maintenance, your equipment will schedule it for you." I really like this and it exactly explains why technical excellence is of critical importance if you want to be successful as a team and consequently, as an organization.

Shane Hastie: What are some of the other team aspects that we should be paying attention to?

Enabling team productivity through trust and transparency [13:41]

Stefan Wolpers: Treat everyone as an adult. I'm always puzzled that managers do not trust the people they hired themselves. And I always ask myself, "Okay, if you do not trust someone, why hire them in the first place?" Maybe that's not a good idea, but I always expect a positive intent and everyone has the benefit of the doubt, and if we believe that someone is a good addition to the team, please treat them as such. And from our perspective, for example, what is mission-critical is that people have a good understanding of the finance of the organization and the team and the product. I do not understand why many teams have no idea how much they cost. So it's a very simple question. I mean, there's these meeting clocks where you can dial in a number and then you see the dollars falling so to speak. This is an excellent idea because in my experience, the moment the team knows, "Hey, when we're working here an hour, it's about a thousand dollars, altogether of us," that they start making different decisions.

From one second to another, they become more entrepreneurial. They really think about, "Okay, what would be a good approach to actually provide this kind of functionality? Does it really have to be the fancy way or can we have a less fancy way? Give it a try, see if it works and if it works, then probably consider whether it makes sense to invest a bit more of our time because we like to maximize the return on investments." This is, my experience, really a good approach from everyone's perspective.

The team feels empowered, now self-organization, self-management actually becomes meaningful in the sense that they make an investment. They're not just collecting their paychecks at the end of their time period. From the organizational perspective, because I've never met a team that was starting to spend money or invest money or their time like crazy, once they knew how much they were costing the organization, because they became rather aware of the fact how much this is. So it's a more kind of cautious spending, applying technical expertise and common sense to the whole aspect. And I think this is a really good way to create a team that really feels empowered and actually performs much better than the ordinary team that's being told what to do when, where and how.

Shane Hastie: Before we started recording, we were talking about the technical career paths and the dual track perhaps. What are your thoughts on that?

Technical career paths [16:10]

Stefan Wolpers: Again, one of the systems issues, I believe, because many organizations, at least those that I know, still have a rather traditional way of defining what career means, and it really does not really align with the needs and requirements of an agile way of working in whatever form you do this, it's not framework specific here. But usually, you have some sort of career path, you start as a junior, then you are the normal, and then you're a senior and then you become the lead and the head of, and whatnot. I mean, I've seen junior Scrum masters, ask myself, okay, what is this junior scrum master? Because you need to have actually a quite serious level of expertise to move anything in a positive direction if you try to do that. And I don't believe that a junior has this kind of experience.

Another problem I see, when you go back to these traditional career paths is that there will be a moment when someone becomes a “lead” and the lead engineer, for example, is critical part of product frameworks. So for example, think about Teresa Torres' Continuous Product Discovery and the Product Trio. In a way, you have the product manager, the tech lead, and the design lead, considering about, "Okay, what might be good opportunities to pursue?" I always think to myself, "Wouldn't it be great if the whole team could do this and not just the tech lead?" Because in a complex environment everyone can have the right idea, the right solution and diversity of opinion is really helpful. So always struggle with the idea that the moment you have a lead on your team, you're probably crowding out a bit of the knowledge of the rest of the team. And the challenge always is, how can I avoid this? How can we find a workaround? What can we do about it?

But on the other side, of course I understand that from a career perspective, it's very natural that an individual has the desire to become a lead because that might be the next step in his career. So, difficult topic, really difficult topic.

Shane Hastie: Something else you've done recently is published a book, the Scrum Anti-Patterns Guide.

The Scrum Anti-Patterns Guide [18:17]

Stefan Wolpers: I did, yes.

Shane Hastie: First of all, why the book?

Stefan Wolpers: That one has long history. So basically, started out when I was working for a large utility here in Germany and I was commuting a lot from Berlin through an area and back. And when I was on the train, I basically took notes on what I observed and then I turned it into blog posts and then there were more blog posts and then I turned it into a small ebook I gave away. And a lot of people said, "Hey, this is totally cool because now we know what we can expect or what to watch out for." And I thought to myself, "Okay, maybe there is more to it than just an opportunistic way of creating blog posts for your community." And I've never written a book before and I thought, of course, "How hard can this be? You can do this." And I reached out to Pearson via scrum.org and they said, "Yes, that's an excellent idea, let's do this."

Then I started to do this a bit more systematically and it was quite a ride because originally, I thought it would just be transferring the ebook into something printed, but it turned out that I completely rewrote everything and why the book? I like the learning principle of inversion. It's a really fun way to actually understand things, figuring out what not to do and how to avoid this. I'm a big fan of premortems, for example, thinking about how the project will fail nine months down the road and what led to it. It's such a cool concept because nothing has happened, no one can be blamed, there is no finger pointing, and yet you can figure out what to avoid while you are trying to accomplish the goal that you will be setting yourself.

And that's basically, the way here too. So figure out what might be useful when you try Scrum or elements of Scrum and what you probably should avoid. And even more importantly, think about why the things may be the way they are. There's always a reason why an anti-pattern is present. They don't fall from the sky. There was always a reason for that and I think it's a good start to think about the why before you jump to conclusions and start helping teams quotes with standard practices that you've been practicing for 15 years or so. Because sometimes a situation does not need ointment, it needs surgery and you should be able to distinguish between the two.

Shane Hastie: So what are some of the key elements? What are some of those anti-patterns that stood out for you and said, I've got to tell this story?

Stefan Wolpers: A lot of has to do with people, again, systems issues. So I mean, if you work in silos with a strict budgeting process, don't be confused when your stakeholders regard your team as an internal agency that they want to produce features they believe are necessary to meet their targets and their numbers. If you work in such an environment, strictly siloed environment, the path to become a feature factory, it's basically, already defined. It's very hard to break out of this. So that certainly is an issue.

Coming from that also, there are a lot of personal issues at the sense of, "Hey, I have invested a lot of time energy in building my network in this organization and I'm certainly not interested in a bunch of hoodie-wearing nerds to take it away because they believe they are self-managing. They're spending my budget and I'm supposed to just hope for the best." Certainly not, no.

Shane Hastie: So many other issues?

Stefan Wolpers: That's actually the interesting part. I started working on some sort of taxonomy of anti-patterns and there is more to it than you believe. Because at the beginning, I thought it was a random assortment of things going wrong, but actually, there's a bit more to it and I'm really looking forward to exploring that a bit deeper. So that's my research part that I like to do.

Shane Hastie: One of the sections that intrigued me is, how to sabotage Scrum masters and product owners at an organizational level. And you've actually got an exercise, drawing on some liberating structure stuff. Tell us a little bit about that.

Ways to sabotage Scrum Masters and Product Owners [22:33]

Stefan Wolpers: Yes, that's a fun exercise. So the task was relatively simple. So I run those in my Scrum classes and I ask the people, "Okay, imagine that your organization is trying Scrum and you believe this is a fad that will go away and you can accelerate the inevitable by making the life of your first product owner or Scrum master as miserable as possible. You're someone in the middle management." The task, I always say, "Okay, this is what you're allowed to do. You can only apply things that are culturally accepted in your organization. So no outsourcing to the local chapters of the Hell's Angels, that's out of the question, but come up with some ideas how to do this." And then I basically send them off to the races. And the fun thing is, that everyone fully understands what the job is, what they're about to do.

I encourage them, unleash your inner doubt. Wait, that's the purpose of the exercise. And then seriously they come back and it's typically, a fun exercise. Engineers by the way, are really good at this, they have a lot of dark creativity. So then we collect all the ideas and then we, in the second step, think about, "Okay, which of those have you already seen practiced in real life in our organization here?" So we create a subset. And the third part, of course is, "Okay, now that we understand that we already practice things we shouldn't be practicing, is there something we can do about it? What will be your first step that you could actually undertake to push against this?" And that will be, in liberating structured terms, the basic exercise is called TRIZ, and we end with a 15% solution. So just to keep momentum going, do something about it that you don't need budget for and you do not have to ask anyone for permission. You can just do it.

And that actually, is a quite interesting exercise because it moves away from this classical thing, "Is this on the test? Will this be relevant for the certification?" And I always say, "It doesn't matter, no one is interested in that. I want you to leave with the idea that you have a basic understanding how things work and when to watch out for things that are not working." And the examples in the book are basically collected from dozens of classes. It's a kind of best of, but it's one of the fun exercises.

Shane Hastie: What are some of the other important messages that are in that book?

Stefan Wolpers: Don't jump to conclusions. Spend time on analyzing why things are the way they are. Observe, ask, analyze, restrain from solving. That's another important issue. Yes, you may point people to the issues that they are facing, but it doesn't mean that you have to solve them because most of the time, the issues are very often problems not impediments. And I believe that a good coach should not work on problems. I mean, if it's cold in the room because the window is open, someone get up and closes the window, it's not my job. And it's part of becoming self-organizing too. I like to help people take a different perspective and understand that, to become good at one thing doesn't mean you have to excel at figuring out what the success factors are. It's a good start if you avoid the typical blunders that all the others make, because that already elevates you above the average. And then you can take it from there. As always, experience grows over time and you need to take it step by step. And we all start at the beginning and this book might give you a little headstart.

Shane Hastie: Wonderful. Well, Stefan, lots of good content there. I thoroughly enjoyed our conversation. It's been great to actually have a talk rather than other sorts of correspondence.

So, if people want to continue the conversation, where would they find you?

Stefan Wolpers: They can Google me, this is the easiest way and they can look on LinkedIn. But one of the privileges as a published author, you have these nice book boxes on Google, it ensures that I'm at the top of the search list, which I find really interesting. So at the moment, it's, I think, the most important external success factor of the book, I would say. Besides that, I learned a lot during writing it.

Shane Hastie: Stefan, thanks so very much for taking the time to talk to us today.

Stefan Wolpers: And thanks a lot for having me, it was a real pleasure. Thank you.

Mentioned:

• Stefan Wolpers on LinkedIn
• Age of Product Newsletter