Listen to the Episode (37:15)
Bob Galen – agile coach, author, and speaker – talks about the three most common scaled agile anti-patterns and how to avoid them.
- [4:42] The Four Quadrants of Product Ownership
- [8:55] Scaling agile @ Siemens Healthcare
- [10:19] Scrum of Scrums
- [11:30] Focus on the Teams
- [16:07] SAFe anti-patterns
- [18:02] A better approach to SAFe
- [20:00] The importance of agile leaders
- [28:44] The secret to scaling successfully: “Think like a Scrum Team”
- [30:31] SUMMARY
- [33:17] Find Bob online
- [35:31] Parting words
- Lead with the Teams. All successful scaled agile installations start with healthy Teams. The mentality for scaling should be ‘Think like a Scrum Team’.
- Leaders must adopt an agile mindset and ensure that your goals and message are consistent. What are you measuring? And do your behaviors support your message?
- Don’t over-commit. It’s better to bite off only what you can chew and deliver on that predictably. Quality and Health need to be the focus – speed of delivery is the natural result of those two focus areas.
Find Bob Online:
- RGalen Consulting
- Agile Moose Blog
- Books and resources
- Meta-Cast Podcast
- Bob on LinkedIn
- Bob on Twitter
Jack Harding: [00:02]
Hey everybody, this is the Signal Cafe where we connect you with the people and resources you need to be successful in agile, product management, and lean startup thinking. This is episode number two and today we’re speaking with Bob Galen an agile coach, author, and speaker who’s been doing this for 20 years and is widely recognized as one of the leading voices of pragmatic agility. Bob, welcome to the show.
Bob Galen: [00:24]
Thank you jack. It’s really a pleasure to be here. I’m not sure how widely recognized I am, but I’ll take that as a compliment and I’ve really been looking forward to this chat, so thanks for having me.
Jack Harding: [00:36]
Absolutely. Thanks for coming on the show. I want to point out and I’d like to refer to you as the most interesting man in agile. I think that you look a lot like the Dos Equis – “Most Interesting Man in the World” – and your sign off on your agile blog is, “Stay agile my friends”. Now is this intentional?
Bob Galen: [00:59]
Well, I like that sign off. I like that tagline from the Dos Equis guy. I’m not sure I look like him. That’s up to everyone else to determine. But I may a little bit with the beard and such that that was unintentional. I just liked that. To me that was a very smooth sign off. And the other part of it is I realize how tough it is for evangelists and champions of agile and coaches to really, it’s tough in the real world. So I want to give them a gentle sort of reminder to just stay rooted and grounded and keep trying is part of that tagline as well.
Jack Harding: [01:39]
Yeah, I like that, because I think his was, “Stay healthy, my friends”. So I love it.
Bob Galen: [01:45]
Yeah, it was intentional. I just liked it and he was a smooth guy and they fired him and I was disappointed in that.
Jack Harding: [01:55]
Me Too. That was a good run. He had a good run. So tell the listeners a little bit about how you got started with Agile coaching and consulting and outside of work, what are you most passionate about? What do you, what hobbies and interests do you just absolutely love?
Bob Galen: [02:11]
Well, my start was in the late nineties and it wasn’t as a consultant. It was as an inside coach – if you will, or a leader who was, I was an early adopter. I’ve always been an early adopter of interesting things that I thought might help my teams and my organizations do better software development. So I was an early adopter of XP practices when I was at Lucent, Bell Labs. I was an early adopter of Scrum in the late nineties when it was just a white paper basically. And, and uh, you know, Schwaber and Sutherland were just talking about it as an experiment and sharing it. And I tried it out at a company in Connecticut. So my genesis was as a practitioner, a leader. – a developer – I’m a developer by training. But as a leader of software development teams, and just being inquisitive. And then over the years I started doing writing and consulting and training.
Bob Galen: [03:07]
As far as for a personal thing for me, I’m very family oriented and I have four children and there’s symmetry in my life. I have two boys, two girls, and they are all grown and out of the house and stuff. And then I have four grandchildren, but the symmetry left and I have three girls and one boy on the grandchild side, and that may grow. But right now I have four kids, four grandkids. And then I’ve replaced, I say this to my kids, but I’ve replaced my children with two dogs and two cats. They don’t like it when I say that. So, my life is around quadrants or sets of four so far. And so I think there’s something, and I actually talk in my product owner book about the four quadrants of product ownership. So maybe I’m stuck on the number four for some reason. I don’t know.
Jack Harding: [04:04]
That’s awesome. What are the four quadrants of product ownership?
Bob Galen: [04:11]
So when I, I’ve written, I just published my third edition of a product owner book. The first time I wrote the first edition was in 2009 and I started writing it. And at the time the role of product owner wasn’t very well understood – well there wasn’t a lot of help around it. You know, around 2006, ’07, ’08. And we were struggling in companies and I thought, well, you need to provide guidance. So I published it and didn’t have the quadrants in it. In the second edition I had this notion of quadrants. So there’s sort of four areas of concern to me of deep and broad product ownership. One is product management. Another one is business analysis. Another one is project management. So I put product management as a profession or a skill or a craft. And then I separate project management out.
Bob Galen: [05:02]
And then leadership is the fourth quadrant where I think product owners have – they don’t have a ‘big L’ leadership responsibility, but they have a ‘little L’ leadership responsibility. For example, setting the mission and vision for their product – really crafting MVPs and really energizing the team. To me, the evangelizing part of that is you have to lead the organization. You have to convince people what way we’re going. Very often they have to convince, you know, executives. So it’s not just downward convincing. It’s upward convincing as well.
Jack Harding: [05:36]
That’s awesome: product management, BA (business analysis), project management, and leadership. And I think that project management is often associated with more of a scrum master role rather than a product owner role. But there is certainly a lot of overlap there – sometimes in actual roles and job titles – but also just in the responsibilities of the product owner. So I think that that’s an awesome call out.
Bob Galen: [06:07]
There’s a wonderful video by Henrik Kniberg in Sweden. You’ve probably seen it if it’s a 15 minute video and it talks about the role of the product owner. And one of the aspects he calls out is managing expectations. So, it’s not just the “ask” side for product ownership, but it’s also the “receive” side. And then are we tracking and managing external expectations? And so to me, that shifts from traditional project management – and those folks can do that to the role. So the askers also have to manage the progress and managing how they’re communicating that progress outwardly to customers and to stakeholders, if you know what I mean. And that video really does a nice job of capturing that. So when I say project management, it’s not so much gantt charts or risk plans and things like that, but it’s sort of that tracking and expectation management sort of ‘ask:realization’. And how are we mapping the original requirements to the realization and delivery?
Jack Harding: [07:11]
That’s really good stuff – I want to transition into scaling agile and you’ve written a lot about scaled agile frameworks, and some cautionary tales and concerns, as well as some suggestions for organizations that may not be able to use a one-size-fits-all prescriptive model, but that may need to actually emerge from the unique situation that a specific organization is in. Talk a little bit about how your opinions have changed on the matter over the years and where you’re at right now.
Bob Galen: [07:55]
I don’t think my opinions have changed too much. I’m old enough that I’ve been around the agile community long enough where the original scaling framework was something called Scrum of Scrums. So before there was LeSS, before there was Nexus, before there was SAFe, before there was Scrum At Scale. There was nobody making lots and lots of money and publishing a picture or diagram on the web or anything like that. There was Scrum of Scrums. I remember in 2007, I was lucky enough to coach briefly for a few months at a company outside of Philadelphia – Siemens Healthcare System. It’s been long enough that I can talk about them in general cases. At Siemens healthcare – they’re in Malvern, PA, and they had at the time 120 Scrum Teams.
Bob Galen: [08:58]
And so 2007 – this was pre all of the scaling Hoopla, if you’re with me. Scrum was an incumbent at the time and XP was an incumbent. So the agile world was very simple. It was scrum. It was XP practices, and it was – Kanban wasn’t even that popular at the time or even that well-defined. This was pre David Anderson’s work. And the only scaling terminology we had at the time was ‘Scrum of Scrums’. The other scaling terminology we had at the time was something called ‘cyclical releases’. Dean Leffingwell had written about release trains at the time – and we were also doing release planning, cross-team release planning – what SAFe calls PI Planning. There were these concepts around that, but there were not three tiers / four tiers / five tiers. There was not Kanban this or three tier that or portfolio that it was those, those were the tools we had.
Bob Galen: [10:02]
And Siemens – to their credit – managed to – they had three large product lines. Those 120 teams were clumped into three product areas that integrated from a consolidated product perspective. But then for arithmetic sake, let’s say there’s 40/40/40. There were 40 teams that were working on major product one / 40 teams on major product two. And they managed to deliver those systems using a Scrum of Scrums. That was Scrum team coordination. That was having a Scrum of Scrums meeting. So integrating product owners and scrum masters. They had a product owner, Scrum of Scrums. They had a Scrum Master Scrum of Scrums. The Product Owners manage some portfolio planning – consolidated backlogs. But they managed in simple terms, they did not have Release Train Engineers. They did not necessarily get stuck on Value Stream Mapping or Value Stream Engineers. I’m picking on SAFe a little bit. They did not flatten the organization. LeSS says 1 product owner per 9 teams or something. They did not overload the product owners. They maintained consistency there. So I guess what I’m saying is I think I was influenced by the basics.
Bob Galen: [11:20]
The other thing that Siemens did that I still honor to this day is they didn’t lose sight of the team. Their prime directive was “The thing that’s generating money for us is the Team”. It’s not about portfolio. It’s not about project management. It’s not about the metrics. All of those things are nice, but they were really focusing at the time on training – making sure that the teams were healthy and mature. They brought in ThoughtWorks and they were doing, XP practice training a lot. And they had coaches – they spend as much money on downward coaching (at a team level) as they did on upward coaching – In fact, more. And it was successful. Arguably you could have nit-picked it, but it was a successful installation.
Bob Galen: [12:08]
So fast forward 2007 to 2019 ( 12 years later ) now we have a myriad of scaling frameworks, et cetera. My beef with all of them in general – and they’re all different; some of them are more simple – but I think some of them – they’ve just added complexity. Not all – Scrum At Scale was relatively simple; LeSS tries to be simple. Um, but SAFe is arguably the most complex of the scaling frameworks. But I guess my beef is – they’ve gotten away from basics. I really care less about how many tiers you have. You know, it’s not that SAFe is bad or good. Let’s make sure that we don’t lose sight of the value proposition. Let’s not lose sight of our principles and invest in the framework too much. I think a lot of the frameworks can. It’s not intentional; They’re not bad. Dean Leffingwell was not trying to screw up the agile universe by introducing SAFe. I know he’s well intentioned – but at the same time, if you give this really complex thing to customers, very often they don’t understand how to do it – How to transform under SAFe. So the simpler the framework can be, I think the easier it can be for organizations to scale. And that was one of the advantages of the learnings at Siemens as well. They relentlessly tried to keep it to the simplest possible thing that would work for them. They didn’t go to a maximus framework, they went to a minimus thing that they had to do to get to get the work done.
Jack Harding: [14:02]
I want to repeat a couple things you said that I think are extremely valuable. First is – keep it simple. Focus on finding the simplest, least complex solution or structure or whatever that looks like, that works for your specific organization. And one of the things that I know you’ve written about is taking the Kanban approach of really starting where you are. What does your organization look like? How is it currently structured? Is the ROI of a really prescriptive framework worth reorganizing… everything – potentially? Because it’s worked elsewhere doesn’t necessarily mean it’ll work in your specific organization. So, focus on the teams, keep it simple and start where you are – taking into consideration the uniqueness of your organization. I think that that’s all really, really valuable – and something that is often missed in a lot of transformation work. And another thing that you said is always bring it back to the principles and make sure that you’re focused on the principles. One of my mentors, an agile coach that I’ve worked with often says whatever the practice, or ceremony, or artifact – Flex on practice and process, but stand firm on principles. And I think that’s really valuable too.
Bob Galen: [15:44]
Absolutely. I’m agreeing with everything you said. It’s the basics. We lose sight of the basics. I’m going to pick on SAFe a little bit now, but it’s good-natured too. I mean, I get that folks are using it and I respect peoples’ decision-making. But when I encounter – and this is an honest statement – I’ve never encountered a successful SAFe installation yet in my coaching journey. Now I’m not exhaustive, but one of the anti-patterns that I see is they’re leaving the teams behind. They’re doing SAFe organizationally. But, when I scratch the surface and look at the maturity of the teams… Are they predictable? Are they having fun? — I know that’s a horrible idea — 🙂 Is there a healthy Team structure? And are the Teams really delivering high value and high energy and predictability? And I find that you have this facade where “we’re SAFe, and we’re PI Planning, and everything’s great, and look at what we’re doing.” But if you look at the Teams, they’re really struggling. And that’s what I mean by “you’ve left the basics behind.”
Bob Galen: [16:58]
So when I DE-scale SAFe, very often I’ll try to convince an organization, “Can we shut it off a little bit? Can we turn it down? Can we turn down SAFe for a little bit? And can we turn up Team maturity? I don’t want to turn SAFe off, necessarily, but I want to make sure – your value proposition is your Team. It’s not the framework. And so let’s make sure your teams are really running on all cylinders. It’s like an engine. You have an eight cylinder engine but only four cylinders are firing. And it’s all polished – the outside of it is nicely polished. We got a shampoo today and look how it shines in the sun. But when you look at the engine, it’s not really tuned very well. And I encounter this universally, almost. Again, I try not to go down SAFe lane and I’m not trying to argue it. What I’m trying to do is this: Can we turn it down a little bit? And then let’s focus on your Teams. Let’s focus on basic performance. And I see that pattern over and over again.
Bob Galen: [17:58]
And so now let’s reflect that back on a SAFe adoption. I think a healthy SAFe adoption would be to start with the Teams. So don’t lead with SAFe. Lead with your Teams. Lead with practices. And then here’s a novel idea. If we’re going to grow, if we need scaling, then grow it from the bottom up. I hope I’m making sense. Grow it from the bottom up and grow it because you need it. So do PI Planning and PI Planning rocks! But do it because you need it. Hire a Release Train Engineer because it makes sense. You don’t even have to call them that – but do it because there’s a need in the organization, not because SAFe says “hire five RTEs, etc, etc. And then if an organization has that bottom up, organic, simplest possible thing that works, if they end up in two years with a full measure of SAFe – I’ll tip my hat to them. Cool. That’s exactly what you needed. So make that, so.
Jack Harding: [18:59]
Let me ask you this. One thing you said you see as an anti pattern in SAFe or in other scaled agile frameworks that focus too much on the scaling rather than the bedrock. They’re leaving the Teams behind The real focus should be to start with the Teams and Team agile maturity. What are some other anti-patterns or some other questions that you would want to ask in the situation where you walk into a new organization, they’re running SAFe or LeSS or Nexus and they perceive there’s room for improvement and you’re asking several initial questions.
Bob Galen: [19:48]
Well it’s not so much a question, but it’s an observation. There’s the Teams aren’t being invested in, or trusted, or empowered sort of anti-pattern. That’s pretty common. I think there’s another common anti-pattern where leaders don’t really understand agile. So now I’m picking on the leadership crowds. They paid for SAFe – I think Scaled Agile has a leadership workshop, right? Like a one or two day bootcamp that they run leaders through. But their behavior doesn’t align with understanding. So I don’t measure leaders agile-ness by the number of certification letters they have behind their name. I measure it by observing their behavior. You can talk about “I have this certification and I read this book and I had I had coffee with Kent Beck last night – we smoked a cigar together, etc”. That’s all great, but how do you behave in the trenches?
Bob Galen: [20:49]
For example, a PowerPoint in SAFe training says “trust the team”, or “healthy team based metrics, not just functional metrics.” How are you measuring teams? Okay, so what’s your behavior? So you learned it in the class. Now what are your measures? You learned it in the class. Are you actually supporting failure? You with me? Failure is learning. Learning is good. Fail fast – learn fast – pivot – adapt. That’s great. Those are great words. But is that how you’re behaving to your teams? And very often the answer is no. So the leaders have had studies but haven’t really been coached and/or trained and/or expected – maybe the senior leader in the organization isn’t really buying it.
Bob Galen: [21:37]
So they haven’t morphed. They haven’t changed their mindset. So it’s not just the teams that have to change their mindset. The Leaders have to change their mindset. And honestly, the behavior to me is the measure of that. So that’s another thing that I’m looking for – and then I’ll coach to that. So when I’m DE-scaling actually, so it’s not just a Team-word. When I was talking about DE-scaling, I try to turn SAFe down, and really re-focus – refocus the organization on their teams. I very often shine the light on and the light needs to shine on you all. And you need to change your mindset. One place to look aside from behaviors are the measures. What is the organization measuring and how are they measuring it?
Bob Galen: [22:23]
And a third anti-pattern I see: This isn’t a scaling problem – this is a general problem. I still see almost every client I encounter biting off more than they can chew. Let’s use points. They have a capacity across teams of 1,000 points per release train per quarterly release interval. And they’re trying to bite off 3000 points and they continually try to convince themselves that they can do that for whatever set of reasons.
Bob Galen: [22:56]
I once attended a PI planning event and there were 20 teams in a room not that long ago with a client and the managers were sort of giving thumbs up / thumbs down to the team commitments. So if they didn’t feel like the teams were biting off enough in PI Planning, they were coercing the Teams. They weren’t bad people, but they were coercing them because the roadmaps said that we needed to get more done than the Teams were actually trying to commit to. And then at the end of the PI Planning Event, when you have that commitment and everyone goes “thumbs up” and “we’re all on board” / “we have a committed release plan” — all the teams went thumbs up and I had observed all this coercion and they basically doubled or tripled it! And everyone smiled and everyone’s thumb went firmly in the air and they gladly went along and said, “This is a committed train!” And everyone applauded. But they bit off more than they can chew.
Bob Galen: [24:00]
Oh. And it was even worse than that. The last time – they bit off more than they can chew and the one before that, too. So the retrospectives had shown them that they had a tendency to bite off more than they could chew, but they didn’t pay attention to that. So I think I’m not picking on the scaling. Those are three really big bang anti-patterns that I see: Don’t lose your Team. Make sure that leadership is only ‘on board’ – because that does it a disservice – Make sure leadership is changing their mindset. They have to be on board AND changing their mindset and that’s a path for them. And then make sure you’re running your organization within capacity and not just thinking that you’re doing that — but making sure that you’re doing it. Does that answer your question?
Jack Harding: [24:48]
Yeah, that totally answered my question. And the third, I think, is really interesting. What’s glaring about it is that you see we bit off more than we could chew two times ago, and again last time, and we’re doing it again. You would like to think that if it wasn’t scaled – if it was just a Scrum team – then we would say, okay, our commit was higher than our delivery for the last three sprints. Let’s try to maybe estimate a little bit better, maybe commit a little bit more appropriately and improve our predictability. I don’t know what the phenomenon is that it causes that at scale. Maybe it’s kind of group think, or maybe it’s the end of two really long days of planning and everybody wants to get home. Or maybe it’ not wanting to challenge a hundred people in a room and express a lack of confidence. I don’t know. But, but I think that there’s really something compelling there that is tough to answer – tough to get right – for sure.
Bob Galen: [26:00]
I think it’s part leadership. I mean, as a leader – I’ve been a senior VP or a CTO in companies. And I think one of the things we have to do is message what’s important. And I intentionally de-emphasize speed and more in all of my conversations, even when we did release planning kickoffs. Because I want more. I want the world. I want to get to Mars next year, right? I want global warming to be resolved, et cetera, et cetera. But at the same time, I want us to bite off what we can chew. I don’t want us to compromise quality. I don’t want us to compromise Team health. And those things are equally important to biting off lots of stuff. And I want us to just trust the process. And as a leader, I think we can set the tone that gives the team space. So I know I’m putting probably 80% of the burden on the leadership and the way we message. It’s even our body language and how we interact with the teams. And I think it’s our responsibility to re-message the team, what the priority balance and delivery. Do you know what I’m saying? And to make sure that it’s okay – It is absolutely okay to bite off what you can chew, chew it, and deliver it. And then I think the Teams sort of get that.
Jack Harding: [27:30]
Absolutely. Yeah. I mean there’s something rewarding and psychologically healthy about estimating correctly, committing appropriately and delivering what was committed. And that helps, then, the alignment between the development organization and the business – because what was committed to was delivered and that helps with roadmapping, and planning, and promises to other parts of the company. That’s really one of the goals I think of any scaling effort – to get better transparency and predictability between the development arm and the business. And when that’s not a result of whatever the efforts are – then it requires, I think, a retrospective on what we’re missing.
Bob Galen: [28:24]
You know – I think you said something powerful, Jack, and I want to circle back to it. You said you brought scaling down to a single team. Remember my example of 20 teams in a room and we’re twisting their arms and we’re biting [off more than we can chew] and we’re failing. If we brought that down to a single team, we would never continue to do that. I actually want to extend – I think what you said is that’s the mindset of scaling. It’s a trap. We sort of think of scaling as different. I actually want us to think like a Scrum team, first. What would a good Scrum team do, and then extrapolate that to the scaling. That’s what I’m saying. Think about the Team. Think about Scrum Team. Think about the basics.
Bob Galen: [29:09]
What would you do with the Team if they ignore their retrospective – and continued to fail. At that level. It’s a simple question, right? How much collaboration do we need? What if the scrum team was doing 80% portfolio analysis and not delivering on their commitments and they were out of balance? What would you do? You would self correct that because the focus there is very simple. What if a Scrum Team said “we have to create business case epics to justify every story and use some prioritization model and methodology for that and it took so much time. Is it worth the value at that level? Again, I think you hit it. It’s scaling – but it should be looked at through the lens of simplicity or the team. It’s a Scrum Team on steroids, right? Rather than an organization on steroids that just happens to have Scrum Teams. And replace Scrum Teams with Kanban teams if you will. It’s not really the methodology. It’s that same mindset.
Jack Harding: [30:26]
Sure. This is awesome. I want to review and just go over one more time, some of the anti patterns and, and focus areas in any agile organization or any scaling effort. You mentioned three big areas and one is to focus on the Team and really make sure that it’s being kept as simple as possible, as lean as possible, and that the Team agile maturity and value delivery and FUN and HAPPINESS and HEALTH is one of the highest priorities. Secondly, you talked about leadership – and really making sure that it’s more than smoking cigars and reading books and getting certifications. But really, truly understanding what the principles are behind agile and understanding what the goals are for the organization – From an agile perspective. And truly identifying with the agile mindset. And third you talked about predictability and alignment and not biting off more than you can chew. Looking at the data, looking backward, and using the concept of retrospectives, organizationally to say, “How can we continuously improve? How can we not commit to more than we can actually deliver?” Because that just causes less predictability, more stress, more tension and divisiveness. So focus on the team, focus on healthy, agile leaders and focus on appropriate commitments. And I think that’s super valuable. Super good.
Jack Harding: [32:18]
So what are you working on now? You’ve put out a bunch of books You’ve got two different blogs that you run. You are running a consulting company. What is your focus in 2019 – in the near future?
Bob Galen: [32:39]
Actually, you’re right. I probably overworked. So by WIP limit was too high last year and into early this year. So I’m actually focusing on taking a break and recharging my batteries. So that’s one thing. All joking aside, this year, this year I’d like to plan my own personal development, like sort of put my money where my mouth is and practice what I preach. So this year I’m going to be going to some coaching training, Send myself back to coaching training and do more coaching and take a little – I’ll continue to write – but take a little bit of a break from the books and things.
Bob Galen: [33:17]
Like you said, I just published a few months ago, the third edition of my product owner book. I’ve done some other books. The one thing I’d like to note is I just recently spun up a new website. I’ve been blogging on RGalen.com, which is my company website – there’s a lot of blogs there – so I would encourage everyone to take a look at the blog. But what I found is I had some things I want to personally say that I didn’t want to put on my company blog. I could have, but I spun up something called Agile-Moose.com. Just like it sounds. And that’s where I want to put things that are a little bit thought provoking or personal. I just did a blog post talking about pocket knives, for Gosh sakes. I’m a collector of pocket knives and I normally wouldn’t post that on my company website. So, pay attention to the Moose; Agile-Moose.com. Look at my writing. I think that’s a great way to catch up with me. The other thing that I don’t know if people are aware of. I’ve been podcasting for coming up on 10 years now. In January it will be our 10th year anniversary of something called the Meta-Cast. A friend of mine, Josh Anderson, and I do that – and we just enjoy being with each other. We’re friends, and we enjoy talking about agile stuff. So that’s another great resource out there. So, if you haven’t listened to the Meta-Cast, please listen to the Meta-Cast.
Jack Harding: [34:58]
I love the Moose. First of all, your writing is just so readable and I’m just really impressed with everything I read that you put out. I love it. I’ll link to your Twitter handle, your company website, Agile-Moose.com, your book resources as well as Meta-Cast in the show notes on our site, signal.cafe. And is there anything else that you would like to share with our listeners before we wrap up?
Bob Galen: [35:39]
I just want to appreciate everyone. Agile is a worthwhile endeavor. So I would just share, continue to try to sharpen yourselves and get better. This podcast – and there’s so many resources out there. But try to find the good ones. Go listen to them and let’s refine our craft. And then the last thing is I want to just thank you for inviting me, Jack. I appreciate it. I really appreciate the opportunity. I had some fun. So thank you for creating an engaging opportunity to share some of my thoughts. And I hope I didn’t offend any of the scaling frameworks in the known universe. And if I did, I apologize to everyone. But thank you.
Jack Harding: [36:17]
No, absolutely. And thank YOU so much for your time and all of your writing and efforts and thought leadership in this space. And I think it would be amiss if I didn’t sign off with “stay agile my friends.”