Easy Agile Podcast Ep.12 Observations on Observability

TL;DR

Jeff Gothelf, renowned author of "Lean UX" and "Who Does What By How Much," discusses the evolution from output-based work to outcome-focused goal setting with OKRs. Key insights: Teams need to shift from "we're building a thing" to defining success as "who does what by how much" – meaningful changes in human behaviour that drive business results; the biggest barrier to agile ways of working is that people get paid to ship features, not deliver value; leaders should change their questions from "what are you building?" to "what are you learning?"; psychological safety is critical – teams need to feel safe admitting when something isn't working; start small by simply asking "what will people be doing differently when we ship this?"; rename teams around outcomes (mobile revenue team) rather than outputs (iPhone app team); proactive transparency through weekly three-bullet-point updates builds trust with leadership. Bottom line: OKRs, when done right, are the "Trojan horse" that enables all other agile practices to succeed.

Introduction

For years, agile practitioners have championed better ways of working – Lean UX, design thinking, continuous discovery, customer centricity. Yet despite widespread adoption of these practices, many teams still struggle with the same fundamental problem: they're rewarded for shipping features, not delivering value.

In this episode, our CEO Mat Lawrence sits down with Jeff Gothelf to explore how this misalignment of incentives undermines even the best agile practices, and why customer-centric OKRs might be the missing piece that makes everything else click into place.

Jeff Gothelf is a renowned author, speaker, and consultant whose work has shaped how product teams approach collaboration and customer-centricity. Along with co-author Josh Seiden, Jeff wrote "Lean UX," which revolutionised how designers work in agile environments. Their follow-up book, "Sense and Respond," helped leaders understand how to manage in software-based businesses. Their latest book, "Who Does What By How Much," tackles the thorniest problem yet: how to align incentives and goals with customer outcomes.

This conversation traces Jeff's journey from helping designers work better in agile teams, to helping leaders create the conditions for success, to finally addressing the root cause – the goals and incentives that determine what gets celebrated, rewarded, and promoted in organisations. It's a masterclass in shifting from output thinking to outcome thinking, with practical advice for both team members and leaders navigating this transformation.

About Our Guest

Jeff Gothelf is an author, speaker, and organisational consultant who has spent over 15 years helping companies build better products through collaboration, learning, and customer-centricity. His work focuses on the intersection of agile software development, user experience design, and modern management practices.

Jeff is best known as the co-author (with Josh Seiden) of three influential books that have shaped modern product development practices. "Lean UX" (now in its third edition) began as a guide for designers working in agile environments but has evolved into a comprehensive framework for cross-functional collaboration and risk mitigation in product development. The book's core principle – moving from deliverables to outcomes – has influenced how thousands of teams approach their work.

Following "Lean UX," Jeff and Josh wrote "Sense and Respond," a book aimed at leaders and aspiring leaders. It makes the case that the overwhelming majority of businesses today are software businesses, and that managing software-based businesses requires fundamentally different approaches to team structure, management, and leadership. The book provides a roadmap for creating organisations where teams can actually practise the collaborative, customer-centric approaches described in "Lean UX."

Jeff's latest book, "Who Does What By How Much," represents the natural evolution of this work. After years of helping teams work better and leaders manage differently, Jeff and Josh identified that the real barrier to change was incentives and goals. Teams kept saying, "That's great, Jeff, but I get paid to ship features." This book tackles that problem head-on, showing how to use objectives and key results (OKRs) to create customer-centric goals that align with – rather than undermine – modern ways of working.

Beyond his books, Jeff has also authored "Forever Employable" and "Lean vs Agile vs Design Thinking," and he regularly speaks at conferences and consults with organisations on product strategy, team effectiveness, and organisational transformation. His approach is characteristically practical and rooted in real-world experience, making complex concepts accessible through clear frameworks and relatable examples.

Jeff's work continues to evolve as he helps organisations navigate the challenges of building products that customers actually want and need, whilst creating work environments where teams can thrive.

Transcript

Transcript

Note: This transcript has been lightly edited for clarity and readability.

Why Write Another Book? The Journey from Lean UX to OKRs

Mat Lawrence: Well, Jeff, welcome. I'm Mat Lawrence for our audience. I'm COO at Easy Agile, and today I'm talking with Jeff Gothelf, who is the renowned author, speaker, and consultant. You've written a good few books, Jeff. I've been looking through the list – Lean versus Agile versus Design Thinking, Forever Employable, and co-authored a few. The latest one being "Who Does What By How Much," and I was just telling Jeff in the intro here how you've managed to get across a lot of the things that I care about when trying to build teams and get them to understand OKRs. I've already given it to a few people and I'm definitely going to be giving it around. So, Jeff, welcome.

Jeff Gothelf: Thank you so much, Mat. That's very kind of you on all of that stuff. I appreciate it. Thanks for having me.

Mat: I'd love to cover a little bit around the book and the concept you're trying to get across. So I suppose the first question I have is what problem are you hoping to solve with the book? Why did you write it?

Jeff: It's really interesting. I wrote a blog post about this a while back because somebody challenged me on LinkedIn – and I appreciate a good challenge. They said, "How can you write about all this stuff? There's no way you know enough about each one of these topics to write a book. You're spreading yourself way too thin."

I thought that was a really interesting challenge. No one had ever asked that question, and it got me thinking. The answer that I came up with is that this book, "Who Does What By How Much," and it's a conversation about customer-centric objectives and key results, is the natural evolution of the work that Josh Seiden and I have been doing together for more than 15 years.

"We started with Lean UX, and Lean UX was a solution for designers helping them work more effectively in agile software development environments. The response to that book was, 'That's great, Jeff and Josh. We'd love to work this way. My company won't let me work this way.'"

So we wrote "Sense and Respond," which was a book for leaders and aspiring leaders to inspire them to manage differently, to recognise that the overwhelming majority of businesses today are software businesses, and that managing software-based businesses is different.

As we began to work with that material and talk about that, we kept bumping up against the same ceiling, and that ceiling was incentives and goals. No matter how hard we tried to convince people to be customer-centric, to learn continuously, to improve continuously, to work in short cycles, they said, "That's great, Jeff. But I get paid to ship features."

The goal, the measure of success, was shipped – preferably on time and on budget. That's what got celebrated and rewarded, incentivised and promoted. It was in the job descriptions and all that stuff. So it felt like we were really fighting a losing battle.

Objectives and key results has been gaining momentum for the last decade or so. To us, that felt like the perfect Trojan horse – and I know Trojan horse has a negative connotation, but I don't think of it in this case as a negative thing. It was the perfect way to have a conversation about goals in a customer-centric fashion that, if applied in the way that we describe in the book, would enable everything else that we've done to happen more easily.

"What Will People Be Doing Differently?" – The Question That Changes Everything

Mat: I love the evolution of it, Jeff. I've been working in tech now for about 15 years. Prior to that, I used to work in the arts and special effects, which in itself is a very agile industry where you're constantly building prototypes and figuring out what things need to do before they go on stage or be filmed.

When I entered into the tech world as an inexperienced founder and product developer, I was designing to solve problems, and I found the teams I was working with responded really well to that. "What are we trying to do? What are we trying to get here?" They used to give me feedback all the time on whether I was helping them see far enough ahead with the value we're actually trying to deliver.

When I joined Atlassian in 2014, when we were introducing OKRs there, I think we were facing a problem that you described really well in the book, which is around people focusing on shipping their to-do list. They have a backlog that is predefined, full of great ideas, and they really want to get it out the door. Trying to change that conversation to be around "how do we know if this is any good?" – the answer was we just don't know.

I'd love to touch on how have you guided teams to move from that more traditional output-based metrics and shipping into that outcome approach? Maybe you could give an example of where that shift has led to some significant success.

Jeff: Sure. The title of the book is "Who Does What By How Much?" Overwhelmingly, the teams that we've worked on and with over the years have focused on delivering output, making stuff. The question that we tried to get them to understand is: if you do a great job – let's say when – when you do a great job with this feature, how will you know? What will people be doing differently?

That's the question that starts the mindset shift from outputs to outcomes. Outcomes, the way that we describe them, is a meaningful change in human behaviour that drives business results. The human that we're talking about is the human that consumes the thing that you create.

"The question is how will you know you delivered value to that human? Traditionally, it's been like, 'Well, we made the thing for them. There it is.' We made the Sharpie. Terrific. Did anybody need a Sharpie? Anybody looking for a Sharpie? How do we know? What are people doing now that the Sharpie is out there?"

The mindset shift starts with that question. Even in an organisation that just doesn't get this yet, it's a really safe question. I think it's a safe question to say, "Okay, we're gonna build the thing. What do we expect people to be doing differently once we ship this thing?" And when I say people, let's get specific about who. Which people? Who?

This is the evolution of the book title and how we teach this stuff. So what would people be doing differently before we start? Which people? Who? Okay, it's accountants in large accounting firms. Great. When we ship this new system to them, what are they gonna be doing differently than they're doing today? Well, they'll be entering their data more successfully and finishing their work in half the time.

Terrific. What are they doing? Who does what? And how much of that do we need to see to tell us that this was actually valuable? Well, today they're seeing at least a 30% error rate in data entry. Okay, great. What's meaningful? What's a meaningful improvement? If we cut that in half, that's a meaningful improvement. By how much?

All of a sudden, we've constructed the success criteria that has moved the team away from "we're building a thing" to "accountants in large accounting firms reduce their data entry errors by 50%." Who does what by how much. That begins the mindset shift in that conversation in a safe way because we're not saying let's set new goals, let's rewrite our incentives. We're just saying, "Look, I'm just asking a question."

Then once we start to build stuff, and especially once we start to ship stuff, you remember that conversation we had three months ago? We talked about who does what by how much. Is it happening? Do we know? Can we find out? And if it isn't, let's figure it out.

The Non-Profit That Changed Their Approach - From One Million Buses to Ten Iterations

Jeff: I'll give you an example. There was an organisation I worked with – I really loved working with them. They were a non-profit organisation that was looking to address major diseases in the developing world. They had three or four very specific diseases that they were targeting in very specific locations around the world, and I was thrilled to be working with them and helping them.

They managed everything with a task list. They were like, "We're gonna create this campaign and we're gonna put it on buses in China." And I was like, "Okay. How do you know that? So what? If the campaign works, what will people be doing differently?"

"Well, they'll scan the QR code that's on the bus."

"Okay, alright. And then what?"

"They'll sign up for an appointment to get a cardiovascular check."

"And then what?"

"For those who need actual care, they'll sign up for care."

"All of a sudden, we've taken 'put an ad campaign on a bus' to 'who does what by how much.' When we started to think about it that way, they fundamentally were rethinking the level of effort."

Because you might imagine, it was going to be one million buses and hope that it works. Instead, they decided, "Hey, we're gonna do 100 of these in one locality, and we're gonna give it a week, and we're gonna not only see what happens, but find out if people saw the ad, if it speaks to them, if they understood what it said. Then based on that learning, we're gonna iterate on the campaign."

So instead of getting one giant shot at this advertising campaign to drive people to take better care of themselves, now they're gonna get ten iterations. I think that was massively impactful in helping that organisation do better work and help more people.

Mat: I love how you're bringing that back to the experimental and iterative approach that people so often want but really struggle to get to. I've seen so many occasions where OKRs end up describing something that takes three, four, five months to build and ship, and they're only trying to measure the big outcome at the end, whereas what you're talking about there is breaking it down, making it far more iterative and experimental.

Jeff: Reducing your risk. Imagine this organisation had, let's say, £100,000 for this campaign. Traditionally, they would spend that whole hundred grand and hope. The reality is there's no need to do that. They could spend 10 and learn and do a better job with the next 10 and a better job with the next 10, and if they've de-risked it enough, take the last 50 and dump it on the thing that you've actually validated.

It's a de-risking strategy as well. You're increasing the value you're delivering and reducing the risk of spending money on stuff that isn't gonna work. Feels like a no-brainer, doesn't it?

The Reverse Five Whys - Asking "So What?" to Find Your Outcome

Mat: You make it sound like everyone should be doing it, which I agree with. There was something that you did in the middle of that conversation which I really like, and it's kind of like the opposite of the five whys. You know, where you see the problem and you ask why, why, why and you go back to the root cause. Whereas you took that in the other direction there.

Jeff: Right. We were moving forward in time for the desired outcome.

Mat: Yeah, exactly. You said, "Okay, you want to put this thing on a bus. So what?" And you took that three or four steps forward to get to that ultimate outcome. I love that, and that's probably a tactical, practical approach that our audience can take.

I think some of the stuff that I've struggled with over the years is getting teams who are new to OKRs to understand how to move from writing their to-do list, writing their backlog, turning that into their key results, and actually getting it into the outcome base. I think that's one of the things that a lot of teams find hardest to grasp.

Jeff: And as I kicked off with, if your entire career you've been rewarded for shipping and producing and ticking off a to-do list, then it's really hard to break away from that without some form of leadership buy-in. That's coming back to that incentives and performance management criteria side of things. That's really hard because that's what people optimise for.

We can preach outcome-based work until we're blue in the face, as they say in America at least. But if you're paid to ship product, you're gonna optimise in most cases for what gets you paid. That's an important component of this that I think gets ignored a lot.

Two Audiences, Two Approaches - What Should Teams and Leaders Do Differently?

Mat: Let's talk practically around this. We're probably going to have different people listening to this. We could probably give two bits of advice. One is somebody who's in a team and they really want to try this, or maybe they've been trying this and struggling because the incentives don't match. The other group may be someone who's in leadership who is trying to change their organisation to move into this more outcome-based approach. What advice would you give to each of those people?

Jeff: Great question. Let's start with the folks trying to make this happen initially. In my opinion, one of the easiest ways to move this conversation forward in your organisation is to ask that question I mentioned: What will people be doing differently when we ship this?

Have that conversation. Position it any way you'd like, word it any way you'd like. But ultimately, you're not challenging the work. You're not saying "I'm not gonna do the work." You're not pushing back yet.

"All you're saying is, 'Look, we're gonna build this thing, and we're gonna do a great job. What do we hope people will do with this once we have it out there? What are we trying to see? Are we trying to see them increase average order value? Do we want them to abandon their shopping carts less? Are we trying to get them to sign up for a medical check-up at least once a year?'"

That starts it. That starts getting people to think about more than just "I am making a thing."

Mat: If you took that to leadership and said, "Yeah, we're gonna get this stuff out the door, but I want to check with you that you're happy that this is the outcome we're trying to get to, that this is the result if we get it right."

Jeff: I think that's great, and I think that you should come back to them after you ship and say, "Look, remember we met three, six, nine months ago and I said we're building this and we're hoping people will do this? Well, we built it as designed, on time, on budget, and so far we're not seeing the results that we anticipated. We talked to some customers, and here's why we think that is. What we'd like to do next..."

To me, that should be a safe conversation inside your organisation.

Mat: I can imagine people listening to this and getting some cold sweats at the concept of going to someone and saying, "I did everything that you expected from me, but it wasn't good enough."

Jeff: It's not that. What tends to happen in these situations is a lot of upfront planning and commitments, and then we execute. Regardless of all the work that people have done to convince people that there are better ways of working, that's generally speaking how people are doing work still. We did the thing, and guess what? It didn't work. It didn't work as we had hoped. It's not because we built it poorly. It works as designed. We did usability testing on it. People can use it, they can get through the workflow.

What we think is it's not solving a meaningful problem, or we decided to put it somewhere in the workflow that didn't make sense, or whatever the case is. I understand it's not a risk-free conversation. I'm not encouraging people to do things that are career-limiting per se, but at some point we've got to talk about this kind of stuff. Otherwise, we're just a factory. I don't think anybody wants to work in a factory.

It's Not About the Quality of Your Code, It's About Learning

Mat: I couldn't agree more, and I think that the heart of what I spend a lot of my time doing is helping people understand how to get the benefits out of being agile, that agility piece. What we've been discussing there is that key part of learning. You can plan and you can build, you can have alignment on those things, you can improve how you're building all the time and reach quality standards and pass usability testing. But ultimately, if you don't learn, you're never gonna get the insight that you need to adapt what you do next.

"Where a lot of people fall down with agility is they go through all of the motions up to that point, and then through fear, self-preservation, or they've just not seen anybody else around them do it before, they hesitate to say, 'This thing that we've all invested all this time and effort into isn't working as expected.' It does take some courage to do that."

Jeff: It does. I agree. But it's an evidence-based conversation. It's not "we did a crap job." We didn't. It's bug-free, it's high performance, it's scalable, it's usable. But you can build products like that – there are infinite stories of products that were amazingly executed that didn't meet a need, didn't solve a problem.

Mat: Yeah, I built one of those and had to close a business for it, so I know that all too well. If there's a lesson I learned through the years of doing that, which you touched on earlier, it's around by focusing on the outcomes that you want to see, those behaviours you want to change, and bringing the work down, de-scoping the work to start to experiment and iterate, you de-risk all of that. You'll learn a lot earlier whether you're on the right track or not rather than getting that big bang at the end.

Jeff: Yeah. Again, you're reducing the risk of building something that people don't want. Let's just use round numbers because they're easy. If you have a million-pound budget to build something – a new product, a new feature, a new service – and you spend 100 of that million and find out that this isn't the right thing to make, it's not a real problem, for whatever reason, you've just saved the company £900,000.

They should hoist you up on their shoulders and sing your praises, parade you around the halls. That's how it should be. You're a hero, and now we can take that £900 and do something that actually will deliver value with it.

If You're a Leader: Stop Asking "When Will It Be Ready?" and Start Asking "What Are You Learning?"

Mat: The second half of that question was around if you're a senior leader in an organisation and you want to move to an outcome-based approach, maybe you start with celebrating the people who are trying to do that and positively reinforcing it in that way. But what advice would you give that person?

Jeff: Absolutely. Celebrate anybody – literally hoist them up on your shoulders and parade them around the halls and say, "Look, this team tried this, figured out it wasn't going to work, and pivoted, and saved the company a million pounds." That should be a regular conversation and a regular thing that the company celebrates.

What's interesting is that you can find yourself on a team with resistant leadership, and you can also find yourself in leadership with resistant teams. And for a variety of reasons, not the least of which is that they've never actually been allowed to work this way and don't believe you that you're gonna let them work this way.

"Without getting caught up in too much process or training or dogma, I think as a leader you start to soften the conversations around this stuff by changing the questions that you ask."

Normally, it's like, "Hey, what are you guys working on? When will it be ready? How much is it gonna cost me? What do you predict the ROI is gonna be?" That's a typical line of questioning for a product team.

Conversely, you can say, "Hey, folks. What are you learning this week? This sprint? This quarter? What did you learn?" You might get a bunch of blank stares initially. They'll say, "What do you mean, what did we learn? We're building what you told us to build."

"Okay, well, cool. Next quarter when we meet, I'd love for you folks – I'm gonna ask you this question again. What did you learn this quarter about the product, about the customer, about the value of the thing that we're delivering? If you don't know how to answer those questions, I can help. I can get training for you. I can get some folks who've done this in other parts of the company to show you how they're doing this work."

To me, you're not enforcing. One of the issues of organisations just mashing process on top of organisations is folks don't understand why. Why are we doing this, and how is this supposed to make anything better? One of the ways to ease folks into a different way of working is to change your expectations of them and make that clear to them.

Instead of saying "What are you building? When will it be ready? What's the ROI?" say "What are you learning? Are we doing the right thing? How will we know?" And then if they don't know how to get the answers to that, don't make them feel stupid. Say, "Look, I'm gonna help you with that. I'll show you how the other teams are doing it. I'll get you some training. We'll work on this."

That's super powerful because you're changing the expectations that you have for your team, and you're making it explicit to them.

Navigating Conflicting Forces - Outcomes vs. Predictability

Mat: I've got this image in my head of people in a large organisation where they're on this journey that you've described with their team. Maybe they're a leader somewhere in the middle of the organisation, working with multiple teams, and they're starting to see some progress. The teams are on board, they trust that the questions you're asking are genuine and authentic, and they really want to understand the outcomes.

They're starting to come back with great questions themselves around who does what, what's the behaviour we're trying to change, how are we trying to change it, are we successfully doing that or not. Whilst that starts to get some traction and momentum, at the same time this leader's got other people in the organisation – maybe some more traditional executives who are getting investors on their boards asking for their KPIs to be met and the efficiency and the predictability they expect so they can forecast.

They have jobs to do themselves, and they seek some predictability. How do you help guide that person to navigate those two conflicting forces?

Jeff: It's hard. I've seen it multiple times. I think there are a couple of ways to navigate those political challenges in an organisation. One is you have to model the behaviour that you want to see both in your teams and in your colleagues as well.

Every interaction that you have with your peers at leadership level should contain these types of conversations around the customer, around learning, around value, around risk mitigation, and continuing to model the behaviour you want to see.

Someone says, "Well, we just have to build the iPhone app."

"Okay, great. But why? Why do we have to build the iPhone app?"

"Because we have to increase mobile revenue."

"Why? What is it today? What are we hoping to get?"

The Power of Renaming Teams

There's a super simple trick I wrote about probably a decade ago. If you're in a leadership position to get the organisation to start to think differently about how to do work, it's simply changing the names of the teams.

For example, let's say you and I work on the iPhone app team. What's our mission? Build an iPhone app. Exactly. So that's the iPhone app team, and that's the CRM team and that's the Android app team, whatever.

"What if we change the name of that team? Same team, same people. But it's the mobile revenue team. All of a sudden, the purpose of the team has fundamentally changed. It's no longer 'build iPhone app.' It's 'increase revenue through the mobile channel.'"

That might be an iPhone app, might be an Android app, might be a better website, might be a million different things. But from a leadership perspective, one of the things that you can influence is the name of these teams, and how you name them determines what work they do. That's really powerful.

Prove the Model

The other thing that you can do as a leader is prove the model. There's a lot of "my idea is better than your idea" type of conversations at work. Instead of saying, "I think we should work this way," say, "Look, I've got a pilot team in my group that's been doing this for the last three months. Here's what the team looks like. Here's the work that they're doing. Here's how they work. Here's what they're producing. Here's their happiness score. Here's their productivity. Here's their efficiency. Here's the impact of the work that they're doing with the customer."

If you've got one or two of those teams working that way, that's a compelling argument for saying, "Look, let's give it a shot." You've got the evidence that says this is a better way of working. Proving the model is always a good way to go.

Team Autonomy and Empowerment

Mat: One of the things that I'm picking up on in what you're saying leads to an outcome within teams that I've seen – around autonomy and empowerment within teams. Something I'm always trying to do in my role in organisations is make myself redundant. If the team don't need me anymore, I've done my job.

I'm at work where I've been very clear with the rest of the leadership team: I'm getting involved in way too many decisions, and I need to remove myself from those decisions because I'm slowing us down. If I have to have all of the context to be able to get involved with that and help move us forward, then we're gonna go slower than we should.

We're very quickly removing me from decisions, and it's been a great journey. Terrifying for me because I don't know as much about what's going on. But I'm seeing the teams themselves equipped with questions like "who does what by how much?" – that's one tool around the OKRs. Also equipped with other tools and ways of working, and usually it comes down to: are they asking the right questions? Are they applying the level of critical thinking to achieve those outcomes?

"Ultimately, if we can get teams to be more autonomous, leaders have a much better time of scaling themselves without burnout, without having to get really drawn in. When teams make decisions when you're not in the room that are fighting to achieve the outcome that you also want to achieve, that's when you really start to move quicker. That's when you start to really see the benefits of agility."

Have you got any thoughts on that that you'd like to share?

Jeff: It's a really tough sell. I see it all the time because I think that leaders have defined themselves – I don't want to speak in absolutes, so the majority of leaders have defined themselves in a way that says, "I tell people what to do." That's my job.

If you ask any kid – 10 years old, 12 years old, 9 years old – "What's a boss?" they'll say "A boss is someone who tells people what to do." I think we grow up with that, and I think leadership canon for the last hundred years has roughly said that, with the exception of the last 20 to 30 years where we've seen a lot of agile-themed, agility-themed leadership books and materials come out.

Still, I think the overwhelming majority of people believe that it's their job when they're in a leadership role to tell their teams what to do and to be keenly aware of every little detail. Because what if my boss comes to me and says, "Hey, what are your teams doing?" If the answer is "I don't know," that's probably a bad answer.

I agree with you. Day-to-day decision stuff – who better to make that decision than the teams doing the work day to day? They know far more about it than I do. They're with the work every day, they're with the customer every day, they're getting the feedback.

There's no reason for you to run these tiny things past the leader every day. It's exhausting for the leader, as you said, and the team knows more about it. Big strategic shifts, invalidated hypotheses, radical shifts in the market, new competitive threats – absolutely, let's talk about that.

The Two-Way Solution

I think there's a two-way solution here. Number one, leaders need to let go a little bit and understand that the most qualified people to make decisions about the day-to-day trivial stuff are the team doing the work.

David Marquet said this in "Turn the Ship Around." He ran the worst-performing nuclear submarine crew in the American Navy and turned it around to the best-performing crew. Basically, what he said was he pushed decision-making down as close to the work as possible. The only decision he kept for himself was whether or not to launch a nuclear missile, because people are gonna die and he didn't want that on anybody. That's his job as the leader.

Same thing here. You're gonna push decisions all the way down, and we've got to get folks to think about that.

Demand Proactive Transparency

To make that easier for people to swallow, people who are not used to this way of working, I think we have to demand greater proactive transparency from the teams.

Teams love to play the victim. "They don't let me work this way. My boss won't let me work this way. My boss doesn't get agility, doesn't get customer-centricity. She just comes down here and yells at us."

"What if on a weekly basis, without being asked for it, you sent your leader three bullet points in an email every week? Here's what we did this week. Here's what we learned. Here's what we're planning on doing next week."

If there's anything significant, you're gonna put that in there as well. But otherwise, just those three things. You're not even asking for a response. Weekly update, three bullet points, 15 minutes max of effort on your part.

In my opinion and in my experience, what happens is leaders chill out. Because all of a sudden they know what's going on. They see that you're doing work, that you're making objective decisions, and that you're taking the time to keep them informed. When their boss comes to them and says, "Hey, what are your teams doing?" they can just look at that email and be like, "This is what Mat's team is doing, this is what Jeff's team is doing."

To me, if there's a role here – and it's not an insignificant one – for the teams to play to improve their ways of working or to improve the comfort level that leaders have with new ways of working, this is it.

Mat: I have had the privilege of being someone on the recipient of those equivalent three-bullet-point emails running 12 different product teams, trying to understand what was going on. You're right – the stress levels go down when you understand proactively what's going on. It became the first thing I would do on a Monday morning knowing I had all that information.

It was something that teams were doing as part of their own weekly reviews as a team, and they just captured it and shared it. So there's no extra work for them. But it made this huge difference of suddenly I could understand where did I need to actually spend my time to help, rather than trying to chase and get information or get too close into managing people who didn't need it because they had it in hand.

I was able to prioritise and think, "Oh, that team looks like they're struggling, so we're gonna go and ask them some questions, see how I can remove some blockers for them."

Jeff: And if there is a blocker, add it in there. "We've been trying for three months to get access to customers. The sales team keeps blocking us. Can really use your help here."

The Shift from Being Rewarded for Knowing to Being Rewarded for Learning

Mat: There's a thing I've observed over the years – it takes a while to get there before you actually start getting rewarded for it in most organisations. In forward-thinking, very agile organisations, it starts a lot earlier, and I think that's something I'd like to try and shift left, try and get it earlier in people's careers.

It's this shift between: spend your entire career being rewarded for being knowledgeable, for being the expert, and knowing how to do something. You get promoted for that, you'll get a bonus for that, you'll get rewarded for it time after time. The more you learn, the more capable you become, the more experienced you are, you've got the answers for everything, you get promoted. You work your way up the career ladder.

Then you hit this tipping point where you hit a level where you realise there aren't many people around you at that point who are seeing the problems. Everyone's busy, everyone's focused on their thing. Then you realise that actually it's your job to call out that this thing isn't working. It becomes your responsibility to say, "There's a problem here we need to address as a company, as an organisation."

As an exec – Nick Muldoon is our CEO – we have an exec weekly, and the majority of that conversation is each of us saying what we don't understand, what we don't know, what we haven't figured out yet. We trust each other that all the rest of it's in hand and working beautifully. The things we really want to talk about is what don't we understand and what are we learning or what are we seeing that we need to try and figure out what to do with.

I see people struggle with that transition if they've not started it earlier in their career. Going back to the basics around sharing the learnings and are we actually achieving what we wanted to, are we seeing the behaviour shift, are we seeing it measured – if we're saying no, having the freedom to be able to call that out earlier, I think it makes that transition in life a lot more straightforward.

Jeff: Look, there's a level of seniority, and the subtheme here that we are dancing around but haven't yet named is psychological safety. It's this feeling that I'm comfortable calling things out that are against the grain, that contradict the plan, that are not working, and I keep seeing and nobody's addressing.

"I think there's a level of seniority that brings some psychological safety. But ultimately, organisational culture has to make it safe."

In other words, if leaders like you and your leadership team are consistently curious – "What do we not know? What are we not aware of? What's not working?" – your teams are going to feel comfortable calling those things out to you because you're asking those questions.

When they change the questions that they ask, it models psychological safety. It models the kinds of questions they want their teams to ask, and that's how change starts.

Building Psychological Safety - "If You Don't Know How, I'll Help You"

Mat: I couldn't agree more, Jeff. I think we've covered a lot of ground today, and psychological safety is one of those really hard intangible things for some people, particularly if they've never experienced it. We see it when we get new people joining our team. We're in a privileged environment where we have a lot of psychological safety.

When new people join from organisations that haven't had that, their behaviour is almost fighting against it. They hold on to their protected ways of working where they get a little bit territorial and they don't want to be vulnerable. It can take a good few months for people to settle in and relax into it.

There was a piece that I want to go back to, and maybe we wrap up on this. You talked earlier around a leader talking to their team and asking them questions to help them understand that it's okay to come back and say, "This thing that we've been developing, this product that we've been getting out the door, isn't having the desired impact." To look at it, question it, be curious, and come back to it.

The thing that you touched on there which I really love was that supportive nature of it. It's okay to do this, and if you don't know how to do it, I'll help you. If you were to give one last tip to our audience – how would you encourage people, leaders specifically, to move more into that space?

Jeff: I think it's a question of asking the right questions. I've been married a long time – half my life, it turns out. I did the maths the other day. If I've learned nothing in my 20-plus years of being married, I've learned that you don't start out immediately solving the problem. You listen and you ask questions. I've learned that. It took a long time.

I think that's our nature as leaders as well. The tendency is "let me solve that for you." Well, hang on. Before you jump to solutions, dig into the problem. What's the issue here? What's the problem? How can I best help you?

"Well, listen, we've set these customer-centric goals now. We've got great OKRs. Thanks for teaching us how to do that. Normally though, we're told what to do, and no one's telling us what to do now, and we don't know what to do. We have no idea how to figure that out. In the past, people have told us. Now I don't know what to do. Can you help us? How do we figure that out?"

To me, those are the kinds of answers you want to elicit from your teams. What's actually going on here?

This is where five whys comes in. "Well, you know, we keep hearing that we should be talking to customers. The reality is it's really difficult to get to our customers."

"Why is it difficult?"

"Well, because we're in a B2B space and we sell aeroplane engines."

"Okay, great. And why does that make it difficult to reach customers?"

"Well, because we have a sales team."

"Why does that make it difficult?"

"Well, because they guard their contacts and they don't want us messing with it."

"Okay, now I understand."

"I think if it's about asking the right questions as a leader, and then when you get to the root cause, you say, 'Well, listen, I can try to unblock it in this way. Do you think that would be helpful? Yes or no?' That becomes far more of a partnership than a hierarchical relationship."

Then you trust me to be honest with you about how well things are working and where things need help, and that's tremendous.

I run a very, very tiny business in the sense of number of people – it's three and a half people total. Even in a three-and-a-half-person business, people try to do good work and people don't want to bother you with what's going on. Sometimes people get overwhelmed, whether it's with work or personal stuff or a combination of the two, and then things start to slip.

The more you can foster that kind of transparency and trust, psychological safety, the less you find out that something is broken with the consequences of it being broken. You find out well in advance of anything actually happening.

Mat: I love that, Jeff. I think that's a great place to wrap up. I'm really grateful for your time, really enjoyed the conversation, and thank you for sharing your wisdom.

Jeff: My pleasure, Mat. Thanks so much for having me. This was fun.

---

‍

Thank you to Jeff Gothelf for joining us on this episode of the Easy Agile Podcast. To learn more about Jeff's work and get your copy of "Who Does What By How Much," visit jeffgothelf.com. You can also find his other books, including "Lean UX" and "Sense and Respond," which provide the foundation for the customer-centric approach to OKRs discussed in this episode.

‍

Subscribe to the Easy Agile Podcast on your favourite platform, and join us for more conversations about agile, product development, and building better teams.

TL;DR

Henrik Kniberg, the agile coach behind Spotify's model, discusses how AI is fundamentally transforming software development. Key takeaways: AI tools like Cursor and Claude are enabling 10x productivity gains; teams should give developers access to paid AI tools and encourage experimentation; coding will largely disappear as a manual task within 3–4 years; teams will shrink to 2 people plus AI; sprints will become obsolete in favour of continuous delivery; product owners can now write code via AI, creating pull requests instead of user stories; the key is treating AI like a brilliant intern – when it fails, the problem is usually your prompt or code structure, not the AI. Bottom line: Learn to use AI now, or risk being left behind in a rapidly changing landscape.

Introduction

Artificial intelligence is fundamentally reshaping how software teams work, collaborate, and deliver value. But with this transformation comes questions: How do we maintain team morale when people fear being replaced? What happens to code quality when AI writes most of the code? Do traditional agile practices like sprints still make sense?

In this episode, I sit down with Henrik Kniberg to tackle these questions head-on. Henrik is uniquely positioned to guide us through this transition – he's the agile coach and entrepreneur who pioneered the famous Spotify model and helped transform how Lego approached agile development. Now, as co-founder of Abundly AI, he's at the forefront of helping teams integrate AI into their product development workflows.

This conversation goes deep into the practical realities of AI-powered development: from maintaining code review processes when productivity increases 10x, to ethical considerations around AI usage, to what cross-functional teams will look like in just a few years. Henrik doesn't just theorise – he shares real examples from his own team, where their CEO (a non-coder) regularly submits pull requests, and where features that once took a sprint can now be built during a 7-minute subway ride.

Whether you're a developer wondering if AI will replace you, a product owner looking to leverage these tools, or a leader trying to navigate this transformation, this episode offers concrete, actionable insights for thriving in the AI era.

About Our Guest

Henrik Kniberg is an agile coach, author, and entrepreneur whose work has shaped how thousands of organisations approach software development. He's best known for creating the Spotify model – the squad-based organisational structure that revolutionised how large tech companies scale agile practices. His work at Spotify and later at Lego helped demonstrate how agile methodologies could work at enterprise scale whilst maintaining team autonomy and innovation.

Henrik's educational videos have become legendary in the agile community. His "Agile Product Ownership in a Nutshell" video, created over a decade ago, remains one of the most-watched and shared resources for understanding product ownership, with millions of views. His ability to distil complex concepts into simple, visual explanations has made him one of the most accessible voices in agile education.

More recently, Henrik has turned his attention to the intersection of AI and product development. As co-founder of Abundly AI, he's moved from teaching about agile transformation to leading AI transformation – helping companies and teams understand how to effectively integrate generative AI tools into their development workflows. His approach combines his deep understanding of team dynamics and agile principles with hands-on experience using cutting-edge AI tools like Claude, Cursor, and GitHub Copilot.

Henrik codes daily using AI and has been doing so for over two and a half years, giving him practical, lived experience with these tools that goes beyond theoretical understanding. He creates educational content about AI, trains teams on effective AI usage, and consults with organisations navigating their own AI transformations. His perspective is particularly valuable because he views AI through the lens of organisational change management – recognising that successful AI adoption isn't just about the technology, it's about people, culture, and process.

Based in Stockholm, Sweden, Henrik continues to push the boundaries of what's possible when human creativity and AI capabilities combine, whilst maintaining a pragmatic, human-centred approach to technological change.

Transcript

Note: This transcript has been lightly edited for clarity and readability.

Maintaining Team Morale and Motivation in the AI Era

Tenille Hoppo: Hi there, team, and welcome to this new episode of the Easy Agile Podcast. My name is Tenille Hoppo, and I'm feeling really quite lucky to have an opportunity to chat today with our guest, Henrik Kniberg.

Henrik is an agile coach, author, and entrepreneur known for pioneering agile practices at companies like Spotify and Lego, and more recently for his thought leadership in applying AI to product development. Henrik co-founded Abundly AI, and when he isn't making excellent videos to help us all understand AI, he is focused on the practical application of generative AI in product development and training teams to use these technologies effectively.

Drawing on his extensive experience in agile methodologies and team coaching, Henrik seems the perfect person to learn from when thinking about the intersection of AI, product development, and effective team dynamics. So a very warm welcome to you, Henrik.

Henrik Kniberg: Thank you very much. It's good to be here.

Tenille: I think most people would agree that motivated people do better work. So I'd like to start today by touching on the very human element of this discussion and helping people maintain momentum and motivation when they may be feeling some concern or uncertainty about the upheaval that AI might represent for them in their role.

What would you suggest that leaders do to encourage the use of AI in ways that increase team morale and creativity rather than risking people feeling quite concerned or even potentially replaced?

Henrik: There are kind of two sides to the coin. There's one side that says, "Oh, AI is gonna take my job, and I'm gonna get fired." And the other side says, "Oh, AI is going to give me superpowers and give us all superpowers, and thereby give us better job security than we had before."

I think it's important to press on the second point from a leader's perspective. Pitch it as this is a tool, and we are entering a world where this tool is a crucial tool to understand how to use – in a similar way that everyone uses the Internet. We consider it obvious that you need to know how to use the Internet. If you don't know how to use the Internet, it's going to be hard.

"I encourage people to experiment, give them access to the tools to do so, and encourage sharing. And don't start firing people because they get productive."

I also find that people tend to get a little bit less scared once they learn to use it. It becomes less scary. It's like if you're worried there's a monster under your bed, maybe look under your bed and turn on the lights. Maybe there wasn't a monster there, or maybe it was there but it was kind of cute and just wanted a hug.

Creating a Culture of Safe Experimentation

Tenille: I've read that you encourage experimentation with AI through learning – I agree it's the best way to learn. What would you encourage leaders and team leaders to do to create a strong culture where teams feel safe to experiment?

Henrik: There are some things. One is pretty basic: just give people access to good AI tools. And that's quite hard in some large organisations because there are all kinds of resistance – compliance issues, data security issues. Are we allowed to use ChatGPT or Claude? Where is our data going? There are all these scary things that make companies either hesitate or outright try to stop people.

Start at that hygiene level. Address those impediments and solve them. When the Internet came, it was really scary to connect your computer to the Internet. But now we all do it, and you kind of have to, or you don't get any work done. We're at this similar moment now.

"Ironically, when companies are too strict about restricting people, then what people tend to do is just use shadow AI – they use it on their own in private or in secret, and then you have no control at all."

Start there. Once people have access to really good AI tools, then it's just a matter of encouraging and creating forums. Encourage people to experiment, create knowledge-sharing forums, share your own experiments. Try to role-model this yourself. Say, "I tried using AI for these different things, and here's what I learned." Also provide paths for support, like training courses.

The Right Mindset for Working with AI

Tenille: What would you encourage in team members as far as their mindset or skills go? Certainly a nature of curiosity and a willingness to learn and experiment. Is there anything beyond that that you think would be really key?

Henrik: It is a bit of a weird technology that's never really existed before. We're used to humans and code. Humans are intelligent and kind of unpredictable. We hallucinate sometimes, but we can do amazing things. Code is dumb – it executes exactly what you told it to do, and it does so every time exactly the same way. But it can't reason, it can't think.

Now we have AI and AI agents which are somewhere in the middle. They're not quite as predictable as code, but they're a lot more predictable than humans typically. They're a lot smarter than code, but maybe not quite as smart as humans – except for some tasks when they're a million times smarter than humans. So it's weird.

You need a kind of humble attitude where you come at it with a mindset of curiosity. Part of it is also to realise that a lot of the limitation is in you as a user. If you try to use AI for coding and it wrote something that didn't work, it's probably not the model itself. It's probably your skills or lack of skills because you have to learn how to use these tools. You need to have this attitude of "Oh, it failed. What can I do differently next time?" until you really learn how to use it.

"There can be some aspect of pride with developers. Like, 'I've been coding for 30 years. Of course this machine can't code better than me.' But if you think of it like 'I want this thing to be good, I want to bring out the best in this tool' – not because it's going to replace me, but because it's going to save me a tonne of time by doing all the boring parts of the coding so I can do the more interesting parts – that kind of mindset really helps."

Maintaining Code Quality and Shared Understanding

Tenille: Our team at Easy Agile is taking our steps and trying to figure out how AI is gonna work best for us. I put the question out to some of our teams, and there were various questions around people taking their first steps in using AI as a co-pilot and producing code. There are question marks around consistency of code, maintaining code quality and clean architecture, and even things like maintaining that shared understanding of the code base. What advice do you have for people in that situation?

Henrik: My first piece of advice when it comes to coding – and this is something I do every day with AI, I've been doing for about two and a half years now – is that the models now, especially Claude, have gotten to the level where it's basically never the AI's fault anymore. If it does anything wrong, it's on you.

You need to think about: okay, am I using the wrong tool maybe? Or am I not using the tool correctly?

For example, the current market leader in terms of productivity tools with AI is Cursor. There are other tools that are getting close like GitHub Copilot, but Cursor is way ahead of anything else I've seen. With Cursor, it basically digs through your code base and looks for what it needs.

But if it fails to find what it needs, you need to think about why. It probably failed for the same reason a human might have failed. Maybe your code structure was very unstructured. Maybe you need to explain to the AI what the high-level structure of your code is.

"Think of it kind of like a really smart intern who just joined your team. They're brilliant at coding, but now they got confused about something, and it's probably your code – something in it that made it confused. And now you need to clarify that."

There are ways to do that. In Cursor, for example, you can create something called cursor rules, which are like standing documents that describe certain aspects of your system. In my team, we're always tweaking those rules. Whenever we find that the AI model did something wrong, we're always analysing why. Usually it's our prompt – I just phrased it badly – or I just need to add a cursor rule, or I need to break the problem down a little bit.

It's exactly the same thing as if you go to a team and give them this massive user story that includes all these assumptions – they'll probably get some things wrong. But if you take that big problem and sit down together and analyse it and split it into smaller steps where each step is verifiable and testable, now your team can do really good work. It's exactly the same thing with AI.

Addressing the Code Review Bottleneck

Tenille: One of our senior developers found that he was outputting code at a much greater volume and faster speed, but the handbrake he found was actually their code review processes. They were keeping the same processes they had previously, and that was a bit of a handbrake for them. What kind of advice would you have there?

Henrik: This reminds me of the general issue with any kind of productivity improvement. If you have a value stream, a process where you do different parts – you do some development, some testing, you have some design – whenever you take one part of the process and make it super optimised, the bottleneck moves to somewhere else.

If testing is no longer the bottleneck, maybe coding is. And when coding is instant, then maybe customer feedback – or lack of customer feedback – is the bottleneck. The bottleneck just keeps moving. In that particular case, the bottleneck became code review. So I would just start optimising that. That's not an AI problem. It's a process problem.

Look at it: what exactly are we trying to do when we review? Maybe we could think about changing the way we review things. For example, does all code need to be reviewed? Would it be enough that the human who wrote it and the AI, together with the human, agree that this is fine? Or maybe depending on the criticality of that change, in some cases you might just let it pass or use AI to help in the reviewing process also.

"I think there's value in code review in terms of knowledge sharing in a large organisation. But maybe the review doesn't necessarily need to be a blocking process either. It could be something you go back and look at – don't let it stop you from shipping, but maybe go back once per week and say, 'Let's look at some highlights of some changes we've made.'"

We produce 10 times more code than in the past, so reviewing every line is not feasible. But maybe we can at least identify which code is most interesting to look at.

Ethical Considerations: Balancing Innovation with Responsibility

Tenille: Agile emphasises people over process and delivering value to customers. Now with AI in the mix, there's potential for raising some ethical considerations. I'm interested in your thoughts on how teams should approach these ethical considerations that come along with AI – things like balancing rapid experimentation against concerns around bias, potential data privacy concerns.

Henrik: I would treat each ethical question on its own merits. Let me give you an example. When you use AI – let's say facial recognition technology that can process and recognise faces a lot better than any human – I kind of put that in the bucket of: any tool that is really useful can also be used for bad things. A hammer, fire, electricity.

That doesn't have so much to do with the tool itself. It has much more to do with the rules and regulations and processes around the tool. I can't really separate AI in that sense. Treat it like any other system. Whenever you install a camera somewhere, with or without AI, that camera is going to see stuff. What are you allowed to do with that information? That's an important question. But I don't think it's different for AI really, in that sense, other than that AI is extremely powerful. So you need to really take that seriously, especially when it comes to things like autonomous weapons and the risk of fraud and fake news.

"An important part of it is just to make it part of the agenda. Let's say you're a recruitment company and you're now going to add some AI help in screening. At least raise the question: we could do this. Do we want to do this? What is the responsible way to do it?"

It's not that hard to come up with reasonable guidelines. Obviously, we shouldn't let the AI decide who we're going to hire or not. That's a bad idea. But maybe it can look at the pile of candidates that we plan to reject and identify some that we should take a second look at. There's nothing to lose from that because that AI did some extra research and found that this person who had a pretty weak CV actually has done amazing things before.

We're actually working with a company now where we're helping them build some AI agents. Our AI agents help them classify CVs – not by "should we hire them or not," but more like which region in Sweden is this, which type of job are we talking about here. Just classifying to make it more likely that this job application reaches the right person. That's work that humans did before with pretty bad accuracy.

The conclusion was that AI, despite having biases like we humans do, seemed to have less biases than the human. Mainly things like it's never going to be in a bad mood because it hasn't had its coffee today. It'll process everybody on the same merits.

I think of it like a peer-to-peer thing. Imagine going to a doctor – ideally, I want to have both a human doctor and an AI doctor side by side, just because they both have biases, but now they can complement each other. It's like having a second opinion. If the AI says we should do this and the doctor says, "No, wait a second," or vice versa, having those two different opinions is super useful.

Parallels Between Agile and AI Transformations

Tenille: You're recognised as one of the leading voices in agile software development. I can see, and I'm interested if you do see, some parallels between the agile transformations that you led at Spotify and Lego with the AI transformations that many businesses are looking at now.

Henrik: I agree. I find that when we help companies transition towards becoming AI native, a lot of the thinking is similar to agile. But I think we can generalise that agile transformations are not really very special either – it's organisational change.

There are some patterns involved regardless of whether you're transitioning towards an agile way of working or towards AI. Some general patterns such as: you've got to get buy-in, it's useful to do the change in an incremental way, balance bottom-up with top-down. There are all these techniques that are useful regardless. But as an agilist, if you have some skills and competence in leading and supporting a change process, then that's going to be really useful also when helping companies understand how to use AI.

Tenille: Are you seeing more top-down or bottom-up when it comes to AI transformations?

Henrik: So far it's quite new still. The jury's not in yet. But so far it looks very familiar to me. I'm seeing both. I'm seeing situations where it's pure top-down where managers are like "we got to go full-out AI," and they push it out with mixed results. And sometimes just completely bottom-up, also with mixed results.

Sometimes something can start completely organically and then totally take hold, or it starts organically and then gets squashed because there was no buy-in higher up. I saw all of that with agile as well. My guess is in most cases the most successful will be when you have a bit of both – support and guidance from the top, but maybe driven from the bottom.

"I think the bottom-up is maybe more important than ever because this technology is so weird and so fast-moving. As a leader, you don't really have a chance if you try to control it – you're going to slow things down to an unacceptable level. People will be learning things that you can't keep up with yourself. So it's better to just enable people to experiment a lot, but then of course provide guidance."

AI for Product Owners: From Ideation to Pull Requests

Tenille: You're very well known for your guidance and for your ability to explain quite complex concepts very simply and clearly. I was looking at your video on YouTube today, the Agile Product Ownership in a Nutshell video, which was uploaded about 12 years ago now. Thinking about product owners, there's a big opportunity now with AI for generating ideas, analysing data, and even suggesting new features. What's your advice for product owners and product managers in using AI most effectively?

Henrik: Use it for everything. Overuse it so you can find the limits. The second thing is: make sure you have access to a good AI model. Don't use the free ones. The difference is really large – like 10x, 100x difference – just in paying like $20 per month or something. At the moment, I can particularly strongly recommend Claude. It's in its own category of awesomeness right now. But that of course changes as they leapfrog each other. But mainly: pay up, use a paid model, and then experiment.

For product owners, typical things are what you already mentioned – ideation, creating good backlog items, splitting a story – but also writing code. I would say as a PO, there is this traditional view, for example in Scrum, that POs should not be coding. There's a reason for that: because coding takes time, and then as PO you get stuck in details and you lose the big picture.

Well, that's not true anymore. There are very many things that used to be time-consuming coding that is basically a five-minute job with a good prompt.

"Instead of wasting the team's time by trying to phrase that as a story, just phrase it as a pull request instead and go to the team and demonstrate your running feature."

That happened actually today. Just now, our CEO, who's not a coder, came to me with a pull request. In fact, quite often he just pushes directly to a branch because it's small changes. He wants to add some new visualisation for a graph or something in our platform – typically admin stuff that users won't see, so it's quite harmless if he gets it wrong.

He's vibe coding, just making little changes to the admin, which means he never goes to my team and says, "Hey, can you guys generate this report or this graph for how users use our product?" No, he just puts it in himself if it's simple.

Today we wanted to make a change with how we handle payments for enterprise customers. Getting that wrong is a little more serious, and the change wasn't that hard, but he just didn't feel completely comfortable pushing it himself. So he just made a PR instead, and then we spent 15 minutes reviewing it. I said it was fine, so we pushed it.

It's so refreshing that now anybody can code. You just need to learn the basic prompting and these tools. And then that saves time for the developers to do the more heavyweight coding.

Tenille: It's an interesting world where we can have things set up where anyone could just jump in and with the right guardrails create something. It makes Friday demos quite probably a lot more interesting than maybe they used to be in the past.

Henrik: I would like to challenge any development team to let their stakeholders push code, and then find out whatever's stopping you from doing that and fix that. Then you get to a very interesting space.

Closing the Gap Between Makers and Users

Tenille: A key insight from your work with agile teams in the past has been to really focus on minimising that gap between maker and user. Do you think that AI helps to close that gap, or do you think it potentially risks widening it if teams are focusing too much on AI predictions and stop talking to their customers effectively?

Henrik: I think that of course depends a lot on the team. But from what I've seen so far, it massively reduces the gap. Because if I don't have to spend a week getting a feature to work, I can spend an hour instead. Then I have so much more time to talk to my users and my customers.

If the time to make a clickable prototype or something is a few seconds, then I can do it live in real time with my customers, and we can co-create. There are all these opportunities.

I find that – myself, my teams, and the people I work with – we work a lot more closely with our users and customers because of this fast turnaround time.

"Just yesterday I was teaching a course, and I was going home sitting on the subway. It was a 15-minute subway ride. I finally got a seat, so I had only 7 minutes left. There's this feature that I wanted to build that involved both front-end and back-end and a database schema change. Well, 5 minutes later it was done and I got off the subway and just pushed it. That's crazy."

Of course, our system is set up optimised to enable it to be that fast. And of course not everything will work that well. But every time it does, I've been coding for 30 years, and I feel like I wake up in some weird fantasy every day, wondering, "Can I really be this productive?" I never would have thought that was possible.

Looking Ahead: The Future of Agile Teams

Tenille: I'd like you to put your futurist hat on for a moment. How do you see the future of agile teamwork in, say, 10 to 15 years time? If we would have this conversation again in 2035, given the exponential growth of AI and improvements over the last two to three years, what do you think would be the biggest change for software development teams in how they operate?

Henrik: I can't even imagine 10 years. Even 5 years is just beyond imagination. That's like asking someone in the 1920s to imagine smartphones and the Internet. I think that's the level of change we're looking at.

I would shorten the time a little bit and say maybe 3 or 4 years. My guess there – and I'm already seeing this transfer happen – is that coding will just go away. It just won't be stuff that we humans do because we're too slow and we hallucinate way too much.

But I think engineering and the developer role will still be there, just that we don't type lines of code – in the same way that we no longer make punch cards or we no longer write machine code and poke values into registers using assembly language. That used to be a big part of it, but no longer.

"In the future, as developers, a lot of the work will still be the same. You're still designing stuff, you're thinking about architecture, you're interacting with customers, and you're doing all the other stuff. But typing lines of code is something that we're gonna be telling our kids about, and they're not gonna believe that we used to do that."

The other thing is smaller teams, which I'm already seeing now. I think the idea of a cross-functional team of 5 to 7 people – traditionally that was considered quite necessary in order to have all the different skills needed to deliver a feature in a product. But that's not the case anymore. If you skip ahead 2 or 3 years when this knowledge has spread, I think most teams will be 2 people and an AI, because then you have all the domain knowledge you need, probably.

As a consequence of that, we'll just have more teams. More and smaller teams. Of course, then you need to collaborate between the teams, so cross-team synchronisation is still going to be an issue.

Also, I'm already seeing this now, but this concept of sprints – the whole point is to give a team some peace of mind to build something complex, because typically you would need a week or two to build something complex. But now, when it takes a day and some good prompting to do the same thing that would have taken a whole sprint, then the sprint is a day instead. If the sprint is a day, is there any difference between a sprint planning meeting and a daily standup? Not really.

I think sprints will just kind of shrink into oblivion. What's going to be left instead is something a little bit similar – some kind of synchronisation point or follow-up point. Instead of a sprint where every 2 weeks we sit down and try to make a plan, I think it'll be very much continuous delivery on a day-to-day basis. But then maybe every week or two we take a step back and just reflect a little bit and say, "Okay, what have we been delivering the past couple of weeks? What have we been learning? What's our high-level focus for the next couple of weeks?" A very, very lightweight equivalent of a sprint.

I feel pretty confident about that guess because personally, we are already there with my team, and I think it'll become a bit of a norm.

Final Thoughts: Preparing for the Future

Henrik: No one knows what's gonna happen in the future, and those who say they do are kidding themselves. But there's one fairly safe bet though: no matter what happens in the future with AI, if you understand how to use it, you'll be in a better position to deal with whatever that is. That's why I encourage people to get comfortable with it, get used to using it.

Tenille: I have a teenage daughter who I'm actually trying to encourage to learn how to use AI, because I feel like when I was her age, the Internet was the thing that was sort of coming mainstream. It completely changed the way we live. Everything is online now. And I feel like AI is that piece for her.

Henrik: Isn't it weird that the generation of small children growing up now are going to consider this to be normal and obvious? They'll be the AI natives. They'll be like, "Of course I have my AI agent buddy. There's nothing weird about that at all."

Tenille: I'll still keep being nice to my coffee machine.

Henrik: Yeah, that's good. Just in case, you know.

---

Thank you to Henrik Kniberg for joining us on this episode of the Easy Agile Podcast. To learn more about Henrik's work, visit Abundly AI or check out his educational videos on AI and agile practices.

Subscribe to the Easy Agile Podcast on your favourite platform, and join us for more conversations about agile, product development, and the future of work.

"Really enjoyed my conversation with William and Riz, I'm looking forward to implementing their recommendations with our team" - Angad Sethi

In this epsiode I spoke with William Rojas and Rizwan Hasan from Adaptavist about the ways we can enable high performing agile teams:

• The significance of team alignment
• When and where you should be using tools to assist with your team objectives
• Prioritizing what conversations you need to be apart of
• Advice for remote teams

Subscribe/Listen on your favorite podcasting app.

Thanks William & Rizwan!

Transcript

Angad Sethi:

Good afternoon/evening/morning everyone. How you guys going?

Rizwan Hasan:

Oh, good. Thanks Angad.

William Rojas:

Yeah. How are you?

Angad Sethi:

Yeah, really good. Really, really stoked to be having a chat with you guys. Should we start by introducing ourselves? Riz, would you like to take it?

Rizwan Hasan:

Sure. My name's Riz Hasan, I'm based in Brussels, Belgium. Very newly based here, actually used to be based in New York, not too far from William. We usually used to work together on the same team. My role here at Adaptavist is I'm a team lead for our consulting group in EMEA. So in the European region and in the UK. So day to day for me is a lot of internal management, but also working with customers and my consultants on how our customers are scaling agile and helping them with tool problems, process problems, people problems, all the above.

Angad Sethi:

Yeah. Yeah. Sounds awesome.

William Rojas:

As for myself, William Rojas. I'm actually based out of a little suburban town called Trumble in Connecticut, which is about an hour plus northeast of New York, basically. And as Rez mentioned, yeah, we've worked for a number of years we've worked together, we were running a agile transformation and scaling adoption team for Adaptavist. My new role now is actually I took on a presales principle, basically a presale principle consultant these days. It's actually a new role within Adaptavist, and what we do is we have, actually all of us, I think most of us are all like ex-consultants that support the pre-sales process, and work in between the sales team, and the delivery team, and all the other teams that support our clients at Adaptavist.

Angad Sethi:

Awesome, awesome.

William Rojas:

I help find to solutions for clients and make the proposals and support them through, get them on through delivery.

Angad Sethi:

I'm Angad, I'm a software developer and I'm working on Easy Agile programs and Easy Agile roadmaps, two of the products we offer for the Atlassian marketplace. We're super excited to speak to you guys about how your teams are operating in, like what's a day to day. Riz, would you like to answer that?

Rizwan Hasan:

Sure. Yeah. So apart from like the internal management stuff, I think what's particular to this conversation is how we walk clients through how to navigate planning at scale, right?

Angad Sethi:

Yeah.

Rizwan Hasan:

I'm working with a client right now who's based in the states, but they're acquiring other software companies left and right. Which I think is also a trend that's happening within this SaaS ecosystem. And when that happens, they're trying to bring all that work in together. So we're talking through ways of how to visualize all that in an easy way that isn't really too much upfront heavy with identifying requirements or understanding what systems we want to pull in, but more so what do you want to pull in? So really right now, in this phase of the data that I'm working with this client, it's really just those initial conversations about what are you planning? What are you doing? What's important to you? So it's a lot of these conversations about that.

Angad Sethi:

And so you mentioned it's a lot of internal management. Are some of your clients fellow workmates, or are they external clients?

Rizwan Hasan:

They're mostly internal because I manage a team, so I have different people who are working on different types of projects where they might be doing cloud migrations. They might be doing some scripting work. In terms of services, we cover everything within the Atlassian ecosystem, whether it be business related, process related, tool related. So it's a big mix of stuff at all times.

Angad Sethi:

Cool. And is it usually like you're speaking to all the team leads, and giving them advice on agile ceremonies, and pushing work through pipelines and stuff?

Rizwan Hasan:

Yeah, actually, so a story of when I first moved to Brussels, because we've... So professional services started at Adaptavist in the UK, and this was maybe like seven-eight years ago, and it's expanded and myself and William were part of like the first group of consultants who were in North America. That expanded really quickly, and now that we're in EMEA, it's almost like a different entity. It's a different way of working, and a lot of leadership has moved over to North America, so there's new systems and processes and ceremonies and then all that's happening. But because of time zones there's a conflict.

So what I started to do when we got here was to reintroduce some of those habits and consistent conversations to have, to really be much more on a better planning cadence. So interacting with people who would be, say, bringing work to delivery in presale. So folks who are, who work similar to William's capacity over here in this region, and then also project managers who would be responsible for managing that work. Right? So on the equivalent of like a scrum master on an engagement or like an RTE on a big engagement. Right?

Angad Sethi:

Yep. Yep. That's awesome. Just one thing I really liked was your terminology. You used conversations over ceremonies or speaks about the agile mindset in that sense, where you're not just pushing ceremonies on teams, where you actually embody being agile. Well, I'm assuming you are from your conversation, but I guess we'll unpack that. What about you, William? What's your [crosstalk 00:06:32]

William Rojas:

I was going to say, one of the things that's interesting challenge that we face, because Adaptavist has an entire branch that does product development and there are product developers, and product managers, and product marketing, and all sorts of things like that. And they set plans and they focus, deliver and so forth, as you would expect a normal product organization to do. On the consulting side, one of the things that's very interesting is that a lot of our, like we have to answer to two bosses, right? Like our clients come in and say, "Hey, we need this," and we have to support them. In the meantime, we have a lot of internal projects, internal procedures and processes and things that we want do as a company, as a practice, but at the same time, we still need to answer to our clients.

Angad Sethi:

I see.

William Rojas:

So that's actually one of the interesting challenges that from an agile perspective, we're constantly facing having to balance out between sometimes conflicting priorities. And that is definitely something that, and although consulting teams at different levels face this challenge. Right?

Angad Sethi:

Yeah.

William Rojas:

So as Riz mentioned, we're constantly bringing in more work and like, "Okay, we need you to now adjust and re-plan to do something different, then manage." Yes. It's an ongoing problem that's just part of this part of this world kind of thing.

Angad Sethi:

Yeah. Okay. I see. And so if I heard that correctly, so it's, I guess you're constantly recommending agile processes, but you may not necessarily get to practice it?

William Rojas:

But more so we're both practicing for ourselves as well as trying to tell our clients to practice it or trying to adjust.

Angad Sethi:

I see, yeah.

William Rojas:

You know, a client comes in with needs and says, "Okay, now we have to re-plan or teach them how to do it, or re-accommodate their new emerging priorities as well." So we ultimately end up having to practice agile with and for our clients, as well as for ourselves. It's that constant rebalancing of having to weave in client needs into internal needs, and then the constant re-priority that may come as a result of that.

Angad Sethi:

Yeah.

William Rojas:

And then we're constantly looking for like, how do we make this thing more efficient, more effective? How do we really be lean about how we do the work and so forth? That is definitely one thing that we practice. We try to practice that on a daily basis.

Angad Sethi:

Yeah. And I guess that's a very, a tricky space to be... not a tricky space. It can be tricky, I guess, but adding to the trickiness is remote work. Do you guys have a lot of clients who have transitioned to remote work? And I don't know, has it, has it bought to light problems, which can be a good thing, or like what's your experience been?

William Rojas:

So that's interesting because so I've been doing consulting for over a couple decades, and traditionally, so I've done a lot of that, that travel warrior, every week you go travel to the client to do your work, you travel back and you do that again next week, and you do that month after month. In coming to Adaptavist, Adaptavist has historically always been a remote consulting company. So five years ago it was like, wow, we would go to clients saying like, "Okay, we need you to do this." And we're like, "Yeah, we can deliver that. And no, we don't need to, you know. We may come in and do a onsite visit to introduce ourselves, but we can deliver all this work remotely." So we've always had that history.

Angad Sethi:

Okay.

William Rojas:

But nonetheless, when COVID hit and everybody went remote, we definitely experienced a whole new set of companies were now suddenly having to work remotely, and having to establish new processes and practices that basically forced them to be remote. And I think we've had the fortune of in a sense, having always been-

Angad Sethi:

Yep, remote start.

William Rojas:

... S8's.

Angad Sethi:

Yeah.

William Rojas:

I know whenever we bring on people into the company, into consulting particular, that's one of the things we always point out. Remote work is not the same as being in the office. It has its ups and downs. But we've always had that benefit. I think we've been able to assist some of our clients, like, This is how this is how it's done, this is how we do it." So we've been able to teach by example type of thing for some of the clients.

Angad Sethi:

There you go.

William Rojas:

Yeah.

Angad Sethi:

Awesome. That was actually going to be my next question is what's the working structure at Adaptavist and what sort of processes? I'm sure that it's a big company and therefore there'd be tools and processes particular to teams in themselves. Just from your experiences, what are some of the processes or tools you guys are using?

Rizwan Hasan:

So, in terms of planning and work management, because we started off as a remote first company, and since COVID, business is good. I'll be frank there, it's been good for us because we specialize in this market. We've had a huge hiring spurt in all these different areas, and one thing that I noticed internally, as well as problems that... I wouldn't say problems, but a trend that we're seeing with a lot of other clients is that because of this remote push, and the need for an enterprise to be able to give the teams the tools they need to do their work, there's a lot more flexibility in what they can use, which has pros and cons.

On the pro side, there's flexibility, the teams can work the way they want. On the con side, administration might be difficult, alignment might be difficult. So we're seeing a lot of that with customers and ours. So we're almost going on this journey with customers as we're scaling ourselves, and learning how to navigate this new reality of working in a hybrid environment.

William Rojas:

I think in terms of some of the tooling and so forth that we get to do. So we obviously internally we have, we're pretty, pretty much in Atlassian. Atlassian stack, that is very much how we work every day. All our work is using Atlassian tools. All our work is tracked, all our client work is tracked in JIRA, all our sales work, basically everything we do, we use JIRA and Confluence, we're really big on Confluence. We have a lot of customizations we've done to our instance over the years, things that we just have developed, and so that's internal.

I think the other aspect is often, depending on the client that comes to us and the type of work that we're doing for that client, then the types of tools that we use can pretty much run the full gamut. We have a lot of Atlassians, we do a lot of work in JIRA with our clients, like work in Confluence. Sometimes we're working on helping them scale, so we bring on some of the add-on to support some of the scaling practices within to support JIRA. We'll do a lot of JSM work. We do often DevOps work, and then we'll bring on a lot of the DevOps tool sets that you would expect to find, so things to support delivery pipelines.

So it really depends quite a bit on the client. We even do some agile transformation work. And then there, we do some a lot of custom build things, practices and so forth. And we bring in surveys and tools that we've been able to develop over the years to support that particularly. So a lot of the tools often are dictated by what the client and the specific engagement call for.

Angad Sethi:

In my personal experience recently with COVID, I find myself in a lot of meetings, we are experimenting with, with Async decision making. Have you experimented with Async decision making processes yet?

Rizwan Hasan:

I'll start by saying I hate meetings. I think most meetings are a waste of time, and I tell my team this. And I'm like, "If we don't need to meet, like we're not going to meet."

Angad Sethi:

Yeah. Awesome.

Rizwan Hasan:

And I think that really comes. Yeah, awesome, for sure. Awesome.

Angad Sethi:

I love it.

Rizwan Hasan:

But it comes down to really is when you do meet, are you having the right conversation? And I think a key component being like an agile team, quote-unquote, is you have an understanding of what we all are doing collectively and what the priorities are. Which is tough to actually get. So when we talk about like asynchronous decision making, with a team that has some degree of understanding of what priorities are, what goals are, it gets easier. And you can have more low impact interactions with people.

So we use Slack a lot and we have a lot of internal bots on our Slack to be able to present information and collect feedback at asynchronous times, because there's voting features, there's places where you can comment. And I think when we talk about teams that are growing across the globe and also time zones and flexible working, that's a real thing now. There's a practical way of how to do that, that we're starting to dig into what does that look like?

Angad Sethi:

Do you find yourself in a million Slack groups?

Rizwan Hasan:

Yep.

Angad Sethi:

Yep. You do. Do you see any extra hurdles you've got to skip because of that? Because you maybe, do you find yourself hopping from conversation to conversation, whereas it would just be easier if everyone was in the same conversation? Does that happen a bit?

Rizwan Hasan:

Yeah. Yeah. All the time.

Angad Sethi:

I hear you, yeah, there you go. Okay. Cool.

William Rojas:

But I would say we have a lot of impromptu. I think we do have a lot of impromptu meetings. And sometimes we may be in a Slack typing away. It says, you know what? [crosstalk 00:17:29]

Angad Sethi:

Just jump in a huddle.

William Rojas:

Into Zoom and then let's chat or Slack conversation, and then just face to face conversation, and then just address it then and there. But I think we have been looking at, it's almost like I think a balance between the time spent on the meeting, and the amount of people that need to be in the meeting, and the benefit and value that comes out of that meeting. And a daily meeting where work was people would pick up work or support from a sales perspective. And it was very, very much necessary as per part of the work coming into the consulting pipeline. But it felt very inefficient.

So that's one of the means, for example, we did away with, and it's now a completely asynchronous process, by which work comes in and it gets allocated, people pick it up, people support it, we deliver things, we track where things are and so forth. And we now use all of that is basically all done through Slack. So we did away with all the meetings around, "Hey, who can help with this?" But meantime, we have another meeting where we're trying to get people on projects. And that is very much a, we need to negotiate on that often. So that's a meeting that's still very much done.

Angad Sethi:

Yep.

William Rojas:

Everybody comes in, we all talk, we decide what we need to get done. People balance back and forth. So that trade off I think is really important to really understand what, there are meetings that are necessary, very valuable, and they should remain. And there's ones that really a Slack is a much better mechanism to be able to make those kind of decisions

Angad Sethi:

Yeah. Very true. Yeah. And does it well, sorry, firstly, pardon the location change. I'm sitting right next to the router now, so hopefully the iPhone holds. What sort of a scale are we speaking about here in your Slack? The reason I ask is with larger organizations, it can be harder to scale. Therefore I'm just trying to get a gauge of what scale your Slack is at.

Rizwan Hasan:

So we just hit, we are just over the 500 mark, that'd be in terms of employees. With basically our general, which seems to be, I think, I don't want to say universal, but the standard across any organization that has Slack general as the best indicator of how many people you have logged on. So we're just about the 500 mark, which I would say is probably around mid-size, but it's definitely getting to the point where we're starting to see, it's almost a little bit too much in order to disseminate information, find their information, etc.

We're actually partners with Slack also. So we work with them pretty closely on some opportunities. [crosstalk 00:20:39] Yeah, exactly. And we're starting to talk with customers also about the same problem, about how much is too much, and when do you start to form communities around people that are delivering the same type of value. So those conversations are more aligned and there's not just a whole lot of chatter and people get confused, like when they read Slack and like, "Oh, is this the priority now? Or am I supposed to be doing this or change in process?" That communication is harder now, I think, really. And this is where a lot of folks, I think, who are moving to this remote environment are struggling with, is that alignment communication.

Angad Sethi:

Yeah. Very true.

William Rojas:

And it is, I would say fairly organic, like our channel proliferation. We do have, I would think even for company of our size, we're pretty loose about how channels get proliferated, who gets to create them, what they're for and so forth. But then it gives the flexibility of based upon your interests or the context of what you need to communicate on, then you can either join a channel that supports it or create a channel if necessary to support it. So it is, in that sense, pretty organic. But it is true that there are hundreds, if not thousands of Slack channels that we have, and so kind of staying like which one should you be on, is definitely one of our biggest challenges.

Angad Sethi:

Yeah. Well, that just blows my mind just because like 500 people on a Slack. Our whole company is 35 people and I'm pulling my hair out being in too many Slacks. So well A, that blows my mind.

William Rojas:

It does allow us, for example, to have client specific Slack channels. So anybody, if you need to talk about, if you're working on a particular account, you're working for a client, then there's a channel for that. And if you're working on another client, there's another channel. The thing I find helpful about it is that it gives you that context of if I want to communicate with so and so, if I communicate with Riz on a particular account, I will go to the account channel. If I want to talk to Riz one-on-one, I go to a one-on-one chat.

Angad Sethi:

I see, yep, the flexibility.

William Rojas:

So we do have that benefit of where to put the information. But it does mean that I have probably over a hundred channels in my roster of things that I follow, and I'm always behind.

Angad Sethi:

Yeah.

William Rojas:

Well, yeah. So the next level of it is, then you begin to prioritize which channels should I really be notified about, and which ones are most important. I want to track those. And I try to keep that list to a minimum in terms of unread messages, and the stuff that I try to get to, and I'm bored and I have nothing else to do so, but yeah.

Rizwan Hasan:

I've been leaving a lot of channels too. I've been just really cutting the cord with some channels. You know, I had some motivation to really help out here, but I just can't and it's just too much noise. And just got to cut the cord and be like, if it's empty, there's no conversation happening or if it's slow, then move on.

Angad Sethi:

Yep.

William Rojas:

We also have the ability to, you can get added back in. So sometimes you leave and then somebody will put you back in, like, "I need you to talk about this." But it is pretty organic. I know we do leave it up to the individual to decide how best to manage that.

Rizwan Hasan:

Yeah.

Angad Sethi:

That's awesome.

Rizwan Hasan:

We had a instance today, actually, where there was an old, it was basically a sales opportunity, a customer who had reached out to us for a certain ask, and we hadn't heard from them for months, like eight-nine months. And someone posted, someone who I'm pretty close with on our sales team posted, "Hey, this is kicking back up again, but I don't have the capacity." And I just left immediately as I saw that message. I was like, "I can't help out. Sorry."

Angad Sethi:

Yeah. The old so-and-so has left the group is a bit of a stab in the heart, but yeah.

Rizwan Hasan:

Yeah.

Angad Sethi:

We will get over it. Just coming back to a point you mentioned, Riz, you said you used the words, alignment and communication. Both of you when consulting with clients, are those the two main themes you guys like to base your recommendations around?

Rizwan Hasan:

I'll give you a very consulting answer and say it depends.

Angad Sethi:

Yeah.

Rizwan Hasan:

But when we engage with a customer, one of the toughest parts of our job is understanding if there is even alignment in the group of people that we're talking to as well, because at the scale of projects that sometimes we work with, we have like 20 to 25 people on a call. And of all of those people, they may have different motivations or objectives of what they're wanting with their engagement with us. So I would say, that's primarily what's driving what we're trying to find out, what we're trying to do with them is get some alignment between the group and ourselves, and communicating that is not always easy.

Angad Sethi:

Yeah.

William Rojas:

Let's say, adding on what Riz, that also depends quite a bit on the specific engagement with that client. So in particular, if the engagement, because if an engagement is like, "Get me onto the cloud." Okay. You know, come in. Often there's much better alignment for something like that. If the engagements are more about, "Hey, help us scale agile, help us get better at how we deliver." Then the need for alignment, the need to make sure that we're all communicating correctly, we all understand, we all come to the meeting with the same objectives and so forth, is so much more critical.

Angad Sethi:

Yeah.

William Rojas:

So in those kind of engagements, we're constantly realigning. Because it's not even like we had the alignment. It's like yeah. Okay. We have it, next week it's gone. We got to go back and get it again. So that keeping, making sure that everybody's marching towards the same set of objectives, defining what those objectives are, letting them evolve as appropriate and so forth, all that becomes so much more critical.

Angad Sethi:

Yeah.

William Rojas:

And that's where the tools, that's where things like JIRA and then again, like how do we scale? How do we show what everybody's doing? And so forth, that's where it becomes that much more important. And in those kind of engagements, the tooling becomes essential. Not that the tooling's going to answer it, but the tooling becomes a way by which it helps us communicate, yeah. This is what we all agree we're going to do. Okay. The tool says so because that's the decision we've made.

Angad Sethi:

Yeah.

Rizwan Hasan:

It's really interesting that you say cloud migration, William, like when you say, "Okay, I'm moving to cloud, we know what the alignment is," but even then, I'm finding is that, especially within the Atlassian ecosystem, because that's what we're exposed to all the time, but when we're moving data from a completely old infrastructure to something brand new, it's not going to be the same. And you have folks who are thinking that, "Oh, we're just going to be taking all this stuff from here and putting it over there." But what usually doesn't come along with it is that you're going to have to also change the way you work slightly. There's going to be changes that you're not accounting for.

And that's where the alignment conversation really is important because we work with small companies who understand, okay, moving to the cloud will be completely different. We also work with legacy organizations like financial institutions that have a lot of red tape, and process, and security concerns, and getting that alignment and understanding with them first of what this means to move to a completely different way of working, is also part of that conversation. So it's a constant push and pull with that.

Angad Sethi:

Yeah, yeah. It's really heartwarming to hear the two of you deal with the JCMA, which is the geo cloud migration system.

Rizwan Hasan:

Quite a bit, yeah.

Angad Sethi:

That's awesome, because yeah, that's something we are working on currently as well. So I'll end with a super hard question and I'll challenge you guys to not use the word depends in there. And the question is the number one piece of advice for remote teams practicing agile. Start with you, Riz.

Rizwan Hasan:

Get to know each other.

Angad Sethi:

Yeah, okay.

Rizwan Hasan:

Keep it personal. I think one of the hardest things about this new reality is making that connection with someone, and when you have that, that builds trust, and when you have trust, everything's a lot easier. So I'd say that. People really aren't... The enemy. That's not the right word, but work shouldn't be a conflict. It should be more of like a negotiation, and if you trust each other, it's a lot easier to do that.

Angad Sethi:

Yeah.

Rizwan Hasan:

So yeah.

Angad Sethi:

That's awesome.

William Rojas:

It really is.

Angad Sethi:

I'm going to definitely take that back with me.

William Rojas:

Yeah. And just if I could quickly add to that. That's like looking for ways how to replace the standing around by the, having a cup of coffee. How do you replace that in a remote setting?

Rizwan Hasan:

Yeah.

Angad Sethi:

Yeah.

William Rojas:

How do you still have that personal interaction that maybe there's an electronic medium in between, but there's still sort of that personal setting. I think that's one of the things you're looking for. Because yeah, it is very much about trust. And I think to that, I would also add, back to the alignment. Right? Because in some ways that strong interaction helps build and maintain the alignment, because often it's not so much that you get alignment is that you stay aligned.

So it is this constant, and having those interactions, having that trust and so forth, is what in a sense allows us to stay aligned. Because we know each other, we know how to help each other, we support each other, so we stay in alignment. So the trust and so forth are a good way to help build and maintain the alignment itself that you're looking for. That's absolutely. In remote world, you don't have the benefit of seeing each other, the whiteboard, all those things are not the same.

Angad Sethi:

Very true. Getting cup a coffee, yep.

William Rojas:

But we still need to stay in sync with what needs to get done. That's so important.

Angad Sethi:

Very true. And so would you guys want to drop any names of tools you're using to facilitate that trust between team members in a remote setting?

William Rojas:

So I would say, like I mentioned from my role, one of the things that we do is in the presales area, we support some of our larger accounts, almost as more of like a solution account manager, per se. So we come in and help make sure that the client is getting the solution that is meant to be delivered. So we work with the delivery teams, we work with the client, we sit in between.

There's one large client that we've been working on for years now, and we basically, to the point that they're moving towards some flavor of safe. That I wouldn't call it fully safe, but they do have a lot of safe practices, but they do PI planning, and so we come in and join the PI planning. That's actually one of the, like I said, how do you stay alive?

Angad Sethi:

That circle. Yeah. [crosstalk 00:33:15]

William Rojas:

You pull up your program definition, you look at what features you want to deliver in the PI, who's going to deliver that feature in the PI, and then in your readout, go back to the tool and say, "Look, this is what we've agreed to." Others can ask questions and so forth, and constantly going back to... For example, just last week, we're doing now sprint planning and saying, "Actually, okay, this feature's going to drag on another sprint. Let me go back and readjust in," this client is using the Easy Agile programs. The original plan of saying this features not going to be, not two sprints, but the three sprints instead, for example.

So that habit of getting into using the tool to communicate what we decided and what we just had to make changes to. So it becomes this, a communication vehicle, it's really important. Yeah, they use programs, they use the roadmap piece of programs to help them do their PI planning, and stay in sync with what it is that ultimately gets communicated out at the end of PI. And then during the sprints of the PI itself, and it's very helpful for them. Again, there's I think they have seven trainings, and they all use that to help stay in sync, stay aligned.

Angad Sethi:

Awesome. Awesome.

William Rojas:

One other quick thing I'll say is, I think there will be, some of where we've gone will now become status quo, become permanent. So I think that this has been as shift across the market, across the industry, across company, how people work. So the idea of remote work, the idea of using tooling to really establish communication, and help facilitate communication, all that, while it's been around, I think the big difference is now everybody, like you have no choice. Everybody has to do it.

Angad Sethi:

Has to. Yeah.

William Rojas:

And I think we've definitely seen a big shift across the entire industry because of that. That will now solidify and let's see what the next level brings. But I definitely think that we've reached a new stage of maturity and so forth pretty much globally, which is pretty cool.

Angad Sethi:

Yeah.

Rizwan Hasan:

Yeah.

Angad Sethi:

Yeah, it is. Thank you guys. I won't keep you too long. I think, has the sun set there, Riz? I can see the reflection going dark.

Rizwan Hasan:

Yeah. It is getting there. Yeah, for sure.

Angad Sethi:

Yeah. Yeah. I won't hold you guys for too long.

Rizwan Hasan:

All good.

Angad Sethi:

But thank you so much for the conversation. I honestly, I took a lot away from that. And yeah, I hope I can add you guys to my LinkedIn. I would love to be in touch still.

William Rojas:

Definitely.

Rizwan Hasan:

Yeah, sure.

Angad Sethi:

Yeah. Trying to establish a point of contact, not to add to one of your Slack channels, but yeah. Just so that we can be in conversation regarding the product and improving it.

Rizwan Hasan:

Yeah, sure. And we have a partner management channel. I know we've been talking to Haley a little bit.

Angad Sethi:

Awesome.

Rizwan Hasan:

She was reaching out, that's about some other stuff.

Angad Sethi:

Beautiful.

Rizwan Hasan:

Yeah, happy to. We engage with your product and it's in our white papers too, and we're going to put out another white paper this year where we're going to talk about Easy Agile too. So yeah. We'll stay in touch.

Angad Sethi:

Cool.

William Rojas:

I just gave you, so my LinkedIn is under a different, my LinkedIn is not with my work email. Because that way I can keep the same account place to place.

Angad Sethi:

Sounds good.

William Rojas:

Yeah. You can look me up on LinkedIn with that.

Angad Sethi:

Wicked awesome. Thanks guys.

William Rojas:

Awesome. All right.

Angad Sethi:

Have a good day.