Podcasts about scrum inc

Jeff is the co-creator of Scrum and a leading expert on how the Scrum framework has evolved to meet the needs of today's business. The framework he developed in 1993 and formalized in 1995 with Ken Schwaber has since been adopted by the vast majority of software development companies around the world. However, Jeff realized that the benefits of Scrum are not limited to software and product development. He has adapted this successful strategy for several other industries, including finance, healthcare, higher education, and telecom.   As the CEO of Scrum Inc. Jeff sets the vision for success with Scrum. He continues to share best practices with organizations around the globe and has written extensively on Scrum rules and methods. With a deep understanding of business process — gleaned from years as CTO/CEO of eleven different software companies — Jeff is able to describe the high-level organizational benefits of Scrum and what it takes to create hyperproductive teams.   Topics of Discussion: [:35] Introduction of Jeff Sutherland, co-creator of Scrum. [3:47] Jeff Sutherland's background: His experience at West Point and lessons in making work visible. [5:19] Fighter pilot experiences that influenced the operational side of Scrum. [6:02] Transition to the Air Force Academy and work in AI at Stanford. [7:38] Learning complex adaptive systems and the origin of Agile from complex systems theory. [8:30] How complex systems theory impacts Scrum and Agile teams today. [9:25] Jeff's first experiences applying Scrum in the banking industry. [11:25] The development of Scrum and the 2001 Agile Manifesto. [12:57] Making work visible and organizing teams, from West Point to Toyota to the Agile Manifesto. [13:23] Fast forward to 2024: Issues in Scrum and Agile practices, including sprint lengths and backlog grooming. [14:34] Jeff's new book: First Principles in Scrum and its relation to Scrum technology stacks. [16:23] Building autonomous systems: Lessons from radiation physics, AI, and complex adaptive systems. [19:16] The influence of autonomous robots on the creation of Scrum. [21:14] Discussion of Scrum and AI, leading to “Extreme Agile.” [22:47] Predictions for the future of Scrum and Agile: Teams becoming 30 to 100 times faster by 2030. [23:37] Example of AI in action: Developing a system to handle expense reports using Scrum principles. [29:37] Challenges with AI-generated code and the need for strong software architecture knowledge. [33:24] The importance of following Scrum “by the book” to achieve hyperproductivity. [35:30] Jeff's closing advice on adapting to extreme agile to stay competitive by 2030.   Mentioned in this Episode: Clear Measure Way Architect Forum Software Engineer Forum Programming with Palermo — New Video Podcast! Email us at programming@palermo.net. Clear Measure, Inc. (Sponsor) .NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, by Jeffrey Palermo “How the Agile Manifesto Came To Be” Become a beta tester for Jeff Sutherland's AI software project for expense reports: support@quickaireports.com   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

Jeff is the co-creator of Scrum and a leading expert on how the framework has evolved to meet the needs of today's business. The framework he developed in 1993 and formalized in 1995 with Ken Schwaber has since been adopted by the vast majority of software development companies around the world. However, Jeff realized that the benefits of Scrum are not limited to software and product development. He has adapted this successful strategy for several other industries, including finance, healthcare, higher education, and telecom.   As the CEO of Scrum Inc., Jeff sets the vision for success with Scrum. He continues to share best practices with organizations around the globe and has written extensively on Scrum rules and methods. With a deep understanding of business processes — gleaned from years as CTO/CEO of eleven different software companies — Jeff is able to describe the high-level organizational benefits of Scrum and what it takes to create hyperproductive teams.   Topics of Discussion: [:35] Introduction of Jeff Sutherland, co-creator of Scrum. [3:47] Jeff Sutherland's background: His experience at West Point and lessons in making work visible. [5:19] Fighter pilot experiences that influenced the operational side of Scrum. [6:02] Transition to the Air Force Academy and work in AI at Stanford. [7:38] Learning complex adaptive systems and the origin of Agile from complex systems theory. [8:30] How complex systems theory impacts Scrum and Agile teams today. [9:25] Jeff's first experiences applying Scrum in the banking industry. [11:25] The development of Scrum and the 2001 Agile Manifesto. [12:57] Making work visible and organizing teams, from West Point to Toyota to the Agile Manifesto. [13:23] Fast forward to 2024: Issues in Scrum and Agile practices, including sprint lengths and backlog grooming. [14:34] Jeff's new book: First Principles in Scrum and its relation to Scrum technology stacks. [16:23] Building autonomous systems: Lessons from radiation physics, AI, and complex adaptive systems. [19:16] The influence of autonomous robots on the creation of Scrum. [21:14] Discussion of Scrum and AI, leading to “Extreme Agile.” [22:47] Predictions for the future of Scrum and Agile: Teams becoming 30 to 100 times faster by 2030. [23:37] Example of AI in action: Developing a system to handle expense reports using Scrum principles. [29:37] Challenges with AI-generated code and the need for strong software architecture knowledge. [33:24] The importance of following Scrum “by the book” to achieve hyperproductivity. [35:30] Jeff's closing advice on adapting to extreme agile to stay competitive by 2030.   Mentioned in this Episode: Clear Measure Way Architect Forum Software Engineer Forum Programming with Palermo — New Video Podcast! Email us at programming@palermo.net. Clear Measure, Inc. (Sponsor) .NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon! Jeffrey Palermo's Twitter — Follow to stay informed about future events! How the Agile Manifesto Came To Be   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

Join Brian and Dr. Tess Thompson as they delve into the complexities of scaling Agile, highlighting the challenges of aligning leadership priorities, fostering transparency, and applying system-level thinking for successful organizational transformations. Overview In this insightful episode, Dr. Tess Thompson tackles the pressing challenges organizations face when scaling Agile, with a focus on the critical role of leadership alignment. Drawing from her extensive experience, she explains how misaligned priorities at the leadership level can stall progress and waste resources. Dr. Thompson emphasizes the importance of system-level thinking, transparency, and communication between teams and leaders to resolve misalignments and ensure success. She also shares her holistic approach, blending practices from various Agile frameworks to meet the specific needs of different organizations. References and resources mentioned in the show: Dr. Tess Thompson Scrum Inc. Scrum.org #68: The Pros and Cons and Real World Applications of SAFe with Mike Hall #94: Connecting Teams and Leadership with Anthony Coppedge Three Questions to Determine If an Organization Is Agile by Mike Cohn Certified Scrum Product Owner® Training Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Dr. Tess Thompson is a visionary leader in Agile transformations, with over three decades of experience reshaping industries from energy to biotech across the globe. As a professor at St. Mary's University, her dedication to fostering Agile leaders has empowered countless individuals to embrace adaptability and forge their own path to success. Auto-generated Transcript: Brian (00:00) Welcome in Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today I have a very special guest with me. I have Dr. Tess Thompson with me. Welcome in Dr. Thompson. Tess Thompson (00:13) Hi, I'm glad to be here. Brian (00:16) I'm so happy to have Dr. Thompson with us. And just for people who aren't familiar, let me make sure that I introduce her and give you the background a little bit. First of all, she's been in this business for almost 40 years now. She's been doing stuff in IT since the 80s. She is a principal consultant and RST fellow with Scrum Inc. Scrum .inc, I should say. She is a PST as well with scrum .org. So two different organizations from two different founders of Scrum. She has been a professor at St. Mary's University. So has that kind of educational background as well. And I was asking her beforehand if there's anything else I needed to say. And she said, well, make sure you say I've got nine grandchildren. That's kind of my claim to fame. I love that. So. Nine grandchildren, very happy for that. So that's who we're talking with. And we wanted to have Dr. Thompson because there's a lot of experience here that she brings to the table in the realm of scaling, obviously being connected so closely with those two organizations. So with all that out of the way, let's talk about scaling a little bit. And Dr. Thompson, what I want to start with is just Tess Thompson (01:27) I'm Brian (01:40) When you work with organizations today that have scaling issues, what are organizations really struggling with? What's kind of the main issues that you see organizations have with scaling today? Tess Thompson (01:55) I would say there's a lot of things, but I would say still the biggest problem is getting everybody to align on what the priority is. So at some point, like you get alignment with maybe people that are doing Scrum and they're the people that are above them, but then the people above them are out of alignment. like, for example, one of the clients I have right now brought some consultants in to work on a project. Brian (01:59) Yeah, right. Tess Thompson (02:24) And those consultants have been stuck now for four weeks. And where the alignment problem is, is actually up at the C -suite with this client. Because one of them says, nope, we were supposed to help. That was a priority in 2023. And the other one's like, no, this is a priority in 2024. And they're not helping each other. So in the meantime, this project is stuck for four weeks. And we're spending money on people that are sitting there doing nothing. Brian (02:50) So just when you say alignment, give us kind of a flavor. when leaders are misaligned, what kind of things are they, are there different ideas about priority or different ideas about why they're doing this? What are they misaligned on? Okay. Tess Thompson (03:09) Both, both, I would say both. The, you know, especially as the companies get bigger and bigger, we have a CEO who's got some priorities, but then all the C -suite under them have their own priorities and they're not always, and then they break down to the next level and these priorities start to get out of alignment because people start bringing in their own objectives and their own priorities and they often don't match what somebody else is doing. So part of it is the different incentives and just the organizations being so big, they have to get even these priorities aligned at different levels. Brian (03:49) So this is kind of an amazing thing, I think, for people to latch onto here, because I hear a lot of people in just regular base level classes talk about how there's a disconnect between them and the leadership on how they're going to do Scrum and how this fits into the overall structure of the organization. just understand, Dr. Thompson here is talking about organizations that The leadership has stated, at least in some way, or form, we're in alignment with this. We want to do this. We want to have Scrum throughout our organization. But even in those situations, we're seeing these misalignments of just priorities and what are the drivers really for what they're trying to do. So I find that fascinating that talking to so many people who just wish that their leadership could get on board. with what it is they're trying to do, that even in those organizations where they do, quote unquote, get on board, there's still these kind of fundamental disconnects. Tess Thompson (04:51) Yep, absolutely. In fact, I do very little work anymore on scrum specific. is many organizations, I mean, almost every organization I go into anymore has some shape or form of scrum going on or people with experience with it. Some people, you know, they're not, it's something that they're trying to do anyway, something agile. And they're... They're getting things done quicker. They're delivering with higher quality. They have better communication at that level. But then as you go up the chain, things start to break down and then teams are stuck. So organizations can only get product out the door with high quality as quick as possible. The more the organ... We have to really think the system. So most of the work that I do today is around the system, which is scaling. It's system agility. Otherwise you start having, you just run into optimization in areas, that local optimization problem. Brian (05:58) Yeah, yeah, not seeing the whole, right? Tess Thompson (06:02) Right, absolutely. So I think that over the years that Agile has been around, we're seeing more and more of it, but then it's, like I said, almost all my work now is system level and not down at the team level. So often I'm not even using Scrum language when I'm talking. It is about alignment. It is about prioritization. So yes, at a Scrum level, your product owner is putting the order of the product backlog, and then the team can pull out off that backlog. based on value from all the different stakeholders that the product owner is working with. But in a big organization, those stakeholders can be a manager, can be a director, it can be another department, it can be, it's from all over the place. And then at some point, how does that work coming into the product owner roll up to the priority of the department or a higher level? And then how does that roll up to the higher level? And that's where we start running into messes. Brian (06:58) Yeah. Yeah. Yeah. mean, it's like you said, with all these various priorities, with all these various drivers, I've always talked to product owners and say, it's a tough job. You're balancing the needs and desires of all these people into one product, and you're having to take them all into account. So yeah, it's not easy. It's not an easy job. Tess Thompson (07:08) You. Brian (07:27) Well, so I'm curious about, you say you don't really even use the Scrum language as much when you're talking to the leaders, because they're not really interested in that, right? They're not really interested in, we doing this exactly according to what the Scrum guide says? They're interested in the outcome, right? The results that you're getting from this. Yeah, so I'm kind of curious, especially since you're a fellow with Scrum Inc. And I know that the... Tess Thompson (07:37) No. Absolutely. Brian (07:55) a Scrum at Scale kind of strategy is very specific about how these things are implemented. There's practices and all sorts of stuff that Scrum at Scale kind of implements. Would you categorize yourself as sort of a Scrum at Scale implementation consultant? Or is it more of just, I take more of a holistic approach to the scaling. Tess Thompson (08:19) Holistic, absolutely. So actually, I'm certified in Nexus, Scrummit Scale, Less, and Safe. I mean, I have all of them. So I always think you need to bring the best tool to the job. One of the things I like about Scrummit Scale and Nexus is they're just so simple. Like if, hey, if these two teams are not, if we need to coordinate, let's get these product owners together and work together to figure out what is really the order. So whether we call it a meta scrum or we call it something else, I don't think that language matters as much as seeing the need and then bringing in a tool to help meet that need. If these teams are interdependent and they need to be chatting to help get rid of those interdependencies, well, let's spin up a scrum of scrums here. Brian (08:58) Yeah. Yeah. Yeah. I've had someone on before that we've talked through kind of the safe model a little bit and talked about how, you know, there's so much additional overhead, there's so much additional roles and events and all these other things that get added from the safe perspective, that it can be very, very overwhelming for a lot of organizations to look at that and say, well, gosh, how are we ever going to, I mean, we're barely hanging on with it, trying to understand what Scrum is. And now we're going to layer in all these other things and, Tess Thompson (09:22) Thanks. Okay. Brian (09:38) It just seems like a recipe for disaster to try to understand all these things. So I guess one of the things that I had in that previous conversation was this dialogue about how you match the problem to the practice. You find the problem that is going on in the organization and you find the right practice that solves that, but not necessarily implementing the whole smorgasbord of practices because you may be trying to solve problems you don't have. Do you see that as kind of your approach when you work with organizations or how do you match the practices to what's actually going on on the ground? Tess Thompson (10:18) Yeah, I would say, you know, it's kind of similar to what happened with, so I'm also a PMP. So when we When we put together the PIMBOK over the years, it became this, know, it was supposed to be, these are best practices that you can have. And over time, it became very, big, thick book and people didn't understand they were only supposed to implement whatever tool from that book really helped solve the problems they were having. And started implementing the whole thing. And I think that's what happens too with like, Brian (10:50) Ha ha. Tess Thompson (10:53) safe or any of these agile practices, even though, know, Ken and Jeff went completely the opposite of PMI and said, hey, we're just going to roll out. This is the absolute minimum that you need for running, running a team or a project or product. And, but it's not enough. So you need to add in some more things to it. You got to bring in some additional tools to help depending on the organization, such as road mapping. I really believe that's one of the. I spend a lot of time helping organizations and product owners think about, we do need to plan ahead. And that is one of the pieces I do like about SAFE is that in their PI planning, have the getting some product owners and teams together to plan together to look out further, I think is pretty essential in most organizations. Now, do we need to do it on a regular cadence of every eight weeks? And do we need to have 200 teams together? I think Brian (11:23) Yeah. Tess Thompson (11:49) Sometimes it's, think organizations end up implementing all of SAFE, kind of like in the pin box, if you will, and it's way more than they need. So I think it's taking the elements of all of these and then using them to meet the need of the organization. I mean, if you're a 30 person organization, do you need a bunch of release trains and engineers and stuff? No. Brian (11:59) Yeah. Yeah. Yeah, I mean, it's very interesting to me with your background that you have all of these different scaling frameworks in mind. How much of what you do do you feel is aligned to a specific framework and how much of it is just piecemeal across the different frameworks? Tess Thompson (12:34) I would say I'm most aligned to, well, Scrum at Scale, never solely. It's always piecemeal. It is a piecemeal thing because I really do believe that teams do get to need to plan out in almost every company I go into. Teams do need to plan out more than one sprint. Brian (12:44) Hmm. Tess Thompson (12:54) Okay, we need to plan out and we're never delivering anything alone with one team. It seems like we're always need multiple teams. So we need that coordination and we need some of the scaling practices for sure. I really use a variation of safe of PI planning, but then I layer in, so we put together our plan for let's say the month, maybe we have a product goal for the month. And then I use the version of PI planning to get the teams together to plan out for sprints. weekly sprints to get to that product goal and try to get rid of the dependencies and problems that we see between the teams. And then we let it run. But then I pull in from Scrum at Scale, definitely the Metascrum. Like every sprint, let's still get the product owners together and revise our sprint plans because we've learned a lot in the last sprint or we learned a lot today. So we're not just going to let it ride for a month, for example, we're going to still get together at a regular cadence, like once per sprint. and realign our backlogs based on what we've just really happened. So it's using both, yeah. Brian (13:55) I love that. Yeah, taking the best of what these different practices offer, Tess Thompson (14:04) Absolutely. Brian (14:06) I love that. Well, one of the things that I wanted to talk to you about as well is sort of in working with scaling practices, I'm sure you already talked a little bit about how leadership has different ideas than the team level does. And the team level is kind of struggling with a certain layer of complexity. The leaders are struggling with another. Tess Thompson (14:22) Okay. Brian (14:33) I know there often appears to be sort of a disconnect between these two groups. I've talked to people who feel like they're speaking a different language. It's sort of like the leaders are, especially when teams, the team level will look and see, there's people in leadership who just, they want us to do Scrum, but then they want a lot of things in the same way that they always have, which is really hard for us to translate and put back into that old language. I'm just kind of curious your thought about that. Do you see leaders, the leadership layer as sort of speaking a different language than the team layer and how do you help them understand each other? Tess Thompson (15:13) Yeah, I mean, my most successful implementations is definitely when the leaders are on board. Leaders are really important to agility. We need their help and we need their support. What I always find super interesting is when I go into an engagement, I usually run an assessment, an agility assessment. And what I'm measuring is kind of where the organization is on culture, delivery, how well they're continuously improving or optimizing the system, how well they prioritize and how customer centric they are. Because I really believe agility is about those... It's those five dimensions, if you will, that you need to really focus on. And so I run this assessment and I always have them self -assess through a survey, interviews, and then observations. So often I see my assessments different than maybe how they self -assess and I'll compare both of them. But the leadership assesses so different than the teams do. And so at the end of the assessment, it's just interesting how different they are. Brian (16:13) Yeah. Tess Thompson (16:21) The teams are thinking they're delivering so well because they're getting all kinds of stuff done and leadership's like they're delivering, they're not delivering. And it's, like, how do we get so out of aligned it all the time at companies? Yeah. Brian (16:35) Yeah, yeah, we will do an assessment to it mountain goat. And one of the things that like became clear to me very early in doing that is that self perception versus, you know, perception of others is very different. And, you know, it was amazing to me, just like you said, to see things like the leadership might think that you have one opinion of something and the teams might have another or, you know, the other thing that I saw was was You know, like the Scrum Masters might think, yeah, our practices are great or they're going really well. And then you ask the developers and developers would say, no, it's horrible. We don't like the way this is working. so, you know, it kind of became apparent to me that you have to factor that human personal perception, right? We tend to be maybe individually more critical on ourselves, but Tess Thompson (17:18) Okay. Brian (17:34) you know, as a group, tend to give ourselves a little more grace in how we're performing, whereas others, when they look in from the outside, will kind of be more honest about it and say, it's not so great in this situation. Tess Thompson (17:49) But what I often find is they are delivering. The thing is they're delivering a bunch of things that the leadership doesn't even know about. So the leadership will have their priority list in their head of projects or things they want the teams to be delivering. But the team is getting hit with all kinds of other stuff that the leadership doesn't know about. So they are working hard and they're delivering. So in their head, they're doing it. It's just this. Brian (17:56) Yeah. Tess Thompson (18:12) the leader maybe not attending to a sprint review and really understanding what the teams got on their plate. Brian (18:17) Yeah, and that's kind of that transparency moment, right? mean, if they think they're not doing anything, they may be, they're just not seeing what they're doing and what they're actually spending their time on. And it's not that they aren't really working hard. As you said, they are working hard. It's just the work they're being asked to do is not really in align with what the leadership thinks the priorities should be. Tess Thompson (18:22) Yes. Absolutely, that's it. Yep. And then should the people be working on the stuff that they're working on? You know, is it the right thing? And often it may not be. Brian (19:00) Yeah. Yeah, I know I've had several instances where I've talked to people when I've been in working with teams where they will, the team level will say, you know, we have all the stuff that we're having to do in addition to the new work. And, you know, we know that that's just kind of a constraint we're under. The organization has asked us to do this as well. And, you know, my comment is always, well, Are you being really transparent about that when you get to something like a sprint review? Are you showing them where you're spending your time? Are you showing them kind of how much of this extra other work you're doing? And I've had situations where we've been in sprint reviews and we've shown them, for instance, like how much support time that they've had to spend. when the lead, right. And the leaders see that and think, my gosh, I didn't know they're spending 60 % of their time doing that kind of work. That's not good. We want them to do, Tess Thompson (19:32) right. Yep, eye -opening. Brian (20:00) new work. So I've had leaders who have actually spun up support teams when they've been confronted with that just because they didn't know what was going on. Tess Thompson (20:09) Yeah, absolutely. That is one of the things I love about sprint reviews is that transparency. And I have seen teams also go into sprint reviews thinking that they just want to show like some progress they made on an increment for a project and not talk about the support work that they did or some of the other buckets of work that come in. And I'm like, you. Part of transparency is seeing, hey, and it doesn't have to be that you show all the support tickets or anything like that. It's talk about something like 50 % of our time, of our capacity was spent on support tickets. Just throwing that in there to make sure leaders are aware. Brian (20:45) Yeah. Yeah. Yeah, I want to go back to something you said earlier too, because you were talking about when we first started about how one of the biggest issues is alignment on priorities. And I want to just dig under the surface in that a little bit, because when we talk about that alignment of priorities, are we talking about more of the product area? Are we talking more about just a general overall? What's our company's priority? What kind of priorities are they misaligned on? Tess Thompson (21:08) All, I would say all, all priorities are misaligned. So it's been an interesting move to, for me, to Scrum Inc. Because Scrum Inc's clientele is very much Brian (21:21) Right. Tess Thompson (21:35) scrum mostly outside of IT. So it's been really fun for me because my career and background was all in IT. So I've been learning so much about all these other different domains out there. And we're doing full transformations of an entire company is doing a version of scrum, right? Or scrum at scale so that they're aligned on priorities. And anyway, so it's very... It's all, all the work tends to be a little out of alignment. And going back to the support, I really like to work companies to help them really understand that almost all support, whether it is support in a field that's doing some kind of drilling or it's or it's IT support or it's HR support, you know, taking phone calls from the employees that it tends to all be tech debt. All support is really some form of tech debt. And so getting that message out there, how much time we're spending on and how much money we're spending on support helps companies, leaders to agree to fund some of these. Brian (22:44) Yeah. Tess Thompson (22:57) projects around reducing tech debt. Brian (22:59) Yeah. Yeah. And there's always the having to overcome the kind of more traditional viewpoint of projects and these things based around projects and scope schedule, that sort of thing. How do you help leaders understand kind of this is a new way of doing things and not that we can't talk about schedules, but Tess Thompson (23:07) Okay. Brian (23:29) that we're kind of shifting our priorities a little bit, or we're trying to focus on what matters more than arbitrary dates. How do you have those conversations? How do leaders understand that? Tess Thompson (23:38) In some organizations it's easier than others. It depends how much the leader above those leaders is on board, to tell you the truth. So I feel like fundamentally they understand. And if we bring up two different priorities and it's two vice presidents, for example, and they're getting bonuses or something based on their performance in their area, we can see Brian (23:50) Yeah. Tess Thompson (24:08) They fundamentally will understand in a meeting together, they'll understand and then we'll leave and they'll still kind of do their own thing. But if I could get even though like the person, the CEO also, a person above them be like, nope, this is important. And for that person to see the two competing priorities and where there's a problem, I mean, it's really about if there's a problem, right? And then they'll agree and kind of one will give up a little bit on. Brian (24:30) Yeah. Tess Thompson (24:37) on their ambition towards getting their thing done, understanding that it's good for all of us, the whole company, we all, to get to work on maybe the other priority first. Brian (24:50) So a lot of negotiation involved, right? A lot of negotiation skills. Tess Thompson (24:54) Absolutely, and getting people in the same room so that they can have the conversation together. You know, it's not me talking to one and then going and talking to the other. I mean, there is some of that too, but then we have to get together here and decide. And yes, unfortunately, yeah, and yes, we will probably be working on these at the same time. However, if there comes into, you know, with an or, Brian (25:10) Yeah, it's amazing how much easier that is, right? Tess Thompson (25:22) With a large organization, when you've got hundreds of thousands of people, of course we're working on a ton of things at the same time. But when there is a conflict, like we need this skill set here and this, then we have to know which one is more important. Brian (25:37) Yeah. Yeah, and someone has to make that call, right? Someone has to be given that authority at some point. Well, this is fascinating stuff. I'm really interested in hearing your perspective of working with these organizations in today's world. So last little question here. From what you just see, especially most recently, Tess Thompson (25:44) Yep. Brian (26:07) from what you've seen in the organizations you've worked with. If you could just blanket, have one thing fixed before they start working with you, or one thing that they were in alignment with that would really give them a boost in their scaling before they start working with you, what would that be? What would be the thing that you think is most often missing in organizations before you work with them? Tess Thompson (26:33) Getting their goals, their strategy and starting to build out their backlog. based on those priorities. In fact, I usually do ask that. Start thinking about what are really your goals? What's your strategy to get there? And what kind of things are you doing to get there? What products are you creating? What services are you What projects you're creating for those products? Start thinking about that and start being a list together. And then when I get there, I'll help organize the list if you don't have it. But it's just starting to think about that ahead of time. Because what I see is leaders or people have multiple lists. They have a list over here of their projects. They have a list over here of stuff they're doing. They have all their emails that are coming in, their chats that are coming in, the phone that's coming in. And it's like, can we get it all kind of in one place so we can really look at it to make better decisions on really where we should be spending our time and our money? Brian (27:14) Yeah. Yeah, yeah, that's a great point. A friend of mine, David Hawks, used to say that organizations are swimming in a sea of opportunity. There's all these different things we could do and really trying to limit that scope and say, yeah, we could do all these things, but what makes the most sense for us to do? What's the most valuable thing for us to do? Tess Thompson (27:58) Yep, absolutely. And getting in touch with and constant feedback with your customer helps you figure that out. So many companies don't even, the people are like, have no, I always love when I get a group and I said, hey, let's name our customers. And they're sort of out of the line on who their customer is. Brian (28:19) Right, and if you don't know who it is you're trying to serve, how do you serve them? Yeah. Tess Thompson (28:25) Yeah, yeah. That's usually one of the first things I ask is, hey, who's your customer? Is it the shareholder? Is it this? Is it that? Let's agree. Yes, you will have multiple customers. Let's get it together and understand who are our customers. Let's all agree on that. Maybe even a priority on some of those customers to some degree. Brian (28:30) You Right, love that. Right. Yeah, yeah, this has been great. Well, I really appreciate you taking time out, Dr. Thompson, for coming on and helping us and to see things from your perspective. It's so great to talk to people that are, know, not just, you know, this isn't just theory or book learning. You're actually out there, you know, doing these in these large scale organizations and, you know, hearing from you what those real world problems are that you're seeing on a day to day basis. Tess Thompson (29:18) And I'm having amazing, amazing results. tell you, I'm, that's why I only had three hours of sleep last night and I'm still. Brian (29:27) Ha ha. Tess Thompson (29:28) woke up full of joy to be here with you today is I love what I do because I'm constantly getting phone calls after the factor during it and it's like, wow, this stuff really works. I'm like, yeah, it does. It really does. Brian (29:41) Amazing when that happens. Awesome. Well, thank you so much for coming on and I just appreciate you sharing your wisdom with us. Tess Thompson (29:53) Anytime. Thank you for having me.

Join Brian Milner and McCaul Baggett as they explore the power of empathy and storytelling in successful Agile transformations. Learn McCaul's five-step approach to effective communication and discover strategies to overcome common pitfalls in organizational change. Overview In this episode of the Agile Mentors Podcast, Brian Milner sits down with McCaul Baggett, Chief Agile Officer at CAVU, to discuss the intricacies of communicating change within organizations. They delve into common pitfalls in Agile transformations and highlight the importance of empathy and storytelling in engaging teams. McCaul shares his five-step approach to effective communication, emphasizing the power of testimonials and spreading awareness. Tune in to gain valuable insights and practical tools for navigating and leading successful Agile transformations. Listen Now to Discover: [1:10] - Join Brian as he welcomes McCaul Baggett, Chief Agile Officer at CAVU and a master of Agile transformation, to delve into the secrets of successful Agile transformation. [3:15] - McCaul emphasizes the critical role of storytelling in engaging and guiding teams through the process of Agile transformation. [5:57] - Brian addresses a common challenge in Agile transformations: navigating the unknown and its impact on team dynamics. [8:01] - McCaul explains how effective communication and a compelling narrative can help teams grasp their value during a transformation. [10:40] - McCaul advocates for going beyond the basic 'why' by incorporating testimonial narratives to create more meaningful connections. [14:39] - Brian suggests using these tools to foster empathy, advocating for their use in both top-down and bottom-up approaches when initiating a transformation. [16:29] - Dive into Mike Cohn's book, Succeeding with Agile, for practical advice on navigating your transformation. Discover strategies for communication, overcoming resistance, and other key aspects of Agile success. [17:54] - Brian inquires about effective ways to connect with and engage resistant individuals within the team. [22:49] - Join McCaul and Brian as they discuss the importance of creating specific best practices that suit the unique needs of this particular team and organization. [28:07] - Brian shares a big thank you to McCaul for joining him on the show. [28:33] - Join Brian in attending Agile conferences to connect with and learn from Agile experts and peers, fostering valuable discussions and insights. [29:53] - If you’d like to continue this discussion, join the Agile Mentors Community. You get a year of free membership into that site by taking any class with Mountain Goat Software, such as CSM or CSPO. We'd love to see you in one of Mountain Goat Software's classes, you can find the schedule here. [30:35] - We invite you to subscribe to the Agile Mentors Podcast. Do you have feedback or a great idea for an episode of the show? Great! Just send us an email. References and resources mentioned in the show: McCaul Baggett Communicating Change Made Easy with McCaul Bagget and Tom Bullock Succeeding with Agile by Mike Cohn Agile 2024 Subscribe to the Agile Mentors Podcast Certified ScrumMaster® Training and Scrum Certification Certified Scrum Product Owner® Training Mountain Goat Software Certified Scrum and Agile Training Schedule Join the Agile Mentors Community Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. McCaul Baggett is the Chief Agile Officer at CAVU, specializing in Agile transformations and effective communication strategies. With a focus on empathy, storytelling, and practical tools, McCaul helps organizations navigate change and foster sustainable Agile practices. Auto-generated Transcript: Brian (00:00) Welcome in Agile Mentors, we're back. This is another episode of the Agile Mentors podcast. I'm with you as always, Brian Milner. And today I have the one and only Mr. McCaul Baggett with us. Welcome in McCaul. McCaul Baggett (00:13) Hey, thanks Brian, really glad to be here. Brian (00:15) Very excited to have you. For those who aren't familiar with McCaul, McCaul is the chief agile officer at Cavu. He has been working in transformations for quite a long time doing some large-scale transformations at different organizations. One that he is allowed to publicly mention is John Deere, but there's others that he's been a part of as well. You know companies are funny that way. They don't always necessarily want you to publicize things for some reasons. I don't know why. McCaul Baggett (00:43) Yeah. Brian (00:44) We were joking about that earlier. But I wanted to have him call on because we were both at the Agile 2023 conference, and I saw him on the agenda, and it was one of those sessions I didn't get a chance to go to, unfortunately, but really thought it was an interesting topic. I wanted to have him come on and kind of chat with us a little bit about this. So his topic was about communicating change and communicating change in an easy way, you know, kind of making that an easy process. So let me start there with you, McCaul, on this is, what do people get wrong when they're going through a transformation and we make the decision to go through a big change in our organization? What are some of the common pitfalls organizations fall into when they make that decision? McCaul Baggett (01:34) Well, let me start by saying it wasn't me solely that was doing the talk. I did have some partners there with me. And if you look it up, you should definitely speak to them as well or look them up as well. Dana Dismukes is a transformation lead for Dell. Tom Bullock is the chief storyteller for Scrum Inc. And really the academics of the talk came out of Tom's brainchild. But through my work, I got a chance to apply it. And it was precisely because of this very issue, the ch- the- non-working approach that many organizations take to communicating about change. There's a tendency in a lot of change management structures to discuss the need for communication, but as Agilists, we don't inherently do a lot of study of the nature of communication. And so I would say probably the biggest, most common error that people in a transformation of any kind and most close to my experience in Agile transformations make in communicating about change is going about it from a way that is, from the perspective of trying to reassure their teams, their departments that this is something that has leadership endorsement by communicating from the top down. I mean, please forgive the hierarchical metaphor, but getting some senior leader to say, hey, this is gonna be great, you can do it, we're gonna do this. When in fact, the most effective way to communicate to someone, especially someone who's not fully bought in, is by telling them a story of someone who is like them, has experience like them that they can relate to. And that storytelling perspective is what we talk about in this talk, Communicating Change, maybe. Brian (03:16) Yeah, there's a lot just in there to unpack. I mean, just the idea, thinking about, I've talked with a lot of organizations and a lot of people have come through classes and stuff that I've talked with who are going through changes like this, but then they're not really even sure how much their leaders are on board with this. They just, they have some layer of management who says, yeah, this is what we're gonna do, but do the people at the top really feel that way? Do they even know what it is that we're doing? McCaul Baggett (03:34) Sure. I mean, that's even tougher. I would find it hard to even consider it a true transformation if you can't be sure your leaders are bought into it. But you're not wrong. It is stunning how often you get these folks that you run into and they say, my leadership may be willing to do this. I teach a lot of Scrum at Scale. And so we talk a lot about executive Metascrums and executive action teams and prescriptions about how involved the leader should be. And people will sort of stop and say, wait, you want a leader to meet about team obstacles every day? And I say, yeah, or however long those executives are willing to let their teams go without support to removing their obstacles. Like, what is it that they're doing that's more important than clearing the impediments for their teams? But that does tend to be the perspective is, I don't know if my leaders even bought into this change. That's tough. Brian (04:34) Yeah. Yeah, it is. And I think that speaks to some of the fundamental flaws, I think, that people have with transformations before you even get to communicating, right? Just do we know why we're here? Do we know what it is we're trying to do? Those kinds of things. I like to focus on the communication, though, here because communication is such a McCaul Baggett (04:46) Yeah, that's true. Brian (04:56) delicate beast. I mean, it just, you know, when you're trying to speak with another human, even if it's just within your team, you know, it's difficult because we're different personalities and we have different backgrounds and everything else, much less when you're talking about it over an entire organization. I would imagine, and you, I mean, correct me if I'm wrong on this, but I would imagine that one of the biggest sources of kind of consternation or, you know, anxiety I think when these kinds of things happen is the unknown, just not really understanding how do I fit in and what does this mean for me. McCaul Baggett (05:33) Yeah, I think you're absolutely right. Sometimes it's phrased that it's termed what's in it for me. And I think that's the wrong perspective to take. People aren't often necessarily, people are not always looking for some kind of payoff for the transformation. They don't need to know sort of what they get out of it. But I think that you really put your finger on a lot of the reason that we see trepidation with a transformation is because it implies that Brian (05:38) Mmm. McCaul Baggett (06:00) Business as it had been occurring before was not acceptable. What you'd been doing previously was not good enough. And now we need to get you to do it another way. That inherently sort of fundamentally starts with a position of questioning whether or not your position is stable. And that gets, you get some amygdala hijack stuff going on. You get the brain started worrying about existence, not just change. So you're right, contextualizing. Brian (06:26) Yeah. McCaul Baggett (06:29) your communication about this is really important. And I think taking a perspective of empathy and meeting especially resistance in a change environment, a changing environment, meeting resistance with an attempt to understand the perspective really fundamentally underpins any successful communication you're gonna have about change management in general, but communication in particular. Brian (06:52) What do you think about that, McCaul? I mean, if you're a leader in that kind of organization and you recognize this and you see, people are gonna, I'm gonna send people into a little bit of a panic, right? Because you're right, there's no way that I can hear that message, hey, we're gonna do things differently than the way that we've been doing them without kind of self-internalizing, well, that means that something I've been doing has not been acceptable, it's not been good enough, it's not been what the organization needs. How do you communicate that in a way to say, no, it's not you, right? It's kind of a process thing. It's not that you did anything wrong. It's that we found this is a better way of working. McCaul Baggett (07:30) Yeah, so I think starting with that fundamental basis of why this is occurring is really key. But even before you get to the communication about why, it's really important to figure out who it is you're speaking to. So going back to that sort of, that empathy piece, there is a need to get that communication about, okay, it's not that you did anything wrong. and here are the reasons why we're doing it, that is the message we're looking to communicate. But at a communication level, like understanding even how to begin that communication really requires us to take a step back so that we can consider the people we're telling that story to. So just to connect this to the topic that actually came up in the talk about how we do that communication, it's really fundamentally about, and just a quick aside about that talk. So in the Agile 2023 conference, we actually applied for a longer workshop, like 120 minutes, 160 minutes, one of the long time boxes. And they'd come back to us and said, why don't you do one of these 30-minute segments? So we really pared down a lot of the things that we wanted to say. And so to connect back to what really, what emerged was actually, it was actually probably a better talk than if we'd had a longer period of time to do it. We just, we had to cut everything until we could come back with just, Brian (08:36) Yeah. Hahaha. Mm. McCaul Baggett (08:58) the real good nuggets. And what stayed was this. In order to communicate effectively when you're going through any kind of change management process, first of all, having a change management process and a plan for how you're gonna manage that, that's your beginning. But to get a little bit more particular about how we communicate about that change, there is one technique which we agreed was probably the thing to focus on so that it would be most universally helpful. in any stage of a transformation that was going on. And that was creating a, finding a way to create a narrative, a personal narrative that could connect to the various people that you're trying to connect to, right? So to create a testimonial. And so we spent our time in that talk discussing how to really get a useful testimonial. And then once you've... got that how to do something useful with it. And we outline kind of five steps for how to think about this. Brian, tell me if I'm getting too deep or you kind of want to... Okay, cool. And I don't know that these are the only five steps. We try to make it easy to remember. The takeaways that we were trying to give were, you have to be first thoughtful about what it takes to make a compelling testimonial. So this is where I mean, you can't start with why. Brian (10:00) No, no, this is awesome. Go for it. McCaul Baggett (10:21) we're doing this, you have to start with who you're speaking to about why. Because the why shifts. If you're speaking to stakeholders, there's one why. And if you're speaking to the organization, to your employees, to the people that are doing the work, it's not that the why is different, but the way that you talk about it may be different. So once you know what it's going to take to make the testimonial, the next step would be to think about how you can work. how you can set yourself up ahead of time to maximize the potential to make an impact with your audience, to plan. how you're gonna get the story, the testimonial that's gonna resonate. Which is the story that I wanna tell? So fundamentally what we're doing here is we're assuming that, testimonial, this is only one way to communicate, but it's a fairly useful one universally. If you're going to try to get that testimonial, what are the questions that are gonna be useful to the who that you've identified ahead of time? What is the story you need to find to tell? Then step three is actually. having the conversation. So you've already done a lot of pre-work ahead of time before you even begin the process of the discussion. And then once you've started the discussion, once you've got it, using that testimonial, which is typically recorded kind of like this, grounding that in a way that doesn't sound overly positive and really connects with reality, and then using what you've got to spread that awareness as broadly as possible. So five steps. Know, think, get. ground and grow. I don't know if that's a useful mnemonic of any kind, but that's what we came up with. Brian (11:59) That's awesome. No, like I said, easy to remember. Just a few things to kind of keep in mind there. Yeah, I love the concept of telling it as a story, that we're not just, because that makes it much easier for me to see myself then fitting in there. Like we talked about earlier, right? If I have a fear of, oh my gosh, does this mean that I'm gonna lose my job? Does this mean that I'm gonna have to... McCaul Baggett (12:03) Yeah, just five steps. Brian (12:24) now do something that's very different from what I've been trained for or what I'm used to doing or what I wanna do as a career, telling it as a story can kind of allow me to see myself in the story. McCaul Baggett (12:37) You are exactly right. Not only does it allow you to do that, we as humans are wired to do that very thing. We do it all the time. In fact, when you're listening to a podcast like this, you'll often sort of have the sense that you're sitting at the table, thinking through, like you're literally exercising pathways in your brain as if you were participating in the conversation. And that direct involvement allows you to mitigate some of the inherent resistance that you. that you find, that amygdala hijack, that fight or flight response is not present because you're following along in a story, hopefully about a successful element of the transformation. So you really engage that piece right from the very beginning. Brian (13:20) Yeah, I love this and understand to the listeners as well, right? I mean, we're speaking at like a neuroscience level here and trying to understand that, you know, the preparation that needs to be made so that, uh, like McCaul is saying, there's not that amygdala hijack going on of just saying, uh, oh my gosh, I'm panicked. I can't get past this panic. Uh, you know, in my, that's going on in my head that has to be stripped away. That has to be. resolved so that now I can start to learn, now I can start to see and form, like you said, the new pathways. And that is, you know, physically what's going on. We're forming new connections in our brain to say, oh, I've never seen it this way, but let me try to make this connection and see it a different way. McCaul Baggett (14:10) Yeah, not only is it important to do that, we as humans, now I'm stepping a little far beyond my training, so I'll be careful. My understanding is that fight or flight response really lives in an entirely different system, in the limbic system of the brain, much earlier part of the brain. And in order to engage the neocortex at all, or in any significant way to create those Brian (14:21) Ha ha ha. McCaul Baggett (14:39) pathways to be able to see a perspective of the other than our own, we have to kind of dampen that limbic response, that fight or flight. Will I, won't I have a means to feed myself beyond this space? Am I safe before we can start to begin that conversation, to begin that connection with someone we want to connect to? Brian (14:59) Absolutely. And I think this applies not only, I mean, we started in kind of approaching this from sort of a high level top down, like you said earlier. But I think it applies even if you're a Scrum Master, or maybe you're part of a small group in the organization. Maybe you are in an organization that's not agile in any way, but you've gotten permission to have a pilot, to just have a pilot team. McCaul Baggett (15:08) Sure. Brian (15:28) and your desire is to grow this in the organization, or maybe they're doing it poorly and you wanted to have one pilot team that does it the right way so you can start to spread this out to other places. All this applies, I think, to you as well because you're gonna be communicating this and you're gonna encounter the same resistances, right? You're gonna have the same kind of skepticism. You're gonna have the same kind of possibility have someone have amygdala hijacks going on thinking, Oh my God, what's this guy doing? What's this woman doing? Why is she trying to make these big changes in the organization? Is she gonna try to change my job? Yeah, am I under threat? So while we started top down, I think it applies bottom up as well. They're all principles I think we have to think through before we even start to try to communicate with this. McCaul Baggett (16:05) Yeah, am I under threat? Oh, absolutely. I mean, any good scrum master is gonna be thinking and hopefully practicing their ability to deal with any tense conversation. And so that limbic engagement, that epinephrine and adrenaline start coursing through the brain. And you can see it in many people when you're looking at group dynamics, regardless of large or small group dynamics, but any group. that shutdown of the ability to really process new information and assimilate it, you have to start by working past the threat. You have to get people beyond that sort of defensive place before the conversation can even begin. Yeah, I agree. Brian (17:01) Yeah, yeah. Awesome. Well, in how we're talking about this, I kind of had this one scenario in mind I wanted to kind of run by you because I know I've encountered this before. I know, you know, I've encountered this in classes before. So I'm curious kind of how this communication approach would kind of adjust for this kind of individual. But what about the person who just sort of is crossing their arms McCaul Baggett (17:11) Sure, hit me. Brian (17:28) And they kind of take the approach of, ah, this is a fad. It's not so much as an active, hey, I'm gonna really counteract you and go against you to try to dispreview, but I'm just gonna, you know, I'm not budging. I'm gonna stay here, because I know this is a fad and it's gonna change eventually back to the way I wanna do things. So you do whatever you wanna do, but you know, I'm not gonna get on board with you because. I've seen lots of things come and go on this is just another McCaul Baggett (17:59) I think that takes a couple of forms. Certainly some of those, and particularly when I've been asked by an organization to come and do training, you get a lot more of those because, nope, they didn't raise their hand to come and join a public class or something. I think there's really two significant flavors of that engagement. One is, as you described, someone who's just sort of like passively waiting for this to sort of blow on by. And that's a lot more tricky than the one that's actively pushing back. By far, I prefer someone who's willing to stand up and say, this is not going to work here and here are the reasons why. Because to come into the space of someone who is not choosing that engagement is inherently threatening. So you've picked a very challenging person to get through to, um, because directly calling them out and being like, Hey, Brian, you've been really quiet. What do you think of what's going on? when they were not inclined to share that, sort of already starts to engage that, am I prepared to risk saying out loud what I think is gonna happen? And it also, it could inherit, it could just by the nature of asking them to speak out loud that they don't believe in what's going on around them, sets them apart from the rest of the group and could mean that makes them something of a target if they don't feel like their culture is a safe place to speak. So, That is your problem Often I have found that a testimonial based approach, one where you can tell someone's stories about someone in a similar position, not stories about why this is going to work from a leadership position, but a testimonial based communication campaign is one of the best ways to reach folks just like this. You don't need to directly address them. You don't need to confront them. It's fine. If you're not, if you're not buying this, that's okay. Why don't I tell you about where it's happened elsewhere? And frankly, that thing is one of the things that training in person used to be so great for, because you could stand away and kind of watch these people who weren't necessarily bought in, sit back and just study what was going on in front of them. It wasn't being forced on them. They could just sort of watch their teams and you'd do something silly like. Brian (19:58) Yeah. McCaul Baggett (20:17) play any number of the Agile games that are meant to demonstrate things like small batch processing or teaming, right? Team dynamics and that joy that human collaboration and competition can bring in a really small scale in a very short amount of time and like a magic trick you could be like was that fun? Was folding these paper airplanes and throwing them across the room fun? And they'd be like yeah it was fun it's paper airplanes whatever I'm not working and then you could take a step back and say okay Was it fun because you just love folding paper airplanes or was it fun because you were making connections with people that you don't get to do in your daily job? And just sort of, again, the story here is, look what's over there. Look what this says about the nature of communication. It's not testimonial based per se, but it is lighting that fire, that inspiration that I always loved about training. And it's not just in person, but it really... I do miss that about in-person training because you could really connect really well. Brian (21:19) Yeah, I mean, we're talking about communication in general and we can't escape the Agile Manifesto comment about it. It's best done in person face to face, right? So it doesn't mean you can't in another way, it just means it's best that way and it works easiest that way, right? Yeah, I completely agree. Yeah, I just wanted to just, go ahead. McCaul Baggett (21:28) That's right. That's right. I'm sorry. Not to go too far off topic, though, but to that very point, we see this request of many executives later, the return to the office movement being another form of, is that the best way to communicate? Yeah, it is. Is it the only way to communicate? Should we be seeking that to the detriment of our work forces at scale? And there are many reasons that people are choosing to encourage their. employees to come back to the office. But I think part of that is because leadership is also far easier in person. So we're missing some opportunities for leadership to understand how to lead remote teams and may have caused that sort of same challenge. Anyway, another topic. Brian (22:23) No, no, I agree. And I think that part of that as well is just kind of the general whole. I've talked about this a couple of times in the podcast where we, we seem to be stuck in a cycle of trying to find out what is the way to do something versus what is the way for this team, for this organization to do something. There's lots of data out there that we can get, can inform us. Just like if I'm a product owner. There's lots of data that can inform me about the market, but ultimately I've got to make the call about what's right for us to do next. Same thing with the organization, same thing with the team. What's going to work in this instance? McCaul Baggett (23:03) Absolutely. It's probably one of the biggest challenges that I think, uh, when we see transformations, not even transformations, when we see an agile, um, enthusiast really go off track and good. I did it for sure when I was a new scrum master. Like this is how the scrum guide says we're supposed to do things and we're not doing these particular things. We need to do scrum the right way. that sort of the willingness to take a step back and say, well, there are a lot of better practices. Is there a best practice in our case that is true? Actually, the challenge is not, is there a better practice in all cases? And almost certainly not, but there may be a better practice in our case, even a best practice in our case, but you have to be willing to let go of the dogma of this is the way it's meant to be, and instead seeking, seeking to be informed by these, yes, science-based studied practices. It is better to be in person, but let's not fire all our remote employees. Let's, let's figure out another way or let's make teams that can figure out other ways to do it. Brian (24:11) Yeah, absolutely. Yeah, we're in an interesting time, I think, as far as that's concerned, because like you said, it's the dogma, I think, of pragmatism and what's gonna work best in this scenario. Yeah, I struggle a lot in classes, even, when people will bring up certain topics, to ever say always, that this is always, it should always be this way. McCaul Baggett (24:22) Yes. Yes. Brian (24:36) Because I don't know, I frequently will say things like, my experience has been, what I have seen is this, but that's just my experience. And that's a limited set of experiences. You have to line that up against what you've experienced and what your organization is going through and say, hey, does this sound similar? Are we seeing those same things? Are we not seeing those same things? There are best practices. There are some things that we could say, yes, this... And a lot of situations will work best in this way, but not all. And that's where it takes experience. That's where it takes somebody who's been there before to know. McCaul Baggett (25:16) Well, yeah, and a lot of this grew up in a very particular environment, right? So Agile practices, many of the ones that we've adopted, grew up through software, and through software in North America. So one of the things that I've been passionate about, and one of the reasons that I've pursued the career that I have is because a lot of the Agile community looks like you and me, right? So if you take into account not only are these the, quote, Brian (25:29) Ha ha. McCaul Baggett (25:43) but it's for teams that tend to look like you and me, tend to live in North America, and tend to be working on software. And that's such a narrow area that we're foolish to assume that such a thing as best practices have been codified yet. Brian (25:58) Yeah, no, and please, for the listeners, don't get me wrong because if you listen to the show, you know I'm a geek for the data. And I love being able to have really hard scientific data that you can look at and say, hey, studies show that this is how you do this, but you gotta be cautious about asking, was that a rigorous scientific actual study or was this just an internet sampling? McCaul Baggett (26:13) Yes. Brian (26:26) That's not a scientific study. That's just kind of gathering people together and saying, hey, if this group of people who choose to respond to this, what do they think about something versus something else? But you're absolutely right. You have to understand the basis of where this comes from. And the basis of where we get a lot of our stuff is people who look like you and me, who have been working in the software industry for kind of the time we've been working in the software industry. So things have changed. McCaul Baggett (26:50) Yeah. Brian (26:53) cultures change, cultures bring different dynamics into things. And what works for my team of five, six developers based here in Dallas, Texas, is going to be very different from my team that I have five people in India and three people here, or even all the team is in India, or all the team is in Malaysia, or all the team is in Saudi Arabia or Ireland. I've worked with teams all over Israel. McCaul Baggett (27:09) Yes. Brian (27:23) You work with teams in different cultures and you have to understand what the playbook I used for that last team ain't gonna work for this next one because they're different people. McCaul Baggett (27:32) I heard the term coined radical pragmatism. It was, JJ Sutherland said it. And it was, it is precisely what we should be shooting for. Radical pragmatism informed by the best data, informed by the best science, and then immediately thrown away when it's not applicable to the situation we're in. Yes, these are the ladder, the rungs, the steps to head in the direction we need to be headed, probably, but let's evaluate them for ourselves and reevaluate. Brian (28:02) Yeah, if you're gonna go buy a car, you're gonna do your research, you're gonna figure out what gets the best gas mileage, blah, right, all this stuff. But then you're gonna get on the line, you're gonna test drive and go, I just like the way this feels. Ha, ha, ha. McCaul Baggett (28:12) That's right, test drive the car, yes, for sure. Brian (28:16) Awesome. Well, this has been a great conversation. I really have enjoyed having you on, McCaul. And yeah, thank you for kind of sharing kind of some of the wisdom in there from the talk. I know we, you know, the talk was not long and we have not long to kind of dissect stuff here in our podcast, but I appreciate you making time to share with us. McCaul Baggett (28:36) Absolutely, Brian, this is a pleasure. And if you ever need somebody to shoot the breeze with again, give me a call. Brian (28:42) I will take you up on that. McCaul Baggett (28:43) Thanks.

Bio Dr. Jeff Sutherland is the inventor and co-creator of Scrum, the most widely used Agile framework across the globe.  Originally used for software development, Jeff has also pioneered the application of the framework to multiple industries and disciplines. Today, Scrum is applied to solve complex projects in start-ups and Fortune 100 companies. Scrum companies consistently respond to market demand, to get results and drive performance at speeds they never thought possible. Jeff is committed to developing the Agile leadership practices that allow Scrum to scale across an enterprise.   Dr. Sutherland is the chairman and founder of Scrum Inc. He is a signatory of the Agile manifesto and coauthor of the Scrum Guide and the creator Scrum@Scale. Jeff continues to teach, create new curriculum in the Agile Education Program and share best practices with organizations around the globe. He is the founder of Scrum Inc. and coauthor of, Scrum: The Art of Doing Twice the Work in Half the Time, that has sold over 100,000 copies worldwide.    Social Media:                 LinkedIn: linkedin.com/in/jeffsutherland                 Twitter: @jeffsutherland Website: Scrum Inc https://scruminc.com               Books/ Articles: The Scrum Guide by Jeff Sutherland and Ken Schwaber http://www.scrumguides.org/index.html Scrum: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland The Scrum Fieldbook by JJ Sutherland Agile Competitors and Virtual Organisations by Steven Goldman, Roger Nagel and Kenneth Preiss https://www.amazon.co.uk/Agile-Competitors-Virtual-Organizations-Engineering/dp/0471286508 Accelerate: Building Strategic Agility for a Faster Moving World by John P. Kotter Leading Change by John P. Kotter Process Dynamics, Modeling and Control by Babatunde A. Ogunnaike and Harmon W. Ray A Scrum Book: The Spirit of the Game by Jeff Sutherland, James Coplien, Mark den Hollander, et al    Interview Transcript Ula Ojiaku: Hello everyone, my guest today is Dr Jeff Sutherland. He is the inventor and co-creator of Scrum, the most widely used Agile Framework across the globe. Originally used for Software Development, Jeff has also pioneered the application of the framework to multiple industries and disciplines. Today, Scrum is applied to deliver complex projects in startups and Fortune 100 companies. Dr Jeff Sutherland is the Chairman and Founder of Scrum Inc. He is a signatory of the Agile Manifesto and co-author of the Scrum Guide and the creator of Scrum at Scale. Jeff continues to teach, create new curriculum in the Agile education programme and share best practices with organisations around the globe. He has authored and co-authored a number of books which include Scrum: The Art of Doing Twice the Work in Half the Time – which has sold over 100,000 copies worldwide. In this episode, Dr Sutherland shares the backstory of how he and Ken Schwaber developed the Scrum framework. I was pleasantly surprised and proud to learn that one of the inspirations behind the current Scrum framework we now have was the work of Prof Babatunde Ogunnike, given my Nigerian heritage. Dr Sutherland also talked about the importance of Agile Leadership and his current focus on helping organisations fix bad Scrum implementations. I'm sure you'll uncover some useful nuggets in this episode. Without further ado, ladies and gentlemen, my conversation with Dr Sutherland.   Ula Ojiaku: Thank you, Dr. Sutherland, for joining us on the Agile Innovation Leaders podcast. It's a great pleasure to have you here. Jeff Sutherland: Glad to be here. Looking forward to it. Ula Ojiaku: Fantastic. So could you tell us about yourself? Jeff Sutherland: Well, I grew up in a small town in Massachusetts. And I always felt that I would go to West Point of the United States Military Academy, even at a very young age. And I finally made it there. I spent four years there. And I went on to a program where a certain number of cadets could join the Air Force. And I told the Air Force, if they made me a fighter pilot, I would move into the Air Force, which I did. I spent 11 years as a fighter pilot in the Air Force. And most of the operational aspects of Scrum actually come from that training. My last tour in the Air Force was actually at the US Air Force Academy, I was a professor of mathematics. And I had gone to Stanford University in preparation for that position. And I had worked closely with the, at the time he was Head of the Department of Psychiatry, became the Dean of Stanford who had studied under my father-in-law, he had become an MD under my father-in-law, who was a brilliant physician. And I was working on research papers with him, both at Stanford and at the Air Force Academy. And I asked him for guidance. And I said, I'm thinking about, given all the work we've done in the medical area. Starting in Stanford, I'm thinking maybe becoming a doctor - become an MD. And he strongly recommended against that he said, ‘you'll just go backwards in your career, what you need to do is you build on everything you've done so far. And what you have is your fighter pilot experience, your experience as a statistician, and a mathematician, you want to build on that.' So, I had already started into a doctoral program at the University of Colorado School of Medicine, which was not far from the Air Force Academy. And so, I talked to my department Chairman there who offered me a position in the department running a large research grant, funded by the National Cancer Institute and so, I decided to exit the Airforce and join the medical school. While I was finishing up my doctoral degree. And as soon as my doctorate was finished, I became a professor of Radiology, preventive medicine and biometrics. I was a joint across multiple departments. And I was doing mathematical research on modeling, particularly the human cell on a supercomputer, (to) determine what caused cancer. And to do that required extensive mathematical research as well as the medical research. But at the end of the day, what we found was for any complex adaptive system, like a human cell, or a person or a team, they go through different states. And they're moved from one state to the next by some kind of intervention. And so, if you understand what causes those changes… turned out in the case of cancer, there were four different states that led to a tumor. And in every state, there were certain interventions, and if you knew what they were, you could prevent them and prevent cancer. Or you could even, to my surprise, take a cancer cell and make it go backward into a normal cell. So, this fundamental understanding is the theory behind Scrum. So, while I'm doing this all at the medical school, a large banking company came by and said, ‘you know, over the medical school, you guys have all the knowledge about the technologies; the new technology, we're using (for) banking, you're using for research.' And they said, ‘you guys have all the knowledge but we have all the money and they made me an offer to come join the bank'    Ula Ojiaku: [Laughs]You couldn't refuse Jeff Sutherland: Not just me, it was my family. So, I wind up as Vice President for Advanced Systems, which was effectively was the CTO for 150 banks that we were running across North America.   Each was, you know, a dozen, 50, 100 branches. And of course, we were mainly doing the software, installation and support to run the banking operation, which is largely computer stuff – (this) is what banks run off. And as we're building these systems with hundreds and hundreds of developers, one of the first things I noticed is that all the projects were late. And I look at what they're doing. And they're using this process where they spend, you know, six months defining requirements, and then they put all the requirements into a Gantt chart. And then they, they plan on taking six months to build something, but it's never done. Because as soon as they start testing that they find there's all kinds of things that are broken. So, virtually every single project of the bank is late. So, as a head of technology, one day I walked into the CEO's office and I said, ‘Ron,  have you noticed all your projects are late?' He said, ‘Yes'. He says, ‘Every morning at least five CIOs or CEOs of the banks, they call me up.' And he says, ‘they scream at me.' I said, ‘wow', I said, ‘You know, it's going to get worse, not better. Because these guys are using this, these Gantt Charts.' And I showed him one. And then being a mathematician, I mathematically proved that every project would be late at the bank. And he was stunned. And he said, ‘what should I do?' I said, ‘we need a completely different operating system in the bank.' This is back in 1983. ‘Let's take one business unit. Let's take the one that's losing the most money, okay, the worst business unit' Ula Ojiaku: They have nothing to lose then. Jeff Sutherland: And it was the automated teller division that was rolling out cash machines all over North America. It was a new technology and they had a ton of problems. So, I said, ‘let's take that unit and every one, sales, market, support, installation, we're going to split them down into small teams. And we're going to have Product Marketing come in on Monday with a backlog prioritized by business value. And at the end of the week, on Friday, we're going to deploy to 150 banks.' ‘And I'm going to train them how to land a project every week, just like I trained fighter pilots to land aircraft. I'm going to give them a burndown chart, we're going to throw away the Gantt Chart, I'm going to give them a burndown chart to show them how to land the project.' So, he said, ‘Well, that's gonna be a big headache.' I said, ‘look, the bank needs to be fixed.' He said, ‘Okay, you got it.' So, I took that unit. I told them, ‘I know it's gonna take several weeks,' today we call them sprints, ‘for you to be successful.' Because as new pilots, trained to land, these high-performance jets, they tend to come in high and then they have to come around and try to land again, they over and over, they practice until they can nail it. And it took them six weeks, six sprints to actually nail the end of the week (and) deploy (to) 150 banks. But within six months, it became… it went from the worst business unit in the bank to the most profitable business unit in the bank. And the senior management said, ‘you know, Jeff, here's another 20 million dollars to throw at whatever that thing you're doing  it's the most profitable thing in the bank, we're gonna put more money in that. So that was the first prototype of what we call today Scrum at Scale. Now, I've been CTO of 11, or CTO or CEO of 11 different companies. And for the next 10 years, I prototyped that model and advanced technology teams until in 1993, at a company called Easel Corporation, we found that because of the tooling we were building and selling to customers, we needed to build the tool with what today we call Agile Practice. Ula Ojiaku: Yes Jeff Sutherland: And we need to train the customer to use the tool by having teams do an agile practice. So, in order to train our customers properly in 1993, we actually had to formalize what I've been prototyping for 10 years. And we wrote it down and at the time we were reading this paper, we're going through 1000 papers in the journals I, you know, I had done many new technology. And, in every one of them, you have to read everything that's ever been done so that you can go beyond. You can use everything that's been done, but then you go beyond, okay? Ula Ojiaku: Yeah Jeff Sutherland:  So, it's a tremendous amount of research to launch new technology. And at about the 300th paper in our file, it was a paper out of the Harvard Business Review, which really surprised me, by two Japanese Business School professors, Professors Takeuchi and Nonaka. And in there, they described the best teams in the world. They were lean hardware teams that reminded them of a game of rugby, they said, ‘we're going to call what they're doing Scrum Project Management.' So, I said to the team, ‘we need a name for this thing that we're going to train our customers in, and let's call it Scrum.' And off we went. So, for the next two years, we were actually using Scrum within Easel deploying products. But it was not public, to the general industry. And Easel got acquired by a larger company. And at that time, I felt that this needed to be rolled out into the industry because we had benchmarked it with the best tooling in the world from the leading productivity company, and showed that it was… that (it) went 10 times faster. The quality was 10 times better, which is what you need for a new technology innovation. And so, I felt it was ready to go to the industry as a whole. So, I called up an old friend, Ken Schwaber. And he was a CEO of a traditional Project Management software company, a waterfall (methodology). He sold these methodologies with 303 ring binders, a software package that would make Gantt Charts. So, I said, ‘Ken, I want you to come up and see the Scrum, because it actually works and that stuff you're selling doesn't work – it makes projects late.' And he agreed to come in, he actually came up, he met with me. He stayed for two weeks inside the company, working, observing the Scrum team. And at the end of those two weeks, he said, ‘Jeff, you're right. This really works - it's pretty much the way I run my company.' He said, ‘if I ran my company with a Gantt Chart, we would have been bankrupt a long time ago.' So, I said, ‘well, why don't you sell something to work that works instead of inflicting more damage on the industry?' So, he said so we said ‘okay, how (do) we do it?' I said, ‘it needs to be open source, it needs to be free.' Ken felt we needed to take the engineering practices, many of which appear today in extreme programming… Ula Ojiaku: Yes Jeff Sutherland: …and let Kent Beck (creator of eXtreme Programming, XP) run with them because Kent had been sending me emails, ‘Jeff, send me every...', he had been following the development of Scrum, ‘…send me everything on Scrum, I'm building a new process. I want to use anything that you've done before and not try to reinvent anything.' So, he (Ken Schwaber) said, ‘let Kent take the engineering practices, we'll focus on the team process itself.' And we agreed to write the first paper on this to present at a big conference later that year. And writing that paper was quite interesting. Ken visited DuPont Chemical Corporation, the leading Chemical Process Engineers there that they had hired out of academia to stop chemical plants from blowing up. And when Ken met with them, they said, describe what we were doing in the software domain. They said, ‘you know, well, that process that traditional project management is a Predictive Process Control System. We have that in the chemical industry.' ‘But it's only useful if the variation in the process running is less than 4%.' They said, ‘do you have less than 4% change in requirements while you're building software?' Ken says, ‘no, of course not! It's over 50%!' And they started laughing at him. They said, ‘your project's going to be exploding all over the place.' ‘Because every chemical plant that has blown up has been somebody applying a predictive control system to a system that has high variability. You need to completely retrain industry to use Empirical Process Control, which will stop your projects from blowing up. And they said, here it is, here's the book, they had the standard reference book for Chemical Process Engineering. And in there, there's a chapter on Empirical Process Control, which is based on transparency, inspection, and adapting to what's happening in real time. Okay, so those are the three pillars of Scrum that are today at the base of the Scrum guide. Ula Ojiaku: Do you still remember the title of the book that the chemical engineers recommended to Mr. Schwaber by any chance? Jeff Sutherland: Yeah, so I have a, when I do training, I have a slide that has a picture of the book (Process Dynamics, Modelling and Control). It's written by Ogunnaike and Ray. But that is the root of the change that's gone on in the industry. And so then from 1995, forward, Ken and I started working together, I was still CTO of companies. And I would get him to come in as a consultant and work with me. And we'd implement and enhance the Scrum implementations in company after company after company. Until 2001, of course, Scrum was expanding but Extreme Programming in 2001, was actually the most widely deployed. They were only two widely-deployed agile processes at the time of Scrum and Extreme Programming. Extreme Programming was the biggest. And so, the Agile Manifesto meeting was convened. And it had 17 people there, but three of them were Scrum guys - that had started up Scrum, implemented it in companies, four of them were the founders of Extreme Programming. And the other 10 were experts who have written books on adaptive software development or, you know, lightweight processes, so, industry experts. And we, we talked for a day and everybody explained what they were doing and there was a lot of arguments and debate. And at the end of the day, we agreed because of this book, Agile Competitors, a book about 100 hardware companies - lean hardware companies, that have taken Lean to the next level, by involving the customer in the creation of the product. And we said, ‘we think that we all need to run under one umbrella. And we should call that Agile.' Ula Ojiaku: So, did you actually use the word umbrella in your (statement)? Oh, okay. Jeff Sutherland: Often, people use that right? Ula Ojiaku: Yes, yes Jeff Sutherland: Because at the time, we had Agile and Extreme Programming, and now everybody's trying to come up with their own flavor, right?  All under the same umbrella of ‘Agile'. And that caused the both Scrum and Extreme Programming started to expand even more, and then other kinds of processes also. But Scrum rapidly began to take dominant market share, Scrum today is about 80% of what people call Agile. The reason being, number one, it was a technology that was invented and created to be 10 times better. So, it was a traditional new technology developed based on massive amounts of research. So, it worked. But number two, it also scaled it worked very well for many teams. I mean, there are many companies today like Amazon that have thousands of Scrum teams. And Extreme Programming was really more towards one team. And (reason number) three, you could distribute it across the world. So, some of the highest performing teams are actually dozens of teams or hundreds across multiple continents. And because of those three characteristics, it's (Scrum has) dominated the market. So that brings us to in 2006, I was asked by a Venture Capital firm to help them implement Scrum in their companies, they felt that Scrum was a strategic advantage for investment. And not only that, they figured out that it should be implemented everywhere they implemented it within the venture group, everybody doing Scrum. And their goal was to double their return on investment compared to any other venture capital firm. They pretty much have done that by using Scrum, but then they said, ‘Jeff, you know, we're hiring you as a consultant into our companies. And you're a CTO of a healthcare company right now. And we don't want to build a healthcare company, we want to build a Scrum company.' ‘So, why don't you create Scrum Inc. right here in the venture group? We'll support it, we'll do the administrative support. We'll write you a check - whatever you want.' So, I said, ‘well, I'm not going to take any money because I don't need it. I understand how that works. If the venture capital firm owns your company, then (in the) long term, you're essentially their slave for several years. So, I'm not taking any money. But I will create the company within the venture group. If you provide the administrative support, I'll give you 10% of the revenue and you can do all the finances and all that kind of stuff. So, that's the way Scrum Inc. was started to enable an investment firm to launch or support or invest in many dozens of Scrum companies. Ula Ojiaku: That's awesome Jeff Sutherland: And today, we're on the sixth round of investment at OpenView Venture Partners, which was the company the six round is 525 million. There's a spin out from OpenView that I'm working with, that has around this year, 25 million. And over the years, just co-investing with the venture group I have my own investment fund of 50 million. So, we have $570 million, right this year 2021 that we're putting into Scrum companies. Agile companies, preferably Scrum. Ula Ojiaku: Now when you say Scrum companies is it that they facilitate the (Scrum) training and offer consulting services in Scrum or is it that those companies operate and you know, do what they do by adopting Scrum processes? Jeff Sutherland: Today, Scrum Inc sometimes help some of those companies, but in general, those companies are independently implementing Scrum in their organizations.   Ula Ojiaku: Right Jeff Sutherland: And okay, some of them may come to Scrum training, maybe not. But since Scrum is so widely deployed in the industry, Scrum Inc, is only one of 1000 companies doing Scrum training and that sort of stuff. So, they have a wide variety, wide area of where they can get training and also many of the startups, they already know Scrum before they started the company. They are already Agile. So, what we're interested in is to find the company that understands Agile and has the right team players, particularly at the executive level, to actually execute on it. Ula Ojiaku: No matter what the product or services (are)… Jeff Sutherland: Products or services, a lot of them are software tooling companies, but some of them are way beyond that, right? So, turns out that during COVID… COVID was a watershed. The companies that were not agile, they either went bankrupt, or they were crippled. That meant all the Agile companies that could really do this, started grabbing all the market share. And so, many of our companies, their stock price was headed for the moon during COVID. While the non-agile companies were flatlined, or are going out of business, and so the year of COVID was the best business year in the history of venture capital because of Agility. So, as a result, I'm spending half my time really working, investing in companies, and half of my time, working with Scrum (Inc.) and supporting them, helping them move forward. Ula Ojiaku: That's a very impressive resume and career story really Dr. Sutherland. I have a few questions: as you were speaking, you've called Scrum in this conversation, a process, a tooling, the technology. And you know, so for some hardcore Agilists, some people will say, you know, Agile is all about the mindset for you, what would you say that Scrum is it all of these things you've called it or would it be, you know, or it's something (else)...? Jeff Sutherland: So, certainly the (Agile) mindset is important. But from an investment point of view, if the organization can't deliver real value, quickly, agile is just a bunch of nonsense. And we have a huge amount of nonsense out there. In fact, the Standish group has been publishing for decades. 58% of Agile teams are late over budget with unhappy customers. So, when you get these hardcore Agilist, that are talking about mindset, you have to figure out ‘are they in the 42% that actually can do it or are they in the 58% that are crippled?' My major work with Scrum Inc. today is to try to get to fix the bad Scrum out there. That is the biggest problem in the Agile community. People picking up pieces of things, people picking up ideas, and then putting together and then it doesn't work. That is going to that's going to be really bad for agile in the future. If 58% of it continues not to work. So, what we found, I mean, it was really interesting. Several years ago, the senior executive (of) one of the biggest Japanese companies flew to Boston wanted meet with me. And he said to me, ‘the training is not working in Japan for Scrum.' He said, ‘I spent 10 years with Google, in Silicon Valley. So, I know what it looks like what actually works. And I can tell you, it's not working in Japan, because the training is… it's not the training of the Scrum that is high performing. And in fact, our company is 20% owned by Toyota, and we are going to be the trainers of Toyota. And we cannot deliver the training that's currently being given to Toyota, it will not work, it will not fly. And we want to create a company called Scrum Inc. Japan. And we're a multibillion-dollar company, we're ready to invest whatever it takes to make that happen.' To give them the kind of training that will produce the teams that Takeuchi and Nonaka were writing about in the first paper on Scrum. And as we work with them to figure out what needs to be in that training, we found that the Scrum Guide was only 25% of the training. Another 25% was basic Lean concepts and tooling, right? Because the original Scrum paper was all about Lean hardware companies. So Lean is fundamental to Scrum. If you don't understand it, you can't do it. And then third, there are certain patterns of performance that we've developed over the years, we spent 10 years writing a book on patterns - Scrum patterns. And there's about a dozen of those patterns that have to be implemented to get a high performing team. And finally, scaling to multiple teams. It turns out, right about this time I started working with the Japanese, I was at a conference with the Agile Leadership from Intel. And they told me that they'd introduced Scaling Frameworks into Intel division, some of which had more than 500 Scrum teams in the divisions and the Scaling Frameworks had slowed them down. And it made the senior executives furious and they threw them all out and they said, we did not want to hear the word Scrum at Intel anymore. But you guys need to go twice as fast as you're going now. So, they came to me, they said, ‘we're desperate. We have to go twice as fast. We can't even use the word “Scrum”. What should we do?' And they blamed me, they said, ‘Sutherland you're responsible you caused problem, you need to fix it.' So, I started writing down how to do what today we call Scrum at Scale. And everybody, you know, most of those people in the industry were implementing IT scaling frameworks. They were all upset. ‘Why are you writing down another framework?' Well, it's because those IT frameworks do not enable the organization to show Business Agility, and win in the market. And in the best companies in the world, they're being thrown out. So, I've had to write down how do you add, how do you go to hundreds and thousands of Scrum teams - and never slow down as you're adding more and more teams. You know, every team you add is as fast as the first team when you start. Yeah, that's what Scrum at Scale is all about. So, there's two primary things that I'm focused on today. One is to fix all this bad Scrum. Second is to fix the scaling problem. Because it turns out that if you look at the latest surveys from Forbes magazine, and the Scrum Alliance on successful Agile transformations - I learned recently, that almost every company in the world of any significance is going through an Agile transformation or continuing transformation they'd already started years ago. And 53% of them do not meet management expectations. And the MIT Sloan Business Review did an analysis of what happens if an agile transformation fails, and 67% of those companies go out of business. So, this is becoming really serious, right? To be successful today, if you're competing in any significant way, you have to be agile. And number two, if you try to be agile and fail, you have a 67% chance going out of business. And the failure rate is 53%. So, this is the problem that we're wrestling with. And half of that 53% failure is due to the bad Scrum we talked about, but the other half is due because of the leadership not being Agile. Ula Ojiaku: I was just going to say, as you said something about the leadership not being agile. In my experience, you know, as an agile coach in some organizations whilst the teams would embrace you know, Scrum and embrace Agility - the practices and the processes and everything. There's a limit to, you know, how much they can get done… Jeff Sutherland: Absolutely… Ula Ojiaku: …if the leadership are not on board. So… Jeff Sutherland: …you hit this glass ceiling. So, I've been, you know, giving presentations on Agile Transformations around the world. And I can remember multiple times I've had 300 people in the room, say, and I say okay, ‘How many of you are agile, in Agile transformations or continuing the ones you'd started?' Of course, everybody raises their hand. ‘How many of you have waterfall traditional management that expects you to deliver all the old Gantt Chart reports that we always got, and don't understand what you're doing?' There's 300 people in the room and 297 people raised their hand. I said, ‘you need to give your leadership the book by Professor Kotter called Accelerate.' Professor Kotter is one of the leading change experts of the world. Ula Ojiaku: And he also, yeah, He also wrote ‘Leading Change' as well - the book, yes. Jeff Sutherland: And in that book, he says, if the leadership of the Agile part of the organization is traditional in their mindset and requirements, the Agile Transformation will eventually fail 100% of the time. Ula Ojiaku: Those are sobering statistics in terms of, you know, the failure rate and how much of you know the success hinges on business agility and the leadership being agile as well and taking the time to know and care what it means. Yeah. Jeff Sutherland: And what's happening is that the Agile Leadership today, if you look at some of the companies that have been most successful during COVID, one of them is John Deere Corporation, the biggest farm equipment manufacturer in the world, probably the oldest. Their stock price went up more than Amazon during COVID. And the board of directors gave their Agile Leadership, the Agile Coaches, Scrum Masters, the highest award in the Corporation for producing that result. So that's another reason I'm trying to communicate to Agile people. The success and survival of your company depends on you. You think your management's going to save you but no, if they are old-style people, they are going to run that company out of business. And you need to either save it before it goes out of business or run to another company before bad things happen. Ula Ojiaku: It's impressive that, you know, John Deere being a farm equipment manufacturer… I think they were ahead of the curve you know, (compared to some of their contemporaries in that industry as well) and embraced agile ways of working. Do you know how their Agile Leadership were able to quantify their contributions to the company? Jeff Sutherland: John Deere started to get Agile more than 10 years ago. So, they've been at it a long time. But in recent years, they really started to build… build internally… Agile leadership, you know, based on my work and they started applying that across the company. I mean, the major focus has not been software actually – it's been in other parts of the company. What has to happen to run a company that's building tractors? Well, there's all kinds of things that have to happen, you know - purchasing, there's legal, there's acquiring all the pieces, it's putting them together at the assembly line, you know, software is a piece of it. You know, that's probably the easiest piece to fix with Agile, it's the rest of the company that's the challenge. They have started doing that really well which is reflected in their stock price. Ula Ojiaku: Amazing. So, you said something about you know, you're out to fix a couple of things, the problem with bad Scrum out there. And, you know, the problem with scaling agile. Jeff Sutherland: Right Ula Ojiaku: So, with respect to the first one, the point about bad Scrum, what in your experience would be the root cause of bad Scrum implementations in organizations? Jeff Sutherland: There're about 11 things, that if you fix them, the team will go twice as fast. And it's multiplicative. So, you know, we have extensive data on, you know, really big companies. What's the difference between the fastest team and the slowest teams? The fastest teams are 2000 times faster than the slowest teams. So why is that? Well, first, the team has to be small. The optimal team size is four or five people. If you have a 10-person team, that's going to take at least 50% longer to get anything done. If you go out, look at the team size, you'll see companies have even not only ten-people teams, they have 15 people in a team, 25 people in a team, okay? Those teams are never gonna meet Agile performance. Second, the backlog needs to be really ready in a sense of small, it's clearly understood, it's properly prioritized. So, you need somebody managing that backlog that can get it right, because we have extensive data for multiple case studies showing the team's production doubles immediately. As soon as you get that backlog right. So you go into many companies, you'll see, there's still arguing about what's the top priority, right? Or everything's top priority. That's just gonna create a massive mess. Third, teams are constantly interrupted. You know, the only teams I know that aren't interrupted are people… these teams and defense contractors working on top secret stuff. And they work in a locked room, the door, it says ‘no managers can enter' and they don't get interrupted. But for the rest of us, there's always somebody coming in wanting something else done. And there's a way to manage that using a pattern we call the interrupt buffer. And if you don't have that pattern implemented properly, you're gonna go half as fast. If you're lucky, you might go half as fast. Ula Ojiaku: And what do you say the Scrum Master has a part to play in making sure the interrupt buffer is there and it's enforced? Jeff Sutherland: The scrum master needs to set this all up. Fifth, in high performing teams, we see this pattern called swarming, where multiple people are working on a story together. That increases the process efficiency, which doubles the performance of the team. So, if people are specialists working independently, that team is going to be really slow. So I'm up to number five, there are six more things, but you probably want to go through them. It's very clear, what makes agile teams suck, we know exactly why. And it needs to be fixed. So, I appeal to anyone listening to this help fix bad agile, it's hurting us all. Ula Ojiaku: Thank you for sharing that. Would this be in any of any of your books or in any of your articles that you've written? Jeff Sutherland: Yeah, it's everywhere and (in) everything I've written, but the best summary, it's the red book Scrum … Scrum, The Art of Doing Twice the Work and Half the Time And we've had people pick, pick this up. A CEO in Kenya came to New York to one of my courses, he said, ‘Jeff, I just read your book. And I'm CEO with three new energy startups in Kenya. And my teams implemented that, and they're going… they're doing three times the work and a third of the time. So, your book is too conservative.' He says to me, this guy, he only read the book, he had no training. So, this book is enough to really get off on the right foot. And if you're having problems, it's enough to fix things. In fact, recently before COVID when we could get everybody together, we had an Apple employee in the class and she said, Jeff, do you know why Apple always meet its states? I said, no, you know, Apple is really secretive. They don't tell anybody anything. She says ‘it's because they do Scrum by the book.' So, I said, ‘What book?' She says, ‘The Red Book - Scrum, The Art of Doing Twice the Work and Half the Time - they do it exactly by the book.' So, again, my message to the Agilists out there: Apple is winning. They are the most valuable company in the world. And it's because they do Scrum exactly by that book. So, you probably should read it. Ula Ojiaku: Definitely. So going by the book, would you say there's any wriggle room for adapting to one's context, or is it about you know, going, ‘check- we've done page 123…' Jeff Sutherland: Well, the whole thing about adapting is fundamental to Scrum. So, one of the things I'm constantly doing in my talks, training, is I'm going back to before Scrum and reading a paper from the leading researchers on complex adaptive systems, in which they mathematically proved, you model things on the computer, that systems evolve more quickly, if they have more degrees of freedom, up until you hit a boundary where the system goes into a chaotic state. So, from the very beginning in Scrum, maximizing the freedom and the decision capability of the team has been fundamental. And we talked about this as self-organization. Now, unfortunately, that term has been so misused, misunderstood that we had to take self-organization out of the Scrum guide. And what we inserted was self-managing. And we put next to it goals, okay, the theme is self-managing to achieve a goal. And to make that happen, they need a commitment to do that. And so, this is one of the fundamental things for Agile teams that work that they have that self-managing commitment to achieve a goal. And the teams that are not working, they're fuzzy about that, right. So, we want the maximum degree of adaptation, the thing that they don't want to change is the basic structure that's in the red book, if they change that, it has the control mechanisms to allow the maximum degree of self-organization - not to go off the rails. Ula Ojiaku: Right. Jeff Sutherland: So, we see a lot of Agilists, ‘oh, you know, let's just tweak the framework this way or that way.' And then the self-organization takes a team off the rails, and then they fall into that 58% that can't deliver, they're late, they're over budget, the customers aren't happy. And so, this is the really one of the hardest things to communicate to people. There're certain things that you absolutely have to be disciplined about. You have to be more disciplined to get a great Agile team than in all ways of working. And that discipline is what allows the maximum degree of self-organization and self-determination, right? So, understanding those two things together, you know, it makes it makes people's brain explode, right? It's hard. Ula Ojiaku: But it works. Jeff Sutherland: But it works right.  Ula Ojiaku: You've already mentioned a lot of books in the course of this interview session, and these would be in the show notes. So, would there be anything any final word of advice you'd have for the leaders that would be listening to this podcast in terms of their transformation journey? Jeff Sutherland: So, one of the things we did to Scrum at Scale is that the difference between that and most of the other scaling frameworks is that it's all about the leadership. So, we need an operating leadership team, that is a Scrum team that needs a Scrum Master, a Product Owner, backlog. And its objective is to improve the Agile implementation of the organization. On the prioritization side, we need a leadership team that, led by a Chief Product Owner, that is prioritizing backlog across the organization. So, you know, I've had the Chief Product Owner of Hewlett Packard in my course, he had a $200 billion portfolio. He learned from that class. Says this class is pretty good.' He said, ‘In just one slide I figured out how to get $20 billion more a year with no additional resources'. Just by understanding how to work the framework right? At the $200 billion level. Ula Ojiaku: And you're talking about the Scrum at Scale course, right? Jeff Sutherland: No, this was a product owner course. Product Owner course. He came to it. We're now doing a Scrum at Scale… we're actually doing a Chief Product Owner course. So, a Product Owners at Scale course which it has been really well received by the leading Agile Practitioners. (They) really like that because they need to work more in the large than in the small often. Ula Ojiaku: Definitely. That means this available on the Scrum Inc site? Jeff Sutherland: Yes. Ula Ojiaku: Okay. Jeff Sutherland: So, one of the things I would recommend I would really recommend is the Scrum Field Book. It's a bunch of case studies for organizations, large and small, that have tried to take the whole organization to Scrum. Well, thank you so much, Dr. Sutherland - it's been a great pleasure having you and hopefully we could have a you know, follow up conversation sometime. Jeff Sutherland: Yes. Thanks for inviting me and glad to do it again. Ula Ojiaku: That's all we have for now. Thanks for listening. If you liked this show, do subscribe at www.agileinnovationleaders.com. Also share with friends and leave a review. This would help others find the show. I'd also love to hear from you, so please drop me an email at ula@agileinnovationleaders.com. Till next time, take care and God bless!    

Taking the Team Coaching Zone Podcast stage this week is James Edmondson! Jame is an Organisational Effectiveness Consultant, a Systemic Team Coach, a Student of Agile and a Veteran.  James presently is an Enterprise Agile Coach at Scrum Inc.  In this episode host Dr. Krister Lowe explores James' journey as a commanding officer in the Royal Australian Navy, to his transition to a number of private sector roles, to his discovery and evolution into team coaching and agile, and to his exciting work scaling teams and teams-of-teams.  You can learn more about James at: https://www.linkedin.com/in/james-edmondson/ This is a fascinating episode that listeners will surely not want to miss! Listen to this and past episodes of the TCZ Podcast via your your favorite podcast player (e.g. Spotify, Apple Podcasts, Stitcher Radio and more) or at https://team-coaching-zone.teachable.com. And for ongoing dialogue about team coaching join us in the Team Coaching Learning Community group on LinkedIn: https://www.linkedin.com/groups/8227188/

Dr. Jeff Sutherland is the Founder and Chairman of Scrum Inc. He is credited with being one of the creators of Scrum, which is celebrating its 30 year anniversary in 2023, and is a framework for enabling business agility at scale across an entire organization. Sutherland's mission has always been to spread Scrum around the world to free people from what he calls “the incredible life-draining system they're working under.” His teachings consistently expose the archaic systems that hinder productivity, and he's at the forefront helping the world's biggest organizations make the transition to Agile. To further his efforts, Sutherland is also a co-creator of The Agile Education Program powered by Scrum Inc., a training suite providing the curriculum and educational standards that give individuals and organizations a clear path to implementing Scrum in a way that drives immediate business results. A graduate of West Point, Sutherland served as a fighter pilot during the Vietnam War and later spent time conducting cancer research before immersing himself in the world of software development. With his expertise, Jeff has held the role of Chief Technology Officer at eleven different software companies, bringing a wealth of experience to each endeavor. In 1993, Jeff pioneered the concept of Scrum by launching the first Scrum team. While things have changed a lot since then (spoiler alert: those original month-long sprints were far too long), he has continued to play a pivotal role in expanding Scrum's ability to drive Agile transformation at organizations across industries including government, finance, healthcare, higher education, and telecom. Recognizing the transformative power of Scrum, Sutherland co-authored the bestselling book Scrum: The Art of Doing Twice the Work in Half the Time, and later published A Scrum Book: The Spirit of the Game. Through his books and extensive knowledge sharing, he has become a respected figure in the Agile community. His passion for fostering energy, focus, clarity, and transparency in project planning and implementation has made scrum a highly sought-after approach for organizations seeking efficient and effective project management. We had a chance to sit down with Sutherland as he reflects on 30 years of Scrum, the new Scrum QuickStart offering and what the future holds for Scrum's biggest possible impact on the world.

This episode originally aired in July 2021.    -------------------------------------------   As many organizations are talking today about becoming “agile” it is important to know what it really means. Dr. Jeff Sutherland (https://www.linkedin.com/in/jeffsutherland/) is the ideal person to discuss this. He is the chairman and founder of Scrum Inc., a signatory of the Agile manifesto, coauthor of the Scrum Guide and the creator Scrum@Scale. He is also the coauthor of the best selling book Scrum: The Art of Doing Twice the Work in Half the Time. Today we talk about the misconceptions of Agile, the origins of the Scrum framework, and how his military experience and his work doing scientific computer modeling influenced him. For more resources, sign up for the newsletter at https://www.hardcoresoftskillspodcast.com/  Connect with me via https://www.linkedin.com/in/yadiraycaro/  

OKR's are continuing to gain more popularity but are they really in helping organizations better understand long and short term goals? Che Ho, Enterprise Transformation Consultant at Scrum Inc. sits down with Unlocking Agile host Bobby Woods and dives deeper into what companies are experiencing and how to set expectations in the use of OKRs with agility.

Keywords Scrum, people, lean, class, business, kaizen, Sutherland, learning, trainers, world, product owner, teach, agile, organisation, coaches, team, training, read, Buddhism.Introduction Welcome to episode 75 of the Enterprise Excellence Podcast. It is such a please to have Mr Avi Schneier on the show with us today. Avi is a leader in all things Agile and Scrum. Avi has had an extensive career as an educator, stockbroker and consultant. Avi is a principal consultant and board member for Scrum Inc. Avi's purpose is to help organisations thrive in a world where change is the only constant. We are proudly sponsored by S A Partners, a world-leading business transformation consultancy.Quotes 04:57 min And here I am sitting in a class, and every single thing that's being said, I'm like, Why? Why aren't I doing that? Why isn't everybody doing that? What's wrong with everybody? Like I could? I couldn't, I couldn't figure it out. 07:48min When you're going to give somebody Backlog. It's what, why, KPI and done by. Where done by is not a person. It's not who. It's when. You're telling you telling the team; this is what I'd like. This is why I think it's important. Here's how I'm going to measure it. And by the way, this is when I expect it to be done to be finished. Or this is what to expect to look at it with you to inspect and adapt and improve for the next time. Right? If you give people those four constraints, you're gold.16:18min So I created the trainers' program with Dr Sutherland because I was like, listen, we want people to preach the gospel, you know, for lack of a lack of a non-religious term, but we want them to do it well.       LinksBrad is proud to support many Australian businesses. You can find him on LinkedIn here. If you'd like to speak to him about how he can help your business, call him on 0402 448 445 or email bjeavons@iqi.com.au. Our website is www.bradjeavons.com.Avi Schneier is available on Linkedin: linkedin.com/in/avi-schneier.What next? Join our competition to win a free training course - either Scrum Master, Product Owner or Scrum @ Scale, running in March 2022. Simply connect with Brad and mention the offer - via email at bjeavons@iqi.com.au. or our website "contact us page", www.enterpriseexcellenceacademy.com, or LinkedIn.Join our membership page to access free planning resources.Join our community, beginning in April 2022. www.enterpriseexcellenceacademy.comSA Partners

Scaling agility can be tricky. But there are proven ways to reduce the complexity of a transformation and boost its chances of success. Scrum Inc.'s Avi Schneier tells you how in this episode of Unlocking Agile.

Unlocking Agile launches in January of 2022 with new episodes released every #TransfromationTuesday

Bio Dr. Jeff Sutherland is the inventor and co-creator of Scrum, the most widely used Agile framework across the globe.  Originally used for software development, Jeff has also pioneered the application of the framework to multiple industries and disciplines. Today, Scrum is applied to solve complex projects in start-ups and Fortune 100 companies. Scrum companies consistently respond to market demand, to get results and drive performance at speeds they never thought possible. Jeff is committed to developing the Agile leadership practices that allow Scrum to scale across an enterprise.   Dr. Sutherland is the chairman and founder of Scrum Inc. He is a signatory of the Agile manifesto and coauthor of the Scrum Guide and the creator Scrum@Scale. Jeff continues to teach, create new curriculum in the Agile Education Program and share best practices with organizations around the globe. He is the founder of Scrum Inc. and coauthor of, Scrum: The Art of Doing Twice the Work in Half the Time, that has sold over 100,000 copies worldwide.    Social Media:                 LinkedIn: linkedin.com/in/jeffsutherland                 Twitter: @jeffsutherland Website: Scrum Inc https://scruminc.com               Books/ Articles: The Scrum Guide by Jeff Sutherland and Ken Schwaber http://www.scrumguides.org/index.html Scrum: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland The Scrum Fieldbook by JJ Sutherland Agile Competitors and Virtual Organisations by Steven Goldman, Roger Nagel and Kenneth Preiss https://www.amazon.co.uk/Agile-Competitors-Virtual-Organizations-Engineering/dp/0471286508 Accelerate: Building Strategic Agility for a Faster Moving World by John P. Kotter Leading Change by John P. Kotter Process Dynamics, Modeling and Control by Babatunde A. Ogunnaike and Harmon W. Ray A Scrum Book: The Spirit of the Game by Jeff Sutherland, James Coplien, Mark den Hollander, et al    Interview Transcript Introduction Ula Ojiaku: Hello everyone, my guest today is Dr Jeff Sutherland. He is the inventor and co-creator of Scrum, the most widely used Agile Framework across the globe. Originally used for Software Development, Jeff has also pioneered the application of the framework to multiple industries and disciplines. Today, Scrum is applied to deliver complex projects in startups and Fortune 100 companies. Dr Jeff Sutherland is the Chairman and Founder of Scrum Inc. He is a signatory of the Agile Manifesto and co-author of the Scrum Guide and the creator of Scrum at Scale. Jeff continues to teach, create new curriculum in the Agile education programme and share best practices with organisations around the globe. He has authored and co-authored a number of books which include Scrum: The Art of Doing Twice the Work in Half the Time – which has sold over 100,000 copies worldwide.   In this episode, Dr Sutherland shares the backstory of how he and Ken Schwaber developed the Scrum framework. I was pleasantly surprised and proud to learn that one of the inspirations behind the current Scrum framework we now have was the work of Prof Babatunde Ogunnike, given my Nigerian heritage. Dr Sutherland also talked about the importance of Agile Leadership and his current focus on helping organisations fix bad Scrum implementations.   I'm sure you'll uncover some useful nuggets in this episode. Without further ado, ladies and gentlemen, my conversation with Dr Sutherland.    Ula Ojiaku: Thank you, Dr. Sutherland, for joining us on the Agile Innovation Leaders podcast. It's a great pleasure to have you here. Jeff Sutherland: Glad to be here. Looking forward to it. Ula Ojiaku: Fantastic. So could you tell us about yourself? Jeff Sutherland: Well, I grew up in a small town in Massachusetts. And I always felt that I would go to West Point of the United States Military Academy, even at a very young age. And I finally made it there. I spent four years there. And I went on to a program where a certain number of cadets could join the Air Force. And I told the Air Force, if they made me a fighter pilot, I would move into the Air Force, which I did. I spent 11 years as a fighter pilot in the Air Force. And most of the operational aspects of Scrum actually come from that training. My last tour in the Air Force was actually at the US Air Force Academy, I was a professor of mathematics. And I had gone to Stanford University in preparation for that position. And I had worked closely with the, at the time he was Head of the Department of Psychiatry, became the Dean of Stanford who had studied under my father-in-law, he had become an MD under my father-in-law, who was a brilliant physician. And I was working on research papers with him, both at Stanford and at the Air Force Academy. And I asked him for guidance. And I said, I'm thinking about, given all the work we've done in the medical area. Starting in Stanford, I'm thinking maybe becoming a doctor - become an MD. And he strongly recommended against that he said, ‘you'll just go backwards in your career, what you need to do is you build on everything you've done so far. And what you have is your fighter pilot experience, your experience as a statistician, and a mathematician, you want to build on that.' So, I had already started into a doctoral program at the University of Colorado School of Medicine, which was not far from the Air Force Academy. And so, I talked to my department Chairman there who offered me a position in the department running a large research grant, funded by the National Cancer Institute and so, I decided to exit the Airforce and join the medical school. While I was finishing up my doctoral degree. And as soon as my doctorate was finished, I became a professor of Radiology, preventive medicine and biometrics. I was a joint across multiple departments. And I was doing mathematical research on modeling, particularly the human cell on a supercomputer, (to) determine what caused cancer. And to do that required extensive mathematical research as well as the medical research. But at the end of the day, what we found was for any complex adaptive system, like a human cell, or a person or a team, they go through different states. And they're moved from one state to the next by some kind of intervention. And so, if you understand what causes those changes… turned out in the case of cancer, there were four different states that led to a tumor. And in every state, there were certain interventions, and if you knew what they were, you could prevent them and prevent cancer. Or you could even, to my surprise, take a cancer cell and make it go backward into a normal cell. So, this fundamental understanding is the theory behind Scrum. So, while I'm doing this all at the medical school, a large banking company came by and said, ‘you know, over the medical school, you guys have all the knowledge about the technologies; the new technology, we're using (for) banking, you're using for research.' And they said, ‘you guys have all the knowledge but we have all the money and they made me an offer to come join the bank' [Laughs].   Ula Ojiaku: [Laughs]You couldn't refuse Jeff Sutherland: Not just me, it was my family. So, I wind up as Vice President for Advanced Systems, which was effectively was the CTO for 150 banks that we were running across North America.   Each was, you know, a dozen, 50, 100 branches. And of course, we were mainly doing the software, installation and support to run the banking operation, which is largely computer stuff – (this) is what banks run off. And as we're building these systems with hundreds and hundreds of developers, one of the first things I noticed is that all the projects were late. And I look at what they're doing. And they're using this process where they spend, you know, six months defining requirements, and then they put all the requirements into a Gantt chart. And then they, they plan on taking six months to build something, but it's never done. Because as soon as they start testing that they find there's all kinds of things that are broken. So, virtually every single project of the bank is late. So, as a head of technology, one day I walked into the CEO's office and I said, ‘Ron,  have you noticed all your projects are late?' He said, ‘Yes'. He says, ‘Every morning at least five CIOs or CEOs of the banks, they call me up.' And he says, ‘they scream at me.' I said, ‘wow', I said, ‘You know, it's going to get worse, not better. Because these guys are using this, these Gantt Charts.' And I showed him one. And then being a mathematician, I mathematically proved that every project would be late at the bank. And he was stunned. And he said, ‘what should I do?' I said, ‘we need a completely different operating system in the bank.' This is back in 1983. ‘Let's take one business unit. Let's take the one that's losing the most money, okay, the worst business unit' Ula Ojiaku: They have nothing to lose then. Jeff Sutherland: And it was the automated teller division that was rolling out cash machines all over North America. It was a new technology and they had a ton of problems. So, I said, ‘let's take that unit and every one, sales, market, support, installation, we're going to split them down into small teams. And we're going to have Product Marketing come in on Monday with a backlog prioritized by business value. And at the end of the week, on Friday, we're going to deploy to 150 banks.' ‘And I'm going to train them how to land a project every week, just like I trained fighter pilots to land aircraft. I'm going to give them a burndown chart, we're going to throw away the Gantt Chart, I'm going to give them a burndown chart to show them how to land the project.' So, he said, ‘Well, that's gonna be a big headache.' I said, ‘look, the bank needs to be fixed.' He said, ‘Okay, you got it.' So, I took that unit. I told them, ‘I know it's gonna take several weeks,' today we call them sprints, ‘for you to be successful.' Because as new pilots, trained to land, these high-performance jets, they tend to come in high and then they have to come around and try to land again, they over and over, they practice until they can nail it. And it took them six weeks, six sprints to actually nail the end of the week (and) deploy (to) 150 banks. But within six months, it became… it went from the worst business unit in the bank to the most profitable business unit in the bank. And the senior management said, ‘you know, Jeff, here's another 20 million dollars to throw at whatever that thing you're doing [chuckles] it's the most profitable thing in the bank, we're gonna put more money in that [Laughs]. So that was the first prototype of what we call today Scrum at Scale. Now, I've been CTO of 11, or CTO or CEO of 11 different companies. And for the next 10 years, I prototyped that model and advanced technology teams until in 1993, at a company called Easel Corporation, we found that because of the tooling we were building and selling to customers, we needed to build the tool with what today we call Agile Practice. Ula Ojiaku: Yes Jeff Sutherland: And we need to train the customer to use the tool by having teams do an agile practice. So, in order to train our customers properly in 1993, we actually had to formalize what I've been prototyping for 10 years. And we wrote it down and at the time we were reading this paper, we're going through 1000 papers in the journals I, you know, I had done many new technology. And, in every one of them, you have to read everything that's ever been done so that you can go beyond. You can use everything that's been done, but then you go beyond, okay? Ula Ojiaku: Yeah Jeff Sutherland:  So, it's a tremendous amount of research to launch new technology. And at about the 300th paper in our file, it was a paper out of the Harvard Business Review, which really surprised me, by two Japanese Business School professors, Professors Takeuchi and Nonaka. And in there, they described the best teams in the world. They were lean hardware teams that reminded them of a game of rugby, they said, ‘we're going to call what they're doing Scrum Project Management.' So, I said to the team, ‘we need a name for this thing that we're going to train our customers in, and let's call it Scrum.' And off we went. So, for the next two years, we were actually using Scrum within Easel deploying products. But it was not public, to the general industry. And Easel got acquired by a larger company. And at that time, I felt that this needed to be rolled out into the industry because we had benchmarked it with the best tooling in the world from the leading productivity company, and showed that it was… that (it) went 10 times faster [chuckles]. The quality was 10 times better, which is what you need for a new technology innovation. And so, I felt it was ready to go to the industry as a whole. So, I called up an old friend, Ken Schwaber. And he was a CEO of a traditional Project Management software company, a waterfall (methodology). He sold these methodologies with 303 ring binders, a software package that would make Gantt Charts [chuckles]. So, I said, ‘Ken, I want you to come up and see the Scrum, because it actually works and that stuff you're selling doesn't work – it makes projects late.' And he agreed to come in, he actually came up, he met with me. He stayed for two weeks inside the company, working, observing the Scrum team. And at the end of those two weeks, he said, ‘Jeff, you're right. This really works - it's pretty much the way I run my company.' He said, ‘if I ran my company with a Gantt Chart, we would have been bankrupt a long time ago.' So, I said, ‘well, why don't you sell something to work that works instead of inflicting more damage on the industry?' So, he said so we said ‘okay, how (do) we do it?' I said, ‘it needs to be open source, it needs to be free.' Ken felt we needed to take the engineering practices, many of which appear today in extreme programming… Ula Ojiaku: Yes Jeff Sutherland: …and let Kent Beck (creator of eXtreme Programming, XP) run with them because Kent had been sending me emails, ‘Jeff, send me every...', he had been following the development of Scrum, ‘…send me everything on Scrum, I'm building a new process. I want to use anything that you've done before and not try to reinvent anything.' So, he (Ken Schwaber) said, ‘let Kent take the engineering practices, we'll focus on the team process itself.' And we agreed to write the first paper on this to present at a big conference later that year. And writing that paper was quite interesting. Ken visited DuPont Chemical Corporation, the leading Chemical Process Engineers there that they had hired out of academia to stop chemical plants from blowing up. And when Ken met with them, they said, describe what we were doing in the software domain. They said, ‘you know, well, that process that traditional project management is a Predictive Process Control System. We have that in the chemical industry.' ‘But it's only useful if the variation in the process running is less than 4%.' They said, ‘do you have less than 4% change in requirements while you're building software?' Ken says, ‘no, of course not! It's over 50%!' And they started laughing at him. They said, ‘your project's going to be exploding all over the place.' ‘Because every chemical plant that has blown up has been somebody applying a predictive control system to a system that has high variability. You need to completely retrain industry to use Empirical Process Control, which will stop your projects from blowing up. And they said, here it is, here's the book, they had the standard reference book for Chemical Process Engineering. And in there, there's a chapter on Empirical Process Control, which is based on transparency, inspection, and adapting to what's happening in real time. Okay, so those are the three pillars of Scrum that are today at the base of the Scrum guide. Ula Ojiaku: Do you still remember the title of the book that the chemical engineers recommended to Mr. Schwaber by any chance? Jeff Sutherland: Yeah, so I have a, when I do training, I have a slide that has a picture of the book (Process Dynamics, Modelling and Control). It's written by Ogunnaike and Ray. But that is the root of the change that's gone on in the industry. And so then from 1995, forward, Ken and I started working together, I was still CTO of companies. And I would get him to come in as a consultant and work with me. And we'd implement and enhance the Scrum implementations in company after company after company. Until 2001, of course, Scrum was expanding but Extreme Programming in 2001, was actually the most widely deployed. They were only two widely-deployed agile processes at the time of Scrum and Extreme Programming. Extreme Programming was the biggest. And so, the Agile Manifesto meeting was convened. And it had 17 people there, but three of them were Scrum guys - that had started up Scrum, implemented it in companies, four of them were the founders of Extreme Programming. And the other 10 were experts who have written books on adaptive software development or, you know, lightweight processes, so, industry experts. And we, we talked for a day and everybody explained what they were doing and there was a lot of arguments and debate. And at the end of the day, we agreed because of this book, Agile Competitors, a book about 100 hardware companies - lean hardware companies, that have taken Lean to the next level, by involving the customer in the creation of the product. And we said, ‘we think that we all need to run under one umbrella. And we should call that Agile.' Ula Ojiaku: So, did you actually use the word umbrella in your (statement)? Oh, okay. Jeff Sutherland: Often, people use that right? Ula Ojiaku: Yes, yes Jeff Sutherland: Because at the time, we had Agile and Extreme Programming, and now everybody's trying to come up with their own flavor, right?  All under the same umbrella of ‘Agile'. And that caused the both Scrum and Extreme Programming started to expand even more, and then other kinds of processes also. But Scrum rapidly began to take dominant market share, Scrum today is about 80% of what people call Agile. The reason being, number one, it was a technology that was invented and created to be 10 times better. So, it was a traditional new technology developed based on massive amounts of research. So, it worked. But number two, it also scaled it worked very well for many teams. I mean, there are many companies today like Amazon that have thousands of Scrum teams. And Extreme Programming was really more towards one team. And (reason number) three, you could distribute it across the world. So, some of the highest performing teams are actually dozens of teams or hundreds across multiple continents. And because of those three characteristics, it's (Scrum has) dominated the market. So that brings us to in 2006, I was asked by a Venture Capital firm to help them implement Scrum in their companies, they felt that Scrum was a strategic advantage for investment. And not only that, they figured out that it should be implemented everywhere they implemented it within the venture group, everybody doing Scrum. And their goal was to double their return on investment compared to any other venture capital firm. They pretty much have done that by using Scrum, but then they said, ‘Jeff, you know, we're hiring you as a consultant into our companies. And you're a CTO of a healthcare company right now. And we don't want to build a healthcare company, we want to build a Scrum company.' ‘So, why don't you create Scrum Inc. right here in the venture group? We'll support it, we'll do the administrative support. We'll write you a check - whatever you want.' So, I said, ‘well, I'm not going to take any money because I don't need it [chuckles]. I understand how that works. If the venture capital firm owns your company, then (in the) long term, you're essentially their slave for several years. So, I'm not taking any money. But I will create the company within the venture group. If you provide the administrative support, I'll give you 10% of the revenue and you can do all the finances and all that kind of stuff. So, that's the way Scrum Inc. was started to enable an investment firm to launch or support or invest in many dozens of Scrum companies. Ula Ojiaku: That's awesome Jeff Sutherland: And today, we're on the sixth round of investment at OpenView Venture Partners, which was the company the six round is 525 million. There's a spin out from OpenView that I'm working with, that has around this year, 25 million. And over the years, just co-investing with the venture group I have my own investment fund of 50 million. So, we have $570 million, right this year 2021 that we're putting into Scrum companies. Agile companies, preferably Scrum. Ula Ojiaku: Now when you say Scrum companies is it that they facilitate the (Scrum) training and offer consulting services in Scrum or is it that those companies operate and you know, do what they do by adopting Scrum processes? Jeff Sutherland: Today, Scrum Inc sometimes help some of those companies, but in general, those companies are independently implementing Scrum in their organizations.   Ula Ojiaku: Right Jeff Sutherland: And okay, some of them may come to Scrum training, maybe not. But since Scrum is so widely deployed in the industry, Scrum Inc, is only one of 1000 companies doing Scrum training and that sort of stuff. So, they have a wide variety, wide area of where they can get training and also many of the startups, they already know Scrum before they started the company. They are already Agile. So, what we're interested in is to find the company that understands Agile and has the right team players, particularly at the executive level, to actually execute on it. Ula Ojiaku: No matter what the product or services (are)… Jeff Sutherland: Products or services, a lot of them are software tooling companies, but some of them are way beyond that, right? So, turns out that during COVID… COVID was a watershed. The companies that were not agile, they either went bankrupt, or they were crippled. That meant all the Agile companies that could really do this, started grabbing all the market share. And so, many of our companies, their stock price was headed for the moon during COVID [laughs]. While the non-agile companies were flatlined, or are going out of business, and so the year of COVID was the best business year in the history of venture capital because of Agility. So, as a result, I'm spending half my time really working, investing in companies, and half of my time, working with Scrum (Inc.) and supporting them, helping them move forward. Ula Ojiaku: That's a very impressive resume and career story really Dr. Sutherland. I have a few questions: as you were speaking, you've called Scrum in this conversation, a process, a tooling, the technology. And you know, so for some hardcore Agilists, some people will say, you know, Agile is all about the mindset for you, what would you say that Scrum is it all of these things you've called it or would it be, you know, or it's something (else)...? Jeff Sutherland: So, certainly the (Agile) mindset is important. But from an investment point of view, if the organization can't deliver real value, quickly, agile is just a bunch of nonsense. And we have a huge amount of nonsense out there. In fact, the Standish group has been publishing for decades. 58% of Agile teams are late over budget with unhappy customers. So, when you get these hardcore Agilist, that are talking about mindset, you have to figure out ‘are they in the 42% that actually can do it or are they in the 58% that are crippled?' My major work with Scrum Inc. today is to try to get to fix the bad Scrum out there. That is the biggest problem in the Agile community. People picking up pieces of things, people picking up ideas, and then putting together and then it doesn't work (laugh). That is going to that's going to be really bad for agile in the future. If 58% of it continues not to work. So, what we found, I mean, it was really interesting. Several years ago, the senior executive (of) one of the biggest Japanese companies flew to Boston wanted meet with me. And he said to me, ‘the training is not working in Japan for Scrum.' He said, ‘I spent 10 years with Google, in Silicon Valley. So, I know what it looks like what actually works. And I can tell you, it's not working in Japan, because the training is… it's not the training of the Scrum that is high performing. And in fact, our company is 20% owned by Toyota, and we are going to be the trainers of Toyota. And we cannot deliver the training that's currently being given to Toyota, it will not work, it will not fly. And we want to create a company called Scrum Inc. Japan. And we're a multibillion-dollar company, we're ready to invest whatever it takes to make that happen.' To give them the kind of training that will produce the teams that Takeuchi and Nonaka were writing about in the first paper on Scrum. And as we work with them to figure out what needs to be in that training, we found that the Scrum Guide was only 25% of the training. Another 25% was basic Lean concepts and tooling, right? Because the original Scrum paper was all about Lean hardware companies. So Lean is fundamental to Scrum. If you don't understand it, you can't do it. And then third, there are certain patterns of performance that we've developed over the years, we spent 10 years writing a book on patterns - Scrum patterns. And there's about a dozen of those patterns that have to be implemented to get a high performing team. And finally, scaling to multiple teams. It turns out, right about this time I started working with the Japanese, I was at a conference with the Agile Leadership from Intel. And they told me that they'd introduced Scaling Frameworks into Intel division, some of which had more than 500 Scrum teams in the divisions and the Scaling Frameworks had slowed them down. And it made the senior executives furious and they threw them all out and they said, we did not want to hear the word Scrum at Intel anymore. But you guys need to go twice as fast as you're going now. So, they came to me, they said, ‘we're desperate. We have to go twice as fast. We can't even use the word “Scrum”. What should we do?' And they blamed me, they said, ‘Sutherland you're responsible [Laugh] you caused problem, you need to fix it.' So, I started writing down how to do what today we call Scrum at Scale. And everybody, you know, most of those people in the industry were implementing IT scaling frameworks. They were all upset. ‘Why are you writing down another framework?' Well, it's because those IT frameworks do not enable the organization to show Business Agility, and win in the market. And in the best companies in the world, they're being thrown out. So, I've had to write down how do you add, how do you go to hundreds and thousands of Scrum teams - and never slow down as you're adding more and more teams. You know, every team you add is as fast as the first team when you start. Yeah, that's what Scrum at Scale is all about. So, there's two primary things that I'm focused on today. One is to fix all this bad Scrum. Second is to fix the scaling problem. Because it turns out that if you look at the latest surveys from Forbes magazine, and the Scrum Alliance on successful Agile transformations - I learned recently, that almost every company in the world of any significance is going through an Agile transformation or continuing transformation they'd already started years ago. And 53% of them do not meet management expectations. And the MIT Sloan Business Review did an analysis of what happens if an agile transformation fails, and 67% of those companies go out of business. So, this is becoming really serious, right? To be successful today, if you're competing in any significant way, you have to be agile. And number two, if you try to be agile and fail, you have a 67% chance going out of business. And the failure rate is 53%. So, this is the problem that we're wrestling with. And half of that 53% failure is due to the bad Scrum we talked about, but the other half is due because of the leadership not being Agile. Ula Ojiaku: I was just going to say, as you said something about the leadership not being agile. In my experience, you know, as an agile coach in some organizations whilst the teams would embrace you know, Scrum and embrace Agility - the practices and the processes and everything. There's a limit to, you know, how much they can get done… Jeff Sutherland: Absolutely… Ula Ojiaku: …if the leadership are not on board. So… Jeff Sutherland: …you hit this glass ceiling. So, I've been, you know, giving presentations on Agile Transformations around the world. And I can remember multiple times I've had 300 people in the room, say, and I say okay, ‘How many of you are agile, in Agile transformations or continuing the ones you'd started?' Of course, everybody raises their hand. ‘How many of you have waterfall traditional management that expects you to deliver all the old (laugh) Gantt Chart reports that we always got, and don't understand what you're doing?' There's 300 people in the room and 297 people raised their hand. I said, ‘you need to give your leadership the book by Professor Kotter called Accelerate.' Professor Kotter is one of the leading change experts of the world. Ula Ojiaku: And he also, yeah, He also wrote ‘Leading Change' as well - the book, yes. Jeff Sutherland: And in that book, he says, if the leadership of the Agile part of the organization is traditional in their mindset and requirements, the Agile Transformation will eventually fail 100% of the time. Ula Ojiaku: Those are sobering statistics in terms of, you know, the failure rate and how much of you know the success hinges on business agility and the leadership being agile as well and taking the time to know and care what it means. Yeah. Jeff Sutherland: And what's happening is that the Agile Leadership today, if you look at some of the companies that have been most successful during COVID, one of them is John Deere Corporation, the biggest farm equipment manufacturer in the world, probably the oldest. Their stock price went up more than Amazon during COVID. And the board of directors gave their Agile Leadership, the Agile Coaches, Scrum Masters, the highest award in the Corporation for producing that result. So that's another reason I'm trying to communicate to Agile people. The success and survival of your company depends on you. You think your management's going to save you but no, if they are old-style people, they are going to run that company out of business. And you need to either save it before it goes out of business or run to another company before bad things happen. Ula Ojiaku: It's impressive that, you know, John Deere being a farm equipment manufacturer… I think they were ahead of the curve you know, (compared to some of their contemporaries in that industry as well) and embraced agile ways of working. Do you know how their Agile Leadership were able to quantify their contributions to the company? Jeff Sutherland: John Deere started to get Agile more than 10 years ago. So, they've been at it a long time. But in recent years, they really started to build… build internally… Agile leadership, you know, based on my work and they started applying that across the company. I mean, the major focus has not been software actually – it's been in other parts of the company. What has to happen to run a company that's building tractors? [chuckles]. Well, there's all kinds of things that have to happen, you know - purchasing, there's legal [Laugh], there's acquiring all the pieces, it's putting them together at the assembly line, you know, software is a piece of it. You know, that's probably the easiest piece to fix with Agile, it's the rest of the company that's the challenge. They have started doing that really well which is reflected in their stock price. Ula Ojiaku: Amazing. So, you said something about you know, you're out to fix a couple of things, the problem with bad Scrum out there. And, you know, the problem with scaling agile. Jeff Sutherland: Right Ula Ojiaku: So, with respect to the first one, the point about bad Scrum, what in your experience would be the root cause of bad Scrum implementations in organizations? Jeff Sutherland: There're about 11 things, that if you fix them, the team will go twice as fast. And it's multiplicative. So, you know, we have extensive data on, you know, really big companies. What's the difference between the fastest team and the slowest teams? The fastest teams are 2000 times faster than the slowest teams. So why is that? Well, first, the team has to be small. The optimal team size is four or five people. If you have a 10-person team, that's going to take at least 50% longer to get anything done. If you go out, look at the team size, you'll see companies have even not only ten-people teams, they have 15 people in a team, 25 people in a team, okay? Those teams are never gonna meet Agile performance. Second, the backlog needs to be really ready in a sense of small, it's clearly understood, it's properly prioritized. So, you need somebody managing that backlog that can get it right, because we have extensive data for multiple case studies showing the team's production doubles immediately. As soon as you get that backlog right. So you go into many companies, you'll see, there's still arguing about what's the top priority, right? Or everything's top priority. That's just gonna create a massive mess. Third, teams are constantly interrupted. You know, the only teams I know that aren't interrupted are people… these teams and defense contractors working on top secret stuff. And they work in a locked room, [Laughs] the door, it says ‘no managers can enter', [Laugh] and they don't get interrupted. But for the rest of us, there's always somebody coming in wanting something else done. And there's a way to manage that using a pattern we call the interrupt buffer. And if you don't have that pattern implemented properly, you're gonna go half as fast. If you're lucky, you might go half as fast. Ula Ojiaku: And what do you say the Scrum Master has a part to play in making sure the interrupt buffer is there and it's enforced? Jeff Sutherland: The scrum master needs to set this all up. Fifth, in high performing teams, we see this pattern called swarming, where multiple people are working on a story together. That increases the process efficiency, which doubles the performance of the team. So, if people are specialists working independently, that team is going to be really slow. So I'm up to number five, there are six more things, but you probably want to go through them. It's very clear, what makes agile teams suck, we know exactly why. And it needs to be fixed. So, I appeal to anyone listening to this help [Laugh] fix bad agile, it's hurting us all. Ula Ojiaku: Thank you for sharing that. Would this be in any of any of your books or in any of your articles that you've written? Jeff Sutherland: Yeah, it's everywhere and (in) everything I've written, but the best summary, it's the red book Scrum … Scrum, The Art of Doing Twice the Work and Half the Time And we've had people pick, pick this up. A CEO in Kenya came to New York to one of my courses, he said, ‘Jeff, I just read your book. And I'm CEO with three new energy startups in Kenya. And my teams implemented that, and they're going… they're doing three times the work and a third of the time. So, your book is too conservative.' He says to me, this guy, he only read the book, he had no training. So, this book is enough to really get off on the right foot. And if you're having problems, it's enough to fix things. In fact, recently before COVID when we could get everybody together, we had an Apple employee in the class and she said, Jeff, do you know why Apple always meet its states? I said, no, you know, Apple is really secretive. They don't tell anybody anything. She says ‘it's because they do Scrum by the book.' So, I said, ‘What book?' She says, ‘The Red Book - Scrum, The Art of Doing Twice the Work and Half the Time - they do it exactly by the book.' So, again, my message to the Agilists out there: Apple is winning. They are the most valuable company in the world. And it's because they do Scrum exactly by that book. So, you probably should read it. Ula Ojiaku: Definitely. So going by the book, would you say there's any wriggle room for adapting to one's context, or is it about you know, going, ‘check- we've done page 123…' Jeff Sutherland: Well, the whole thing about adapting is fundamental to Scrum. So, one of the things I'm constantly doing in my talks, training, is I'm going back to before Scrum and reading a paper from the leading researchers on complex adaptive systems, in which they mathematically proved, you model things on the computer, that systems evolve more quickly, if they have more degrees of freedom, up until you hit a boundary where the system goes into a chaotic state. So, from the very beginning in Scrum, maximizing the freedom and the decision capability of the team has been fundamental. And we talked about this as self-organization. Now, unfortunately, that term has been so misused, misunderstood that we had to take self-organization out of the Scrum guide. And what we inserted was self-managing. And we put next to it goals, okay, the theme is self-managing to achieve a goal. And to make that happen, they need a commitment to do that. And so, this is one of the fundamental things for Agile teams that work that they have that self-managing commitment to achieve a goal. And the teams that are not working, they're fuzzy about that, right. So, we want the maximum degree of adaptation, the thing that they don't want to change is the basic structure that's in the red book, if they change that, it has the control mechanisms to allow the maximum degree of self-organization - not to go off the rails. Ula Ojiaku: Right. Jeff Sutherland: So, we see a lot of Agilists, ‘oh, you know, let's just tweak the framework this way or that way.' And then the self-organization takes a team off the rails, and then they fall into that 58% that can't deliver, they're late, they're over budget, the customers aren't happy. And so, this is the really one of the hardest things to communicate to people. There're certain things that you absolutely have to be disciplined about. You have to be more disciplined to get a great Agile team than in all ways of working. And that discipline is what allows the maximum degree of self-organization and self-determination, [Laugh] right? So, understanding those two things together, you know, it makes it makes people's brain explode, [Laugh] right? It's hard. Ula Ojiaku: But it works. Jeff Sutherland: But it works right. [Laugh] Ula Ojiaku: You've already mentioned a lot of books in the course of this interview session, and these would be in the show notes. So, would there be anything any final word of advice you'd have for the leaders that would be listening to this podcast in terms of their transformation journey? Jeff Sutherland: So, one of the things we did to Scrum at Scale is that the difference between that and most of the other scaling frameworks is that it's all about the leadership. So, we need an operating leadership team, that is a Scrum team that needs a Scrum Master, a Product Owner, backlog. And its objective is to improve the Agile implementation of the organization. On the prioritization side, we need a leadership team that, led by a Chief Product Owner, that is prioritizing backlog across the organization. So, you know, I've had the Chief Product Owner of Hewlett Packard in my course, he had a $200 billion portfolio. He learned from that class. Says this class is pretty good.' He said, ‘In just one slide I figured out how to get $20 billion more a year with no additional resources' [Laugh]. Just by understanding how to work the framework right? At the $200 billion level. Ula Ojiaku: And you're talking about the Scrum at Scale course, right? Jeff Sutherland: No, this was a product owner course. Product Owner course. He came to it. We're now doing a Scrum at Scale… we're actually doing a Chief Product Owner course. So, a Product Owners at Scale course which it has been really well received by the leading Agile Practitioners. (They) really like that because they need to work more in the large than in the small often. Ula Ojiaku: Definitely. That means this available on the Scrum Inc site? Jeff Sutherland: Yes. Ula Ojiaku: Okay. Jeff Sutherland: So, one of the things I would recommend I would really recommend is the Scrum Field Book. It's a bunch of case studies for organizations, large and small, that have tried to take the whole organization to Scrum. Well, thank you so much, Dr. Sutherland - it's been a great pleasure having you and hopefully we could have a you know, follow up conversation sometime. Jeff Sutherland: Yes. Thanks for inviting me and glad to do it again. Ula Ojiaku: That's all we have for now. Thanks for listening. If you liked this show, do subscribe at www.agileinnovationleaders.com. Also share with friends and leave a review. This would help others find the show. I'd also love to hear from you, so please drop me an email at ula@agileinnovationleaders.com. Till next time, take care and God bless!   PROMOTION: Sign up for a free month's trial with Amazon Music to get unlimited, ad-free access to 75 million songs, podcasts  in HD here: https://www.amazon.co.uk/music/unlimited?tag=agileinnovati-21 *  * By clicking "Sign up and pay," you agree to the Terms of Use and authorize Amazon to charge your default card, or another card £7.99 per month after your trial. Your subscription renews automatically until cancelled. Cancel renewal anytime by visiting Your Amazon Music Settings.

Interview video available on the Agile Innovation Leaders Youtube channel: https://youtu.be/FYFKaJoagTc Guest Bio: Dr. Ivar Jacobson is the Founder, Chairman and CEO of Ivar Jacobson International. He received his Ph.D. in Computer Science from KTH Royal Institute of Technology, was awarded the Gustaf Dalén medal from Chalmers in 2003, and made an honorary doctor at San Martin de Porres University, Peru, in 2009. Ivar has a flourishing career in both academia and business. He has authored ten books, published more than a hundred papers and is a frequent keynote speaker at conferences around the world. Ivar is a father of components and component architecture - work that was adopted by Ericsson and resulted in the greatest commercial success story ever in the history of Sweden, and it still is. He is the father of use cases and Objectory, which, after the acquisition of Rational Software in 1995, resulted in the Rational Unified Process, a widely adopted method. He is also one of the three original developers of the Unified Modelling Language. But all this is history. Ivar founded his current company, Ivar Jacobson International, which since 2004 has been focused on using methods and tools in a smart, super light and agile way. This work resulted in Ivar becoming a founder and a leader of a worldwide network, SEMAT, which has the mission to revolutionize software development based on a kernel of software engineering. The kernel has been realized as a formal OMG standard called Essence.   Contact/ Social Media Email: ivar@ivarjacobson.com LinkedIn: https://www.linkedin.com/in/ivarjacobson Twitter: @ivarjacobson Books The Essentials of Modern Software Engineering by Ivar Jacobson et al https://www.amazon.co.uk/Essence-Software-Engineering-Applying-Kernel/dp/0321885953 Denotational Semantics by Joseph E Stoy https://www.amazon.co.uk/Denotational-Semantics-Computer-Science-Scott-Strachey/dp/0262690764 Resources/ Websites Essence for Agility Meetup https://meetup.com/essence-for-agility Essence Education Forum https://forum.essenceineducation.org    Ivar Jacobson International https://ivarjacobson.com   Interview Highlights: Timestamp 02:59 – Growing up in Sweden 07:05 – Coming up with concept for component-based software development and architecture 15:14 – On Essence OMG Standard as a unifying platform for methods 24:22 – Special offer announcement (Better Scrum Through Essence course) 29:41 – “Shy Boys Don't Kiss Beautiful Girls” – Swedish proverb 32:34 – “Doing it smarter…”   Interview Transcript Ula Ojiaku: 0:04 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. Hello everyone! Welcome to Season 2 of the Agile Innovation Leaders podcast! I'm honoured to have Dr Ivar Jacobson – Founder, Chairman and CEO of Ivar Jacobson International (IJI - a global consulting and training organisation) as my guest on this episode. Known as one of the fathers of modern software engineering, he has many accomplishments under his belt including developing the concept of Use Cases and Use Case modelling. In this episode, Dr Jacobson shares his experience growing up in Sweden; how he came up with the concept for components and component architecture whist at Ericsson (which helped Ericsson with its remarkable commercial success) and his current focus on Essence, an Object Management Group (OMG) standard revolutionising the world of Software Development. Quick sidebar: Ivar Jacobson International Chief Scientist, Ian Spence will be delivering a training on ‘Better Scrum Through Essence' this November, 2021. Make sure you listen to the very end for details on offers available to AILP listeners. You won't want to miss this! Without further ado, ladies and gentlemen, my conversation with Dr Ivar Jacobson – enjoy! Ula Ojiaku: 02:28 Thank you so much Ivar for joining us on the Agile Innovation Leaders' podcast. It's a great pleasure to have you. Ivar Jacobson: 02:35 Thank you. Thank you. I'm looking forward to it. Ula Ojiaku: 02:40 Well, I've been very excited right from when I got your response saying “yes”, the honor is definitely mine. Now, with I know that our audience would be, you know, keen to know, who is Ivar, you know, can you tell us about yourself? Ivar Jacobson: 02:59 Yes, I can. I was born in a very nice family in a small city, in Sweden, in the very south of Sweden, very close to Denmark. And, I was an ordinary kid. Nobody in my family had ever studied, so to speak. My father had six years in school, and my mother, maybe one year more. And he was an entrepreneur, quite successful. And, I hated by the way when I was older, the idea that I would be an entrepreneur, but it always a seed in the blood. So, I was not very good at school, clear. And I remember my mother, when I had passed Junior High School. And I suggested, maybe I should go to high school, I have very low grades. And so, but I can work hard, I said. And my mother said, it's good if you can just pass junior high school. You know, you don't have a head for studies. So, I don't know what happened. But I really got the interest and succeeded to get up to high school. But in high school, I was not very good either. I was more interested in sports, I played handball, handball is similar to soccer, but you play with the hands instead of the feet and it's very popular in Europe, probably gets popular in US too, but it takes time. And I was passionate about it. But even if I worked harder than anyone else, I never really became the star. I was okay. But instead, I became a coach and now I found passion. I really worked hard as a coach, my team became the best team in the city, we had many handball teams, and not only in the city - in the province. And then what I started to know I loved to coach, I loved to feel that I could help people to become better and they became much better. I was a coach both for boys and ladies. So that made me popular. And so, I was very well treated and had a very hard time to imagine moving away from my small city. I went out High School and then I wanted to stay in the city, to be electrician. But my aunt decided differently - she applied to Chalmers which is an Institute of Technology. And, I actually was accepted as the last student, had so low grades, so last student (to be accepted to study) to Electric engineering. Ula Ojiaku: 06:28 Wow! Ivar Jacobson: 06:29 And yeah, I did quite well. I found it so fascinating - engineering, mathematics and so on, but became very different. So, I was the first one in my whole big family that ever passed junior high school, high school, and becoming a bachelor of electrical engineering or almost the master. It was unthinkable in my family. Ula : 07:04 Wow! Ivar Jacobson: 07:05 And then I was absolutely sure I should continue to do research. But I was smart enough, to say you need to know what it means to work in the industry. So, I took the most boring work I could imagine at Ericsson, working with old fashioned systems, not digital, it was a electromechanical. And I was sure after one year, I will go back to Chalmers to get the doctor (my doctorate degree). But after one year, I felt, “this is life!” Projects, people, collaborating, is very different from doing a research at Chalmers. So, it was not in my mind to go back. Instead I learned something absolutely fundamental, that impacted me for the rest of my life, namely, how to build systems. And in hardware, you build with components. So, after a couple of years, I was actually working with hardware system. And they had, the managers had seen something in Ivar. And so, they actually offered him to become project manager for the most mission critical system, which was based on computing. And that was absolutely unbelievable - I knew nothing at that time about computing. And I didn't, I've never written a code. (At the time) I never really understood how a computer works. But I was now Project Manager, and the reason was, they probably felt like I could manage a project and you don't need so deep knowledge, you're probably more difficult if you know too much. But to me, it was unthinkable to be a project manager without knowing how we work and what it was. So, I studied very hard every night. And at that time, there were no books, really, But after three months, I felt well, this was not so hard and now I became difficult. Because I couldn't see that the product we're building would ever be successful. Because Ericsson was selling to the whole world. But every country wanted their own market adaptation. And the way we built software - the standard way of building the software at that time, was not easy to change. Modularity was only in the code-oriented data structures. So, you separate the code and data and this separation meant, if you made a change, it could result in changes anywhere. Anyway, so that's how I came up with component-based development, which was the biggest fight I've ever had in my life. It was when I was 28 plus, and, no one did component-based development at that time, as we heard about Bell Labs, the other competitors did it the same way as Ericsson did. But for some reason, there was one guy ‘up there' who said, “Ivar is right. Let's do it”. And that resulted after some years in the greatest commercial success story in the history of Sweden. And it still is, it's even more successful than ABBA and Spotify – so you can imagine. I was rewarded, I got after 10 years people said, “oh, God that was so good”. And so, I could study, get the PhD during work hours. Ula Ojiaku: 11:34 Wow. Ivar Jacobson: 11:35 So, I think I leave it a little for you now. Ula Ojiaku: 11:40 Know this yours is a very fascinating story. So, there were lots I could pick on (to ask more questions) but the first one you said about, you know, playing handball, and despite how hard you worked, you didn't quite make it as a superstar you wanted to be in handball, but you found out that you did great at coaching. I think there's a parallel to that and coaching in real life as well. A coach doesn't necessarily have to be the expert in the area, but it's really about being able to draw out the best in people. Would you say… Ivar Jacobson: 12:18 And show a path forward… Actually, girls at that time were playing handball in a way that was very girlish, you know, balls like this and not like shooting it . I mean, very softballs. Whereas my girls were trained with my boys. So, I put together guys and girls in the same team and made two teams. And the girls started to play like boys, and that made them superior other teams because they didn't do it. So, I mean, I invented a new method, let's say that. Ula Ojiaku: 13:00 You definitely are an innovative inspiration. It seemed like everyone in your family knew you were barely getting by in Junior High school, High school. I'm wondering, what was it that your aunt saw that made her despite all the indications she went and registered you at Chalmers? Did you ask her? Ivar Jacobson: 13:25 No, I felt, I really didn't think about it. I felt I understood her. I mean, I had showed her that I was not very good at school. So… But then what really happened was that I was fed up by school in the last semester (of) Junior High and wanted to leave. Then she said to me, “No, no, you should at least go get the junior high school graduation”. Because we celebrated it in Sweden at that time, not anymore but at that time. But now when I relaxed and didn't study, didn't prepare for mathematics or anything like that. Really, I tried. I had private lessons in mathematics. I mean, it's hard to believe I had it. And the reason was that the way I had learned was by learning rules. I mean, not thinking. “This is the rule you use when you see this problem” and that limits you. So now for the first time, I had no rules to apply. I start to think, and I remember very well, after one exam that the teacher came in with a book and he had all the books in a package and then he put it on the desk and he says, one of you have (has) decided to change his life; Ivar Jacobson - best in class. And you know, I was flabbergasted and not only me, the whole class. So, and then I understood that was something I could do. So, everything all my grades went up. Ula Ojiaku: 15:14 That's just amazing. So, you are currently, you are credited with you know, developing the used cases, components, the RUP rather the Rapid Unified Process, which is, you know, one of the ‘fore bringers' of Agile Methodologies. And currently you are working or you've been working most recently on Essence, can you tell us a bit more about Essence, what it is and you know, what's the story behind it? Ivar Jacobson: 15:52 Now we were around year 2000. And then, I was a rock star traveling around the world, talking about the UML and Rational Unified Process. And everyone wanted to have… use these things. They misused both UML and they misused RUP (Rational Unified Process), but they were wanted to have it. It's very similar situation with SAFe today. So anyway, at that time, it was very popular. But I… now Agile came. And I remember very well when I was at the OOPSLA (Object-oriented Programming, Systems, Languages and Applications) conference, the biggest conference at that time. And I was on a panel of 2000 people in the audience, and I was there with agilisters really great guys - people I'm very good friends with today. And the audience basically booed every time I was about to talk. Ula Ojiaku: 16:49 Why? Ivar Jacobson: 16:50 Because we're talking about the we enemy, the Empire, the old Empire, that the audience wanted to kill. And I listened very carefully, and then I went home and studied more about XP, it was about XP. And I said, “Okay, this will dramatically change the future”. I tried to convince my company at that time Rational, with the top stars in the company, many famous people. But it took a while; there was nothing new in XP is what I heard. But it was a lot of new (it had lots that were new) particularly about social engineering. So, and then a couple of years later Rational was acquired by IBM and I had a chance to be with IBM in a very interesting position. But I decided no, IBM is too big for me, I want to do my own business. So, but I also was thinking this is not sustainable. The world is ridiculous. Here you have gurus like me, and we play such an important role. And still, the guru is just a methodology salesperson. You can be an expert on a few things, but you're never an expert on all things you need to do when you develop software, or develop anything for that matter. Hardware systems… and anything. So I wanted to get rid of (this attitude). I felt this is stupid. And I use the word foolish because it's a little nicer. But having gurus that develop methods and ideas in the methods cannot be used in another method without rewriting it. So, for instance, Scrum has been used in SAFe, but it doesn't fit into SAFe without rewriting it. And that means with the original authors of Scrum are diminished, instead it moves into something else. So, we get no collaboration between these top guys. They don't like one another. And I'm not talking about any particular person, but that's the general problem. Instead, we want the top guys to collaborate and help to work. So, I came to the conclusion we need to do something dramatically different. Instead of having all these different methods and with nothing in common, nothing in common and that is visible and still a lot is common. It's just hidden, because everyone hides it without the purpose to hide, but it becomes hidden in a particular method. So, what I said is that every method has a number of ideas - you can call them practices or method precepts. They are in a precept guarded by a guru. Isn't this foolish? At least I think so. So, in 2005 we decided in my company to do something different and we started to identify a common ground between all methods. What is it that is essential… that we always do always produce, always have in terms of competences, for instance, and so on. And it created, let me call it the kernel. It's very small, it's very powerful. And it works as a platform to describe methods. So, instead of it (being that) every methodology has its own way of describing everything: its own language, its own terminology, its own isolated island, we created a common ground which has actually become a standard and on top of this standard, people now can describe their own method. So, Scrum, for instance, has become Scrum Essentials. (It) is described on top of this kernel, which is called Essence. A standard is very important, because… first of all, nothing should be standard without being such that everybody can accept it. If there is any, really controversial stuff, throw it out and keep it at such a small level. So, but big enough to be useful, and as useful for everybody. So, now many companies are using Essence to describe their own methods. We are working with Jeff Sutherland (co-creator of Scrum) - he has  ‘Essentialised' as we call it, both Scrum, and his Scrum at Scale. We're also working with Scott Ambler (co-creator of Disciplined Agile Delivery, DAD) who has essentialised some of his practice. He has so many practices. So, he has to wait till we build a bigger library of practice. So, we have it today in my company, we have 100 practices, this guide; 50 of them are published and available. But there are many other people around the world, that develop practices. And we can put them in an ecosystem, which we are trying to do. So, people can go there and select the practices. And they (could) say, ‘I want user stories, I want to Scrum, I want test driven development..', compose, these three practices, and I have my method. And then you can add more and more as you become more and more competent, you scale up, you don't scale down, but you have to do with big frameworks, like RUP and SAFe. So, the idea is that we in this way by collecting knowledge and making it available at one place or many places - similar places can grow competency instead of having (this) so fragmented. You know, in one single company today, you may have 10 different ways of using use cases for instance. Ula Ojiaku: 24:07 True, true… Ivar Jacobson: 24:08 If they don't learn for one. Okay? Ula Ojiaku: 24:13 Because they work in silos, so everyone is just doing their own thing. Ivar Jacobson: 24:18 Yeah, they have their own methodology and everything you know. So… Interlude/ Announcement (Ula Ojiaku) 24:22 Hi again listeners. Quick message before we continue with Ivar Jacobson's interview. Did you know, according to Scrum Inc., 58% of Scrum implementations fail. Dr Jeff Sutherland, co-creator of Scrum says their investigation revealed that, of the 21 components of Scrum, an average Scrum team implements one-third well, one-third poorly and the last one-third not at all! Dr Sutherland also acknowledged that Essence ‘is the key to success…' As mentioned earlier, Ian Spence, Chief Scientist at IJI will be running a 3-day, live virtual training on ‘Better Scrum Through Essence with Essence Games Master certification' this November 2021. If you want proven ideas on how to address failed Scrum implementations, this course is for you! I know - because I'd attended the alpha version of the course earlier on in the year. Register on the website www.ivarjacobson.com  at least 2 weeks before the training to take advantage of the early bird pricing. As a valued Agile Innovation Leaders podcast listener, you can also get an exclusive 5% off when you use the code AILP5OFF. That's AILP5OFF. Back to my conversation with Ivar Jacobson… Ula Ojiaku: 26:32 Wow, well, it does sound like Essence is going to be a game changer. Where do you see it? What's your ideal state for Essence, in terms of adoption? Ivar Jacobson: 26:44 Okay. So, the roadmap is we now have developed tools that we are using with clients and they're tools we never had before - the kind of tools we never had in the software engineering discipline before. And we are using web client learning, and we take, we work with one client after the other. We expect to, at the end of the year, have verified and vetted the work. Then the approach is that we make it more widely available. Okay, and we are looking more for volume than for big accounts. Ula Ojiaku: 27:34 Right, right. Ivar Jacobson: 27:35 So now we are extremely optimistic. There are as, you know, we have a forum … two forums…. One is a meetup called Essence for Agility, which has now in just a couple of months got 2000 members. And next time, we will get my good friend Grady Booch to speak together with (a) couple of other people about Architecture and Agile Methods. We also have created a forum in the academic world called Essence Education Forum; where more than 50 university professors are collaborating to create a material for training and so on, and also do projects and basically anything on top of Essence. So, it's… no I'm very bullish. I've never seen so much progress as now You know, if I look back on the things I have contributed to, and I can say basically all of them have been by first identifying a problem but no one else has identified. And then sell that problem, so other people think it is a problem. And that's not trivial, that's absolutely the hardest thing and once I have succeeded to sell it, then of course the solution is not so far away. Ula Ojiaku: 29:14 Wow. Now that is just fascinating. So, it seemed like in selling your idea, it wasn't really about the technical skill, it was more about what's … quote, unquote, you'd call the you know, “soft skills” of selling, marketing. That you had to…” Ivar Jacobson: 29:27 Yeah, that's it was the most important I mean, you can be the best technical guy had best ideas, but if you cannot sell them, you won't have them. Ula Ojiaku: 29:41 Okay, now it is kind of ties in with, you know one of your favourite (Swedish) quotes that you shared with me that “Shy boys don't kiss beautiful girls”, do you want to expand on that? Ivar Jacobson: 29:59 This is a Swedish expression. There is nothing similar that I know in English that you can say that is strong enough, probably similar but not strong enough. It means basically, that even if you have an idea that is controversial, you have to express it, because it will never … otherwise it will never happen. I remember a situation when I was in South (of) France and at the conference, for it was a conference for executives. And they I had a company with 10 employees and I was CEO. So, I was an executive. It happened that Bill Gates was also there. And he had a company with 10,000 employees. So, we were colleagues. And I was out jogging and came back after half an hour sweating and maybe smelling too. And I saw crowd standing beside the pool. And in the middle of that crowd was Bill Gates. Now is the chance. So, I ran up and I don't know, for what reason… if I was… I was not really rude in any way, but they moved around, they opened - the crowd… and I stood face to face with Bill Gates and I did my elevator pitch. And then we talked a little and when he said he welcomed me to Microsoft, he gave me his business card and said you have to come and talk about the engineering in software. So that's an example of that, shy boys may not kiss beautiful girls. So don't be shy. Ula Ojiaku: 32:09 It reminds me of the saying in English that Fortune favours the brave. So maybe that's the closest saying to that, but it's really about being bold and seizing the moment. Ivar Jacobson: 32:24 Yeah. That is exactly what it is. And by way it's valid in the other direction too. It's not the only boys you're talking about. It can be anything. Ula Ojiaku: 32:34 Well said Ivar. Well said. You also have another quote that you like… or that you use a lot in your organization, “Can we do it smarter?” What do you mean by that? Ivar Jacobson: 32:49 Basically in every situation where you meet difficulties, and you may come up with a solution, that is very straightforward. Most uncontroversial story, solution, but it's really not fantastic. It just is a solution. In this situation, I ask all.. almost always, “can we do it smarter?” And the interesting thing is but if people start to think like that, can we do it smarter? They often come up with smarter solutions. And I have my own experience has been exactly that. Ula Ojiaku: 33:43 Would you tell us about the book you're writing for your son? You said you have a five-year-old son, and you're writing a book for him that's titled “What They Don't Teach You in School?” Ivar Jacobson: 33:58 Yes, I am a very lucky man. I have a five-year-old son. My name is Ivar in Swedish. And his name is Ivar Theodor, which becomes IT. And the thing was not on purpose. It just happened. We like to name; my wife liked the name Ivar Theodor. Ivar is a Viking name. Theodor means God's gift. And then you know, I am not 20 years old. So, (to) get the son is really God's gift if I may use these words. So I want to write the book for him that he can read when, when I don't know where I will be. I'm certain if I will be somewhere else, than on this planet, it will be in heaven, that's for sure. So, he will get the book. And this book is about smart cases. So, I describe situations in life, when you can do something smart or not so smart. I mean, first of all, there is a huge difference between being intelligent and being smart. I have a lot of friends that are extremely intelligent, analytical, and so on, but I wouldn't say they are smart. I have written about the 100 pages, it takes quite a lot of time. And it must be funny or entertaining, otherwise, he will not read it. Ula Ojiaku: 35:44 Now, what books have you found yourself recommending to people, or giving as a gift to people the most and why? Ivar Jacobson: 35:59 Yes, I think two books I would mention and this is also where I could recommend others. One of the most influential books on my career was about the denotation semantics as it's called. It's a way to mathematically describe, for instance, a language. And, I have used it to describe several languages. Ula Ojiaku: 36:35 Denotational Semantics. Okay. Do you know … what was the name of the author, please? I can always (look this up) ... Ivar Jacobson: 36:43 First book I learned was pure mathematics. It was Discrete Mathematics in computer science. And when it comes to Denotational Semantics, I read a book about the Vienna Development Method. The Vienna Development Methods, it was developed by a Dines Bjorner, and Chris, Chris Jones, I think, and a couple of our people at IBM. But then there are later versions on Denotational Semantics that may be that I don't know that. But this is a book I read. Ula Ojiaku: 37:21 It's been a fascinating conversation Ivar, and I really appreciate your time, where can the audience find you, if they you know, want to learn more, or if they want to contact you? Ivar Jacobson: 37:34 They can always contact me via email. And they are welcome to do that. And also, I get a lot of emails, so it may take a couple of days. But I always respond, even if I had to work many hours to do it. But I think attending this Essence for Agility meet up a there will be a lot related to what we have been talking about. And if you're an academic, I would recommend (you) join Essence Education Forum. Ula Ojiaku: 38:20 Okay. And we will put all the links and you know, the resources you mentioned in this, in the show notes. So just to wrap up, then do you have any final word of advice for the audience? What would you like to leave us with, as we end this conversation? Ivar Jacobson: 38:42 Yeah, in some way, the books I mentioned, and the quotes about, the shy boys becoming smarter. But I think what really has helped me has been that if I have an idea, and I believe in it, I don't give up. So, perseverance is probably a very important property. And some people when things were not so good, after introduce components, people will replace perseverance with stubbornness. So, the difference is: if it's good, it's perseverance; if it's bad, it's stubbornness. So, I may be a little stubborn, but I think it's more being persevere. Ula Ojiaku: 39:48 Depends on who you ask. Ivar Jacobson: 39:52 Yeah. So don't give up. Push your ideas. And also, I'm very lucky, I think what I'm doing is fun. I don't do anything for money. I do it for fun. But of course, it's very important to have money. So, I do my best to help my company to make a profit so we can invest in doing these things. It's not money for me, it's money for the company. Ula Ojiaku: 40:29 Thank you for sharing those wise words. Ivar, thank you so much for your time. Ivar Jacobson: 40:35 Thank you. It was a pleasure. Ula Ojiaku: 40:38 The pleasure is mine. Thanks again. That's all we have for now. Thanks for listening. If you liked this show, do subscribe at www.agileinnovationleaders.com.  I'd also love to hear from you, so please drop me an email at ula@agileinnovationleaders.com

Diane H. Leonard, GPC, STSI | https://www.dhleonardconsulting.com/ (dhleonardconsulting.com) Diane is a Grant Professional Certified (GPC) and Approved Trainer of the Grant Professionals Association. Diane has recently become a Certified Virtual Presenter through https://www.espeakers.com/marketplace/speaker/profile/27305/diane-h-leonard-gpc-lst (espeakers). She is also a Scrum Trainer by Scrum Inc, Scrum Master by Scrum Inc, and Scrum Product Owner by Scrum Inc. credentialed by the Agile Education Program powered by Scrum Inc.™ Since 2006, Diane and her team have secured more than $86 million dollars in competitive grant awards for the clients of DH Leonard Consulting & Grant Writing Services. She is an active member of the Grant Professionals Association. She is a graduate of Cornell University in Ithaca, New York, with a Bachelor's of Science in Industrial and Labor Relations.  When not working with her team on grant applications for clients, Diane can be found in the 1000 Islands, out for a run, or drinking a strong cup of coffee. https://resources.foundant.com/education-webinars-for-grantseekers/being-an-agile-leader-in-your-nonprofit-regardless-of-your-title (Being an Agile Leader webinar ) https://resources.foundant.com/education-webinars-for-grantseekers/you-are-not-alone-burnout-is-real-relevant-and-recoverable (Webinar on preventing burnout) https://www.amazon.com/Happy-Healthy-Nonprofit-Strategies-without/dp/1119251117 (Healthy Happy Nonprofits book) https://info.foundant.com/2021-10-08AgileinNonprofitsSummit_RegistrationLP.html (Upcoming Agile Summit) Agile Blogs from DH Leonard Consulting & Grant Writing Services DH Leonard's Agile in Nonprofits website https://www.amazon.com/Scrum-audiobook/dp/B00NHZ6PPE/ref=sr_1_2?dchild=1&gclid=CjwKCAjw7rWKBhAtEiwAJ3CWLIPVTwqaFkLUPFSwYZZ5G7LbCSnw0uu781ESZGXxm3iykxAXaNwjcBoCC1cQAvD_BwE&hvadid=241618947090&hvdev=c&hvlocphy=9021324&hvnetw=g&hvqmt=e&hvrand=18386138660889644940&hvtargid=kwd-333795142695&hydadcr=22597_10356339&keywords=scrum+the+art+of+doing+twice+the+work&qid=1632499702&sr=8-2 (Scrum: The Art of Doing Twice the Work in Half the Time) Contact Info: Twitter: @innonprofits  Facebook: https://www.facebook.com/agileinnonprofits/ (Agile in Nonprofits) Diane'st email: diane@dhleonardconsulting.com  Want to see additional resources? https://resources.foundant.com/ (Visit resources.foundant.com) https://www.foundant.com/events/nonprofits/ (Register for a webinar) and your question might be heard in a future episode! Brought to you by Foundant Technologies.

Learn how to make productivity tools work for you, not run your life in this fun, fast-paced interview with Scrum and Agile expert Avi Schneier, the Principle Consultant, Agile Transformations of Scrum Inc. From writing more grants, to raising more money, to the importance of tracking happiness, we cover the waterfront of efficiency and effectiveness in this episode. In the episode, Avi shared three great scrum related resources, and they are: (1) Book - Scrum The Art of Doing Twice the Work in Half the Time (AKA the red book) (2) Book - The Scrum Fieldbook: Faster Performance. Better Results. Starting Now. (AKA the yellow book) (3) Blog Post - 7 Steps To Hybrid Teams Success - Scrum Inc

This week's interview was one I had wanted to do for a long time. I work as Product Owner working closely with software developers creating apps at a military organization. We use the Scrum framework, which is one of the multiple agile approaches focused in delivering solutions quickly to customers. The approach is not just about being technically savvy, but on making good use of those critical skills like teamwork, listening and management. As many organizations are talking today about becoming “agile” it is important to know what it really means. Dr. Jeff Sutherland (https://www.linkedin.com/in/jeffsutherland/) is the ideal person to discuss this. He is the chairman and founder of Scrum Inc., a signatory of the Agile manifesto, coauthor of the Scrum Guide and the creator Scrum@Scale. He is also the coauthor of the best selling book Scrum: The Art of Doing Twice the Work in Half the Time. Today we talk about the misconceptions of Agile, the origins of the Scrum framework, ,and how his military experience and his work doing scientific computer modeling influenced him.

Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this episode, we explore how the skill of asking questions is so critical for PO's, and we learn from Dahm some exercises to show the importance of that skill.  The Great Product Owner: The Deep Listening PO Great Product Owners are good at listening to the team, and the stakeholders, but mostly to the customers and the market. In this segment, we talk about how PO's can practice deep listening, and use that skill to improve their effectiveness in the role.  The Bad Product Owner: Learning to ask questions with empathy Bad Product Owners have many lacking features, but in this segment, we focus especially on the inability to ask questions from the team, and the customers. Dahm shares some of his signature workshops, and how he uses those controlled environments to help PO's learn how to go deeper in the understanding of the team and the customer. Are you having trouble helping the team work well with their Product Owner? We've put together a course to help you work on the collaboration team-product owner. You can find it at bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO's collaborate. About Dahm Hongchai Dahm Hongchai is an Agile coach, a Scrum Master, and a business consultant with 5 years experience in high-tech and Startup industries in Silicon Valley, Thailand, and Australia. He was the first Thai to become a Scrum Trainer (ST) with Scrum Inc. Dahm also has 10+ years of experience with other approaches such as Lean Manufacturing and Six Sigma. And he is an Agile trainer and helps people to understand Agile via, for example Agile Cooking. You can link with Dahm Hongchai on LinkedIn and connect with Dahm Hongchai on Twitter.

Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. As we dive into the definition of success, we learn about the skill of Deep Listening. Dahm walks us through how that skill can help Scrum Masters bring the team to understand each other better, and learn to collaborate effectively.  Featured Retrospective Format for the Week: Continue / Stop / Start Dahm likes this simple format, because it helps people open up with the help of facilitation. The format is simple to explain and facilitate for Scrum MAsters, and can help them focus on helping the team members start, and continue their conversation.  Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!   About Dahm Hongchai Dahm Hongchai is an Agile coach, a Scrum Master, and a business consultant with 5 years experience in high-tech and Startup industries in Silicon Valley, Thailand, and Australia. He was the first Thai to become a Scrum Trainer (ST) with Scrum Inc. Dahm also has 10+ years of experience with other approaches such as Lean Manufacturing and Six Sigma. And he is an Agile trainer and helps people to understand Agile via, for example Agile Cooking. You can link with Dahm Hongchai on LinkedIn and connect with Dahm Hongchai on Twitter.

Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Dahm was working with an exec team, which was not able to collaborate. Scrum Masters are responsible for collaboration in the teams they work with, and executives are just as much a team as any other team. Dahm explains how we can help teams learn to collaborate, and create a trustful environment. In this segment, we refer to the book: The 5 Dysfunctions Of A Team by Lencioni.  About Dahm Hongchai Dahm Hongchai is an Agile coach, a Scrum Master, and a business consultant with 5 years experience in high-tech and Startup industries in Silicon Valley, Thailand, and Australia. He was the first Thai to become a Scrum Trainer (ST) with Scrum Inc. Dahm also has 10+ years of experience with other approaches such as Lean Manufacturing and Six Sigma. And he is an Agile trainer and helps people to understand Agile via, for example Agile Cooking. You can link with Dahm Hongchai on LinkedIn and connect with Dahm Hongchai on Twitter.

Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this episode, we discuss how teams are often unaware of what is going on around them. Their desire to perform and focus on their work, can lead them to ignore the dependencies around them. Dahm shares one such story, and we discuss what we can do as Scrum Masters to help teams be aware, and react to what other teams need around them.  Featured Book of the Week: Peopleware: Productive Projects and Teams by DeMarco and Lister In Peopleware, by DeMarco and Lister, Dahm found a call to focus on people, which was missing in his experience. Many businesses are good at technology, but are not so good with co-workers and people in the business. The book covers many insights that help Scrum Masters understand and implement the people focus that is often missing. How can Angela (the Agile Coach) quickly build healthy relationships with the teams she's supposed to help? What were the steps she followed to help the Breeze App team fight off the competition? Find out how Angela helped Naomi and the team go from “behind” to being ahead of Intuition Bank, by focusing on the people! Download the first 4 chapters of the BOOK for FREE while it is in Beta! About Dahm Hongchai Dahm Hongchai is an Agile coach, a Scrum Master, and a business consultant with 5 years experience in high-tech and Startup industries in Silicon Valley, Thailand, and Australia. He was the first Thai to become a Scrum Trainer (ST) with Scrum Inc. Dahm also has 10+ years of experience with other approaches such as Lean Manufacturing and Six Sigma. And he is an Agile trainer and helps people to understand Agile via, for example Agile Cooking. You can link with Dahm Hongchai on LinkedIn and connect with Dahm Hongchai on Twitter.

Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Dahm shares a story from his own journey as a Scrum Master. When Dahm started, he felt comfortable being a facilitator, which is an important skillset for Scrum Masters. However, that's not enough. When reflecting on that story, Dahm understood that as a facilitator he was missing a critical aspect for the team to succeed: he wanted to facilitate Scrum, but the team was not ready for that. Listen in, to learn how Dahm changed his approach away from a pure-facilitation focus to a more leadership and coaching focus!  About Dahm Hongchai Dahm Hongchai is an Agile coach, a Scrum Master, and a business consultant with 5 years experience in high-tech and Startup industries in Silicon Valley, Thailand, and Australia. He was the first Thai to become a Scrum Trainer (ST) with Scrum Inc. Dahm also has 10+ years of experience with other approaches such as Lean Manufacturing and Six Sigma. And he is an Agile trainer and helps people to understand Agile via, for example Agile Cooking. You can link with Dahm Hongchai on LinkedIn and connect with Dahm Hongchai on Twitter.

An interview with Henry Latham. Henry started out studying Spanish & Portuguese before having an epiphany and moving into foundership and product management. Disappointed with the applicability of some of the education materials out there, and reeling from being fired by a dysfunctional product company, he decided to double down and build an education programme to really help people move the needle and build products effectively. We talk about a lot, including: How dissatisfaction with all the standard product content out there drove him to start Prod MBA, and how it differs from other more established product schools Details of the Prod MBA approach and how they get you from defining a vision and building a releasable product in 8 weeks How to land product thinking with people that aren't necessarily from a product background and have a more traditional view of business How to sell the concept of business risk to traditional stakeholders and get comfortable with risk yourself How getting fired from a product job opened his eyes and led him to inspire better product managers in the future The importance of getting out of negative thought patterns & not accepting your fate but actually working to make it better How to help people to move the needle in dysfunctional companies and making your own moves to demonstrate the value of product thinking Why he wrote his two books "Why Your Startup is Failing" and "Product Leadership Starts With You", some of the key themes, and how they'll help you be a better founder & build better products Some of the problems he has with agile frameworks, specifically Scrum, what his alternative is and whether it's Scrum Inc's job to fix it And much more! Check out Prod MBA If you like the sound of Henry's product training programme, check out the Prod MBA website for more details. Buy Henry's books Henry has two books: "You want your product to succeed. Yet considering nearly 90% of products fail, how can you ensure that you are part of the 10% that actually succeed?"   Check it out on Amazon or Goodreads. "Despite what many aspiring product leaders may think, being an effective product leader is not about using the right frameworks, the right methodologies or delivering features quickly. Instead, it's about something entirely different: Building a strong foundation for product success that starts with you."   Check it out on Amazon or Goodreads. Contact Henry If you want to catch up with Henry, you can reach him on LinkedIn.

In this episode, Richard interviews Jeff Sutherland, a co-creator of the Scrum, founder of Scrum Inc., inventor of Scrum@Scale, and a signatory of the Agile Manifesto. He is also the author of the international bestselling book Scrum: The Art of Doing Twice the Work in Half the Time. Jeff shares with us his personal experiences which made him one of the leaders of the IT industry and beyond. Read the full transcript of the episode at https://kasperowski.com/podcast-67-jeff-sutherland/.

The success of a construction project depends on owners, designers, GCs, and trade partners working together as a team. But with the divergence of ideas and information, how can we achieve a win-win environment for each project-delivery process? In this episode, we have Felipe Engineer-Manriquez, Director, Lean of McCarthy Building Companies, Inc., who will walk you through the fundamentals of strategic problem-solving when delivering projects to clients. We will also discuss the different project delivery methods and the mindset people need to adopt to provide desired results.  Tune in now and stay with us until the end to discover the fool-proof way to project delivery! Discussion Points: 0:00 Introduction 2:42 “Construction: it sucks, but it’s fun,” is it true?3:55 Strategic problem-solving in the construction industry6:02 Understanding the client’s perspective12:04 The design-bid-build model14:14 Educating clients about different types of project delivery18:47 When do you walk away from a project opportunity?22:22 Key performance indicators in construction25:24 What is a non-commodity trade?29:32 Why do projects fail?31:06 The importance of increasing information flow in the success of a project42:35 What is visual management?44:29 Laying a foundation of respect for people49:46 Healthy self-respect vs. unhealthy ego58:25 Felipe’s opinion on the paradigm shift in the construction industry1:05:46 How to achieve a more collaborative project delivery method About the Guest:  International Lean speaker, a serial intrapreneur, Felipe Engineer-Manriquez is a committed Lean practitioner sharing decades of construction industry experience as the host of The EBFC Show Podcast (www.theebfcshow.com). Engineer-Manriquez is an active contributing member of the Lean Construction Institute (LCI) and is an approved instructor/facilitator and 2019 LCI Chairman’s Award recipient for contributions to the Institute and the design and construction industry as a whole. Felipe has a Bachelor of Science in Electrical Engineering, a Master of Business Administration, and leads the Lean Construction Program for McCarthy Building Companies, Inc. Moreover, Engineer-Manriquez is a Jeff Sutherland Certified ScrumMaster® and Scrum Trainer by Scrum Inc.™ in addition to being a Product Owner by Scrum Inc.™ and Certified Scrum@Scale Practitioner™. Resources:  Do Your Project Executives Need to Become Better Leaders? Book a 10-minute call with Eric Anderton (https://10minutes.youcanbook.me/)  The EBFC Show (www.theebfcshow.com) Connect with Felipe Engineer-Manriquez on LinkedIn, Twitter, and Instagram https://www.linkedin.com/in/engineerfelipe/  https://twitter.com/felipe_engineer  https://www.instagram.com/thefelipeengineer) Subscribe to Felipe’s Youtube Channel (https://www.youtube.com/c/FelipeEngineer) Lean Construction Institute (https://www.leanconstruction.org/) Lean IPD (https://leanipd.com/) Lean Construction Blog (https://leanconstructionblog.com/) Recommended Restaurant:  Jamba Juice (https://www.jamba.com/) Connect with me on LinkedIn. For more podcast episodes, you may also visit my website. Tune in and subscribe to the Construction Genius: A Leadership Master-Class Podcast on Apple Podcasts, Spotify, and Stitcher. Thank you for tuning in! 

Alisa Stolze ist zu Gast in dieser Folge, in der es um das Thema "Women in Agile" geht. Mit David spricht sie über ihr umfassendes Engagement in unterschiedlichsten Organisationen, wie der Scrum Inc., dem Scrum Day, Scrum-events.de oder dem "Agile Frauenstimmen"-Meetup. Nachdem wir die Frage nach dem "Warum" für die Women in Agile-Konferenz geklärt haben, sprechen wir natürlich auch über das gesamte Thema Gleichberechtigung und gendern uns vom einen in das nächsten Fettnäpfchen:in. Viel Spaß beim hören.

Dr. Jeff Sutherland invented Scrum to help people make better products and services faster and with people having a good time doing it. Jeff Sutherland, Scrum co-creator, and Scrum Inc. Principal, Dee Rhoda, share why design & construction companies are implementing Scrum to: ✅  gain market advantage ✅  honor people to increase pride in work well done ✅  drive towards desired outcomes ✅  deliver projects on-time ✅  deliver on-budget ✅  meet customer expectations Project teams that more quickly adapt to changes, overcome obstacles and remove bottlenecks deliver more value while having more fun too.  If you are ready to serve a design and construction project team or your organization it's time to adopt Scrum and reliably deliver your projects safely, on-time, on-budget, and to customer's expectations. Lean and Scrum together are Jeff's recommendations for companies that want to survive today and tomorrow. Not sure what Scrum is, watch this video to see what it is and how it works. [Updated] Scrum Framework - How Scrum Works Today via YouTube:  https://youtu.be/zVNnEIf_PLY Jeff's Book Recommendations: Scrum: The Art of Doing Twice the Work in Half the Time by Jeff and JJ Sutherland Certain to Win by Chet Richards Accelerate by John P. Kotter A Scrum Book by Sutherland, Coplien, and The Scrum Patterns Group Business Dynamics, Systems Thinking and Modeling for a Complex World by John D. Sterman Connect with Jeff via  LinkedIn at https://www.linkedin.com/in/jeffsutherland/ Connect with Dee via  LinkedIn at https://www.linkedin.com/in/deerhoda/ Connect with Felipe via LinkedIn at https://www.linkedin.com/in/engineerfelipe  Twitter at https://twitter.com/felipe_engineer   Instagram at https://www.instagram.com/thefelipeengineer     Today's episode is sponsored by Construction Accelerator. Construction Accelerator is an online learning system for teams and individuals that offers short, in-depth videos on numerous Lean topics for Builders and Designers to discuss and implement, just like on t his podcast. This is tangible knowledge at your fingertips in the field, in the office, or at home. Support your lean Lean learning at your own pace. Learn more at http://trycanow.com/    Today's episode is also sponsored by the Lean Construction Institute (LCI). This non-profit organization operates as a catalyst to transform the industry through Lean project delivery using an operating system centered on a common language, fundamental principles, and basic practices. Learn more at https://www.leanconstruction.org   –––––––––––––––––––––––––––––– The EBFC Show Intro Music: California by MusicbyAden https://soundcloud.com/musicbyaden   Creative Commons — Attribution-ShareAlike 3.0 Unported — CC BY-SA 3.0 Free Download / Stream: https://bit.ly/al-california  Music promoted by Audio Library https://youtu.be/oZ3vUFdPAjI  ––––––––––––––––––––––––––––––

Dr. Jeff Sutherland invented Scrum to help people make better stuff faster and have a good time doing it. JJ Sutherland is the CEO of Scrum Inc, the leading provider of Scrum training and consulting. He is the author of two of my favorite Scrum books, “The Scrum Fieldbook: A Masterclass on Accelerating Performance, Getting Results, and Defining the Future” and the red book, “Scrum: The Art of Doing Twice the Work in Half the Time.”  JJ is a worldwide leader in Scrum. He shares how Scrum can be used across industries and has firsthand experience using the framework to help teams deliver faster, much faster.  Connect with JJ via LinkedIn at https://www.linkedin.com/in/jj-sutherland-b1486b6/ Connect with Felipe via LinkedIn at https://www.linkedin.com/in/engineerfelipe  Twitter at https://twitter.com/felipe_engineer   Instagram at https://www.instagram.com/thefelipeengineer     Universal Paperclips Game Links: Online https://www.decisionproblem.com/paperclips/  iPhone https://apps.apple.com/us/app/universal-paperclips/id1300634274 Android https://play.google.com/store/apps/details?id=com.everybodyhouse.paperclipsuniquetest   Today's episode is sponsored by the Lean Construction Institute (LCI). This non-profit organization operates as a catalyst to transform the industry through Lean project delivery using an operating system centered on a common language, fundamental principles, and basic practices. Learn more at https://www.leanconstruction.org   Today's episode is also sponsored by Construction Accelerator. Construction Accelerator is an online learning system for teams and individuals that offers short, in-depth videos on numerous Lean topics for Builders and Designers to discuss and implement, just like on t his podcast. This is tangible knowledge at your fingertips in the field, in the office, or at home. Support your lean Lean learning at your own pace, visit Try CA Now dot com. Learn more at http://trycanow.com/     –––––––––––––––––––––––––––––– The EBFC Show Intro Music: California by MusicbyAden https://soundcloud.com/musicbyaden​  Creative Commons — Attribution-ShareAlike 3.0 Unported — CC BY-SA 3.0 Free Download / Stream: https://bit.ly/al-california​ Music promoted by Audio Library https://youtu.be/oZ3vUFdPAjI​ ––––––––––––––––––––––––––––––

Dr. Jeff Sutherland invented Scrum to help people make better stuff faster and have a good time doing it. Avi Schneier helps Jeff do that, specializes with Scrum outside of software, and shares how using Scrum with large firms led to the Scrum at Scale Guide for multiple teams. Avi Schneier is a Principal Consultant at Scrum Inc. responsible for international needs in the Asia Pacific region and some Fortune 500 and 200 clients in the United States. “A bad attitude and a Brooklyn accent goes a long way to get leadership to listen to you.”  Avi shares how any organization can adopt Agile and Scrum and why the framework goes beyond Plan, Do, Check, Act (PDCA) Lean Thinking. YouTube Video at https://youtu.be/XWdzyaFR97A  Follow Avi on LinkedIn at  https://www.linkedin.com/in/avi-schneier/  Follow Felipe on social media via LinkedIn at https://www.linkedin.com/in/engineerfelipe Twitter at https://twitter.com/felipe_engineer  Today's episode is sponsored by the Lean Construction Institute (LCI). This non-profit organization operates as a catalyst to transform the industry through Lean project delivery using an operating system centered on a common language, fundamental principles, and basic practices. Learn more at https://www.leanconstruction.org

Scrum with distributed teams. Agile in a traditionally non-Agile environment. Project Management in the time of Agile: is it still relevant? These are the topics we cover in the third episode of our series from the 2020 UMD Project Management Symposium. Listen to highlights from the three presentations, along with follow-up interviews with the presenters. Listen, learn, and get a free PDU! PDU Information Use the following information in PMI’s CCRS system to register the PDUs for this podcast: PDU Category: Online or Digital Media Provider Number: 4634 PDU Claim Code: 4634ASFWPF Activity Number: PMPOV0079 PDUs for this episode: 1 About the Speakers   Christine Brennan Schmidt has worked at the American Chemical Society for approximately 27 years. She has managed education programs and two textbook projects. In 1999, she made the jump to technology. She has worked on technology-based projects and products in positions within IT and Membership divisions. She currently has a wide variety of functions, including project manager for various department-led initiatives, product owner for a social collaboration platform, consultant on various enterprise-wide projects, and staff liaison to a governance committee. JJ Sutherland is the CEO of Scrum Inc., a consulting and training firm that uses Scrum to rapidly deliver results in companies across the globe. He is the author of The Scrum Fieldbook: A Master Class on Accelerating Performance, Getting Results, and Defining the Future, and coauthor of Scrum: The Art of Doing Twice the Work in Half the Time, written with his father, Jeff Sutherland, the co-creator of Scrum. Richard Wyatt has worked across the globe in UK, US, Australia and Indonesia delivering projects of growing size and complexity. He recently spent nearly five years as Director of Strategic Programs at TIAA, a leading Financial Services provider. During his career he has observed project managers struggle, as the size of their projects increase, and has researched and articulated the skill set required to be successful.

This week, Dan Neumann is joined by his co-host and collaborator, Sam Falco, to discuss the topic of professional Scrum.   What does professional Scrum refer to? What is professionalism? What does a professional Scrum Master look like? What does it look like to practice Scrum professionally through principles and values laid out in The Scrum Guide? What does professionalism look like on a Scrum team? Sam and Dan answer all of these questions and more in this episode!   Key Takeaways What does professional Scrum refer to? Ken Schwaber’s definition: “A professional is someone who works for money and follows the rules established for the profession. Professionals act and work according to standards where they exist. They also embrace and embody a set of ethical principles established by their profession.” Adhering to the rules set forth in The Scrum Guide The Scrum values fulfill the role of the “ethical principles” in the software development industry A mindset of professionalism and a commitment to a certain set of standards An emphasis on communication and empathy between business and development (so that you can ensure that you are delivering what the customer actually wants and can use) Professionalism includes really understanding why you’re doing the things that you are doing Examples of professionalism: If you are shooting to release a product to end customers by a certain date, how do you use the Scrum events, the sprint planning, the daily Scrum, and the sprint review within the sprint timebox to make sure that you’re on track? In the sprint review, identify which adjustments and decisions are needed, and iterate Important notes about doing Scrum professionally through The Scrum Guide: It’s not just about having the roles, artifacts, and events in place; you also need to be cognizant of the rules that bind these three things together Commit each sprint (as a team) to a goal, not a scope When a sprint goal is a laundry list of things to do it can become overwhelming — it is much better to commit to a goal and negotiate your scope as you go throughout the sprint Focus on delivering on the goal; delivering on the value It is important that the organization gives the Scrum team(s) space to be professional “Professionalism is not just for the Scrum team, just as the Scrum values are not just for the Scrum team; they’re for the organization to live and make space for.” The responsibilities of a professional Scrum Master: They are responsible for coaching the Product Owner, the team, and the organization on how to use Scrum in an effective way The Scrum Master should not be a glorified administrator The Scrum Master should be working with the entire organization to help it achieve business agility and valuable outcomes rather than just lots and lots of output Look for ways in which the organization is inhibiting your team’s further growth and success Look for the areas and opportunities in the organization for further agility Aspects of professionalism on a Scrum team: Strong collaboration (i.e. the Product Owner and the team need to collaborate, and the Scrum Master needs to collaborate with the team, the Product Owner, and the organization) “What does it mean to be a professional Scrum developer?” It’s more than “I’ve got my work done” The team should not be working siloed At the daily Scrum, the team should be collaborating on the most effective thing to do that day to get closer to the sprint goal, figure out who needs help, and understand who’s doing what Toward the end of the sprint when development work is winding down, it is important that developers are helping the test activities happen “The development team is not just the people that are writing the code; it’s all of the people on the Scrum team that are needed to deliver that increment, aside from the Product Owner and the Scrum Master.” It is important to find the balance between being a “busybody” and being a “T-shaped person” A healthy team spirit is vital Reduncies in skill sets of team members are incredibly valuable Being open to learning new things beyond your expertise and having the intellectual curiosity to step outside of your role makes for a healthy, well-rounded team   Mentioned in this Episode: The lawsuit between Scrum Alliance and Scrum Inc. Scrum Alliance Scrum Inc. Ken Schwaber Mastering Professional Scrum: A Practitioner’s Guide to Overcoming Challenges and Maximizing the Benefits of Agility, by Stephanie Ockerman and Simon Reindl The Scrum Guide Arcade Perfect: How Pac-Man, Mortal Kombat, and Other Coin-Op Classics Invaded the Living Room, by David L. Craddock and Milan Jaram Eric Landes   Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

In this second session of our Grantseekers and COVID-19 webinar series, our panel of experienced grantseekers discuss: Available programs, assistance and resources Funder responses, adjustments and trends Tips and advice: How to move forward in this time of crisis Q&A session with panelist in addition to participants sharing through chat   ADDITIONAL RESOURCES https://resources.foundant.com/i/1244265-covid-19-concerns-in-grantseeking-s-2-resources (Resources from the panelists, the audience, and more >>>) https://resources.foundant.com/i/1244262-covid-19-concerns-in-grantseeking-s-2-qa-summary (Q&A from the audience during the live session >>>) https://resources.foundant.com/i/1244259-covid-19-concerns-in-grantseeking-s-2-polls-chat-log (Chat log and polls from the audience during the live session >>>)   PANELISTS Amanda Day, GPC | Co-host, https://www.fundraisinghayday.com/ (Fundraising HayDay Podcast) Amanda is a Grant Writing USA trainer and former municipal grants administrator turned consultant with 17 years’ experience. She’s the Fundraising HayDay Podcast co-host and Board Member of the Grant Professionals Association. Amanda is a total book nerd, grant geek, and music lover. Follow her and her podcast on Twitter: @wholewheatgirl & @fundinghayday. https://resources.foundant.com/authors/amanda-day ([Read More]) Kimberly Hays de Muga | Co-host, https://www.fundraisinghayday.com/ (Fundraising HayDay Podcast) Kimberly is the co-host of the Fundraising HayDay podcast, successful grant writer, fundraiser, and national speaker and trainer. She has more than 22 years of fundraising and grantseeking experience focused on health and human service nonprofits, from hospitals to food banks to programs supporting children and adults with developmental disabilities. Her passion is coaching and training nonprofits and funders toward successful fundraising that better serves their communities. https://resources.foundant.com/authors/kimberly-hays-de-muga ([Read More]) Jo Miller, GPC, SMS | Managing Director and Founder, http://smartegrants.com/ (SmartEGrants) Jo is the founder and Managing Director of SmartEGrants and the SmartE Learning Center, a professional development and training organization, and owner / principal of J Miller & Associates, Inc., a consulting firm specializing in grants, fund development, social media strategy, program design, team development, and online communications. Jo has more than 25-years experience in grants, fund development, social media strategy, program design, team development, and online communications working with nonprofits and government agencies. https://resources.foundant.com/authors/jo-miller ([Read More]) Johna Rodgers, GPC | Founder, https://www.facebook.com/johnarodgersgpc/ (Johna Rodgers Consulting, LLC) Johna has been there and done that. And almost every step of her divergent path included grants. For nearly 30 years, Johna has helped organizations of all types and sizes address their most critical needs—at the federal, state, corporate, and grassroots levels. In 2015, she opened Johna Rodgers Consulting, LLC, a full-service consulting agency. With more than $162 million in grant awards, she has the competitive experience needed to ensure proposals are fundable. https://resources.foundant.com/authors/johna-rodgers ([Read More]) Diane H. Leonard, GPC, LSPO, LSM | Owner, https://www.dhleonardconsulting.com/ (DH Leonard Consulting & Grant Writing Services) Diane is a Grant Professional Certified (GPC), Approved Trainer for the Grant Professionals Association. She is also a Licensed Scrum Master and Licensed Scrum Product Owner through Scrum Inc. Since 2006, Diane and her team have secured more than $64 million dollars in competitive grant funds for her clients. Diane began her work in philanthropy by serving as a grantmaker first, and continues to draw on that...

Q&A with JJ Sutherland, the CEO of Scrum Inc and author of Scrum: The Art of Doing Twice the Work in Half the Time and The Scrum Fieldbook. JJ answers some of our biggest questions and shares some Scrum insights. We hope you enjoy this as much as we did! ----Do you want to learn more about Scrum? Follow us!Twitter / Facebook: scrumsup | Instagram: twoscrumsupFind out more about Alley at https://alley.co

Brandi Olson on Agile Uprising, Judy Rees on Engineering Culture by InfoQ, J. J. Sutherland on Agile FM, Angie Jones on Developing Up, and Eric Ries on Unlearn. I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email podcast@thekguy.com. And, if you haven’t done it already, don’t forget to hit the subscribe button, and if you like the show, please tell a friend or co-worker who might be interested. This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting November 11, 2019. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers. BRANDI OLSON ON AGILE UPRISING The Agile Uprising podcast featured Brandi Olson with host Andy Cleff. Andy asked Brandi about what she means by multitasking. At the individual level, she says we use the word multitasking to describe what is happening when we are trying to do more than one thing at the same time. It is a misnomer though because our brains do not actually do more than one thing at the same time. Her bigger interest is in what happens when you have groups of people trying to multitask all day long. She calls this “organizational multitasking.” Say you have a team and they have a backlog. Organizational multitasking happens when somebody tells that team, “You need to get all ten of these things done this week and you need to start them all and I want to see the progress you are making each day.”  The opposite of that, organizational focus, happens when you say, “Work on this thing first before you work on the next thing.” At the team level, she says, there are a number of illusions about how to be more productive and effective. One illusion is that getting started on everything is the way to get it done and if everything is important we have to do it all at the same time. This breaks down because of the reality of how our brains work. Research shows that when a person has to juggle two projects throughout a day, they will spend 40% of their brain capacity and energy on context-switching. For three projects, energy devoted to context-switching jumps to 60%. Not only does this take time away from more productive work, but we don’t even notice the time we lost. A further cost of having entire teams of people running around at 40% brain capacity is that they are less likely to identify the real problems to work on and it feels like they cannot slow down to figure out what the real problems are. Andy asked whether the solution should come up at the individual level where someone starts to say, “No,” or is it something that starts at a leadership layer. Brandi says it is not a problem that can be solved individually. It needs to start with our leaders. Some of the problems that start to show up in these contexts are a failure to solve the right problems, a reduction in quality, an increase in employee turnover, a reduction in equity and diversity, and burnout. These problems typically get addressed by solving the symptoms. Andy asked what she does to help organizations separate the symptoms from the cause. Brandi says she does this by making the costs of multitasking visible. She told the story of a company that surveyed 600 companies and their HR leaders about the biggest threats to their workforce. Over 80% of those leaders said that employee turnover was the biggest threat. The company then surveyed the employees at those same companies and the employees overwhelming named having too much overtime and unrealistic work expectations. Going back to the same HR leaders, a fifth of them wouldn’t be doing anything about their turnover problem in the next year because the leaders had too many competing priorities. The overwhelming illusion that too many leaders buy into is that, while turnover and burnout are problems, we cannot do anything about it because there is too much important work to do. A further illusion is that we can capacity plan by cutting everybody’s time up; we can break up your time among projects and it will all add back up to 100%. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/the-cost-of-organizational-multi-tasking-with-brandi-olson/id1163230424?i=1000453339079 Website link: http://agileuprising.libsyn.com/the-cost-of-organizational-multi-tasking-with-brandi-olson JUDY REES ON ENGINEERING CULTURE BY INFOQ The Engineering Culture by InfoQ podcast featured Judy Rees with host Shane Hastie. Shane asked Judy if it is possible to have an effective remote meeting. She says absolutely and backed it up with an example of one of her own students telling her recently that participants in her remote meeting said that her remote meeting was better than an in-person meeting. Shane asked about the secret sauce of a good remote meeting. Judy says it is probably planning. She also said that when remote, each person brings part of the meeting room with them. She says people don’t realize how important the environment is to conversations. When you put people in a small space, they pay attention to small details and administrative kinds of things. For “blue sky thinking,” take people outside or to a room with a big view. In real world spaces, we already know where to find small rooms and rooms with big views, but online, we need to create equivalent spaces. You need not only to ensure that all participants turn up with a decent headset, cameras turned on, and light on their faces, but also to figure out the activities so that you have enough social time at the beginning, during, or end of the meeting. The beginning and end of the meeting are critical parts of a meeting. Online, we often miss out on these beginnings and endings and it affects the quality of the conversations. She also says that most people find it easier to engage and participate when the meeting is small. This connects with what Courtland Allen said on Software Engineering Daily about communities in the previous fortnight’s review. She says that if you can’t limit the space, you can limit presentation time to 5 to 7 minutes and get then people doing something. She also says to use breakout rooms and use liberating structures like 1-2-4-All (http://www.liberatingstructures.com/1-1-2-4-all/). Knowing Judy’s expertise in Clean Language, Shane asked how might Clean Language be used to enhance remote meetings. Judy says that teaching people on remote teams to ask more non-judgmental questions about what somebody means by what they say can have a profound effect. Because of the missing socialization in remote meetings mentioned earlier and the fact that remote teams often have more cultural differences than co-located teams, misunderstandings are more likely. Therefore, learning to ask questions to clarify in a way that doesn’t sound like an interrogation but helps both parties to get clearer more quickly becomes particularly valuable. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/judy-rees-on-effective-remote-meetings/id1161431874?i=1000450875620 Website link: https://soundcloud.com/infoq-engineering-culture/judy-rees-on-effective-remote-meetings J. J. SUTHERLAND ON AGILE FM The Agile FM podcast featured J. J. Sutherland with host Joe Krebs. J. J. Sutherland is the CEO of Scrum Inc. and the son of Jeff Sutherland, the co-creator of Scrum. J. J.’s new book is called “The Scrum Fieldbook.” Joe asked what made him pick such a title. J. J. said he wanted to write a book about all the places Scrum Inc. has been all over the world and the many different domains far beyond software. He also wanted to show how Scrum Inc. thinks about Scrum and what are the patterns and anti-patterns. He says that Scrum is a universal framework for accelerating human effort with applications in aerospace, banking, and even beer-making. No one does Scrum just to do Scrum. Scrum is designed to produce value, which requires knowing more than just the Scrum guide. It involves understanding why Scrum works the way it does, understanding complex adaptive systems theory, knowing that you need to empower your teams and ensuring your teams are the right size. Scrum is about running experiments and getting feedback from the customer and adapting to that feedback. He sees people spending six months to a year planning how to do Scrum before they even start. Instead, he says to just do something. That is where you’ll get the information to iterate towards the right thing. Joe expressed his appreciation as a Scrum coach for the chapter in the book on the difference between busy and done. When J. J. worked in radio, producers used to talk about how much effort they put into the radio programs and he would have to point out to them that no listener cares how hard you worked on it; they care about what comes out of the box. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/jj-sutherland-agile-fm/id1263932838?i=1000453430262 Website link: https://agile.fm/agilefm/jjsutherland ANGIE JONES ON DEVELOPING UP The Developing Up podcast featured Angie Jones with host Mike Miles. Mike asked Angie what she considers the ultimate goal of code review. Angie says the goal is to ensure everyone is aware of and content with what is being contributed to the code base; it is not a nitpicking session or an opportunity to bash your least favorite developer. Code review is also a good way to catch missed requirements. Angie encourages code reviewers to review the unit tests just as closely as the implementation.  Angie says the best code reviews are those you block out time for and make part of your routine. They aren’t something you skim while you drink a cup of coffee. When she reviews code, she always pulls up the requirement in the spec, doc, or ticket to see that the code under review fulfilled it. She looks for whether the implementation is efficient and at the right level of abstraction. She says that code reviewers have the opportunity to think at a broader level and see opportunities for code reuse. Angie sees code review as a form of mentoring without having an official mentorship relationship. Official forms of mentoring can feel like an obligation for the mentor because they have to set up meetings, learn the mentee’s career goals. Angie says that code review is a more subtle form of mentorship that is just as powerful. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/code-reviews/id1156687172?i=1000452808997 Website link: https://www.developingup.com/episodes/46-dflXzZ1V ERIC RIES ON UNLEARN The Unlearn podcast featured Eric Ries with host Barry O’Reilly. Eric described how he started his company IMVU and how, when wanted to do practices like split testing, he got pushback. People thought of it as a direct marketing technique, not a product development technique. He would argue, “Shouldn’t we use the scientific method to test our hypotheses?” He wanted customers involved from day one, he wanted to ship more frequently than was considered normal at the time. Looking back, he sees how extreme his ideas were at the time and is glad his cofounders didn’t fire him. As the company got more successful, his techniques got more controversial because the company now had more to lose. He said, “When you do things in an unconventional way, every problem the company has gets blamed on the unconventional method.” Barry pointed out that having to constantly explain the value of these unconventional methods likely made his thinking more resilient and could have been the seed for his next step. At one board meeting, he felt like he was going to be fired. He was tempted to apologize and compromise, but made the conscious choice to advocate for what he actually believed despite the potential negative consequences. He rationalized it like this: this is a small business and a small business is like a small town. In a small town, everybody knows everybody and he wanted people to know what he stood for. If people don’t like it this time and they fire him, okay. A day will come, he reasoned, when they are going to be in a situation where they need to get something done fast and will remember him because they know what he stands for. He radically misjudged the situation: the more he stood for those values and explained them, the more they resonated with people. If he hadn’t had the courage to put his career and reputation at risk, he never would have found out who the ideas resonated with. Eric says it wasn’t until later that he understood the importance of iteration happening within the context of a long term vision. Today, people understand Lean Startup as scientific hypotheses, a testing philosophy, small batches, and pivoting or changing strategy without changing vision. They know it is logically incoherent to have a pivot if you have no vision. Companies who were early disciples of Lean Startup, unfortunately, did not understand this and thought they could A/B test their way to success without any kind of vision. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/the-lean-startup-pivot-with-eric-ries/id1460270044?i=1000451993479 LINKS Ask questions, make comments, and let your voice be heard by emailing podcast@thekguy.com. Twitter: https://twitter.com/thekguy LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ Facebook: https://www.facebook.com/thekguypage Instagram: https://www.instagram.com/the_k_guy/ YouTube: https://www.youtube.com/c/TheKGuy Website:

This is a podcast about results, getting things done. How to move past uncertainty and define the future.  In this episode I talk with J.J. Sutherland. He is the CEO of Scrum Inc and is also the co-author of Scrum: The Art of Doing Twice the Work in Half the Time, written with his father, Jeff Sutherland, the co-creator of Scrum. His newest book The Scrum Fieldbook, A Master Class on Accelerating Performance, Getting Results, and Defining the Future, is the topic of this show. For those of you unfamiliar with the term Scrum, it's a framework originally used as a faster, more effective way to create software in the tech industry. The Scrum process is now being used successfully in general business practice all over the world in companies of all types, outside of pure tech. This chat is in part a discovery process as to why that is.  J.J. says Scrum is the art of changing the possible or what is possible. And I think after listening to this episode, you might join him in that belief.  Some great advice here on not only what Scrum really is or how it works but J.J offers some great insights on teamwork, why projects fail, how to use failure and fear as catalysts and how Scrum can be applied anywhere.  Be prepared to be motivated to get stuff done after listening.  Enjoy!  I blog about all episodes, for more info visit larryweeks.com

Joe Krebs speaks with JJ Sutherland about his new book "The Scrum Field Book - A Masterclass on Accelerating Performance, Getting Results and defining the Future". JJ is also the co-author of the book "Scrum - The Art of Doing Twice the Work in Half the Time" with his father Jeff Sutherland. JJ is an award-winning NPR correspondent and producer with assignments in Iraq, Afghanistan, during the Arab Spring and Japan during the Tsunami in 2011. He is also the CEO of Scrum Inc.

In this episode,JJ and I talk about his new book "The Scrum Field Book - A Masterclass on Accelerating Performance, Getting Results and defining the Future". JJ is also the co-author of the book "Scrum - The Art of Doing Twice the Work in Half the Time" with his father Jeff Sutherland. JJ is an award-winning NPR correspondent with assignments in Iraq, Afghanistan, during the Arab Spring and Japan during the Tsunami on 2011. He is also the CEO of Scrum Inc. If you like to hear him speak live, join the 10th Annual Agile Day in New York on NOV 14.

JJ Sutherland is the CEO of Scrum Inc., a consulting and training firm that uses Scrum to rapidly deliver results in companies across the globe. He is the author of The Scrum Fieldbook: ​A Master Class on Accelerating Performance, Getting Results, and Defining the Future​ and coauthor of Scrum: The Art of Doing Twice the Work in Half the Time, written with his father, Jeff Sutherland, the co-creator of Scrum. Previously, he was an award-winning Correspondent, Producer, and Baghdad Bureau Chief for NPR. He covered the wars in Iraq and Afghanistan, the Arab Spring, and the aftermath of the 2011 tsunami in Japan. He has won Dupont, Peabody, Edward R. Murrow and Lowell Thomas awards for his work.

Scrum Inc, CEO, JJ Sutherland’s new book The Scrum Fieldbook: A Master Class on Accelerating Performance, Getting Results and Defining the Future offers a compelling collection of stories breaking down what makes Scrum (and other forms of Agile) succeed or struggle in organizations. Drawing on his personal experience, as well as that of his colleagues at Scrum Inc., JJ offers a wide range of case studies on how individuals and organizations have been able to leverage agile practices to solve business problems and deliver value for their customers. In this interview JJ shares a few of those stories, makes the case for The Renaissance Enterprise, and explains why organizational refactoring is such a crucial part of Agile Transformation. One thing students request in every single class I teach is “More Real World Examples”. JJ”s new book offers exactly that. If you are familiar with Scrum: The Art of Doing Twice the Work in Half the Time, you’ll have an idea of what makes this book stand out. JJ is not only the son of Jeff Sutherland, co-creator of Scrum, but he also worked as an award-winning news correspondent and producer at NPR before becoming a Certified Scrum Trainer. With a background that is deep in storytelling JJ has put together a collection of tales from the field that draw you in with the narrative while delivering tips you need to know on what it takes to make Scrum (and Agile) succeed (or fail) in your organization. The Scrum Fieldbook Amazon - https://amzn.to/2lILCRE Google http://bit.ly/2nfHcST Barnes and Noble http://bit.ly/2msNuyn Apple Books https://apple.co/2ngyXpw Contacting JJ LinkedIn https://www.linkedin.com/in/jj-sutherland-b1486b6/ Twitter https://twitter.com/jjsutherland Scrum Inc. https://www.scruminc.com

At the 2019 North America Global Scrum Gathering, I had the chance to sit down with Carol McEwan, CEO and Chief Product Owner of Scrum at Scale, to talk about her new role and what has happened since the Scrum Alliance and Scrum Inc. announced Scrum at Scale as a joint venture at last year’s Gathering.  Carol took on the role of CEO/CPO of Scrum at Scale in March, but she previously served as the Managing Director of the Scrum Alliance. She has had a deep impact in the Scrum Community and in this interview you’ll get to hear about the new things she’s been working on, as well as how Scrum at Scale is helping organizations like Saab redefine their operational model and reduce decision latency using Scrum from top to bottom, and how this is enabling business agility across the entire enterprise.  To learn more about Scrum at Scale: https://www.scrumatscale.com If you’d like to get in touch with Carol to follow up, here is how you can reach her: LinkedIn: https://www.linkedin.com/in/cmcewan/ Twitter: https://twitter.com/carolmcewan Email: carol.mcewan@scrumatscale.com Phone: (303) 598-5039

Jeff's work has really had a profound impact on the way I approach a lot of problems. I remember when one of the companies I ran switched to Scrum (mSpoke) and it was like a light switch went on in the organization. I can't really talk enough about how positive Scrum's impact was on that organization and a lot of the companies I've worked with since then. It was really amazing to meet Jeff. He's a brilliant guy and I took away a ton from our conversation. If you're thinking about how to operationalize Agile philosophies in your organization regardless of the size, I think Scrum is a great technique. And if you're already using Scrum, hopefully, there'll be new things you can learn from our conversation. I know there are a few things I've already changed in terms of how I recommend deploying Scrum based on this conversation. Show Links:   https://www.scrumatscale.com/  http://iriannual.com/  Detecting Aigle BS: https://media.defense.gov/2018/Oct/09/2002049591/-1/-1/0/DIB_DETECTING_A

Where will Scrum@Scale take the Agile industry?  Co-creator of Scrum Jeff Sutherland sits down with @AgileToolkit to explore Scrum@Scale at Agile2018. Connect with Jeff Sutherland on Twitter. Learn more about Scrum@Scale.   @AgileToolkit is sponsored by LitheSpeed.   Transcript:   Bob Payne:  The Agile Toolkit. [background music] Bob:  I'm your host, Bob Payne. I'm here with Jeff Sutherland, one of the co‑creators of Scrum. Now you're working on Scrum at Scale. We're very excited about that at LitheSpeed. Just wanted to hear a little bit about Scrum at Scale and where you think that's going to take the industry. Jeff Sutherland:  It actually starts a long time ago. I was pulled out of medical school in 1983. For 15 years I was a research scientist, working with tools for Bell Labs. Learned how to write software for super‑computing, modeling the human cell. Really, all the basics of Scrum were formulated in that environment. When I was pulled out of the medical school by a big banking company they said, "Over at the medical school you guys have all the knowledge, but at the bank we have all the money." [laughter] Bob:  It's not an attractive feature of the banks. Jeff:  They made me an offer that my wife couldn't refuse... [crosstalk] Jeff:  ...the bank. [laughter] Bob:  Why do you rob banks? Because that's where the money is. [laughs] Jeff:  Of course, the first thing I realize I'm working on their new technologies such as the vice president for advanced technologies. I noticed their projects are all late. They have hundreds and hundreds of programmers and we're running 150 banks all over North America. Our customers are actually CIOs of banks. I walked into the CEO's office one day and I said, "Have you noticed that all your projects are late?" He said, "Yeah, the customers are calling me screaming every morning. Bob:  The system's perfectly designed... [laughs] [crosstalk] Jeff:  I said, "I'm just a medical school professor, a mathematician, a computer scientist, but I've looked at their Gantt charts on the wall. You have whole walls of Gantt charts and these tasks, names, and dates. I calculated the probability of being late using this Gantt chart and it's 0.9999999. You're virtually certain to be late on every project. It's a completely inappropriate method to manage projects with lots of change like software.. Bob:  Or uncertainty. Jeff:  He said, "Well, what should I do?" I said, "Well, you authorized me to keep this grant." When I came to medical school I had this grant from the Kellogg Foundation. A leadership grant where I had to with 50 national leaders travel around the world a third of my time for three years. To my surprise the CEO said he was going to support it. He said he thought he was going to get his money back, basically. I said, "You know, I've been running around the world and a subgroup of our leaders are actually business school professors. I've been talking to them about the bank, and they say we need to create a completely new operating model within the bank, a little company within a company, an entrepreneurial startup." I said, "That's what we ought to do." I said, "Here's the way these operate. I need everybody sales marketing, support, installation. I'm going to split them into small teams, four or five people. We're going to have product marketing come in on Monday morning and prioritize everything they're doing by value. Friday afternoon everything is going to be done and if it's software it's live. I need you to give me the whole operation. You and senior management can be my board of directors. I will report to you the financials once a month. The rest of the time you have to stay out of my company because I don't want you messing it up." He said, "We'll that's not going to be as much fun as looking at new technology." [laughter] Jeff:  I said, "It needs to be fixed." He said, "OK, you've got it." You've got that headache. He gave me the worst business unit in the bank. We split them into small team. I said, "We're going to throw away the Gantt chart." I said, "We're going to train you how to land a project just like I train fighter pilots to land an aircraft. I'm going to give you a burn down chart instead of the Gantt chart. This is back in 1983. All of this was the first prototype. It wasn't a prototype of Scrum. It was a prototype of Scrum at Scale. That's were it began. How do you run a whole organization with Scrum? How do you create an agile environment that is actually protected? I was protecting the environment from the Waterfall company. How do you prioritize everything for the organization and then execute those priorities as small as sprints? The teams, how are they responsible for actually delivering at the end of every sprint, which is one of the fundamentals of Scrum. I experimented with that through several companies until I finally got to Easel Corporation in 1993 where we gave it the name Scrum from... Bob:  From the paper. Jeff:  That was the first team that was called a Scrum team. Then in 1995 I pulled Ken Schwaber in. Ken Schwaber was leading a CEO of a project management software company selling waterfall methodologies. [laughs] I said, "Ken, come on in and look at Scrum. It actually works. That stuff you're selling doesn't work." He came in. He spent two weeks with the Scrum team and at the end of it he says, "You're really right. This is really more or less the way I run my company." He said, "If I used the Waterfall methodology to run my company I'd be bankrupt." [crosstalk] Bob:  ...respond to the marketplace. Jeff:  I said, "Well, why don't you sell Scrum instead of selling all this Waterfall stuff?" He thought about it and he said, "Yeah, why don't we do that." Then we decided, OK, I want to make opensource so that it can be widely deployed. We need to write the first paper on what it is. Formalize it, which we presented at OOPSLA'95. Then Ken started selling Scrum out into the market. I was head of engineering inside companies implementing this. One of the very first companies we go together into was a company called Individual, an Internet startup that had just gone public. We had 60 million dollars to spend. We were hiring people like crazy. We had multiple Scrum teams. What do we do? We implement Scrum at Scale. Bob:  Scrum at Scale. [laughter] Jeff:  These guys went from they were delivering every six months, the first quarter we implemented what we call today Scrum at Scale, they were doing multiple releases of their flagship product and delivered two new products in three months. Bob:  That's great. Jeff:  Scrum at Scale is designed to incrementally deliver quickly with a whole organization involved in making that happen. That's the challenge of Scrum at Scale. Bob:  One of the largest early project that Sanjiv Augustine and I did we brought in for stabilization recovery from a classic Waterfall fiasco. [laughter] At the time we were using XP or Extreme Programming, but interactive and incremental. We'd executed it on a small team. We were like, "There's no reason these ideas shouldn't be simply scalable up to a larger team." We had about 300 people on that program and we just said, "Look, we're going to integrate and demo the system," which took them two months to build before their first testing phase, "every two weeks." Of course, they didn't do it for the first four iterations, but after that every two weeks we got a demoable system up, we had some cross‑organizational planning, and a daily stand up that then the team member would step out, and we had it in a big long hallway. We would do the Scrum and then the Scrum of Scrums on a daily basis because things were changing so fast. Jeff:  Absolutely, yeah. The other interesting thing in those first two prototypes with Scrum at Scale is that today DevOps is a big buzz word, but that was fully implemented in both of those prototypes. In fact, in the Internet company they were having trouble with deployment. I said, "I want the deployment server and the developers cube and you guys will deploy multiple times a week. That's the way it's going to be. There isn't going to be operations blocking deployment." It was funny because the operations team, of course, screamed, but I was the head of engineering. I said, "You guys are too slow. We're not using you anymore." A week or two later they came back by and they said, "We've implemented Scrum in operations and we want to become part of your Scrum at Scale. We'll meet in your Scrum of Scrums daily meeting. [laughter] Jeff:  Can we have out server back if we do that?" [laughter] Bob:  You said, "Maybe. We'll see." Jeff:  "Only if the developers can deploy multiple times a week with the server in your server farm, if not we're taking the server back to the development area." Bob:  Multiple times a day, yeah. [laughter] Bob:  That's funny. Other than the deployment what sort of engineering practiced were you guys using for test automation and that sort of thing in those early days. Jeff:  Actually in the first Scrum a team testing product was part of the Scrum because it was a small token environment so we had a fully integrated piece of code running all the time. From the very first sprint we deployed internally. The tooling was such that our consultants could actually use it in the field to get feedback. Jeff McKenna was working with us today as one of the Scrum trainers, wanted to start a testing company. We were particularly interested in component architectures. Move way beyond the unit testing levels. How do you test for a component? Which, today has turned into micro‑services, right? [laughs] . How do you set up a test environment that tests the micro‑services and then make sure it's ready for deploy? All of this stuff has been around for a long time. Bob:  It has. The pattern have been there for a while. Now you've pulled it together. You're doing trainings and certification around that. Jeff:  In recent years we've been pulled in Toyota, GE, Maersk, the world's biggest shipping company, 3M we're the global trainers for 3M. We've been pulled into these big companies. I've had to coach the coaches that have gone in there. We need to formalize the method of scaling that works in really large. We work with SAP who's implementing this. It has 2,000 Scrum teams. These people with really large implementations have told us what we need to do to make it work, not only for one or two teams but for thousands. That's the beauty of Scrum at Scale. It will work really well for one or two teams because it has no extra overhead. It's the minimal viable bureaucracy. Bob:  The Scrum framework... [crosstalk] Jeff:  It scales up to thousands of teams. It works just as well as for thousands with a minimal addition of any bureaucratic overhead. High performance for an organization. 3M had the biggest stock price jump in history last November. If you read "The Wall Street Journal" it's because of several technology divisions, some of which we'd implement Scrum at Scale, because it is an organizational implementation to increase the value of the organization, not just make a project better. [laughs] Bob:  There was a heated article to really springboard off of. Jeff:  About a year and a half ago the Scrum Alliance came to us and said, "We are interested in participating in a scaling framework where we have ownership and our trainers and our membership within the Scrum Alliance can actually participate in the evolution of that framework. We can't do that with the other frameworks. Can we do it with you?" It took about a year of negotiation to decide how we're going to set this up. We have a joint venture now called Scrum at Scale LLC. It's half owned by the Scrum Alliance. It's half owned by Scrum Inc., my company. Its goal is to train the trainers and do the whole certification process for Scrum at Scale. Within the first few months, we have 42 trainers. They're training all over the world. We're off and running. Bob:  We're excited to be on that ride with you. [laughter] Bob:  Louise, Q. Is it in the class? The joke was that he was your bodyguard or something because he was very pumped up. [laughter] Jeff:  Yes. It was some guys from South America or something that said "Oh, Q, he must be his bodyguard," or something. [laughter] Jeff:  Q looks like... Bob:  He works out a lot. Jeff:  He wears sunglasses all the time, dark glasses. He looks like a martial artist. [laughter] Bob:  He's like Bono meets Steven Seagal. [laughter] Jeff:  That's pretty funny. Bob:  That's very exciting. How do you see the growth rate? You said 42 trainers in the first few months. Jeff:  We just did two train‑the‑trainer sessions last month, one in Denver and one in Boston. We'll be doing one in October in London, probably another one in January in London. We're going to be doing them in Europe. We'll be doing another one in Boston. Walking up here, there's a guy from Austin really twisting my arm trying to get us to come down to Austin and do it. Bob:  From the Scrum gathering or near the Scrum gathering in Austin? Jeff:  Yes. There's a lot of pent‑up demand for a better alternative for a scaling framework. It's growing really fast and I think it will continue to grow. Our challenge, mainly, is to... we'll have plenty of trainers, how do we help them fill their courses all over the world? That's a major objective to Scrum at Scale. To really get those trainers successful wherever they are. Bob:  What's been interesting in your trip to San Diego? Anything on the personal front or just business? Jeff:  I have the opportunity where we're doing some training up in Sunnyvale. My wife was with me. I said, "Why don't we just come down the West coast? We'll do a little road trip, rent a sports car. Stop at all the nice locations. [laughs] [crosstalk] Jeff:  That's what we did coming down here to San Diego. We're about to do that to go back up again. I have a Scrum at Scale training in Sunnyvale on Monday, Tuesday. That's been fun. Bob:  It's humid here which is an odd experience in San Diego. Jeff:  Yes. [laughs] Bob:  Thank you very much, Jeff. I really appreciate the time. I look forward to doing the train‑the‑trainer course with you coming up. Jeff:  Thank you very much for inviting me. Bob:  Thank you. The Agile Toolkit Podcast is brought to you by LitheSpeed. Thanks for tuning in. I hope you enjoyed today's show. If you'd like to give feedback or be on the show, you can ping me on Twitter. I am @agiletoolkit. You can also reach me at bob.payne@lithespeed.com. For more free resources, transcripts of the show and information about our services, head over to lithespeed.com. Thanks for listening. [music]

This episode of SoundNotes focuses on Definition of Ready. A few weeks ago, Dave Nicolette created a post in Field Notes that was the result of a current debate in the Agile community about whether having a Definition of Ready helps, or harms our ability to deliver value for the customer. The episode begins with Dave Nicolette explaining Definition of Ready within the context of the LeadingAgile model. After that, he and Dave Prior discuss/debate the the pros and cons of DoR from their respective backgrounds (Developer vs. PM). Links From The Podcast The LeadingAgile Compasswww.leadingagile.com/our-compass/ Dave Nicolette's Field Notes Post "Should Agile Teams Have a Definition of Ready?www.leadingagile.com/2018/05/should…tion-of-ready/ Mike Cohn's blog post "The Dangers of a Definition of Readywww.mountaingoatsoftware.com/blog/the-d…n-of-ready Jeff Sutherland's Definition of Ready post on Scrum Inc. with comments from Michael Jameswww.scruminc.com/definition-of-ready/ If you'd like to check out a sample Definition of Ready, here is one provided by Kenny Rubin.www.innolution.com/blog/definition-of-ready For more on Alexander Laufer's work on Uncertaintywww.tandfonline.com/doi/pdf/10.1080…67.1994.9726951 Or you can read Mike Cohn's explanation here.www.mountaingoatsoftware.com/articles/t…ncertainty RUN FORREST RUN!youtu.be/x2-MCPa_3rU?t=44s Contacting Dave Nicolette• LeadingAgile: www.leadingagile.com/guides/dave-nicolette/• Twitter: twitter.com/davenicolette• LinkedIn: www.linkedin.com/in/davenicolette/• Contacting Dave Prior If you’d like to contact Dave you can reach him at:• LeadingAgile: www.leadingagile.com/guides/dave-prior/• LinkedIn: www.linkedin.com/in/mrsungo• Twitter: twitter.com/mrsungo• Email: dave.prior@leadingagile.com If you have a question you’d like to submit for an upcoming podcast, please send them to dave.prior@leadingagile.com And if you're interested in taking one of our upcoming Certified ScrumMaster or Certified Scrum Product Owner classes, you can find all the details at:www.leadingagile.com/our-gear/training/

During the 2018 North American Global Scrum Gathering in Minneapolis, (https://bit.ly/2LOd5ZD) I had a chance to interview the Interim Co-CEOs of the Scrum Alliance: Shannon Carter, Renata Lerch, and Angie Stecovich. In addition to their new roles, they also serve as VP of Education, VP of Global Marketing and Communications, and Sr. Director of Finance, respectively. Shannon, Renata, and Angie explain how their roles have changed at the Scrum Alliance and how being part of an agile leadership team has prepared them for this. They also speak about all the new things happening at the Scrum Alliance. During the interview, they share details about a number of new initiatives at the Scrum Alliance (including how the certifications offered by the Scrum Alliance have changed over the last year and continue to evolve) as well as new benefits being offered to Certified Scrum Professionals (like free access to Comparative Agility (https://www.comparativeagility.com), an online assessment tool that can be used to help organizations develop their agile capabilities). By far, the biggest announcement the Scrum Alliance made during the 2018 North American Global Scrum Gathering was the partnership with Jeff Sutherland and Scrum Inc. to form a new organization called Scrum at Scale (https://www.scrumatscale.com) that is focused on helping large organizations transform to Agile. If you’d like to check out an interview with Jeff on the partnership, you can find it here: http://drunkenpm.blogspot.com/2018/04/jeff-sutherland-at-2018-global-scrum.html For more on the Scrum Alliance: https://www.scrumalliance.org

This is a rerun episode so a re-release of the episode with Joe Justice of WIKISPEED and Scrum Inc. Why a rerun? There are a few reasons for it and I brought up some during the last episode. One of the reasons, as mentioned, has to do with slowing down at the beginning of the year. Another reason is that this episode was in the top 5 most downloaded episodes in 2017. It had a major impact on me as well since after my conversation with Joe I embraced agile to the fullest: I use it both in my professional and personal life. This re-release emphasizes the importance of this topic. Execution is extremely important for startups and agile is one of the best or the best method I know for project management, and for hardware its application is spreading faster and faster. As for Joe he is the President of Scrum @ Hardware at Scrum Inc, the company which is led by the initiator of scum, Jeff Sutherland. Enjoy this very inspiring, information-dense episode. In this episode we elaborate on the topic of scrum. Raw transcript is available at: https://www.thehardwareentrepreneur.com and show highlights can be seen below: Why I think this episode is important so it has to be re-released - [0:34] Nokia's story coming to an end - [3:23] Can you describe the Scrum method? - [4:36] What the New Zealand All Blacks #1 rugby team has to do with Scrum - [7:09] Some companies that use Scrum, especially in the hardware field - [9:17] Situation with Scrum for startups in the hardware field, and small or medium sized enterprises? - [13:11] Examples where Scrum has been scaled up, specifically for hardware - [16:12] Tesla and their job postings; WIKISPEED competing against Tesla - [17:59] How to think like Elon Musk? - [19:37] The connection between Kanban, Lean Startup, Lean Canvas and Scrum - [19:50] Two major obstacles for implementing Scrum framеwork, especially in the hardware field? - [24:10] Countries approving Scrum - [29:17] “the last of the old will still be the first of the new” - [30:16] How the leader, the Scrum master or the product owner, can motivate the team? - [31:43] If you could go back in time, when you were younger, what notes what would you take back to that time to keep it to yourself? [37:43] Books which had the biggest impact on his career - [39:44] Joe's incredible routines to be super-efficient, super-energetic - [43:12] Memorable cultural differences he has encountered - [46:00] How to reach him - [48:47]

Today I have a special guest. If there was a black belt in his field, he would certainly be one of its holder. He's a master of a type of project management and innovation style, agile, specifically he's into scrum, which is the most commonly used agile framework. My guest is Joe Justice from the USA, President of Scrum @ Hardware at Scrum Inc, and CEO, founder of a company called Team WIKISPEED. In this episode we elaborate on the topic of scrum. Raw transcript is available at: https://www.thehardwareentrepreneur.com and show highlights can be seen below: Nokia's story coming to an end - [3:23] Can you describe the Scrum method? - [4:36] What the New Zealand All Blacks #1 rugby team has to do with Scrum - [7:09] Some companies that use Scrum, especially in the hardware field - [9:17] Situation with Scrum for startups in the hardware field, and small or medium sized enterprises? - [13:11] Examples where Scrum has been scaled up, specifically for hardware - [16:12] Tesla and their job postings; WIKISPEED competing against Tesla - [17:59] How to think like Elon Musk? - [19:37] The connection between Kanban, Lean Startup, Lean Canvas and Scrum -  [19:50] Two major obstacles for implementing Scrum framеwork, especially in the hardware field? - [24:10] Countries approving Scrum - [29:17] “the last of the old will still be the first of the new” - [30:16] How the leader, the Scrum master or the product owner, can motivate the team? - [31:43] If you could go back in time, when you were younger, what notes what would you take back to that time to keep it to yourself? [37:43] Books which had the biggest impact on his career - [39:44] Joe's incredible routines to be super-efficient, super-energetic - [43:12] Memorable cultural differences he has encountered - [46:00] How to reach him - [48:47]

話したこと Podcast へのフィードバックをぜひ #omoiyarifm までお願いします！ スクラムガイド改訂 スクラムガイド スクラム 5 つの価値基準 価値基準が明示されたことの嬉しさ 「尊敬」というより「尊重」？「勇気」とは。「正しいこと」とは。 [Scrum Guide Refresh Jeff Sutherland Ken Schwaber Scrum Inc](https://www.scruminc.com/scrum-guide-refresh/) 新技術導入の遅さの一端はラーニングモデルの違いかもしれない - メソッド屋のブログ どこまでやれば理解したといえるのか？ 先人のアドバイス、後押しは重要。 「完全理解がスピードを生む」？ 経験と知識が結びついて、本質への理解が深まる 自信は座学だけでは身につかない やってみて、きちんと振り返る、を当たり前にやる。 Fearless Change #10 電子フォーラム Slack のリアクションアイコン機能は素晴らしい イベント時の実況チャンネルは盛り上がる なにかをやろうとするときの「演出」の重要性 「初心者向け大歓迎」ってなんのため？ 電子フォーラム、持続は大変。やるなら本気でやろう。 まず最初に後進を見つけよう。 横道「金継最高」 [monoかたり by 工藤茂喜「金継ぎ」 Web mag. panorama](http://panorama-index.jp/webmag/monokatari_kudo_3/) 新大久保・イスラム横丁の完全ガイド。世界のスパイスが10倍安く買える？ : Cooking Maniac 三浦「ピアノ習い始めました。電子ピアノ買いました」 [サイタ 300種類以上の趣味・習い事・資格取得探すなら](https://cyta.jp/) 横道、三浦、 XP 祭りに登壇します。 XP祭り2016

Vic is joined by Zach Bonaker (@ZachBonaker) and Larry Lawhead (@LarryLawhead) at the Cape Rey in Carlsbad for a lively morning of Agile and Coffee. In this episode, our Agile heroes discuss: Eight-minute talks Why companies lose Scrum focus Power of Metaphor What have you been reading lately? Here's the long list of books that Larry started and Zach and I added to: The Toyota Way - by Jeffery Liker The Toyota Way to Lean Leadership - by Jeffery Liker, Gary L. Convis The Spirit of Kaizen - by Leigh Ann Hirschmann, Bob Mauer The Lean Startup - by Eric Ries Kanban: The Kanban Guide - by Paul VII The Innovator's Dilemma - by Clayton Christensen The Wisdom of Crowds - by James Surowiecki Leaders Eat Last - by Simon Sinek The Five Dysfunctions of a Team - Patrick Lencioni Coaching Agile Teams - Lyssa Adkins The Art of Thought - Graham Wallas Larry has also been viewing a lot of webinars in Scrum Inc's “Scrum Lab” with his prime membership, but there is also a lot of stuff on their "Scrum Lab Open” (click “Online Learning”). Reach out to Vic (@AgileCoffee) and use the hashtag #tellAgileCoffee to interact with us on an upcoming episode. Events: Come join us for two days of conversation at the San Diego Agile Open this February 25 & 26. More info online at agileopencalifornia.com/san_diego.html Want more? You got it! Four days of focused, team-based learning at the Scrum Coaching Retreat in San Diego from March 13-16. More info online at www.scrumalliance.org/scrum-coaching-retreat-san-diego-2016

I am pleased to share an interview with Agile pioneer, Jeff Sutherland.  Jeff is a founding father of Scrum and Agile.  He is a noted author and speaker.  Jeff provides insight to many of the largest organizations in the world.  In this episode, Jeff addresses some of the tough issues facing today's organizations.  Please take a moment to listen using the link below or subscribe to the podcast using this link.Please visit Jeff's website: scruminc.com to learn more and check out available courses. During the episode, Jeff mentioned several great books which are linked below for your convenience.  Please take a moment to pick up a few copies for your Agile teams.Scrum: The Art of Doing Twice the Work in Half the TimeAll Things Agile - Episode 006 - Jeff Sutherland InterviewTranscript:Welcome to the All Things Agile Podcast – your destination for tips and interviews with the leaders in the world of Agile. Don’t forget to subscribe to this podcast on iTunes and please check out our sponsor: TeamXcelerator.com. And now, here’s your host: Ronnie Andrews Jr.Ronnie: Hello everyone and welcome to the All Things Agile Podcast. I’m very excited to announce that today’s guest is Jeff Sutherland. He’s a true legend in the world of Agile, especially Scrum. He’s a founding father of Scrum and also an original participant in the Agile Manifesto. I’m very excited to have him on today’s show and I’m hoping that he can shed some insight into how implement Agile teams in larger organizations. So let’s go ahead and get started. First off, thank you Jeff for joining us today! Regarding my first question, I’d like to know what is your input or advice on how to implement Agile successfully in today’s global workforce where we often have teams that are spread across the globe: India, China, etc. How can we implement Agile successfully even if our teams are globally distributed?Jeff: Well, first of all, Scrum simplifies their already complex Waterfall implementations. So Scrum is easier to implement globally than traditional approaches. I’ve worked with many skilled firms over many years – the first one was actually IDX, now GE Healthcare, which was a competitor to McKesson and in fact, the head of marketing – Pam, at IDX who worked with me, implementing Agile there, went on to become the CEO of McKesson; she might still be there, I don’t know, I haven’t checked recently. But she was probably there when you were doing your Agile transformation.But IDX, at the time, had 8 business units. Each business unit had a minimum of 3 products. Many of them were acquired technologies, acquired companies, mainly in the United States, but some teams that I’ve worked with were in Europe; but scattered all over the place. So we scaled Scrum in a big way. One of the best teams was actually in 3 locations across the continent. So I’ve written about at least a half a dozen papers on good distributed implementations of Scrum, and Scrum is the only way of doing software that allows you to actually scale up without losing productivity per developer. As soon as you start to scale Waterfall, the productivity per developer goes down. It starts to drop radically once you get more than 6 people, which is why we keep Scrum teams small. But by keeping Scrum teams small and then using the scalability mechanism that we do, we actually have several case studies now which are the only ones every published showing that you can scale globally and when you scale, you can get linear scalability by adding teams.Of course, you have to do Scrum well. Now, one of the problems with any kind of distribution – Microsoft did a study on this a few years ago in a process group – and they found that in every case, in 10 years of doing Microsoft distributed development, in every case, it delayed the project, it increased the project risk and it increased the dysfunction on the teams. And so, any time you distribute, those are the 3 things that you have to deal with. And as I’ve said, Scrum can effectively deal with all of them, but only if you run a very good Scrum locally. Then you can distribute it. If you distribute a bad Scrum, then you magnify the dysfunction when you distribute. But that’s also true with Waterfall. So, in the worst case, Scrum is better than Waterfall.Ronnie: Okay – and maybe just a follow-up question to that: In your opinion, when an organization is looking to adopt Scrum and globally distribute, have you found that it’s easier to sort of treat the teams all as equals, if you will? Each one’s equally able to grab work from a bigger picture from the product backlog, or do you think that it’s easier to delegate certain either component areas or certain pieces of functionality to particular teams; or do you think that creates too much of a siloed pigeonhole?Jeff: You always want to maximize the feature teams. You always want to have cross-functional teams and have every capability on the team that’s needed to get to a ‘done’ state. One of the most interesting models today in scaling is Spotify because they elegantly did what I try to do at GE Healthcare. And what they’ve done is they have almost all features-driven teams. They do have some component teams, but almost all features-driven teams and all features-driven teams have a visible piece of the Spotify user interface. And every team can upgrade their piece of the product, every sprint, without disrupting any other piece of the product. And so, by making things visible for every team, and really managing the architecture and the dependencies properly, it gives them a very powerful way to implement a really cool product. And they really have to be fast and they really have to be Agile because their competitors are Amazon, Google and Apple. And any one of them will crush them if they don’t run fast enough. Google, Apple and Amazon are like a big tsunami, all coming at them at once and they have to run fast enough so that the wave doesn’t crash on them. Basically, they use Agile globally to do it. So I’d recommend that your people really study the way Spotify has done this.Ronnie: Excellent. If we look at that, it does make a lot of sense. I guess the next question I have is in relation to more of the program or release level type planning and the question is really regarding: when you have teams kind of more in the trenches that are in the process of adopting Agile, however you may still have parts that work large organizations at the program level or they’re trying to work through what’s going to be in a particular release and they’re still in Waterfall mode. Do you have any advice for organizations that – the trenches may be adopting Agile, but maybe at the top level, they’re still kind of left in Waterfall?Jeff: Well, basically that’s the way Scrum always started. We started in the middle of a big Waterfall implementation. So it’s not only common, it’s the usually problem when companies are starting off. And what we find, if we look at the success rate of traditional projects vs. Agile projects, even though there’s a lot of bad Agile out there, we publish data this Danish group gave up in our book on software in 30 days last year and the data showed clearly that about 10 years’ worth of Agile vs. traditional projects and over 50,000 projects showed that the success rate for traditional projects was 14%. 86% were either late, over budget, with unhappy customers or complete failures, nothing ever delivered. Whereas on the Agile side, and this is global data, worldwide averages, the success rate for the Agile projects was 42%. About 3 times the success rate of traditional projects. And many, of course, of these Agile projects are embedded within Waterfall. So what that means is that when you’re doing Scrum inside a company that’s doing Waterfall, you’re going to be 3 times as effective at delivering your piece at the right time and 86% of the time, the Waterfall part of the company is going to be late.So that means that every Scrum team working inside that environment needs to get a very clear commitment from Waterfall on dates and they have project managers that are supposed to do that. In fact, that’s the big role of the project manager that’s left since Scrum doesn’t need them. So the Waterfall project managers have to commit to a date; the Scrum teams with their product owner will commit to the date and most of the times, the Scrum teams will hit it and then traditional implementations will fail. So the Scrum teams always have to have a Plan B so they need to clearly articulate to the management that when the Waterfall teams have missed their date and that they’re going on to Plan B and they should be called when the Waterfall team fixes their problems. One of the things that we sometimes see is that when the Waterfall teams are late, which they mostly are, then they say ‘Well, the Scrum teams – you guys are faster so we’ll just put you on the Waterfall teams’ which is a really bad idea, because it just slows the Scrum guys down to Waterfall speed. A better idea is for the Scrum guys to say ‘Look, we’re faster than you are – give us functionality, we will Scrum it – we may need some of your people to do that, but we can produce it much faster’. If you do that, Scrum will gradually grow in the organization and start to drain the swamp of failed Waterfall projects.Ronnie: Okay, excellent. I guess, my next question would be again in relation to large organizations, is on the subject of documentation. Obviously one of the challenges that a large organization gets is bureaucracy. That there are typically already in place a lot of gatekeeping documentation and they often times have so many different departments and one department hands off another’s keys to another – and in your experience, when implementing Agile or in particular Scrum at a large organization, what advice do you have on the subject of documentation? Ensuring that you have enough, but at the same time, that you’re still able to move quickly? Jeff: Okay, when Scrum launches just enough documentation and every time I ask anyone: do you have just enough documentation? They say: No! And I say: Well, take a look at what you got and get just enough. When I’ve actually looked with them, we find that about 68% of their documentation is totally useless and they’re actually missing a little bit – about 10%. That’s what we seen at some big companies. And companies that are doing medical devices that have to be FDA compliant, FDA certified we find that – one of my partners recently went into a German medical device company, they had 12,000 pages of documentation for an implant medical device. So he actually took that documentation to the FDA and said: Is this just enough? And the FDA said: Are you kidding? We won’t even read 12,000 pages. What are those people thinking?So he worked with the FDA and after 6 months, he got it down to 800 pages. So this is what we typically see on these high documentation traceability projects. Companies are generating 95% of what they’re generating is totally useless. The FDA doesn’t want it. And when you get it down to just enough documentation, only 5% is needed. So what Scrum will do in any company is ask the question: Do you have just enough documentation? If the answer is no, then they’ll look at what is just enough and when they determine that, they’ll make that really clear to the management and the rest of the company.If the management insists on producing 95% junk as in the case of the FDA compliant people, then nobody can help them. They’re just going to waste a lot of money. But what Scrum will make it clear is what is that’s just enough, what do we really need and we’ll get that on the table.Ronnie: Okay, perfect. I guess the final question I’d like to ask you about is in sort of the executive buy-in and dealing with some of the political aspects. When you often have large organizations, you may have some well-entrenched executives that maybe they don’t quite get Agile or they may be stuck in their ways, so can you give some suggestions if you had some people that are working on their Scrum teams and running into some roadblock with their upper executives? Do you have maybe some book recommendations on anything you’ve worked on or a colleague worked on that may be beneficial to recommend to an executive?Jeff: In many companies – my company, Scrum Inc. does a lot of management workshops. Mostly with the senior management. With the middle management, you want get them all in the certified Scrum Master training so they really understand how it works and what they need to do from a management point of view. Without that training and education, it’s pretty hopeless because management – if management doesn’t know what Agile is, then they tend to do things that actually disrupt it and cause it to either go slow or fail outright. Just out of being clueless. So education and training is really critical.At the end of the day, there may be people that are more interested in maintaining their empire than they are in furthering the organization. And senior management has to deal with that. I remember one global telecom company went completely, 100% Scrum all at once and the Scrum trainer that was leading the effort was communicating with me, he said: Yeah, is this going to work? And I said I’ve already written a paper on this, it’s called ‘Hitting the Wall’. What happens when you take a global organizations, take them to Scrum all at once.What happens is they run into their biggest impediment really fast, and depending on what the management does at that time, that will tell you whether it’s going to be successful. And the Scrum coach and trainer said they’ve already hit the wall. I said: What was it? He says there were 30 managers that were getting in the way and the CEO just fired all of them. So at the end of the day, there may be some housecleaning needed.Ronnie: Yeah – but that’s one of the greatest advantages to Scrum, it’s that it really exposes what was already there. Well, I think that’s an excellent suggestion. If it comes to organizations that I’ve personally worked at, have provided certification, training to some of their middle and directorial-level positions and I do think that was really helpful. And it is very interesting that you mention that you do have workshops for some senior management and that’s really great to point.If someone wanted to find out more about yourself and about your company and the services that you provide, where do you recommend that people take a look?Jeff: Well, they can certainly go to our website: ScrumINC.com. They can send me an email: jeff@scruminc.com and I’ll get back to them.Ronnie: Excellent. And do you have any particular books or works that you’ve written or your colleagues written that you’d definitely recommend?Jeff: Yeah, there are two books that were written last year. One of them is actually really good for managers – it’s written as a novel. It’s the story of a company that was in big trouble; how they brought in Scrum and how they turned a disaster into a success. And it’s not a long work, you can read it in a few hours and you really get the basic ideas. The other more IT-focused book that I did last year with  Ken Schwaber ‘Scrum in 30 Days’ and both of these books are on Amazon. An even more interesting book is up on Amazon but will not be released for a few months; it’s called ‘Scrum: The Art of Doing Twice the Work in Half the Time’. And it is a book for the general business reader and Randomhouse founded this in their business book ‘Division’ and they wanted it at least 80% of the examples outside of IT. And so this is a really good book for the general business guy to get a handle on what is Agile, what is Scrum all about? What are its benefits, what are the key principles? How can it help my company? So, ‘Scrum: The Art of Doing Twice the Work in Half the Time’ – you can go to Amazon and preorder it.Ronnie: Okay, excellent. I’ll definitely provide links to those. That concludes all my questions. Jeff, I’d like to thank you for your time, I really appreciate it!Jeff: Okay, thank you! I enjoyed talking with you! Thank you for listening to All Things Agile. We look forward to you subscribing to the podcast on iTunes and leaving a kind review. Thanks and God bless!