Related articles and podcasts:
- More about Jeff: https://jeffgothelf.com/
- Jeff’s article: Working Backwards: A New Version Of Amazon’s “Press Release” Approach To Plan Customer-Centric Projects
- Project Manager Or Project Leader? (With Rebecca Germond From FCV Interactive)
- Making Agile Work With Metagility (With David Bishop From Agile Worx)
- Learn The 4 Scrum Ceremonies For Agile Teams
- 3 Key Similarities Between Lean And Agile Methodologies
- Workflow Design: Learn From My Failed Attempt
To be honest. Do your projects ever truly deliver what you’d hoped they would? Could or should? Now, why is that? Is it because perhaps you didn’t plan? Well, because you didn’t manage your team well. Or perhaps because you struggled to manage and along your stakeholders. Maybe it’s all the above. Maybe it’s because you weren’t all fully aligned on the ultimate outcome and vision of the projects. So keep listening to today’s podcast. If you want to learn how you can work backward to go forward more confidently with good projects, reduce the risk of failure, and increase your chances of project success.
Thanks for tuning in. I’m Ben Aston, founder of the Digital Project Manager. Welcome to the DPM podcast. We are on a mission to help project managers succeed, to help people who manage projects delivered better. We’re here to help you take your project game to the next level.
Check out thedigitalprojectmanager.com to learn about our training and resources we offer through membership. This podcast is brought to you by Clarizen, the Leader in Enterprise Project and Portfolio Management Software. Visit Clarizen.com to learn more.
So today, I’m joined by Jeff Gothelf and Jeff teaches executives and teams through remote advising and coaching workshops, keynotes, and books to focus on the customers, to learn from mistakes in crane agile culture that continuously improves their products and services in the way that they work.
He’s the co-author of a bunch of books you’ve read, or at least probably heard of Sense and Respond. Lean UX being the big one there. Lean versus agile vs. design thinking. Recently he co-founded Sense and Respond Press, and that’s a publishing house for modern transformational business books. So, hey, Jeff, thanks so much for joining us today.
Hey, Ben, thanks for having me on the show.
And I want to start actually by talking about projects, and I know you’re very much a product orientated guy, but for us PMs managing projects, that might be part of a larger program of work or product roadmap.
And I’m curious how you think it is. As we as project leaders, we can help orientate ourselves and our teams to a more iterative approach. And I know that you’ve just written a post on the top 10 rebuttals to Agile is great, but it won’t work here. So I want to talk about some of the challenges that I think we face as digital project managers and why.
Fundamentally, I think clients that we work with, all stakeholders like the idea of working agile. I mean, and we can discuss with agile means, but whether or not we’re talking about delivery framework or more broadly, a more of a mindset. And I think let’s just talk about more of this mindset kind of approach to agile.
But I think one of the challenges that I need to talk about three challenges. Firstly, when I talk about client mistrust, then I want to talk about too tightly defined requirements. And thirdly, the kind of challenge, lack of budget and time. So clients wanting to be agile, but not really having the budget to do that all the time to do that.
Clients having to tightly defined requirements and also client mistrust. So clients not really trusting the agency or the team to fully kind of let go and just trust the process. So three challenges there. Which ones do you want to talk about first?
What’s… Let’s talk about the mindset shift first? Because I think that’s the critical thing, especially for digital project managers to really kind of grasp. I think if we’re going to be successful at building good teams, good products, good services, successful companies, successful customers, and users, it’s important to realize the fundamental difference in digital product development today.
The fundamental difference today versus 10 years ago, 15 years ago, and so forth, is that software today is continuous. We don’t go to the store and buy a box of software anymore. So, just we subscribe to it or we install it and then we download it, install it, and then it just updates continuously.
Right. It just keeps getting better. Right. You don’t go to that. You don’t go to a store and buy the next version of Facebook. You don’t go to the store, buy the next version of Pinterest or Amazon or anything like that. It just continuously gets better over time or improves and changes over time. That’s the and that’s the fundamental difference between project thinking and product thinking, right? Projects and products don’t.
And today we’re really building these systems, these continuous systems that we have a choice every cycle. You call it a sprint. You can call it an iteration, whatever you like. But we have a choice about how to make that system better. Do we add stuff to it? Do we optimize the stuff it already has? Do we take stuff out of it? Right.
There are all kinds of things that can be done to it, but that’s roughly the three categories. And that’s the key thing to take away because these things don’t end this idea. Well, I manage the project to a successful launch. That’s cool. But a launch is simply the beginning of the conversation with your target audience. It’s not the end of the product.
Definitely, yeah. So one of the things that I think that we as digital project managers face when we are trying to talk to clients about engaging in a more agile, well engagement, a more agile way of working, where we say to them, hey, just pay us for a dedicated team for a period of time and let’s collaborate together. Let’s say we’ve launched your… We’ve launched your website. And now let’s iterate on it.
Let’s, you know, like you’re talking about software and continuously updating. Maybe their website is doing the same thing. But it relies on this trust, right. That the person paying for it is gonna get good value out the other end of the process. So how do you think we as project managers, as people trying to guide our clients through this process? How do you think we can guide them through that mistrust where this you know, they would prefer probably to say, hey, well,
I want to give you one hundred thousand dollars, but I want you to confirm absolutely. That I’m gonna get all my stuff that I want at the other side of this process. But I want you to be agile. And they’ve got this list of requirements. And you’re saying, well, you know, we can’t tell you exactly what you’re going to get because we’re doing this process where we let’s identify what’s going to generate the most value. Let’s prioritize those things.
And let’s work through them sequentially. Let’s get things shipped. Let’s get things done. Let’s build. Let’s test. Let’s learn. That iterates. But that requires a certain level of trust. So how do you what are your kind of tips first for bridging that gap of trust when the deliverables are unknown?
Yeah. So there’s a lot to unpack here. And so let’s start with the fundamental foundational piece here. The foundational piece here is what business are you in? Right. You really have to ask that question as you think about it, from a client-vendor or a service provider’s point of view.
Are you in the business of partnering with your clients to help them achieve outcomes, or are you in the business of delivering a strict set of requirements? Because like you said, there’s a fundamental mismatch between here are the requirements, but please be agile with them. Right.
That doesn’t make sense. That statement doesn’t make sense. There’s a spectrum that I learned from my friend and colleague Jeff Patton that really helps clarify the thinking around that question. It’s a spectrum on one end of the spectrum. You’ve got the word doctor. And on the other side of the spectrum, you’ve got the word waiter.
And I would challenge you as a service delivery organization to think about where you sit on that spectrum. If you sit on the waiter side of that spectrum, then your job is to bring me exactly what I asked for.
And whether you eat it or you don’t eat it or you like it or you don’t like it. That’s not my problem. You asked for steak with salad and a Coke. That’s what I brought you. Right. And that’s and that’s there are tons of organizations that’ll do that, right. Give me 100 grand. I’ll build you the ark right at the other end as a doctor.
A doctor. You don’t tell. You don’t come into the doctor and say, listen, I’d like this medicine, this vaccine, and this treatment. And the doctor says, OK, I’ll give it to you. The doctor works as a consultant to help you improve, ultimately to improve your KPIs, to improve your metrics. Right.
And so the question is, where do you sit on that spectrum? It is significantly easier to be agile on the doctor’s end of that spectrum than it is on the waiter end of that spectrum because the measures of success are fundamentally different at either end of that spectrum. On the waiter side of that spectrum.
The measure of success is output. Did you deliver the thing that I asked for on-time and on a budget? Right. Yes. And I brought you the steak, the salad, and the coke in 15 minutes. And it’s priced at what you expected to be priced, correct? That’s a measure of success. There’s no agility in that whatsoever. At the other end is outcomes. It’s changed in behavior. Of your customers’ changes in the measures of those behaviors.
Right. So, hey, did we get customers to buy more, to spend more, to spend more time to tell their friends to buy more than one product from us? That type of thing. Right. That’s where agile shines when there’s a significant amount of uncertainty and there’s not a clear sense of exactly what will achieve the business result that we’re looking for.
And that’s when operating as a doctor is far more valuable and so agile. And more importantly, agility cannot come into play in the conversation unless you start moving what you deliver and how you deliver it away from the waiter side of the spectrum and towards the doctor’s side.
And so, I mean, it comes down to me making that transition from a client or stakeholder, seeing themselves as. You know, it comes down to control and trust. So when you’re coaching organizations, how do you encourage people to look beyond or have an appetite for the unknown and beyond? You know, the requirements that, you know, there’s a business driver for a project or a product iteration generally.
And often we can jump to one of the low hanging fruit. And that becomes the project or the next thing in the iteration. But, how do you help people understand, like, the value of a more agile mindset and how to help them have an appetite for more of that. Consultant doctor approach rather than a waiter.
So the way to do it is to find a respectful and non-engagement limiting way to ask the question of why. So when I come to you and I say, listen, I need these ten features, I need them by Friday, how much will it be? You need to be able to respectfully ask the question, why do you want those features?
And the way that you do that is you work with your clients to transform these fixed requirements into a problem statement. The problem statement that the organization is trying to solve or that the team is trying to solve. So when the team says, hey, listen, I need the mobile app.
By Friday, how much will that be? And you say, wait a minute, why do you need the mobile app? And I say, well, we need the mobile app because, you know, our mobile commerce numbers are down and we need to increase mobile commerce. OK. So the problem we’re trying to solve is we’re trying to get more people to buy through the mobile channel. How much more? Fifteen percent increase would be significant. OK, great.
See what we did there. We transformed. Build a mobile app to increase mobile commerce by 15 percent. And what you’ve fundamentally done there is you’ve removed the specific requirement from that conversation, which now explicitly forces the team to be agile in testing, experimenting, learning, iterating, and improving their solution.
To a point where it increases mobile commerce by 15 percent. Right. That’s the measure of success, not deploying the app. There is tremendous risk in assuming that your feature set is going to achieve the outcomes that you believe that it will most of the time you’re going to be wrong no matter how good you are at this.
In fact, in fact, if you talk to kind of some of the products, people who’ve been around a long time and they’ll tell you that a good product manager, the good product manager will be right 30 percent of the time. That’s a good product manager.
And that holds true for stakeholders, you know, clients, whoever, whatever you want to call it. And so if you’re going to be wrong 70 percent of the time, wouldn’t you rather use a process that allows you to discover the most accurate way to achieve your goals as quickly as possible rather than to blindly say, ship me an app by Thursday, make it blue and have it, do these five things?
Right. That’s the fundamental difference here.
Yeah. No, I think I think that’s very wise. And you’re thinking about reframing the ask from our client into those problem statements and digging into the why I think is really valuable in changing that conversation from that list of requirements to something that gives us a scope to explore the problem and identify solutions that we can build.
Then we can test them. We can learn and allows us then to iterate, and that can help us deal with those tightly defined requirements, which was that second issue I talked about. And I just want to touch on this third challenge. And again, in your post, Agile, it’s great, but it won’t work here. Do you think a lack of budget and time could be a reason why agile won’t work here?
To me. To me, there’s a fundamental misunderstanding of what agile processes bring to the game. Right. This is not a matter of budget on time. It’s a matter of risk mitigation. Right. It’s a matter of saying, listen, instead of working for it for the next three months on somebody’s idea of what success looks like. Let’s start to learn whether or not we’re heading down the right path as quickly as possible.
And if we’re not, let’s adjust the course. That’s it. That’s the whole thing. Like, if it basically if the team is adjusting the course based on evidence from the marketplace, then that team is being agile. And that’s got nothing to do with a budget, with time, because, look, the alternative is what it’s going to cost. Seventy-five thousand dollars to build the app in the next month. OK, great.
Now, is that a good estimate? Is that a bad estimate? Who knows? Right. You’re going to build the best thing that you can in that timeframe. And then the budget is gone. And what if it doesn’t work? Right. That’s true. That’s the risk that you’re taking by in a digital product with a waterfall approach, with this predictive top-down, prescriptive, sorry, prescriptive, top-down waterfall approach.
You’re just saying I know what it needs to be. I know what it needs to look like. I know what it needs to do. And I need it by this date. Is it is a tremendously risky point of view? And like I said, a good stakeholder client product manager is going to get that part of it. Right. One out of every three times.
Yeah. But then it does that does depend on who’s who. Who’s making the ask. Right. So back to your example of the steak salad and coke for, you know, in 15 minutes. I can’t remember how much you said it. But, you know, let’s say 30 dollars. I’ve got thirty dollars. I want steak, coke, and salad.
Even if that’s not what’s best for me. That’s what I want. Because that’s what I want. And it might not be the right thing, but I’m just looking for someone to give me a steak salad and coke, please.
Yes. And in that situation, you go to a waiter, right? If you go to your doctor and your doctor measures your KPIs. Right. Your body mass index year weight, your blood pressure, your cholesterol. And you say, listen, I want to steaks out and cook. That just doesn’t say nope. Right. That’s is not going to give you that because their job isn’t to give you a steak salad and a Coke. Their job is to make you healthier.
That’s the outcome that they’re seeking. A waiter does not care about your health. A waiter will give you what you ask for because that’s their job and that’s the business that they’re in. And that’s what I think most service providers fail to grasp with Agile is that this is not one process versus another. This is one business model versus another. And that’s very difficult for traditional service providers to grasp and then ultimately to convert to.
Yeah, well, and it requires maturity from the person who they’re doing the work to accommodate that, right?
So, I mean this it really is about, I think, a maturity that’s required. And for those of us who are working in agencies and working with clients who say they just want a steak, a salad, and a Coke and give it to us, please, by next Thursday and then I’ll be happy. That is a big challenge for us.
I think it’s in reframing, reframing to ask and putting on that doctor hat, and getting rid of our waiter outfits. I think that’s a good challenge there. And just written a great post about customer centricity and planning customer-centric projects with an updated version of the future press release technique, which borrows from Amazon’s working backward process and focuses, as we’ve been talking about, heavily on outcomes.
It’s about risk management. It’s about collaboration. And I’m not gonna spoil the story shed in the post. But you can check out on thedigitaprojectmanager.com. But I’m curious, in your experience, does this how does this approach help? Because I think there are lots of techniques that we can use and it feels like a fun activity. But in your experience of actually using it on the ground what’s happened in terms of the process that you go through to write this future press release and how is that helps.
So the first and foremost, it really starts to imagine a future where you’ve been successful and it forces you to think through what made you successful in the first place. Now, the variation that’s in the article on the site really injects the customer into the center of this thing, not just, hey, we shipped this amazing new system and everybody loved it and we made a ton of money.
It’s along the lines of what we shipped it. And this is the behavior change that we’ve seen. But these are the outcomes that we’ve seen. And to get there, not only did we actually have to consider success in terms of customer behavior, but we had to really think through how we were going to provide that value to that customer across the organization.
What was the collaboration challenges that we had to put together? And then ultimately, how did that help the business? Right. And the key thing is that this forces the team if you’re doing a pre premortem, this is some variation of the premortem that says when we finally launch this thing and it’s successful in the marketplace, how will we know that it was successful? And what do we believe we would have had to overcome to get there?
And it’s a conversation that rarely happens right at the beginning of an initiative. Typically, you say, okay, I need you to build this thing and go build it. And success is you ship it on time and within my budget. In this particular case, what we’re trying to say is success is building the kind of process that allows us to positively impact our customers in a way that makes them more successful. That made them more successful and now makes the business more successful as well.
And if you can have that conversation at the outset of the initiative, that it forces you to then think through the work that you do during the initiative, you can kind of use that future press release as a filter to say, is this something that will help us achieve this goal? And if it’s not or is it something to help us live up to these values or these ideals that we’ve articulated in the document? And if it’s not, hey, we’re not going to do that, we can do something else. And that’s very powerful.
So this is kind of for those of you who haven’t read the posts, which we’re trying to imagine, the future, the future state, and kind of look into our crystal balls. And I think this is in some ways, we’re kind of looking at product-market fit. We’re looking at desirability. Do people actually.
Is this going too well into the desirability? Is there a large market of people who really need this problem solved? Is it viable? Is there is this a this is business model going to work? Is it feasible? Can we actually do this? So it’s into the product-market fit. It’s a good risk lens, I guess, to use in terms of thinking about is it going to do these? Is it gonna do these things? And we’re kind of using empathy to look forward and think, okay.
Is it going to? Is it going to take the boxes for us? But I think the thing that I’m curious where we’re kind of using our imagination to do this. Right. There’s no way truly validating this or is there how often you’ve written your future press releases, how do you validate that? Because we can. I mean, you were just talking about how as a product manager, we’re only. Right. 30 percent of the time. So what about that 70 percent? And how does that I guess? Well, you know, the fog of war play into. How accurate or useful this is as a tool?
So, look, this provides us with a goal. It’s aspirational. It’s the goal that we’re shooting for as a team. Right. You’re trying to predict the future, so you’re going to be wrong about parts of it. But overall, you’re trying to predict what success looks like, what your obstacles were, and how you overcame them. And you’re trying to tell a compelling story about that.
Now, you have to live up to that story as you work your way through the initiative, through the work. There are going to be elements of that that inevitably, inevitably aren’t going to come true. And that’s OK as long as you can very clearly and objectively say this is why these are this part of the story isn’t going to come true and the sad story is going to change. But this is our goal. We hold this up as our goal, we hold this up as our aspiration for how the team is going to work and what success they’re going to achieve.
And we filter our decisions through that until we get the evidence back from the market that says, look, every time that we’ve filtered our decision through this bit of the criteria, what’s come back has been a suboptimal result. So we’re going to change that now.
We’re going to move focus. We learned that this part of our aspirational goal is no longer valid or no longer valuable. And so we’re going to adjust that and move forward. But it starts off as the goal and the aspiration. And it’s the reason why you can’t adjust to moving forward. You’re not moving the goalposts. You’re adjusting the goal based on reality, which you didn’t have at the beginning of the project.
Yeah. OK. And in terms of thinking about moving, moving the goalposts, or shifting the goalpost to align, better do find in terms of using this approach. Is there anything that doesn’t work well with it? Can it? In what ways can this actually stymie the team or their creativity or view kind of identified any problems or challenges with using it?
I know you talk about how this is an iteration of Amazon’s kind of approach or technique. So do you want to kind of explain why you’ve iterated on it and the potential challenges of that?
Yeah, it looks so. The biggest challenge I see with teams about this is about this technique is they’re actually not creative enough. They’re not aspirational enough. They make this a very, very safe document. So, you know, there’s a term for this in American English. It’s called sandbagging. Right.
Where you. Right, you said that you set the goal that you know you’re going to hit. Yeah. And to me, that’s the biggest risk in this, is that you don’t anticipate the big problems. You don’t set your success criteria. It’s aspirational to high enough aspirational level. So that’s the biggest challenge that I’ve seen with this. The iteration that I’ve made it. Look, Amazon as use this with great success.
There’s lots of articles talking about it. The iteration that I’ve made here are two-fold. The first is that the original template lacked a focus on outcomes, outcomes, or the measurable changes in customer behavior that tell us we’ve delivered something of value. That’s what we want our customers to be doing when we ship the thing that we are building.
The original press release template didn’t speak about outcomes. It talked about business benefits. We made money, right? We didn’t lose customers. But why? What is the customer behavior that we actually want to see? If this is successful, that leads to making money and retention and that type of thing.
And then the other thing that I think it lacks in this is particularly important for a larger organization is that the template lacked a discussion of collaboration challenges, nothing ships to market. Just put the product team working on it. Right. It’s got to go through legal. It’s gotta go to finance.
It’s got to go through marketing. It’s got to go through, you know, OPS. It’s got to go through compliance. All these different departments. Right. How are we going to collaborate across the organization to make sure that we can still deliver the kind of experience that we’re targeting and involve all of these different folks and departments in that particular process?
That is key to a successful launch, particularly in any organization bigger than, say, I don’t know, 50 people, 40 people. Right. And so that was lacking from that as well. And I want teams to think about that because you’re not an island, you’re not going to ship this on your own.
And so you need to start to involve those folks significantly sooner than you normally would if you want to hit the aspirational target. And that’s what I hope comes out of it.
And I think this is super powerful. We’re thinking about not just the outcomes, but thinking through the process as well. Because I think so often we can actually identify quite good goals. Quite good success metrics. We can envisage the outcome that we’re looking for.
But in terms of the process that needs to happen to make that a reality, I think we can often that’s often where things fall down around the communication. It’s around the collaboration. So check out Jeff’s post on working backward to go forwards. And I’m sure going to take away some really useful nuggets there.
But I want to switch gears and dove a bit into the process, which I know you’re passionate about. You’ve worked in consulting, startups, and agencies and now you’re working for yourself, which has given you lots of exposure, I’m sure, to things working well and probably not so well.
And I’m wondering how you’ve seen and do you see the process, the methods that we use to deliver things evolving? Because obviously we have the agile process evolution, whilst fundamentally is the same. We have things like lean, agile, design thinking, service design and we see these things evolving, different techniques, you know, having different labels.
How do you see process evolving and agile maturing and these different techniques and frameworks for ideation and for delivery, evolving and changing and what do you see as the future for that?
I think. Inevitably, at some point Agile, the lower, lower case, “a” agile agility will become the default in organizations kind of across the world. And I’ll be honest with you, the pandemic that we’re living through is going to speed that up. The organizations that are already agile, that are on their way, that are increasing their ability to sense and respond, are going to survive this.
And the organizations that can’t do that or aren’t able or it’s just not in their DNA, they are going to inevitably suffer from this and potentially be killed by it. Which is the reality, I think that agility has to become the norm moving forward because the pace of change and the volatility of the markets and of the world is only increasing. And so if you function as a monolith. Then you are going to sink like a monolith.
But if you can function as a series of as a set of semi-autonomous teams that sense and respond and learn and share that knowledge and adjust course based on that evidence and inform everybody, then your ability to adjust course when things like, you know, like these major crises strike will allow you to survive.
Do I think that in 20 years we’re gonna sit here and talk about sprints and velocity and burned down charts and backlogs? Maybe, maybe not. The language may change. The brand names for the processes may change, but I can’t imagine a successful world, a successful, you know, economic reality, where customer centricity, continuous learning, continuous improvement aren’t the de facto ways of managing an organization.
And those are the core philosophies that underlie agile and more, more specifically, agility. And so that’s where I see the future going. And I suspect that you’re going to see it. It’s going to be accelerated even more significantly given the crisis that we’re currently living through.
Yeah. And going back to those kinds of frameworks and the naming of them. So obviously you’re passionate about Lean. You’ve written about that a lot. And since then, you know, there’s been very specific techniques taught around design thinking, around service design, where, you know, some of these can actually be quite prescriptive in terms of the techniques that we use.
And we have different people waving the flags for different delivery frameworks. I’m curious as to, you know, you as a practitioner in the field, do we need them all? And what’s your opinion on how well they work together? We have. I mean, different types of projects. Is it hard to make a blanket statement on this, but why? I’m wondering what’s philosophically what’s your take on, you know, agile development vs. design thinking?
Yes. So I wrote a very short book called Lean versus Agile versus Design Thinking. The core thesis in that book is that these are different brand names that sit on top. Very similar philosophies so that the names are different. The activities are called something else. You know, the cadences might be a little different philosophically.
These are all the same things. And so if you can reconcile that inside your organization, then at some point you have to pick one or mash them all together and put together something that works for you as a company. But at the end of the day, your goal is not to implement a recipe blindly. Your goal is to increase the agility of your organization. And so ultimately, the REST the recipe that you choose doesn’t really matter.
Right. Your goal, your goal is to learn how to become a chef. Right. So another metaphor. Right. And in a food-related one at that. Right. So if you think about cooking. Right. If you if you’re a beginner if you’ve never cooked before. What are you gonna do? You’re gonna go get a cookbook.
You’re gonna download a recipe off the Internet, and you’re gonna follow the instructions, word for word. Right. And that’s the first thing that I would expect most organizations, most teams to do. Let me get one of these recipes. Give me lean. Give me a scrum. Give me design thinking. Like, give me whatever XP. Right.
Let me execute that right after a while doing that. You get pretty good at following the recipe. You start to embellish that recipe. Right. You start to add a few things that weren’t in the original recipe, but they make the dish tastier. Or in this particular case, they make your team slightly more successful.
That’s pretty good, right? Now you’re evolving the recipe and you’re getting to something that actually works for you. Eventually, you become a professional chef, right? Professional chefs don’t use recipes. They throw all that stuff away and they inherently know how to operate in any kind of cooking environment.
To me, that’s the ultimate level of maturity in a team or an organization, is that when they inherently know how to be agile in any environment using a variety of different tools and methodologies. Right. But it doesn’t really matter to them. Right. What the recipe is, but they understand the goal that they’re trying to achieve and they know how to use the tools to get there. So that’s ultimately the goal.
What I think that organizations that marry themselves to a specific recipe set to set themselves up for failure because again, they are saying, look, we just want you to follow the steps blindly here and once you follow the steps that success and it’s not a success. It might be the first step in a journey. The journey is agility, not the implementation of the recipe. As destination as agility.
Yeah, definitely. And I think that’s why I think this is why when people say things like, hey, but this isn’t how you’re supposed to do it, it calls for concern because the whole idea is that the process itself can be iterated on and it’s not about following the process. And I think when we start having a discussion around, you know, do we have to do it exactly like this or can we kind of bend the rules a bit?
Because actually that’s much more going to be much more effective in delivering what we need to deliver. That’s going to help us reach the outcome we’re trying to achieve. That’s what we should be. That’s what we should be asking, not looking back at the textbook and saying, hey, but here it says that you know, it should be on a Wednesday, not on a Thursday. So that’s what to do. So I think it’s blindly, blindly the following process, I think can be can be a real challenge.
Now, I know that you’ve written the book Sense and Respond that’s talking about organization, listening to customers, creating new products. It’s kind of being a theme of some of the things we’re been talking about today. And you talk about techniques. Are there any techniques that we haven’t talked about so far that you think are successful organizations adopting as they enter this, particularly in this COVID world? What do you see? What do you see as some of the techniques that are going to be impactful for organizations as they move forward?
To me, the piece that organizations leave, that leave to the last thing that they change, and it’s by far one of the most critical pieces of this whole puzzle is incentive structure and performance management criteria. This is where the rubber hits the road, as they say, because we can apply all the recipes and all the methodologies and all the philosophies.
But at the end of the day, I get paid to ship a feature as opposed to achieving an outcome. I’m going to ship that feature. And whether it’s agile or lean or design, thinking, or waterfall, none of that is going to matter because you’re paying me to ship that feature. And that’s the key here.
The key here is how do we measure success of our folks, right. How do we change what we measure to encourage the kind of behavior that we’d like to see, the kind of curiosity, the kind of learning, that kind of improvement that ultimately makes for successful products and services? How do we incentivize that? And if we don’t currently incentivize that, it’s not going to happen.
And if it doesn’t happen, all of that agility goes right out the window. And that’s the key thing that organizations that get it do. It’s hard work. It’s really hard work. And it’s risky. But it’s worth the risk because, at the end of the day, you have better products and services, happier customers, and more successful employees.
So are you talking about okay, out here specifically or are you talking more broadly about talking about?
I’m talking about linking your incentives to the OKRs. Rest of the OKRs, we become them the measure of success for the team and part of their performance review. And part of their incentives. Hey, did you or are you hitting your OKRs? If you are, here is how we are getting paid for that.
Yeah. Yeah, and I saw recently that I thought this is super helpful, instead of job descriptions using job scorecards, which can be a useful way of measuring kind of right down to the individual and incenting them to understand those key metrics that are going to actually create the change.
If those metrics are correct, obviously going to help people understand the change that you’re trying to engage them in. And I think so often actually deciding on those metrics can be super challenging. And I know like myself, sometimes I find that I, I create an OKR or I create a metric and then realize once that metrics have been kind of achieved or delivered, that actually that’s the wrong metric.
And because it creates a work or energy in a way to deliver something that actually you realize once it’s been delivered or that’s actually that’s not quite the right thing. But I think this focus on results and focus on delivering outcomes through this kind of laser focus on results, is this super helpful? I want to finish by just talking about your scrum course and we’ve talked about different frameworks here.
Scrum obviously being an agile framework. And the course that you’ve kind of developed with them is a UX. With scrum course, and answers, how do you how do we do design UX from research within the Scrum framework? And I think this is something about people who work within agencies are challenged by because it seems very prescriptive for development. And that seems to work really well.
But once we start adding in the UX research design component, things get a bit complicated because I’ll be always working in the same two-week sprint. Are we a sprint or two ahead for people who are faced with this challenge? They think scrum is the agile delivery framework that is going to be good for them, but they’re trying to work out how to drop in that the front part, the strategic UX design research component.
How does? Can you explain the high-level? How do you see these things working together? Because I think this is probably one of the biggest challenges of people in agencies trying to implement Scrum.
Yeah. And so this is the challenge that the course sets out to solve the professional scrum with UX course or PSU, as it’s known for short, is designed to solve that challenge. And we take a very pragmatic and very real look at what scrum is today and how Scrum needs to be adjusted to support these practices that frankly weren’t considered when Scrum was invented and now we have to have them to build great products.
So how do we actually do that? And we focus on what goes in the backlog. How do we write stories? Who does this work? What happens when this work is being done? And what’s what else should be going on? How much of our sprint should be learning work versus delivery work? Right. All of these questions are tackled in that course. And the short of it is, is it’s down to cross-functional collaboration.
So designer or, you know, has to be on the team as a full-time member that the discovery work is equally as important as the delivery work. But there’s an ebb and flow between discovering delivery, and that’s sometimes that work gets done. The discovery work of design work, the research work gets done by non-designers. And that has to be OK with everybody on the team as well. And that’s a very, very high-level summary of the course, but definitely worth looking at.
Cool. And one thing I’m curious about, obviously, my beef typically with Scrum is that it is so prescriptive. And I know we’ve talked about today, you know, this is just a framework. So just a starting point. And they should evolve. But I find the scrum.
Yeah. I guess the scrum approach and the way that it’s kind of testing in terms of how well, you know, the approach very I mean, it’s very prescriptive. So within. I’m curious as to kind of your whole appetite for kind of getting involved in a framework and a prescriptive framework and how that kind of sat with you tried to trying to work through.
Hey, we’re being prescriptive here in terms of this is what you do because people want to know the answers. Yeah. On the other hand, knowing the reality of, hey, this is going to need to be tailored to whatever organization. How did you achieve it? Kind of designing a process work through that tension yourself?
Yeah. Look, the nice thing about doing this scrum.org is that they were willing to adjust their position. The nonstarter for us and having these conversations with other organizations in the past was, well, this is scrums. It’s not budging. So whatever you’re doing, change it to make it work.
So the nice thing about that is that they were willing to adjust what they were doing as well. And that’s a that’s already a win and a step in the right direction. Secondarily, this is a recipe. I’ll be very, very blunt about it. This is a recipe. And if you don’t know how to solve this from right now, start with this recipe.
Eventually, you’ll adjust it to meet your needs and to meet your unique circumstances and your organization or on your team. But start with this. And so in the end, then get better at this and, you know, augment the recipe as necessary. But this is a great place to start that’s worked for us.
Yeah, I think that’s super helpful and I think for anyone who’s thinking about implementing a more agile approach, understanding that some of these frameworks that describe a process are a recipe, and they don’t mean that you prescriptively have to follow them to the letter and that there is a license to be flexible there to achieve the outcomes that you’re looking for not necessarily.
You’re not being graded by how well you follow the framework. You’ll be graded by how well you achieve those desired outcomes. And I think that has been a kind of the theme of today’s discussion. So thank you so much, Jeff, for joining us today.
My pleasure, Ben. It’s been a blast. Thanks for having me on the show.
Cool. Well, I wonder what you think. What are your hacks tips and tricks for delivering well? How do you deliver success? Have you tried the press release technique? Let us know in the comments. Tell us your failed stories. Tell us your wins. Let us know.
And if you want to learn more and get ahead in your work, come and join our tribe with DPM Membership head to thedigitalprojectmanager.com/membership to get access to our Slack team, templates, workshops, AMA Sessions, office hours, e-books, and more. And if you like what you heard today, please subscribe and stay in touch on thedigitalprojectmanager.com. But until next time. Thanks for listening.