(S4) E034 Bryan Tew on Meeting Teams Where They're At (Part 1)

Bio  

Bryan is a seasoned Enterprise Transformation Strategist, Coach and Trainer specialising in the practical implementation of Business Agility practices within all types of organisations. He brings a balance of business, technical and leadership expertise to his clients with a focus on how to achieve immediate gains in productivity, efficiency, visibility and flow. Bryan is a key contributor in the development of the AgilityHealth platform, AgileVideos.com and the Enterprise Business Agility strategy model and continues to train, speak and write about leading Business Agility topics.  

Interview Highlights   

04:15 Interrogating KGB agents

06:00 Now that I see it – overcoming failed deliveries

07:15 Agile ways of working

09:00 Meeting teams where they are at

11:50 AgilityHealth

14:10 Business Agility vs Enterprise Agility

17:30 Establishing a Strategy

 21:25 Driving Strategy forward  

Social Media  

LinkedIn: linkedin.com/in/bryantew

Twitter: @B2Agile

Email: [email protected]

Website: www.agilityhealthradar.com 

Episode Transcript

Intro: Hello and welcome to the Agile Innovation Leaders podcast. I’m Ula Ojiaku. On this podcast I speak with world-class leaders and doers about themselves and a variety of topics spanning Agile, Lean Innovation, Business, Leadership and much more – with actionable takeaways for you the listener.

Ula Ojiaku 

Hi everyone, my guest for this episode, actually, we're going to have a two part episode, is Bryan Tew. Bryan is a seasoned Enterprise Transformation Strategist, a coach and a trainer that specialises in the practical implementation of business agility practices within all types of organisations. I first came across Bryan when I did the Agility Health Enterprise Business Agility Strategist Course. I was mind boggled, my mind opened to possibilities, and I thought this is someone I would really like to speak with. In this episode, Bryan and I, for part one anyway, we talk about overcoming failed deliveries, or overcoming failed transformations, the importance of meeting teams where they're at. We also looked at the term Business Agility versus Enterprise Agility and Bryan explained his view on what that is all about. We also talked about strategy and how to establish that and drive that forward. I hope you enjoy listening to Bryan Tew's episode, as much as I enjoyed having this conversation and recording it with him. So part one, Bryan Tew.

So I have with me Bryan Tew, who is a seasoned Business Agility Strategist, coach, trainer extraordinaire. He is just an all-round awesome expert in the Business Enterprise Agility space, and he works with AgilityHealth. Bryan, thank you so much for making time out of your busy schedule to have this conversation with me as my guest on the Agile Innovation Leaders podcast.  

Bryan Tew  

It's my pleasure. Thanks for having me on, Ula.  

Ula Ojiaku  

Awesome. Thank you again. So, growing up, can you tell us a bit about your experience, your background, and how you wound up to where you are today?  

Bryan Tew

Sure, absolutely! So I grew up in the state of Utah, in the United States. It's a wonderful area, there’s lots of mountains, and many outdoor things to do, so I love the outdoors. I grew up skiing and snowboarding and playing outside, hiking, I do a lot of canyoneering and rock climbing and all kinds of outdoors, sometimes extreme sports, I just love those kinds of things, it helps me connect with nature. I had a great growing up, great schooling, but I'll tell you the thing that really changed my life, what's most influential for me is when I was 19 years old, I decided to serve a two year mission for my church, and I was called to St. Petersburg, Russia. You don't get to choose where to go, and that was actually a very interesting area for me. As you can imagine, this was in the early nineties, so a lot of different things changing in that area. And I had the most amazing experience, you know, two years where I wasn't focused on myself at all. It was all about serving others, and we would do things from helping kids in just these terrible orphanages, helping people on the streets, working with youth to try to help change their lives, teaching about God, helping families, it was just such an amazing experience and that really changed me and made me into a person that really was not so much about me, and kind of the selfish environment that we typically are in, but more about what can I do to maybe better myself so I can help others, and that was phenomenal. Now, as part of that, you know, obviously I was able to speak Russian every day, every day, all day, and so I became pretty fluent in the Russian language. And so following my mission, I came back, and as part of my schooling, I decided to use that, and I, just as a part-time National Guardsman, I joined the US Military Intelligence as an interrogator. So I actually was able to use my language to interrogate former KGB agents, Russian scientists, you know, different things to get information, and that was tremendous. And that just helped me through school. I didn't do a lot with that other than, you know, those six years where I was in the Guard. But that was a really influential time as well, and you know, as it came time for a real career, I actually started out in Washington DC, that's where my wife and I, after we were married, we moved there. She was working in congress, as a staffer, and so I started working for a lobbying firm, and that was really cool, you know, in fact, my interrogation skills helped a lot.

Ula Ojiaku

I can imagine.

Bryan Tew

Right? But you know, the reality is that it's a sleazy industry, and we saw some things, even just day to day, some things that I just didn't approve of. So I knew that that wasn't going to be a career for me. So, I actually decided to pursue an MBA, a Master's in Business (Administration), and we moved back to the state of Utah where I went to BYU for a Master's degree. And we thought, you know, while we're having our first child, it'd be nice to be close to grandparents. We just loved it back being home, so we've actually been there ever since. And from there, after my Master's degree, I actually started my technology career, that's where I became a Project Manager at Novell, which does infrastructure and networking software… Had a great experience there working waterfall projects. But the problem was we had many failed deliveries. And I remember hearing sometimes these five little words that I've come to dread, which is now that I see it, and maybe you've heard those words, maybe audience you've heard or maybe even said those words, right, usually something bad follows like, now that I see it, I don't think you understood my requirements. Or now that I see it, we have to go back and really fix a lot of things, or now that I see it, we completely missed the boat. And we had some of those experiences. And so it was multiple projects later where we were working on an enterprise service bus and my team had a real need for some expert consulting help. So we had this great gentleman from Australia, can't even remember his name, but he had some expertise in that area, but he also had some ideas on our broken process. So he would talk to our team and he said, you know, because this is such a large and complex project, I recommend that every day, let's just come together as a team, we can invite any of our key stakeholders who want to be part of it, but let's just stand up and talk about who's working on what and what our daily needs are, and how we can resolve some of these dependencies and just try to get on the same page as far as a daily plan. So we started doing that. He didn't call it a daily Standup or anything, it's just, this is something that can work. And so that was helping us for sure. He also said, you know, because we need to be on the same page as a team, I suggest that every couple of weeks or so, let's get together and let's talk about what's working and what's not working and what we can do to improve maybe the next couple of weeks. And again, that was just a really, just great idea to get us starting to think more collaboratively as a team. And he said, you know, because this is such a complex project with lots of moving parts and lots of different stakeholders, let's actually bring them all together. Let's try to help them understand and collectively build out a vision for where this is going. Let's think about how, what some of those customer needs are, and let's start to build a backlog of prioritised work that they can engage with us on. And let's start to deliver that maybe every couple of weeks to show our progress. I mean, as you can tell, just bringing in some of these Agile concepts without calling it a certain methodology. I mean, this was back in 2002, I didn't know anything about the Agile Manifesto at the time. He just said these are some practices that can work. Now having gone through that project, implementing some of those ideas, we just thought, wow, this is such a better way to work. And that's when I started to really start researching, what is this called? What is this all about? And so I got a little bit of agile experience there, and it just so happened that at the time in this area in Utah, we call this area the Silicon Slopes, because it's kind of like Silicon Valley in terms of technical experts here, lots of great developers and that understanding. So there were a lot of technical firms and there was one organisation that was actually looking for some Agile help, so this was about 2005 now, and I was one of the only ones that had Agile experience. And so I was hired on to help lead some of the effort there, and it was tremendous. In fact, I loved going from team to team, helping to introduce Agile concepts and kind of looking at a strategy. We had some software teams, and this was at ancestry.com, but we had software teams and operations teams and all kinds of different types of teams. And that's when I realised that, you know, there are so many different methods and what works for one team may not work for another. And so we have to be very particular about what kind of work do you do? What kind of customers do you have? What type of team are you? And then the methods will fit what you're trying to accomplish from an outcomes perspective. And that was super exciting to me, to implement Scrum for some teams and then others, you know, we had some Kanban methods and maybe a blend with Scrumban. That was exciting.

Ula Ojiaku

On that point in terms of, you know, what works for one team might not necessarily work exactly, and the fact that you're taking the time to understand their context, their work, what are outcomes they're trying to achieve, and then help them navigate, you know, find the best practice that would help them and processes that would help them get to where they're going to. Did you find out, I mean, that maybe some teams, they might start with a practice and then later on that practice doesn't necessarily work for them and they'll change?

Bryan Tew

Over the years I found that there are certain agility practices that can work for any kind of team. And at the time I didn't know that, and so we would start them on certain things, you know, let's try at least to prioritise your work or let's try to just put your work in some kind of visual place where you can see how it's moving. Like, just simple things like that. Let's try to think about what your vision is from your customer’s perspective and which later became more of an outcome-driven approach. But at the time we knew nothing about this, this was very new. And so we would try certain things, but one thing that I heard over and over was, for instance, like an infrastructure team. An operations team, a support team, like we're not software, so don't try to force fit what they're doing with us. And we still hear that today, don't we? And so just understanding, okay, let's learn about what you do day to day. How does your work flow? What do you focus on each day? And how much of your work is rapid response work? How much of your work is more around projects that you can plan out? And then based on that, that's where we can recommend certain practices. So that was super-exciting and we get a lot of success from that. And to this day I continue to recommend to leaders, if you have different types of teams that are unique or do different work than maybe your traditional Scrum teams, listen to them, don't force fit things that will potentially not work or potentially make them very cynical about the process. Listen first, and meet them where they are. And it just so happened that, you know, after a while, that kind of work was, is super exciting, but now that we were all agile and kind of moving that in that direction, like, well, now I need more, right? And that's when I started consulting. And so I was lucky to have joined Steve Davis with Davisbase. I was, in fact, it was just he and I for a while, and we did some training, we did a little bit of coaching and we started to build that business, and that's where I started traveling all around doing training classes, and it was just really fun, just such a fun time early on. This was about 2008, 2009, and very exciting. After a while I realised that, you know, our goals weren't exactly aligned and I was starting to look at, you know, maybe I just form my own company and start working through things. And it was right around Christmas time. In fact, it was like right after Christmas, and I just got this LinkedIn message out of the blue. And it was from Sally Elatta, who was just starting up a company herself called Agile Transformation, and she said, you know, you come recommended, I'm looking for a partner to start to build this business. And it just was such a perfect time for me as I was looking for, you know, how do we actually build transformations? How do we help organisations from start to finish instead of just doing quick hit training classes? And so she and I hit it off right away and I started working with her back in about 2011 and, you know, it's been just a match made in heaven, I've been working with her ever since. It was about, a few years later when we realised it's more than just transformation work, it's more than just training and coaching. We had a lot of organisations, especially leaders, asking us questions like, how do I know that this transformation is working? How do I know the ROI of the work that we're doing? How do I know how my teams are doing? How do I even know if they're better than when they were doing waterfall? We were trying to do some different flow charts to look at how teams were producing, but it was just not sustainable, it wasn't scalable, and it wasn't answering the right questions. And so that's where Sally's ingenuity to build the AgilityHealth platform came into play and really, we did it for our own clients, but what we found out is this is much bigger than us, so that's when we actually changed our name to AgilityHealth, and since then we've been more of an enablement company, really helping not only our clients, but partners and anyone who's interested in the enablement services that we provide, which include kind of the health and measurement platform and the outcomes dashboard and so forth. But also our Business Agility services.

Ula Ojiaku

Oh, wow! That's an inspiring story and it's just amazing how things seem to have aligned, hindsight is 20-20, isn't it? And you've nicely segued into, you know, one of the topics we were to discuss, which is Enterprise Agility versus Business Agility. Are they one and the same, or are there differences to the terms?

Bryan Tew

Well, although there are similarities, they're actually very different things and I'll try my best to describe this, but first of all, Business Agility is really the ability to adapt to change, to be able to learn and pivot as you see disruption. And that's really important to understand, because that can apply at any level in an organisation. I can have one division, or even a single release train, or even team that are adopting some of those practices, and so that would include things like customer centricity and your lean portfolio management and a focus on outcomes and how we prioritise, and our organisational design, and all those different practices, right, which are super important. But that can be done in a small scale, that can be done in a single group or division. When I think about enterprise agility, that's where we're actually applying those practices and those concepts and mindsets to the entire enterprise. That's where you get to see true flow from an outcomes perspective at a company level and where all different leaders are talking the same language. They're collaborating well together, they have the same outcomes, we know what we're trying to accomplish from a vision and purpose perspective. And you can't do that when you're just looking at many moving parts that are all doing their own thing. Now I will also say that when I talk to leaders, I like them to think of business agility as agile for leaders. I mean, we know a lot about Agile for teams, and certainly the support that is needed from leaders, but business agility is what leaders have to own, and their job is to provide the right environment so that teams can actually be successful and provide the most valuable work to customers.

Ula Ojiaku

And what are those sorts of things that leaders can do? Because what I'm getting from you is there are some things that they would need to influence or change in the environment, what sort of things?

Bryan Tew

Well I'll kind of frame it this way because you're familiar with our Enterprise Business Agility Strategy model, and I'll just kind of talk about a couple of points from there, because this is what we share with leaders, this is what you need to own. So for instance, how do we take a more customer-focused strategy? And that's where we build in a process for how we can validate that we're actually solving the right customer problems. So leaders, you need to engage your product people, your marketing people, your support people, those who are hearing customer problems and understanding how do we validate that we're solving the right ones? Not just guessing, not just hearing from those who think they know, but actually validating that. And that's where many of the practices around journey mapping and so forth can come in. But then the second part is, how do we validate then that we're actually solving those problems the right way? I mean, if you're solving the right problem, but you have a terrible solution or a solution that doesn't really fit the need, then you're still not winning. So that's where discovery work, and there's so many great approaches now on how to do discovery, which is part of that whole customer solution, okay. So, leaders can help drive that. But then of course there's the lean portfolio management side. How do we establish a strategy? And if there's one thing that I would have leaders start with, it's you need to define and get aligned with your fellow leaders on what your strategy is, and that's an enterprise strategy, but also a division, or portfolio strategy. We need to make sure that that is not only clear, but then the second part of that is how do you communicate that strategy to your people? Not just through a chain of command, but through specifically clarifying what the strategy means and how that applies to each of your groups that are working to move forward on your strategy. So that's really important. And I would say part of that is to build an outcome-based strategy. So we like to use OKRs to do that, and, you know, the way that we suggest building OKRs is a little bit different, where you actually have a hypothesis statement that ties together what you expect to do and the outcomes you expect achieve, and then the key results can help you really measure that. So that's the thing that we ask leaders to do, and not just, give that to your people to try to accomplish, or to try to do for you, but actually think about what are our enterprise and maybe longer term, like three year OKRs, and then from there, how do you align the work there? How do you align the outputs, the projects, the initiatives to your outcomes, and break that down into the prioritised items that you need your groups to own. Like that is something that the teams can't do for themselves, they can guess, but they'll probably get it wrong when it comes to actually looking at strategy. So those are all things that happen. And then one of the things we'll certainly get into is funding models. You've got to be thinking about how do you fund your work? And I know that that's what we call an elephant in the business agility room, because it's hard to talk about. And it's something that's not just a thing that you implement on your first day of moving to business agility, but it needs to be discussed early on, to start getting the balls rolling. So we'll talk through that. And then your org structure and your design of your teams, like that's something that leaders have to own, what is the optimal org structure? Do we look at value streams? What kind of value streams? Is it product focused? Is it journey focused? Is it more around your capabilities? Like, that matters because that's how you start to bring the right people to work together. And then of course, your leadership and culture, you know, you need to be thinking about the culture transformation along with any kind of agile or business agility transformation. So, all of those things are what leaders should be thinking about, including their technology agility, like, how are we potentially providing the right technical environment, and tools and systems, and everything else we need that might need to be modernised, or maybe looking at digital transformation work to support our teams actually providing the best products to our customers.

Ula Ojiaku

That's amazing. So there are some things you've said about what leaders need to do and some of them include, you know, looking at the lean portfolio management, taking an outcome-based approach to defining the strategy at all levels and making sure that, you know, it kind of flows, not in a cascaded manner, but in a way that each layer would know how it's feeding into delivering the ultimate strategy of the organisation. Now, how, from a practical perspective, I mean, yes, you use OKRs, or objectives and key results, you know, that's one way of doing that. But how, are you suggesting then that the leaders would have to write the OKRs for every layer? Or is it just about being clear on the intent and direction of travel and letting each area define it within their context, but with some input from them?

Bryan Tew

No, it's a great question and I'll try to visualise as much as I can, but when you think about it this way, when you start at the top, and let's say that we're coming up with some enterprise level three year OKRs. So where are we going for the next three years? And you know what, things can change, so that's why we check in on those, you know, at least every six months, if not every quarter, because we're learning a lot and we want to adjust. But the thing is, if we have that level of strategy clarified, and not only that, but we're aligned across our leadership group, that means that the priorities that we're focusing on should align as well, and that's the important thing here. So now as we start to move from the enterprise down to maybe a division or portfolio level, all of the OKRs at that level should in some way align up to our enterprise, right? Whether it's around certain objectives that we're trying to accomplish from a financial perspective, or customer goals, or people goals, whatever it is, but now there's something that we can connect to as a foundation. So those senior leaders, although they can provide support and help, typically now it's your portfolio leaders that are taking the lead on building their OKRs that are aligned, and then down to maybe your program or train or whatever level you'd call it, what those OKRs will look like, all the way down to where every single team, which in reality, every single person in the organisation, sees how they fit in driving strategy.

Ula Ojiaku

That was a very, very insightful conversation with Bryan, and this is only part one. In part two of my conversation, Bryan gets to talk about aligning OKRs, that's Objectives and Key Results, the ten elephants in the business agility room, what are those? And the importance for leaders to take the driver's seat in cultural changes and many other things as well. That’s all we have for now. Thanks for listening. If you liked this show, do subscribe at www.agileinnovationleaders.com or your favourite podcast provider. Also share with friends and do leave a review on iTunes. This would help others find this show. I’d also love to hear from you, so please drop me an email at [email protected] Take care and God bless.