This is a transcript of episode 312 of the Troubleshooting Agile podcast with Jeffrey Fredrick and Douglas Squirrel.
Incompatible regulations, competing customers - this week, a listener in a government IT agency tells us about his team’s difficult challenges.
Show links:
Listen to the episode on SoundCloud or Apple Podcasts.
Andreas’ Problem
Listen to this section at 00:14
Squirrel: Welcome back to Troubleshooting Agile. Hi there, Jeffrey.
Jeffrey: Hi, Squirrel.
Squirrel: So this week we have one of our favorite things. We have someone who listened to what we say at the end of every episode, which is get in touch with us with questions and problems and challenges. And we have a listener named Andreas, and he got in touch with us about a fascinating problem. Jeffrey, do you want to summarize what Andreas told us?
Jeffrey: Yeah, absolutely. So Andreas is in a little bit different position than a lot of people in which they’re a product owner, but in a Swedish government agency. So that’s a little bit different. And that’s really the heart of their question, is asking a question about stakeholder management in their different contexts.
Jeffrey: The context they have is like they are building a product, but they have a lot of different stakeholders in different agencies that need to use their software. And the problem is that these different agencies have different laws that they are trying to comply with, and so they actually end up needing different things. And what they find essentially is that they they have to build things differently for each stakeholder, and they’re having trouble managing all that complexity.
Jeffrey: And the question is: how does this prioritization work in government? And is it possible, for us to build a valuable product in these difficult circumstances? So that was the question.
Squirrel: Oh it’s fascinating. So there’s wrinkles here, but it sounds pretty familiar and pretty relevant to our listeners who aren’t in government as well. Because if Andreas had all the power, if Andreas were the the prime minister of his country, for example, then I might say, ‘hey, hang on, we probably ought to change how this is working, because it doesn’t necessarily make sense for one team to provide many disparate products to lots of different agencies. It might make sense for them to function kind of like a software consultancy, and to build custom products for everybody that are really different.’.
Squirrel: But I’m suspecting that Andreas is writing to us because they’re not staffed to do that, and they’re not set up to function that way, otherwise everything would be hunky dory. Andreas would just be adding lots of new, wonderful developers and building a bunch of different products. But Andreas is trying, as I understand it, to build a single product that serves all these different folks and doesn’t have the power to change that. And that probably is relevant to lots of our listeners who are in larger organizations.
Squirrel: If you’re in a tiny startup, you would be well advised to serve just one persona to try to help. You know, I have a client I’m working with right now in transport, and they got started with trains. They’re moving on to airlines and taxis and other things to provide their particular service. But they started with trains in one country, and that was a persona that they got to know very well, and they became very successful with it. Similarly, it would be great, but probably not an option for Andreas if he could start with just one and make all the others go away. But I suspect from the way Andreas wrote to us that that’s not the situation that they’re in.
Jeffrey: Yeah. That’s right. And that’s the thing that first struck me is the description of the problem, which is that all these different stakeholders with different demands essentially need their own work. And then the final question, ‘can we build a valuable product?’ And the idea, the assumption that it’s one product, because that does resonate with something I’ve heard in software, which is that people often have very different personas, not as extreme as what Andreas is driving, describing where there’s different regulatory frameworks, although that can happen as well.
The Solution: Common Core and Serialization
Listen to this section at 04:01
Jeffrey: But what it made me think is that maybe he’s they’re not actually building a single product, but rather maybe it’s more like a platform play, which is what you do with this kind of thing in a product environment. You’d say, well, ‘what’s our Common Core?’ And then we need to build separate pieces on top of that. And then as you say, these are like completely different efforts. You realize what you’re doing with one market is different than where you’re from, a different market, even if there’s a common element.
Jeffrey: And I think something like maybe Salesforce is a good example, where there’s a common platform, but then there’s different pieces on top. And the key thing that I think gets to what you describe is, well, you you might have one team build out different add ons on top of your common core, or you might have different teams build it, but there’s not the idea that you can necessarily have one team build everything at once. You don’t go have them build, you know, four different add ons on your Common Core at the same time, and thinking that that’s a good idea.
Squirrel: And of course, one of the great things about a Salesforce or a Shopify or any of those types of platforms is that there’s also the option which may not be available to Andreas, but is worth exploring: having your customers build things as well. So if they’re feeling impatient and they really want you to do a nifty thing, you can say, ‘well, here’s our API, here’s our documentation, go and build your own thing. We’ll get there in time, and maybe we’ll use what you have, what you come up with. But we’re not blocking you. You’re still able to go and do it. It’ll just cost you some more.’
Squirrel: But I have the feeling knowing the government as as I do, I don’t know, Andreas’ government. But assuming it’s a normal government, there’s probably not a lot of money around for that. And there’s not a lot of patience with the other agencies saying, ‘oh, yes, of course we’ll go hire our own developers.’
Jeffrey: Right, exactly. And so in this sense, it kind of reminds me of an old fashioned, IT cost center in a large enterprise where-
Squirrel: Yep!
Jeffrey: -the idea is like, ‘well, of course it’s the IT people who are doing it, who need to build all of our software.’ And then you have the different lines of business that want demands on them, and they expect all of their things to be done at the same time because, ‘well, look, we’re all asking for the same thing,’ from their point of view, even if their requirements are very different. So that in that challenge of, you know, cost center accounting as the sole supplier in your organization, that also sounds very familiar to me and not particularly a government constraint.
Squirrel: And so it strikes me there are there are two solutions, two parts of a solution here that we can offer to Andreas, neither of which is very much fun. I don’t think we’re going to give Andreas easy medicine that’s going to go down nicely with a spoonful of sugar here.
Squirrel: So the first part is pretty much assuming that Andreas has a limited team size, and he says they are struggling to keep up with all of these different demands. He really needs to serialize them. So the demands of reality, the demands of human organizations and software malleability say that really, Andreas needs to build something for agency number one and then for agency number two and then for agency number three, and can certainly create a common core underneath them.
Squirrel: But they’re really architecturally, his engineers are going to think about it as a core platform with plugins that really are separate and do completely separate things. They may they may borrow a few ideas from each other, but they’re really separate code repositories that are probably going to be separate in an architectural sense.
Squirrel: So that’s hard enough. And I imagine Andreas is having trouble creating that reality for himself. And getting that architectural change in place with the engineers. But then he has a second challenge. I’m sorry! And that is, he’s got to get somebody to approve doing things in order. And that’s probably somebody within his own organization who may not have a lot of technical knowledge but is very interested in delivering well and would like it if the team could deliver more and if that didn’t cost any more. But the team could do ten times as much. And there’s going to be a difficult conversation there, Jeffrey, I think.
Jeffrey: Yes, and this reminds me of a previous discussion I did have with a government. In my case, it was a local city government. I live in Santa Cruz, and probably 13 or 14 years ago there was a meeting, they had a new CTO who then invited in some of the local tech community, and we got to talk to different people. And actually, I came across someone who had a very similar challenge to what Andreas is describing within the government context. And what we said is very much what you’re describing.
A Frictionless Team on an Infinite Plane
Listen to this section at 09:03
Jeffrey: ‘You’re going to have to have a difficult conversation with your stakeholders who are waiting for things.’ And I said, ‘and the most difficult part is going to be that what you should do, what gives the best answer is the most difficult politically, which is to say this strict serialization.’ And we introduced a simple toy model, which, we may have discussed this in the podcast before, but you can imagine if you had four projects and each of them for four different agencies, and each one will take one month. Then what naturally happens from political pressure is you work on all four in parallel.
Jeffrey: And that’s even more true in Andreas’ case, where people feel like it’s the same product. ‘Well, you know, can’t you work on all of it at once?’ And so then what happens is, if you imagine any kind of theoretical physics sense, this perfectly frictionless team on an infinite plane, that they time slice between the different projects. And all four projects are done in four months. And that’s kind of what people are used to today. But what you want to do is go into the serialization where the first project is done in one month, the second is done the second month, third is done in the third month, and the fourth is done in the fourth month. And there’s a weird thing happens because-
Squirrel: We don’t live on that infinite plane, because the reality and I think this is what triggered Andreas to write us, is that it’s tremendously complex to do that. What engineers would call context switching, going from one activity to another is not frictionless. It’s not simple. It’s not easy to try to meet all the different demands from all the different stakeholders at once.
Jeffrey: Yes.
Squirrel: And in fact, it will take you much longer than four months if you try to do all of them simultaneously.
Jeffrey: Yeah, the reality goes even more towards serialization, but the thing is, even in that best case context where you’re not paying the friction, three of your four projects are done sooner and no one is any later. The hard part is the political part where that fourth person, the fourth stakeholder who’s being told that their project isn’t being worked on for three months.
Jeffrey: That’s the really difficult part, but this is true, we see this all over when the answer is serialization and some people need to wait, having that difficult conversation is the hard part. Where that will happen and how that happens in a cost center organization is a little bit different than the way it happens in a profit center. And so there is some nuance there. But fundamentally, you’re going to have to come down to that.
Squirrel: Absolutely. Concretely what Andreas can be doing again, we’re not giving him easy medicine, is determining what’s involved in setting up the platform. You’re going to need lots of engineering help with that. But the engineers will be excited about it. I imagine they’ll say, ‘Hallelujah, somebody is talking sense, finally!’
Squirrel: And he needs to work out, what is that cost? What’s involved in working on one project at a time, if we possibly could? How would we create a common core that could be useful in the next project? And what would the cost be for investing in this, and what would the benefit be? In what way will we save costs in the future? Because almost certainly in a government, he’s not going to be interested in increasing revenue. He’s probably not driving greater tax income, although if he is, that would be interesting. He’s probably providing a service and wants to do that at a lower cost.
Squirrel: And then once Andreas has that clear, he needs to find somebody who can make really political decisions. These are internal political decisions. I don’t think he needs to see the party leader of whoever’s leading the government at the time. I don’t know who that is. He doesn’t need that. But he needs someone who is servicing these other agencies, who is at meetings with them, who has promised that Andreas and his team will do the work at a certain cost and has responsibility for the budget and is accountable for that budget to, I guess, the Treasury or somebody like that. And once Andreas finds that person, that may be difficult to do. Andreas might not know that person. He might need help from his boss and his boss’s boss and folks like that to get to the right level.
Squirrel: And then at that level, you need a difficult conversation about reality, which us engineers do a lot. Finance people often do this as well, ‘hang on. I know it’s wonderful that we want to launch seven new products, but actually we don’t have any money in the bank, so we have to do something about that. Let me show you a chart that shows how we will be bankrupt next month unless we do A, B, and C.’ So that’s the kind of reality check that Andreas needs to have, with a lot of trust and listening and fear reduction. So he’s going to need… Andreas says he listens to a lot of our podcasts, so he may need to review some. For things like the trust conversation and the fear conversation, because that’s what he’s going to be doing, and probably with somebody who’s higher up in the organization than him, who might be a bit intimidating.
Squirrel: So, Andreas, you’re going to need a lot of a lot of tools here. We’d be very interested in hearing how it goes for you, but I think finding that person, presenting them a good option, which is better than struggling along and failing as the team is currently doing, is the best shot that Andreas has of getting somewhere. Knowing governments as I do, the government may prefer to struggle and fail over actually succeeding, and then you can’t do very much, but you can give the person who has the power, the best information you can, and give them a reality check that allows them to choose to do something that will work better.
One Bit of Hope
Listen to this section at 14:31
Jeffrey: That’s right. And there is one bit of hope, I will say, when I when I hear about this. And I listened and I agreed with everything you said about the stakeholder management, which is once you get through these difficult conversations, one of the key elements here that Andreas mentioned is that none of the current stakeholders are particularly satisfied with the way things are working.
Squirrel: Yes.
Jeffrey: They probably won’t be happy with the change. But it’s often been the case in organizations, and this is one of the things that helped the transition to agile software development in enterprises, in internal IT teams, is that when you get through the difficulty of making the change, if you start delivering things faster… In other words, you can go in and make small pieces that you’re delivering serially, and the stakeholders are seeing more things coming out because you’ve addressed these kind of frictional problems of trying to do everything at once, then actually people appreciate the improvement.
Jeffrey: So the good news is, if you can be successful in those stakeholder conversations, then there’s chance of then improving and building trust and people appreciating the changes. But getting to that part is always the difficult part. So I did want to offer that little bit of hope to Andreas. I feel like, as you say, we’re giving him some strong medicine of all the things he has to do. But there’s the hope for payoff on the other side, which is something that’s better for himself and the team. And then actually having the stakeholders be happier as well is a quite plausible outcome.
Squirrel: Absolutely. And, you know, it strikes me that Gene Kim’s most recent book and also his more well-known earlier ones, Phoenix Project and Unicorn Project, are all novels, they’re all on this topic of making a change in a larger organization and overcoming these kinds of barriers. So, have a look at that. And of course, our episodes just in the past few weeks where where you had a very interesting chat with Gene, that might be another source of inspiration for Andreas.
Jeffrey: Very true.
Squirrel: Well, Andreas, we’d love to hear from you more about how this works out for you. And we’d also like to hear from other listeners who are in a similar situation or equally feeling stuck. People who have successfully made this kind of change. Maybe you did it differently to how we suggested. We’d like to hear that. And if you think we’re just completely nuts and nothing like this would ever work, we’d like to hear that, too. We invite you to get in touch with us with any of those ideas and thoughts and challenges. You can do that best at agileconversations.com, where you’ll find our email and our X, and you’ll also find our book and lots of free videos and writing and all kinds of other good, free stuff that we have there at agileconversations.com for you. And of course, the other way to keep in touch with us is to come back again next Wednesday for another edition of Troubleshooting Agile. Thanks, Jeffrey.
Jeffrey: Thanks, Squirrel.