Agile Toolkit Podcast

Agile Toolkit Podcast

Conversations about Agile Development and Delivery

Mik Kersten - DevOps Enterprise Summit 2018 2018/11/07, 22:21
Mik Kersten - DevOps Enterprise Summit 2018

<p>CEO of Tasktop Technologies Mik Kersten discusses his session "Project to Product: How Value Stream Networks Will Transform IT and Business"<strong> </strong>at the DevOps Enterprise Summit 2018.</p> <p>Connect with <a rel="nofollow" href="">Mik</a> and <a rel="nofollow" href="">Bob</a> on Twitter.</p> <p> </p> <p>Learn more about AgileToolkit Sponsor LitheSpeed at <a rel="nofollow" href= ""></a>.</p> <p> </p> <p>Transcript: </p> <p>Mik Kersten ‑ DevOps Enterprise Summit 2018</p> <p> </p> <p><strong>Bob Payne</strong>:  "The Agile Toolkit."</p> <p>[music]</p> <p><strong>Bob</strong>:  Hi, I'm your host, Bob Payne, here at the DevOps Enterprise Summit 2018 with Mik Kersten. Mik, you gave a really great talk, one of the keynotes, and I really love the message that you were pulling in, bringing some of the Lean Manufacturing ideas. I know you've been working with BMW, so it's a pretty close call.</p> <p>This idea of looking at data visualization, flow metrics versus compartmentalized, "We've gotten 20 tickets done, but what sort of value have you captured?" I love the fact that you were mixing four different types of work so that you can visualize ‑‑ How are your investment strategies paying off? Are you investing in paying down debt?</p> <p>How does that, in the future, affect your ability to deliver feature flow? I just want to talk a little bit about your flow framework and some of the work that you've been doing.</p> <p><strong>Mik Kersten</strong>:  Excellent. Thanks, Bob. Yeah, I think that's a great summary.</p> <p><strong>Bob</strong>:  Great.</p> <p>[laughter]</p> <p><strong>Bob</strong>:  Why don't you just give a little recap of the things that you were saying and some of the clients you're at?</p> <p><strong>Mik</strong>:  I realized, like you, like a lot of us, having to live now through basically, a decade of large organizations trying to go Agile and seeing some repeated failures, knowing that the core practices make sense, yet these transformations tend to go sideways. I just kept asking myself, "Why do they go sideways?"</p> <p>I've witnessed some of the longest running ones, as closely...It's one of the things that I relayed in the book that we launched here, "Project to Product," which will actually be available on November 20th. That's still on pre‑order.</p> <p><strong>Bob</strong>:  I don't yet have a copy of that. I went out to dinner at Lotus of Siam. [laughs] I didn't make the sign‑in.</p> <p>[laughter]</p> <p><strong>Bob</strong>:  I wish I had.</p> <p><strong>Mik</strong>:  There's a story in there of Nokia, who were a poster child of Agile transformation. They were, at a business level, incredibly motivated by this thing called the iPhone to succeed in that Agile transformation, and, yet, something failed.</p> <p>Stephen Elop, in, I think, 2013, sent that burning platform memo when he was CEO of Nokia, realizing they had not done the right things to allow them to become a software innovator, which when, screens get that large, you'd better be if you're going to compete with Apple. Somehow the business, the leadership at Nokia at that time, was doing the wrong things.</p> <p>I was speaking to technologists there who actually knew what the problem was. They knew that the Symbian Operating System ‑‑ they were in transition, going from Series 40 to Series 60 ‑‑ it was not going to be able to support the kind of features that you needed, things like building on an App Store, on top of the platform that was there. Yet those investments were not being made in replatforming.</p> <p>They were being pushed to go Agile and they were being tested, basically. The measurement for the transformation was the Nokia test, how agile these teams were.</p> <p>Whether they were trained on Scrum, that had nothing to do with how much more quickly, if you look at the end‑to‑end value stream of what Nokia was doing of delivering software, how they were actually optimizing or improving their ability to deliver the kind of platform features that you needed to survive and be a phone.</p> <p><strong>Bob</strong>:  A local optimization problem rather than a system's.</p> <p><strong>Mik</strong>:  I got this term from Carmen DeArdo. I think of it as 100 percent as a local optimization of the value stream. They were completely doing a local optimization of the value stream. Then you have to ask yourself, "Well, was it really the architecture that was a problem? Were their deployments that's still there?"</p> <p>She had some impressive security checking deployment automation. They had some reasonable automation in place. I actually thought they were doing quite well for a company at that time on their delivery pipeline.</p> <p>The bottom line is the business was not giving the technologists the chance to replatform and give them a shot of surviving. Of course, then they end up switching operating systems and the whole mess happened. They lost the market as a result.</p> <p>You look at all these other companies who have done that. Amazon completely replatformed. Probably spent over a billion dollars doing that. Bezos realized that they could not scale on the old platform. We've seen LinkedIn do this.</p> <p>Many of the tech giants know, at a business level, when to shift and, rather than incrementally building features, recreate a platform so that you can get through the next generation of technological change. Those companies who have replatformed, they tend to have CEOs who came from software development, who actually were programmers at one time.</p> <p>I realized that we need a new language to help these Agile, these DevOps transformations succeed so that business leaders and technologists can work together to determine they need to do something like a feature stand down, when they need to do something like a replatforming.</p> <p>When security risks or other kinds of risks, like the privacy risks, need to become a focus, and what that means across the different product value streams.</p> <p>In doing that and trying to create this framework, I realized that the main thing getting in the way of people having the right conversations ‑‑ leaders on the business side and finance side with the people on the technology side ‑‑ was that there was this completely messed up layer separating the two. That layer was project management.</p> <p>[laughter]</p> <p><strong>Mik</strong>:  The fact that rather than measuring ‑‑ and this is where the car man and production line, manufacturing line analogies do help. There are places where they don't help, but [laughs] one of the places that they do help...</p> <p><strong>Bob</strong>:  Time and motion set us free example. [laughs]</p> <p><strong>Mik</strong>:  One of the places where they do help is that there is no separation between the business and production at a company like BMW. Everyone knows how much is flowing through those value streams. When they need to increase production of a car, like in '93, they increase production and there's more market demand.</p> <p>The concept of pull goes all the way through production, right to the business. The business understands the concept of pull and of product value streams. I realized we need to replace that product management layer that manages things to costs, budgets, and timeframes, and assumes time frames are certain.</p> <p>Which, of course, goes completely against agilities to bake in two years of uncertainty into a software project. It sounds as crazy as it is, right? Yet, everyone is saying...</p> <p><strong>Bob</strong>:  Also, you were unable to exploit opportunities that come because your plan doesn't include those opportunity.</p> <p><strong>Mik</strong>:  Exactly. The only thing is to get away from what Mary [indecipherable 7:12] had called the cost in a trap in this great blog post that she wrote. Which is, again, if you're measuring to cost, chances are you're going to succeed at reducing costs. There's an even better chance you're going to succeed at reducing how much value you deliver in the process.</p> <p>Whereas cost reductions can be very important, but you need to focus on value delivery. We need to measure value delivery in software.</p> <p>I realized, for me, as someone who has come out of...worked a lot in Agile, who spent basically two decades doing Agile development, or overseeing Agile development, that the way that I was communicating about it was not working for people on the finance side.</p> <p>When I first told my CFO about story points, he looked at me like I had a unicorn horn on my head or something of that sort. That we needed a language that was higher‑level and more compatible with the way that business leaders think to allow them to basically participate in understanding what flows through software delivery and have these teams work together.</p> <p>That's really the goal of the flow framework.</p> <p><strong>Bob</strong>:  Great. I know that the flow framework, it looks at feature flow, which is a proxy for value. It's not a direct measure of value. You certainly have quality metrics built in. I notice that you also looked at team engagement as part of that part of the Tasktop tool.</p> <p>Are you also doing anything integrating ‑‑ and I'm sure you probably are with some of the tools that you're able to integrate ‑‑ pulling in customer MPS, referrals, or any other pirate metrics or other indicators of possible...that are a little closer to real value?</p> <p>As Microsoft showed, one third of their things added value, one third were neutral, and one third were negative. You could run like hell and stay exactly where you were, producing equal numbers of negative drivers and positive drivers. I'm just curious because I haven't drilled down enough on that.</p> <p><strong>Mik</strong>:  No, I think that's a really important question. The flow framework at the highest level has two components. It has these flow items, like features. Let's just talk about features. There are features, defects, risks, and debts are the four flow items.</p> <p>It has those, and so you basically measure the flow of those. At that point, all you're really doing, as you're saying, Bob, is focusing on the efficiency of flow, the productivity flow and so on. That's not telling you at all whether you've done something useful to a customer</p> <p><strong>Bob</strong>:  There is a huge advantage because you're tracking across business, IT, and operations, which is different than tracking work inside of an Agile team.</p> <p><strong>Mik</strong>:  Yes, there is. It's different, yeah. What you're doing ‑‑ and we can do the car analogy at this point, the plant analogy ‑‑ is you're seeing if value can flow without interruptions through this value stream or where the long waits are.</p> <p>It's because there's a dependency on another product value stream who's not made that API for you that there were supposed to, and so on. All you're getting there is making sure that things flow. You're not necessarily delivering any value. The flow is based on pull. What you do is you correlate the four flow metrics.</p> <p>In the flow framework, you have this section of business results. Those do define value, cost, and so on. You basically are looking at a dynamic system.</p> <p>The business results, the whole goal of the framework, both the flows and the business results need to be defined for each product value stream whether that's an external product, whether that's an internal billing system, whether that's a developer API that you're building or a piece of the developer platform.</p> <p>When I'm looking at the full framework internally at Tasktop, what I see is, "OK, we've delivered all these features. We increased our feature velocity. Did that produce more value?" For me, as a software vendor, the value is going to be revenue.</p> <p><strong>Bob</strong>:  Revenue, retention, referral.</p> <p><strong>Mik</strong>:  Exactly. Retention rate, upsell rate, so on. That's the value component. The key thing is the flow framework forces, A, the measurement of flow across the entire organization, and, B, specifying value, cost, quality, and happiness for each value stream.</p> <p>Now, for an internal product, you might just specify value as adoption. The key thing is you're specifying it. Otherwise, you have no business investing in it if you don't know what the value is. It's a correlation. We don't see exactly how this feature...It's not taking the approach of putting a business case in every single feature and measuring the outcome of that business case.</p> <p>It's actually allowing you see this much...You can do that if you're that sophisticated, but you're seeing this much higher correlation then. "OK, we invested a lot in feature delivery. Did that produce a business result?" The other key thing is to measure cost.</p> <p>You measure cost per product value stream. Keep in mind that the whole point of making these product value streams first class is because I notice that Agile teams or feature teams, they're great, but they're not coarse enough, they're not big enough.</p> <p>One product can involve up to, I think 10 is probably the most reasonable number. When I see project investments go over 10, things start getting worrying. Having a couple hundred people contributing to one thing gets tricky. It's the false Scrum of Scrum size that you can go. You're measuring cost and employee engagement through something like the NPS across the product value stream.</p> <p>As an example, in the case of Nokia that we talked about, you would have seen a horrendously bad employee NPS on the product value stream of the people who were working on the core platform because they could not do enough features. They had this technical depth.</p> <p>I've seen this at Tasktop as well, where, if you put too much flow load, Web work in progress on a team, and through giving them too big of a backlog of features that they can't complete, I have seen repeatedly that team's employment or promo score go down because everyone's miserable.</p> <p>We hire people who want to deliver value, and when we get in their way of doing that, they're not happy. [laughs]</p> <p><strong>Bob</strong>:  That's back to classic work that Deming did. He looked at upscaling employees. The assumption that he went in with is everyone is trying to do their best. If you want different results, you've got to change the system.</p> <p>What you're talking about from pull rate or the backlog, the focus between features and not paying down technical debt, all of those are part of what he would consider the system ‑‑ How is demand flowing into the team?</p> <p>The same way that Toyota never takes more orders than they can fulfill. They never do. They do lots and lots of work to even the flow. It has turned them into an amazing industrial giant, but they don't have the "Glengarry Glen Ross" salespeople out there selling things they can't deliver. They know exactly what that'll do in the long term.</p> <p><strong>Mik</strong>:  Exactly. One thing I want to build on with your point around Deming is that my approach with the full framework assumes ‑‑ I've seen the opposite be assumed too frequently ‑‑ is that the business people are also doing their best.</p> <p>Given their understanding and their frame of reference, which might be a financial background, might be a sales, go‑to‑market background...</p> <p><strong>Bob</strong>:  Might be a traditional project control background.</p> <p><strong>Mik</strong>:  Absolutely. They are doing their best. They have these extremely large budgets. They want this transformation to succeed, but, because the languages are different...Again, talking in terms of releases and deploys per day, those are not value metrics for someone on the business side who's trying to allocate hundreds of millions of dollars.</p> <p><strong>Bob</strong>:  When somebody across the table is speaking a language you don't speak, you see risk.</p> <p><strong>Mik</strong>:  Absolutely. You assume the worst and you see risk. For someone who's responsible for financial controls, that's your job. That's really my hope here, is that by creating this higher level, this less granular language, on top of what we've learned with Agile and with DevOps because, of course, those metrics down below are very important if that's where your bottleneck is.</p> <p>At least it allows people to spot the bottleneck from this higher level to figure out how to invest, and to move the conversation away from projects, timeframes, and budgets, to project value streams.</p> <p><strong>Bob</strong>:  I don't know whether you happened to see Mark Schwartz's talk. He talked about three possible models that you can use when you move away from a classic project. One is the product that you talked about. These are obviously hybridizable. I'm not even sure if that's a reasonable...</p> <p>[crosstalk]</p> <p><strong>Mik</strong>:  It sounds like a word to me.</p> <p>[laughter]</p> <p><strong>Bob</strong>:  It does sound like a word, we we'll give it that. These are concepts that could work together. He says there's a product view. There's a product model that can work. There's a budget and investment model that can work. Then there's also the outcome model that can work.</p> <p>When he was at Citizenship and Immigration Service, he said, "Look, we need to reduce the wait times for people applying for benefits, the backlog that's holding up adjudicators. We need to improve the adjudicator's ability to do their work," and some other objectives, depending on which portion of the business or the mission that he was looking at.</p> <p>He just simply laid out objectives. He says, "If you do it with adding IT features, great. If you do it with eliminating IT features, great. If you do it changing a business process and not doing anything with IT, great."</p> <p>I'm curious. My gut reaction is I can see how we might be able to instrument that flow framework to look at those outcomes. What is your thought on those three models that he posited in his book? It was released at the same time yours was. [laughs]</p> <p><strong>Mik</strong>:  Yep, Mark's doing some great work. Just because I've seen too much, I would just call it flailing between different terminologies and so on, I've just decided to try to create again a common and as simple language as possible. I did iterate a lot with a lot of very smart people on what those words should be.</p> <p>You can do everything in terms of customer experience. In the end, this is all about having a customer‑centered perspective. That's why it's easy and good to go back to those Lean principles from Lomack, from Lean thinking ‑‑ product value streams, customer pull. It's very compatible. The approach that I've taken is that everything's a product.</p> <p>The reason I've done that is because I've seen that work. I've seen some very forward‑thinking companies like the BMWs, the Nationwides, the Targets of the world who, when they start thinking of everything as a product ‑‑ because if you think of things as a product, you have to specify the customer ‑‑ it's not a product if you haven't specified the customer.</p> <p>It forces people, especially on the business side, to think in terms of the customer ‑‑ internal customer or external customer, technical customer or paying customer. There is this discipline that we can now just continue evolving. We've got product owners. We've got product managers. Product management is a discipline that's actually getting established.</p> <p>We can apply those things. Once that's in place, wherever the organization ends up in terms of the hybrids that they would take from Mark Schwartz's models, in my view, they're on the right track.</p> <p>Maybe they will call it the customer experiences or engagements, whatever it is. In the end, to me, consumers love products. They love consuming products. You might call them services sometimes. You might get with their online and so on, but, in the end, we want those products to work better for us. We want more features sooner and so on.</p> <p>I've tried to distill it to give people a very concrete starting point. If they want to evolve the terminology, they certainly can.</p> <p><strong>Bob</strong>:  Is there something that you've learned or are going to take away from this particular conference?</p> <p><strong>Mik</strong>:  Yeah, there have been some fascinating learnings. The program's been just amazing. The amount of work that Gene puts into the program, it blows my mind every year, and seems to get better every year.</p> <p>Interestingly, not only because of his effort, but because of this collective scenius, basically, where you've got people working together, starting to use similar terms, evolve those terms, have these great conversations.</p> <p>I've been amazed at how much actual consistency of message there's been at this conference as everyone...The different angles that the different speakers and other contributors are looking at, taking a great set of practices from DevOps.</p> <p>I really think DevOps had a, by virtue of being so focused on automation, flow, and feedback, it really has accelerated some of the things that I do think stalled out in Agile.</p> <p><strong>Bob</strong>:  The one thing that I fear is that we may stall out. Certainly, the folks here get it, but we may stall out when those mainline organizations think, "Oh, DevOps, that's an IT thing."</p> <p><strong>Mik</strong>:  Oh, yeah. That's happening. That is the way everything will get derailed and DevOps in these organizations will fail in similar ways to how we've seen that in transformation failures. If you push it off to IT, that then...That is one of the stories that I recount in the book, which is, you think it's that part of the transformation's IT. You're wrong.</p> <p>That was really my goal. The biggest goal of the flow framework is to say you have to do this and then you have to do this at an organizational level. If you just allow our teachers to transform on their own, you will fail. In the end, it's about creating, again, these product value streams.</p> <p>The really interesting thing in the program now is actually that, which is taking something that's a good set of technical practices and tools that we've learned out of DevOps, the components of Lean that have gone into this community, making them bigger, and bringing them to the rest of the organization, bringing them to the business.</p> <p>The fact that there was a talk with...Who was it? From Nike. I believe her name was Anna. She's a lawyer. She's one of their top lawyers. The fact that she's on stage with Courtney Kissler, that's pretty amazing that the learnings from this community are actually reaching to that part of the business.</p> <p>I would personally love more conversations with people like CFOs who care profoundly what's happening with value and spend. [laughs]</p> <p><strong>Bob</strong>:  Oh my God.</p> <p>[laughter]</p> <p><strong>Bob</strong>:  Yeah, especially as they look at the disruption and the people falling off S&P 500 or whatever index of being a great company you look at. CFOs have to be keenly interested in, I believe, survival. You can't grow unless you survive.</p> <p><strong>Mik</strong>:  Exactly, and in this, because one of the things I point out is that we are at this turning point, this point where the rate of disruption then creative destruction will probably accelerate, I don't think you can survive if you don't grow, and you can't grow without mastering software.</p> <p><strong>Bob</strong>:  I often use the other Deming quote, which he was talking about, continuous improvement, "Learning is not compulsory. Neither is survival." [laughs]</p> <p><strong>Mik</strong>:  Yeah, exactly. Back to Deming, everyone has the best of intentions. The budgets are there. It's just a question of having the right model and framework to make sure that things are tracking the way that you expect them to rather than to be disappointed two years down the road, that you've saved some costs, but now things are moving even slower than when you started.</p> <p><strong>Bob</strong>:  Yep. Excellent. Thank you very much for coming on the podcast. I hope your book is a smash success. We're looking forward to working with customers that are using Tasktop. I don't usually do any tool plugs, [laughs] but yours looks very interesting because it focuses on an area that we think is crucial in the work that we do.</p> <p>We're mostly tool agnostic. We often joke that our biggest tools are your executives.</p> <p>[laughter]</p> <p><strong>Bob</strong>:  We do a lot of work with executive teams and organizational transformation. I never actually make that joke.</p> <p>[laughter]</p> <p>[crosstalk]</p> <p><strong>Mik</strong>:  Yeah, exactly. There's rooms where that joke'll fall flat.</p> <p><strong>Bob</strong>:  Yeah, that might fall flat.</p> <p><strong>Mik</strong>:  [laughs] That's great. Thank you, Bob. It's been a great conversation. Thank you.</p> <p><strong>Bob</strong>:  Great. 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</p> <p>For more free resources, transcripts of the show, and information about our services, head over to Thanks for listening.</p> <p>[music]</p> <p><br /> <br /></p> <p>Transcription by CastingWords</p>

Jeffrey Davidson, Jo Avent - Agile2018 2018/11/07, 19:00
Jeffrey Davidson, Jo Avent - Agile2018

<p>Jeffrey Davidson and Jo Avent join Bob to discuss their Agile2018 session <a id="4ba218781f44a95c2f51d9a1bbf61e7b" class="name" rel="nofollow" href= "" name="4ba218781f44a95c2f51d9a1bbf61e7b">Hunting for Diamonds: Hiring the Very Best for Your Agile Team</a>.</p> <p> </p> <p>Connect with <a rel="nofollow" href= "">Jeffrey</a> and <a rel="nofollow" href= "">Bob</a> on Twitter.</p>

Shane Hastie - Agile2018 2018/11/05, 19:00
Shane Hastie - Agile2018

<div class="sched-container-header"> </div> <h3> </h3> <div class="sched-container"> <div class="sched-container-inner"><span class= "event ev_8 ev_8_sub_1"><span class="event ev_8 ev_8_sub_1">Shane Hastie joins Bob to discuss his Agile2018 sessions: <a class= "name" rel="nofollow" href= "">Being Agile in a Remote Team</a> and </span></span><a id= "cedc72a2d5ce31fa3594da5e2fc81819" class="name" rel="nofollow" href= "" name="cedc72a2d5ce31fa3594da5e2fc81819">The Foundations of Business Agility</a></div> <div class="sched-container-inner"> </div> <div class="sched-container-inner">Shane is the Director of Agile Learning Programs at ICAgile, Chair of Agile Alliance New Zealand, Lead Editor for Culture & Methods & Podcast Host on <a class="twitter-timeline-link" dir="ltr" title= "" rel="nofollow" href="" target="_blank" rel="nofollow noopener" data-expanded-url= ""><span class= "invisible">http://</span><span class= "js-display-url"></span></a><span class= "js-display-url">.</span><span class="tco-ellipsis"><span class= "invisible"> </span></span></div> <div class="sched-container-inner">Connect with <a rel="nofollow" href= "@shanehastie%20">Shane</a> and <a rel="nofollow" href= "">Bob</a> on Twitter.</div> </div>

Johanna Rothman - Agile2018 2018/11/02, 15:00
Johanna Rothman - Agile2018

<p><a rel="nofollow" href="">Johanna Rothman</a> joins the podcast at Agile2018 and discusses her sessions: <a id= "d635cc44a884f4f104b13e7342878be3" class="name" rel="nofollow" href= "" name="d635cc44a884f4f104b13e7342878be3">You Have to Say More There: Effective Communication in a Distributed Agile Team</a> and <a id="2b258506ab442badb847c7a90839eaf4" class="name" rel="nofollow" href="" name="2b258506ab442badb847c7a90839eaf4">Agile and Lean Roadmapping: Incorporating Change at Every Level of Product Planning.</a></p> <p> </p> <p>Connect with <a rel="nofollow" href="@johannarothman">Johanna</a> and <a rel="nofollow" href= "">Bob</a> on Twitter.</p>

Sam Guckenheimer - DevOps Enterprise Summit 2018 2018/11/01, 20:21
Sam Guckenheimer - DevOps Enterprise Summit 2018

<p>Bob chats with Microsoft Azure DevOps Product Owner and author of <em>Agile</em> <em>Software Engineering with Visual Studio,</em> Sam Guckenheimer, at the DevOps Enterprise Summit 2018.</p> <p>Connect with <a rel="nofollow" href="">Sam</a> and <a rel="nofollow" href="">Bob</a> on Twitter.</p> <p> </p> <p>Transcript</p> <p>Sam Guckenheimer ‑ DevOps Enterprise Summit 2018</p> <p><strong>Bob Payne</strong>:  "The Agile Toolkit."</p> <p>[music]</p> <p><strong>Bob</strong>:  Hi, I'm your host Bob Payne. I'm here at the DevOps Enterprise Summit 2018 with Sam Guckenheimer. Welcome, Sam.</p> <p><strong>Sam Guckenheimer</strong>:  Thank you, Bob. It's great to be here.</p> <p><strong>Bob</strong>:  It's the first time we're really chatting. We chatted a tiny bit last night. My colleague Sanjiv Augustine said you were instrumental in hosting The Agile leadership network when it formed and came up with the declaration of Interdependence. How did that end up coming about?</p> <p><strong>Sam</strong>:  Well, that was no what 14 years ago or something like that.</p> <p>[laughter]</p> <p><strong>Sam</strong>:  What we saw was at that time that this was of course way pre‑DevOps. The Agile community had fractured into many groups saying "More agile than thou." That seemed stupid.</p> <p><strong>Bob</strong>:  That fracturing has continued and remains as stupid today or... [laughs]</p> <p><strong>Sam</strong>:  Yes. Unfortunately, the fracturing has continued and it hasn't gotten less stupid. That was the reason for trying to get the interdependence declaration together to get these leading lights from what was then the Agile community working together.</p> <p>In the meantime, the pure Agile has largely been eclipsed by DevOps. As you see something like this DevOps Enterprise Summit going on its fifth year roughly doubling every year in scale. I'm here now. Still there.</p> <p>[laughter]</p> <p><strong>Bob</strong>:  There are a number of things that I found at this conference that I haven't been able to make a ton of sessions because we have a booth. I've found that I haven't really learned, maybe this is my own fault, anything at the Agile conferences for probably about 10 years. It wasn't any substantially interesting information.</p> <p><strong>Sam</strong>:  That's correct. I last keynoted at the Agile conference in 2014. That's probably the last time I've been there. It got kind of stale. The energy in innovation, in practice I think has really shifted to DevOps. That's come about, because the DevOps' definition of Dunn is not potentially shippable and promotes...</p> <p>[crosstalk]</p> <p><strong>Bob</strong>:  It's captured a value, enlargement value.</p> <p><strong>Sam</strong>:  It's live in production with Telemetry that is demonstrating the value delivered.</p> <p>Going from a world where you were effectively stopping at an intermediate activity that didn't reach the customer or end‑user to go to one where you have to reach the end‑customer and you have to measure the value delivered, is much, much more powerful for all the stakeholders, for the business, for the people involved.</p> <p>It's much more satisfying. You disintermediate the development to customer relationship. You think of things as one engineering discipline, not as silos post the Scrums, so to speak.</p> <p><strong>Bob</strong>:  Certainly there were a number of great Agile teams and organizations that fully believed that Dunn meant in the hands of customers and delivering whatever goal, that...</p> <p>[crosstalk]</p> <p><strong>Sam</strong>:  I do not mean to bash anyone. I certainly think there great Agile teams. A lot of what we do today has its roots in extreme programming, but things like XP at the time, had this notion of, for example, pair programming.</p> <p>We have largely, as a community, moved to the notion of a pull request as a virtual pair programming. We have moved from the idea of onsite customer to measuring customer impact, which isn't to say onsite customer is a bad idea, it's a great idea, it's a rarely achievable one.</p> <p>All of these seeds that were planted back then in the late '80s by the early Agilists were important seeds. The garden where I think they're really bearing fruit now is in this DevOps community.</p> <p><strong>Bob</strong>:  The other thing that I think is probably the next wave that we will see in organizations that are not already there, certainly, many organizations have already integrated business into this flow. Without that DevOps is necessary but not sufficient to actually change the outcomes that businesses are seeing.</p> <p>That's the next frontier for those companies that we're not sort of born in the world of IT as the fundamental driver of business outcomes.</p> <p><strong>Sam</strong>:  That's correct. DevOps is the flip side of the coin from digital transformation. Digital transformation is the business term for taking your business model and turning it into one that can improve continuously in an Internet‑powered age. DevOps is the shorthand for the technical practices that enable that.</p> <p><strong>Bob</strong>:  I see way too many organizations mistaking a DevOps transformation for digital transformation. They're fundamentally doing the DevOps practices, but they're not backing up into the initial value proposition to begin with. That will sort itself out.</p> <p><strong>Sam</strong>:  This is a common thing of confusing means and ends. The ends are things around growing the business customer, acquisition customer, engagement customer, employee delight, all of these measures of happiness and success.</p> <p>The practices are ways of getting there. The goal is to focus however on those end results. The clear sign of dysfunction is when you see people measuring the inputs, not the outputs.</p> <p><strong>Bob</strong>:  If Deming or [inaudible 7:33] came back and saw that Toyota was doing the same practices it was doing 75 years ago they would drop dead after having just come back to life. [laughs] In real systems the practices and the processes are never the ends. They are all in service of maximizing flow...</p> <p>[crosstalk]</p> <p><strong>Sam</strong>:  Exactly. If you think about the evolution, the practices today are different because the constraints are different. One of the overriding constraints was for example infrastructure availability. You get all of the stuff around how to manage and schedule the infra.</p> <p>Today with the public cloud that constraint is gone. It's a classic example of, in Eliyahu Goldratt terms, elevating the constraint or removing the bottleneck. Then you see the constraint shifting. As you're adopting these practices what happens is you have a continual shift of the constraint, and you have the next one to attack the next bowling pin to knock down.</p> <p>[crosstalk]</p> <p><strong>Sam</strong>:  Right. What DevOps says has basically taught us as well. You can remove infrastructure a constraint by using the cloud. You can focus on the value delivered to the customer and measure it so you can have both qualitative and quantitative view of that.</p> <p>You can take the quality game and shift it left and right so that quality does not become this big testing bottleneck in the middle. It can become part of the pull request flow. It can happen before code merges.</p> <p>Then you can in production gradually expose value to more and more of users so that the blast radius is something that's flexible, so you don't have the constraint of saying, "I need to master my MTBF in order to release."</p> <p>You can say, "I need to maximize my ability to recover and may have the shortest time to recover, so that by controlling the blast radius and being able to recover quickly I can experimentally by increasing the rate of experimentation I can deliver and measure value delivered on a cycle that was never possible in the old days."</p> <p>It wasn't possible before we had the Internet, it wasn't possible before it hit the public cloud, it wasn't possible before we had these practices of high‑quality, highly‑rugged automation that we do today.</p> <p><strong>Bob</strong>:  Yeah it has been a sea change since I did Fortran on punch cards [laughs] .</p> <p><strong>Sam</strong>:  There have been many sea changes yes. Mike Pearson gave a great talk yesterday, borrowing from Carlota Perez on the structure of industrial revolutions, and postulates that we're at the point of disruption from the period of adoption to the period of dispersion.</p> <p>That would account for a lot of the changes that we're seeing, and it would account for a lot of the anxiety that you see among people who are saying, "How do I learn fast enough? How do I catch up fast enough? How do I get ahead?"</p> <p>At the same time, what you see very clearly reflected in company success, company's market gap, and company's ability to innovate and pivot, is that the ones who have mastered the go‑fast‑without‑breaking‑things‑and‑adjust‑course‑as‑you‑go, are the ones that are winning in pretty much every sector.</p> <p><strong>Bob</strong>:  I love Mark Schwartz's analogy of the battle of the Russians with Napoleon, and the speed of decision‑making being fundamentally out of sync with the reality of the battle.</p> <p><strong>Sam</strong>:  Exactly, that was also true on Omaha beach in Normandy, that was true in Vietnam, that's been true in pretty much every military conflict, that the degree of autonomy and speed of innovation has determined the outcome in the end, and people who are great at enabling the next war instead of fighting the last ones, are the victors.</p> <p>The latest example decide or...I don't know if that's politically correct to go there, but you see it now in...</p> <p><strong>Bob</strong>:  [laughs] That have been substantially politically correct on this podcast [laughs] .</p> <p><strong>Sam</strong>:  You see this in cyber. The Russian budget for cyber is less than the cost of an F‑35.</p> <p><strong>Bob</strong>:  No one could argue that the F‑35 is more costly than it needs to be but it's... [laughs] .</p> <p>[crosstalk]</p> <p><strong>Sam</strong>:  Who cares? The point is, they're not trying to win the manned aerial dogfight. They are extending the notion of total war to a new battlefield and they've been very successful, but finding the place where there are no defenses and where it's possible to innovate quickly and it's proven to work.</p> <p>You could also argue that as David Sanger does in "The Perfect Weapon", that the US started this cyber‑war arms race. In any event, we've not follow through on the consequences of what we started.</p> <p>The military analogies, they turn some people off, but they have their value. We are, and the rest of society also, in a place where we need to be winning the future, not the past.</p> <p><strong>Bob</strong>:  It's actually one of the analogies I quite often use when I'm talking to people that are OK with the military analogies.</p> <p>The OODA loop, the Boyd loop of observe‑orient‑decide‑act. The team that can turn that loop the fastest, whether it's Amazon, Netflix, or a manned‑aerial dogfight, or a cyber‑attack, is going to win.</p> <p><strong>Sam</strong>:  Exactly. In our world, the OODA loop results in some kind of software or service delivered. One of the things we know from measuring it is that about a third of the time, we get the results we'd want, a third of the time, we get opposite result from what we hypothesized, and about a third of the time, it makes no difference.</p> <p>The implication of that is that you want to be able as quickly as possible, to double down on the successful third and fail fast or pivot away from the other two thirds, which means that you need to make the OODA loop as short as possible, which is what Boyd talked about in his idea of aircraft design and aerial battle.</p> <p>That's exactly true in how we develop and that means not just using small batches which Agile taught us. That means not just breaking down the silos, but it means really focusing on time to remediate and focusing on quality to the left so that you have clean delivery and you have the mechanism in production to control exposure and to go faster and wider as you need to.</p> <p><strong>Bob</strong>:  You mentioned the one‑third, one‑third, one‑third, I know that was a study that came out in Microsoft. Actually...</p> <p>[crosstalk]</p> <p><strong>Sam</strong>:  Ronick O' Harvey was behind that. Ronny is now a technical fellow, he wasn't back then. He basically took a very large sample of "improvements" that were delivered.</p> <p>Let's measure, are these really improving, what we wanted? The result was a third of the time, in other words, I've confirmed the others' change is bad, unless is great. That was quantitative demonstration of that. I don't know if he published that before he did a stand for PhD or after, but it was a famous study and it holds up.</p> <p><strong>Bob</strong>:  I also very much like this idea of very small batches, because without the small batches, it's hard to get attribution of what improved the customer experience and what was neutral or negative, because you're conflating way too many changes if the batch is large.</p> <p><strong>Sam</strong>:  That's why the pull request flows becomes successful, because you can make the pull request a batch that is a few lines of change, it's possible to have a human‑code review on it, and it's possible to have extensive automation on it.</p> <p>Again, an example of a practice that wouldn't have been possible pre‑cloud is when we do pull requests, we run the build‑in automation on them with typically 80‑some thousand tests before asking for the human‑code review. Human eyes are only focused on those things that automation has said looked good already.</p> <p>As opposed to the way things were done, pre‑cloud in the XP pair programming model, where human eyes were first defense. That was very appropriate given the constraints at the time. The constraints of today are different.</p> <p><strong>Bob</strong>:  That was certainly one aspect of pairing. The other is just as the design discipline getting the collaborative design quite often yields better results, but...</p> <p>[crosstalk]</p> <p><strong>Sam</strong>:  I totally think that people should collaborate on design. I'm totally for that. I'm not trying to..</p> <p><strong>Bob</strong>:  I totally get the point about the quality. Is automation...we want lazy engineers [laughs] . We want engineers focusing on creative thought, rather than repetitive action.</p> <p><strong>Sam</strong>:  Exactly. Another example of that that's possible these days, is you want a very high reuse, an open source. If you can solve a problem with 30 lines of code and reuse thousands, that's much better than creating 3000 lines of codes that need to be maintained.</p> <p>In effect, we want to reward people for writing less code, which again turns on it's head, one of those classic input matrix and myths of, "Well, how much code did you write? How busy were you? How many hours did you put in?" As opposed to, "What result did you achieve?"</p> <p><strong>Bob</strong>:  What are some DevOps practices that have really changed Microsoft fundamentally? I know you've got a couple of talks related to that here at the conference.</p> <p><strong>Sam</strong>:  I bucket our lessons learned, usually in five groups. One is how we focus on value delivered to the customer, both quantitatively and qualitatively, and let that drive the way we think about what we're delivering and how we measure that.</p> <p>Two is how we apply production‑first mindset. Our CEO tends to call this a live‑site culture, in other words, you build it, you test it, you run it, you secure it, you troubleshoot it, you improve it with responsibility residing in you, the creating team, not getting fragmented across these Silos.</p> <p>Three is the idea of team autonomy and enterprise alignment that you want to let teams at the level of the feature crew Scrum, cream squad, whatever your favorite term is, you want to let these small feature crews work autonomously on their stuff, and control what they are taking into the next sprint or what items they're doing next.</p> <p>You want them to support their stuff in production and you want the mechanisms to align their work up to the common business results, so that they know which needles they need to move by the work that they do and they know how to view those gauges.</p> <p>The fourth is shifting quality left and right so that you can get a signal in the pipeline of green meaning green and red meaning red, and in production, you can see continually what is happening with every changes, you expand its exposure.</p> <p>Fifth finally is using cloud to make infrastructure‑flexible resource.</p> <p>That's how I bucket it. I did one talk yesterday with my friend Ellen Smith about how we moved our DevOps' ass. It's really a story about eight years of taking what's started as a non‑premise product and turning it into a cloud service and on‑premise product. That was an attempt to myth‑bust the idea that if you're going to the cloud, you need to start in the cloud and throw everything away.</p> <p>It was an attempt to say, "Here's a proof instance where we had a business, pre‑cloud, with on‑prem product. We preserve that and made it better, and use the same codebase to go the cloud where the cloud is making the on‑prem better." Of course the cloud's the majority of usage and the fastest growing now, but it wasn't a throwaway, which of that story.</p> <p>The other one which is similar, which I'm doing tomorrow, is a talk about Windows' journey to DevOps. Windows division is the extreme case of scale and legacy, and they have successfully moved to DevOps. There were a bunch of bumps along the way. For example, to get Windows to be able to use Git at their scale, we needed to fix the Git, and that took three attempts.</p> <p><strong>Bob</strong>:  Really?</p> <p><strong>Sam</strong>:  Yes.</p> <p>When we started doing something like a Git clone of the main Windows repo, took 12 hours. That was if the network didn't burp, or your laptop didn't go to sleep, or nothing else wrong happened. If any of those things did happen, then the whole operation needed to start over.</p> <p><strong>Bob</strong>:  Need to start again, yeah.</p> <p><strong>Sam</strong>:  That now takes a couple minutes. We did a series of 300x or better improvements in Git performance with what is now open‑sourced as the virtual file system for Git. Windows motivated all of that to be able to support their scale of codebase, which was hundreds of times larger than anything else anyone was using.</p> <p><strong>Bob</strong>:  That's interesting. I did not know that you guys were major contributors to the Git.</p> <p><strong>Sam</strong>:  We're one of the top two. We're the largest open‑source contributor of any company, have been for about two years now. Git is a project where we have been very heavily in, and virtual file system is one of the latest aspects of that.</p> <p>Come to the talk tomorrow.</p> <p><strong>Bob</strong>:  OK, I may. What time is it?</p> <p><strong>Sam</strong>:  11:25, I think? 11 something. The times here are weird. All these weird five‑minute increments.</p> <p><strong>Bob</strong>:  [laughs] . It is five‑minute increments and three hours off, because I'm an East Coast person. Are you out of...</p> <p>[crosstalk]</p> <p><strong>Sam</strong>:  Along Seattle.</p> <p><strong>Bob</strong>:  Thank you so much, Sam. This has been great. Is there any one thing you'd like to close off with that you're interested in?</p> <p><strong>Sam</strong>:  Yeah. There's something that I'd like to make our listener aware of, and that is I curate a website. The short link to it is It's, DevOps and Microsoft.</p> <p>What I try to do is to put up our experience reports there, not the high‑level marketing level stuff, but like, "How did you actually do the change in testing? How did you go to no downtime deployments? How did you start using service reliability engineering? Etc."</p> <p>There're about 50 articles up there, but half of them with good video. They're just stories about how we work. I love people to use that as a...</p> <p><strong>Bob</strong>:  As a resource?</p> <p><strong>Sam</strong>: resource.</p> <p><strong>Bob</strong>:  Thank you very much. It was very nice meeting you and chatting.</p> <p><strong>Sam</strong>:  Thanks a lot, Bob.</p> <p><strong>Bob</strong>:  Thanks.</p> <p>The Agile Toolkit Podcast is brought to you by LightSpeed.</p> <p>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</p> <p>For more free resources, transcripts to the show, and information about our services, head over to Thanks for listening.</p> <p>[music]</p> <p> </p>

Esther Derby - Agile2018 2018/11/01, 19:46
Esther Derby - Agile2018

<p>Esther Derby chatted with Bob at Agile2018 about her two sessions - <a rel="nofollow" href= "">Creating an Environment for Successful Agile Teams</a> and <span class= "event ev_17 ev_17_sub_2"><a id="6c9717d7f80305b8ab1e78083cf3722d" class="name" rel="nofollow" href= "" name="6c9717d7f80305b8ab1e78083cf3722d">Clarity, Conditions, Constraints: An Alternative to Top Down Control.</a></span></p> <p> </p> <p>Connect with <a rel="nofollow" href= "">Esther</a> and <a rel="nofollow" href= "">Bob</a> on Twitter.</p> <p> </p> <p> </p>

Scott Ambler - Agile2018 2018/09/28, 17:00
Scott Ambler - Agile2018

<p><a rel="nofollow" href="">Scott Ambler</a> joined Bob on the podcast at Agile2018.  Hear about Scott's Agile2018 talks "<a id="c39cba53905022217bc014e977f3d23f" class="name" rel="nofollow" href= "" name="c39cba53905022217bc014e977f3d23f">Database DevOps: Strategies to Address DevOps' "Last Mile"</a> and "<span class= "event ev_11 ev_11_sub_2"><a id="70ef3e875b677b32800d74b430e76123" class="name" rel="nofollow" href= "" name="70ef3e875b677b32800d74b430e76123">Agile Architecture: Mindset, skills, and practices."</a></span></p> <p> </p> <p>Connect with Bob on <a rel="nofollow" href= "">Twitter</a> and <a rel="nofollow" href= "">@LitheSpeed</a>.</p>

Steve Mayner - Agile2018 2018/09/28, 01:55
Steve Mayner - Agile2018

<p><span style="font-size: 10pt;">How's the Agile world growing up?  Dr. Steve Mayner, SAFe Fellow and Principle Consultant at <a rel="nofollow" href="">Scaled Agile, Inc.</a> joins Bob on the podcast at Agile2018.  </span></p> <p><a rel="nofollow" href="">Connect with Steve on Twitter. </a></p> <p><span style="font-size: 10pt;">Follow <a rel="nofollow" href= "">Bob's Twitter</a> and visit <a rel="nofollow" href= ""></a> for support building an Agile organization.</span></p>

Jeff Sutherland - Agile2018 2018/08/21, 21:46
Jeff Sutherland - Agile2018

<p>Where will <a rel="nofollow" href= "">Scrum@Scale</a> take the Agile industry? </p> <p>Co-creator of Scrum Jeff Sutherland sits down with @AgileToolkit to explore <a rel="nofollow" href= "">Scrum@Scale</a> at Agile2018.</p> <p>Connect with <a rel="nofollow" href="">Jeff Sutherland on Twitter</a>.</p> <p><a rel="nofollow" href="">Learn more about Scrum@Scale.</a></p> <p> </p> <p><a rel="nofollow" href="">@AgileToolkit</a> is sponsored by <a rel="nofollow" href="">LitheSpeed</a>.</p> <p> </p> <p>Transcript:</p> <p> </p> <p><strong>Bob Payne</strong>:  The Agile Toolkit.</p> <p>[background music]</p> <p><strong>Bob</strong>:  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.</p> <p><strong>Jeff Sutherland</strong>:  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.</p> <p>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."</p> <p>[laughter]</p> <p><strong>Bob</strong>:  It's not an attractive feature of the banks.</p> <p><strong>Jeff</strong>:  They made me an offer that my wife couldn't refuse...</p> <p>[crosstalk]</p> <p><strong>Jeff</strong>:  ...the bank.</p> <p>[laughter]</p> <p><strong>Bob</strong>:  Why do you rob banks? Because that's where the money is. [laughs]</p> <p><strong>Jeff</strong>:  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.</p> <p>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.</p> <p><strong>Bob</strong>:  The system's perfectly designed... [laughs]</p> <p>[crosstalk]</p> <p><strong>Jeff</strong>:  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.</p> <p>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..</p> <p><strong>Bob</strong>:  Or uncertainty.</p> <p><strong>Jeff</strong>:  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.</p> <p>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."</p> <p>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.</p> <p>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."</p> <p>He said, "We'll that's not going to be as much fun as looking at new technology."</p> <p>[laughter]</p> <p><strong>Jeff</strong>:  I said, "It needs to be fixed." He said, "OK, you've got it." You've got that headache.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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...</p> <p><strong>Bob</strong>:  From the paper.</p> <p><strong>Jeff</strong>:  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]</p> <p>I said, "Ken, come on in and look at Scrum. It actually works. That stuff you're selling doesn't work."</p> <p>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."</p> <p>[crosstalk]</p> <p><strong>Bob</strong>:  ...respond to the marketplace.</p> <p><strong>Jeff</strong>:  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."</p> <p>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.</p> <p>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.</p> <p>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.</p> <p><strong>Bob</strong>:  Scrum at Scale.</p> <p>[laughter]</p> <p><strong>Jeff</strong>:  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.</p> <p><strong>Bob</strong>:  That's great.</p> <p><strong>Jeff</strong>:  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.</p> <p><strong>Bob</strong>:  One of the largest early project that Sanjiv Augustine and I did we brought in for stabilization recovery from a classic Waterfall fiasco.</p> <p>[laughter]</p> <p>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."</p> <p>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."</p> <p>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.</p> <p><strong>Jeff</strong>:  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.</p> <p>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."</p> <p>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."</p> <p>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.</p> <p>[laughter]</p> <p><strong>Jeff</strong>:  Can we have out server back if we do that?"</p> <p>[laughter]</p> <p><strong>Bob</strong>:  You said, "Maybe. We'll see."</p> <p><strong>Jeff</strong>:  "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."</p> <p><strong>Bob</strong>:  Multiple times a day, yeah.</p> <p>[laughter]</p> <p><strong>Bob</strong>:  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.</p> <p><strong>Jeff</strong>:  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.</p> <p>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.</p> <p>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] .</p> <p>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.</p> <p><strong>Bob</strong>:  It has. The pattern have been there for a while. Now you've pulled it together. You're doing trainings and certification around that.</p> <p><strong>Jeff</strong>:  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.</p> <p>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.</p> <p>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.</p> <p><strong>Bob</strong>:  The Scrum framework...</p> <p>[crosstalk]</p> <p><strong>Jeff</strong>:  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.</p> <p>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]</p> <p><strong>Bob</strong>:  There was a heated article to really springboard off of.</p> <p><strong>Jeff</strong>:  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?"</p> <p>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.</p> <p>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.</p> <p><strong>Bob</strong>:  We're excited to be on that ride with you.</p> <p>[laughter]</p> <p><strong>Bob</strong>:  Louise, Q. Is it in the class? The joke was that he was your bodyguard or something because he was very pumped up.</p> <p>[laughter]</p> <p><strong>Jeff</strong>:  Yes. It was some guys from South America or something that said "Oh, Q, he must be his bodyguard," or something.</p> <p>[laughter]</p> <p><strong>Jeff</strong>:  Q looks like...</p> <p><strong>Bob</strong>:  He works out a lot.</p> <p><strong>Jeff</strong>:  He wears sunglasses all the time, dark glasses. He looks like a martial artist.</p> <p>[laughter]</p> <p><strong>Bob</strong>:  He's like Bono meets Steven Seagal.</p> <p>[laughter]</p> <p><strong>Jeff</strong>:  That's pretty funny.</p> <p><strong>Bob</strong>:  That's very exciting. How do you see the growth rate? You said 42 trainers in the first few months.</p> <p><strong>Jeff</strong>:  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.</p> <p>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.</p> <p><strong>Bob</strong>:  From the Scrum gathering or near the Scrum gathering in Austin?</p> <p><strong>Jeff</strong>:  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.</p> <p>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.</p> <p><strong>Bob</strong>:  What's been interesting in your trip to San Diego? Anything on the personal front or just business?</p> <p><strong>Jeff</strong>:  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]</p> <p>[crosstalk]</p> <p><strong>Jeff</strong>:  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.</p> <p><strong>Bob</strong>:  It's humid here which is an odd experience in San Diego.</p> <p><strong>Jeff</strong>:  Yes. [laughs]</p> <p><strong>Bob</strong>:  Thank you very much, Jeff. I really appreciate the time. I look forward to doing the train‑the‑trainer course with you coming up.</p> <p><strong>Jeff</strong>:  Thank you very much for inviting me.</p> <p><strong>Bob</strong>:  Thank you. The Agile Toolkit Podcast is brought to you by LitheSpeed. Thanks for tuning in. I hope you enjoyed today's show.</p> <p>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</p> <p>For more free resources, transcripts of the show and information about our services, head over to Thanks for listening.</p> <p>[music]</p>

Evan Leybourn - Agile2018 2018/08/21, 21:33
Evan Leybourn - Agile2018

<p>Business Agility Institute founder Evan Leybourn shares results from the 2018 Business Agility report at Agile2018.</p> <p>Connect with Evan on Twitter: <a rel="nofollow" href= "">@Eleybourn</a></p> <p><a rel="nofollow" href= ""> Download the Business Agility Report (2018)</a>.</p> <p><a rel="nofollow" href= "">Add your voice to this report: Take the Business Agility Survey for 2019's report here.</a></p> <p>Follow <a rel="nofollow" href="">@AgileToolkit</a>.</p> <p>Visit <a rel="nofollow" href=""></a> to help your organization embrace Business Agility.</p> <p> </p> <p>Transcript:</p> <p>Evan Leybourn ‑ Agile2018</p> <p> </p> <p><strong>Announcer</strong>:  The Agile Toolkit.</p> <p>[music]</p> <p><strong>Bob Payne</strong>:  I'm your host, Bob Payne. I'm here with Evan Leybourn from Australia. Evan, you're ahead of the Business Agility Institute, and you guys just released the Business Agility report today, you're at Agile 2018. I was leafing through it. There's a lot of great infographics and information behind those infographics.</p> <p>Do you want to just talk about how you went about getting the report? Then, maybe we can talk about some of the interesting results.</p> <p><strong>Evan Leybourn</strong>:  Thanks, Bob. It's great to talk to you again. I absolutely love being on this podcast. I think it's my third time now. [laughs]</p> <p><strong>Bob</strong>:  Is it third already?</p> <p><strong>Evan</strong>:  Third already.</p> <p><strong>Bob</strong>:  [laughs]</p> <p><strong>Evan</strong>:  Third already. We put together the reports over the last couple of months based on the feedback we had from our members. A lot of people were asking for evidence.</p> <p>There's a lot of hearsay. There's a lot of anecdotes about business agility, and they wanted more proof. How does it work? Why does it work? Who does it work for?</p> <p>We went out, and we started sourcing information. We put out a survey. We'll share the link with your listeners in the text below the podcast. We got some fantastic insights which, I'll be honest, not many surprises. Most of the anecdotes that we hear, the data has borne it out, so that's actually pretty fantastic.</p> <p><strong>Bob</strong>:  If not surprising, what are some of the important insights that folks were questioning and that now has been borne out in the data?</p> <p><strong>Evan</strong>:  [laughs] We can probably narrow it down. I'll give you the really simple ones. The larger the company is, the less agile it is. I don't think that's a surprise to anybody at all.</p> <p><strong>Bob</strong>:  [laughs]</p> <p><strong>Evan</strong>:  Now, we have the data to show just how much more agile a small company is. In fact, we're doing some additional research now in terms of company thresholds, the size of organizations, and the operating model that's required for agility at those sizes.</p> <p>15 to 50, 50 to 150, how do those sizes interface with agility, the practices, and the principles behind that? We know that agile organizations work differently. We know there are benefits, but how does size...</p> <p>If I'm 5‑person organization, then how I do agility is has to be different if I'm a 5,000‑person organization. We want to be able to outline that this generic information about X, Y, and Z, this is how it's specifically tailored to every size.</p> <p>Industries' wise, financial services, information technology and consulting, the top three industries who are adopting business agility right now. Both in terms of the quantity of organizations doing it as well as the maturity or the fluency that those organizations have.</p> <p>That's not really a surprise. We know from personal experience that banking and finance, every bank is trying to...</p> <p><strong>Bob</strong>:  Huge competitive pressures with dust cycles.</p> <p><strong>Evan</strong>:  FinTech eating their breakfast as they say. IT companies, Agile emerging technology and software. It's natural for these organizations to expand beyond the IT early, certainly earlier than other organizations.</p> <p>Consulting was a bit of a surprise. I wasn't expecting them in the top three. In fact they're number one to be precise. Now, cynical Evan thinks that, "Well, maybe the consulting organizations are just sort of..."</p> <p><strong>Bob</strong>:  Self‑reporting a little higher. [laughs]</p> <p><strong>Evan</strong>:  Self‑reporting a little higher because they're trying to say, "Hey, look how great we are." Less cynical Evan actually there's some logic behind it because consultants do need to be at the bleeding edge of business.</p> <p>If they're going to be transforming the client organizations, they've already got to be there. It does make sense that a lot of these consultancies are pushing the boundaries as much as they can. I think that's a natural behavior.</p> <p><strong>Bob</strong>:  Did you get any breakout that was aggregated against those different industries? Were different moods of business agility?</p> <p><strong>Evan</strong>:  No.</p> <p><strong>Bob</strong>:  Was it really customer pitted or service or...?</p> <p><strong>Evan</strong>:  We did slice and dice. We had some data scientists look at this information for us. They're the ones who provide a lot of the insights. We wanted to make sure that we were doing it meaningfully, specifically meaningfully.</p> <p>When we looked at the data, whether we sliced it at the company size, whether we sliced it by industry, not by industry, by company size or by high fluency, if we remove just the high fluency run the ones who are 9s and 10s, the outliers.</p> <p>Even if we normalize for who's reporting, whether it's the CEO reporting or an individual contributor because there was a difference. Even after all the slicing, those three industry still came out as 1, 2 and 3 so no matter how we sliced the data. It was pretty consistent actually. In fact, I mentioned that contributors, that was one of the few surprises that we got.</p> <p>Anecdotally, I assumed that the C‑Suite would over‑report and the individual contributors would under‑report maturity or fluency in business agility. We actually found that, because we had multiple respondents from the same company, in a single organization we thought they'd be different, but they were actually within 0.5 of a point from each other.</p> <p><strong>Bob</strong>:  That's probably...</p> <p><strong>Evan</strong>:  It's statistically...</p> <p><strong>Bob</strong>:  ...insignificant.</p> <p><strong>Evan</strong>:  ...insignificant. Now, there is a trend. Yes, the CEO is 0.5 higher than the individual contributors and line managers and senior leaders. Senior executives fall on that trend line, but it's quite negligible.</p> <p>The big surprise was we invited external consultants to assess the maturity, the business agility, fluency of their client organizations. They were about 15 percent lower on average.</p> <p><strong>Bob</strong>:  The client organizations.</p> <p><strong>Evan</strong>:  Yes. When the external parties assessed them, they assessed them 15 points lower. 1.5 points lower, 15 percent lower than themselves.</p> <p><strong>Bob</strong>:  That may make sense with your transformational model...</p> <p><strong>Evan</strong>:  It could.</p> <p><strong>Bob</strong>: well, because I can't really help unless I'm in some aspects better at it than the organization.</p> <p><strong>Evan</strong>:  Yeah, it's interesting. We need to do some further investigation as to why that's the case. My gut feeling is that there's probably two main reasons. The first being the rose‑colored glasses that happen within an organization. You see the transformation, you see you're making change, and it looks a little bit better, but the people from the outside are comparing you against...</p> <p><strong>Bob</strong>:  Other people.</p> <p><strong>Evan</strong>:  ...other people who are better. As an outsider, what you rate as a five, I rate as a three, just because I'm seeing that's a five over there. The inverse is also true.</p> <p><strong>Bob</strong>:  We probably have different north stars that we're measuring against.</p> <p><strong>Evan</strong>:  That's it. Maybe someone who's outside doesn't see a lot of the good. They're dealing with the procurement processes, they're dealing with the contracting processes, which are painful in almost every organization.</p> <p>They would underreport their client organization because the business agility hasn't hit procurement yet. It's just hit how employees are being engaged. Maybe they're underreporting for that reason as well.</p> <p><strong>Bob</strong>:  Was the survey both public and private sector?</p> <p><strong>Evan</strong>:  It was actually mostly private sector. We had a small number of respondents from the public sector, two or three percent. Though that data has mostly been excluded from the report just because there wasn't enough data points to meaningfully assess that information. We're hoping that version two of this report will be able to draw the public sector view.</p> <p>Because we are doing the government's Agility Conference in November, I think it would be a good idea to actually maybe create a government version where we survey the government organizations before the conference and maybe put something together for them.</p> <p><strong>Bob</strong>:  Even if we have some objectives out of the conference, what do we want people to take away, even if it's a simple survey of, before they attend the conference, after, how much more do they know about business agility, if they're not already executing in that way. I really see, and I know we've talked about this, on the committee calls...</p> <p>[laughter]</p> <p><strong>Bob</strong>:  ...the Government Business Agility Conference. It is just the early days in many, many government agencies on the delivery side, and without delivery, you can't turn the crank on the major business outcomes.</p> <p><strong>Evan</strong>:  Spot on. I talk a lot about theory of constraints and the theory of...I've probably mentioned this in a previous podcast, but an organization can only be as agile as its least agile part.</p> <p>In business, 30 years ago, that was software, so we invent Agile. 10 years ago, that was operations, so we invent DevOps. Today, in business, it's HR, it's finance...</p> <p><strong>Bob</strong>:  [inaudible 10:00] .</p> <p><strong>Evan</strong>:  ...but government is probably still where the business was 20 years ago. In many government organizations, they're only now getting the benefits of Agile, let alone DevOps and full‑on business agility which is even in the future.</p> <p>That being said, we have some great stories, some great case studies in the government space around policy developments being done in using Agile, service delivery for social services being delivered using Agile mindsets and techniques around the creation of citizen‑centric approaches.</p> <p>Everything from budget games being done in San Jose, I think it was San Jose. If you Google, you'll find out exactly where it's being run, where they crowdsource the budget from citizens using Agile game theory. It's absolutely fantastic.</p> <p><strong>Bob</strong>:  I was just chatting with somebody from a government agency. We were actually talking about using the Colleague Letter of Understanding with the Morningstar as a way of creating a rather hierarchical structure, a mesh commitment structure, within that organization. There're little pockets of these ideas taking hold.</p> <p><strong>Evan</strong>:  We have a video from the very first business agility conference in New York in 2017. The deputy CIO of the State of Washington had adopted holacracy in the state government. I used to be a public servant, this is 10 years ago. The thought of holacracy in government was mind‑blowing. I couldn't believe they could even do that. They did and a huge success.</p> <p><strong>Bob</strong>:  It can get a little tricky. I don't know if the state governments are the same but federal sometimes gets tricky when you hit the unions.</p> <p>[laughter]</p> <p><strong>Evan</strong>:  Yes. In that scenario, in the institute, we're developing some position papers, some white papers on various complex topics. Incentives, motivation reward is a white paper that's being released tomorrow, in fact. By the time you listen to this, it'll already be released, and we'll share the link.</p> <p>One of the next white papers that we're going to put out there is business agility in a unionized environments, because a lot of our members are in united environments that's complex.</p> <p><strong>Bob</strong>:  We may often give entities like the bureaucratic...paint them with a bureaucratic brush, but actually another agency that we did some work in, they were partners in creating an open workspace environment for everybody.</p> <p><strong>Bob</strong>:  Going back to the report, some of the key findings that we did come up with, market success is one of the highest benefits of business agility, which I would actually be surprised by. Not because I don't believe that business agility brings with it financial and market success measures, but I didn't think as a community that we were there yet.</p> <p>I thought we had a while to go, that the benefits move on softer. Now, we have some great quotes, some great feedback from the survey respondents saying that now they have gained more customers, greater customer satisfaction, more repeat business through the adoption of business agility. The usual ones they are around, better way of working, and so forth.</p> <p><strong>Bob</strong>:  Retention of clients.</p> <p><strong>Evan</strong>:  Retention of clients, yeah.</p> <p><strong>Bob</strong>:  Competitive advantage. I see better ways of working, came in at 16 percent, collaboration, communication, not shocking 14, and engagement up as well. That's what we see in the VersionOne survey on the IT delivery side, that engagement goes up a lot.</p> <p><strong>Evan</strong>:  When we look at challenges, the top challenge, which should be of no surprise to anybody, is leadership. Leaders love them, but they can either make or break a transformation based on the culture that they help to instill in an organization. Buy‑in is number two or three in the challenges. What's the next one? That's embarrassing. I don't...</p> <p><strong>Bob</strong>:  Just trying to find the page right now.</p> <p>[laughter]</p> <p><strong>Bob</strong>:  Leadership, lack of buy‑in, inappropriate organizational design.</p> <p><strong>Evan</strong>:  Of course, old design. Sorry, I should remember that one. It's off my head. Basically, the value stream is broken.</p> <p><strong>Bob</strong>:  The silos.</p> <p><strong>Evan</strong>:  The silos. When work goes from team to team to team, every hand off adds complexity and delays. An agile organization is one where the value stream is as much as possible contained in a single cohesive team.</p> <p>I don't mean a small team, those teams can be big, but the ownership, the accountability is held singly from ideation to customer delivery. Companies still struggle with that, but that's changing. We're seeing that change in companies although even in government organizations.</p> <p><strong>Bob</strong>:  Even if you can get a decent alignment of the silos to create those, not solid line report, but dotted line to the value stream, that can go a long ways. In thinking about the market's success statistic, I actually think that makes sense because if we look at the...Again, I don't want to compare you guys, the VersionOne survey, but I'm...</p> <p>[crosstalk]</p> <p><strong>Evan</strong>: due. We've admired the VersionOne survey for years.</p> <p><strong>Bob</strong>:  It has been a valuable tool.</p> <p><strong>Evan</strong>:  It's one of the reasons we created this is to go [inaudible 15:53] .</p> <p><strong>Bob</strong>:  Number one is better ability to manage change. What do markets want? They want responsive goods and services.</p> <p><strong>Evan</strong>:  The market will evolve faster than the company. It's why startups can out‑compete a legacy large organization who's got hundred times the budget, a thousand times the market share.</p> <p>They're dominated and overtaken by a tiny startup because the startup is able to adapt and provide a service that the customers want as opposed to what has been delivered for the last 20 or 30 years, which maybe what the customers wanted 30 years ago, but time moves on.</p> <p>I know Uber and Airbnb and everything else. Those examples are trotted out every single time if someone talks about market agility or market entity.</p> <p><strong>Bob</strong>:  [inaudible 16:48] .</p> <p>[laughter]</p> <p><strong>Bob</strong>:  [inaudible 16:50] is running in my head.</p> <p><strong>Evan</strong>:  They're the obvious ones, but it doesn't matter what industry you're in. I spent the last four years living in Singapore, and every bank there had a decent revenue coming out of international remittance, sending money home.</p> <p>Australians, Filipinos, Indians would send money back to their home countries through the banks. Within the space of two years, the FinTechs emerged. They had better, faster, cheaper services, and the banks lost a couple of percent of their top line overnight.</p> <p><strong>Bob</strong>:  We get [inaudible 17:23] all the time. That's just one possible transactional character.</p> <p><strong>Evan</strong>:  If you put yourself in the shoes of a bank, no one's going to take away the deposit account because that's not a...Maybe I could be lying but I don't think that's a disruptable service, partly because there's no money in a deposit account.</p> <p>Banks make their money out of credit cards and all these transactions, and all these other things, so the FinTechs are coming in.</p> <p><strong>Bob</strong>:  They can be in the right market if you've got some liquid cash that you're...</p> <p>[crosstalk]</p> <p><strong>Evan</strong>:  That's certainly not where the banks are making their profit.</p> <p><strong>Bob</strong>:  No.</p> <p><strong>Evan</strong>:  The banks are looking at this going, all of the stuff they're doing that are high profit, the FinTechs can come in and do it better, faster, cheaper. All they're going to be left with is the slow, low‑profit services, like core banking. Now, they're desperately trying to become FinTechs themselves.</p> <p>If I'd walk into a bank 10 years ago and let's say, "Let's create an agile bank," I would've been laughed out. Now, they're coming to us saying, "How do we become an agile bank?"</p> <p><strong>Bob</strong>:  "How do we disrupt ourselves before someone else does?"</p> <p><strong>Evan</strong>:  That's it. I use banking as an example. The same is true in utilities, the same is true in healthcare, engineering. Any industry which you think is undisruptable, I guarantee you, will be disrupted within five years.</p> <p><strong>Bob</strong>:  We're seeing people fall off the Fortune 500 lists.</p> <p><strong>Evan</strong>:  57 percent of the 1983 Fortune 500 no longer exists.</p> <p><strong>Bob</strong>:  Not even just off the list. Just out of existence.</p> <p><strong>Evan</strong>:  Some have been acquired, some have gone through merges, some have gone through divestments. They're a fraction of what they were. Others have gone bankrupt. Some have come out of bankruptcy. They're still nothing.</p> <p><strong>Bob</strong>:  We'll have the link to the report. Where can folks learn about the Business Agility Institute?</p> <p><strong>Evan</strong>:  Thanks. We'll put the links below, I love the fact that .institute is a top‑level domain.</p> <p><strong>Bob</strong>:  [laughs]</p> <p><strong>Evan</strong>:  We bought that.</p> <p><strong>Bob</strong>:  .institutionalized.</p> <p>[laughter]</p> <p><strong>Evan</strong>:  That's what I should be. Absolutely., you'll find all the information. We're a membership organization. I do encourage all your listeners to join up as a member. Help support us, help support the community, and develop new and great research.</p> <p>The inverse is true as well. It's not just a one‑way, we'll provide you things. We want you to share your stories with us. If you have a case study, if you would like us to create a white paper on a topic, ask us. We will do our best to actually build that for the community.</p> <p><strong>Bob</strong>:  Thank you very much.</p> <p><strong>Evan</strong>:  No, thank you very much, Bob. Until next time.</p> <p><strong>Bob</strong>:  Until next time.</p> <p><strong>Evan</strong>:  [laughs] Thank you.</p> <p><strong>Bob</strong>:  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</p> <p>For more free resources, transcripts of the show and information about our services, head over to Thanks for listening.</p> <p>[music]</p> <p> </p>