AgileToolkit Podcast

*/ ?>

Latest Episodes:

Kevin Fisher - DevOps Enterprise Summit 2018 Feb 06, 2019

Show notes

Kevin Fisher, Nationwide Insurance Associate Vice President, Lean Process Management (Lean, Agile, DevOps) sat down with Bob at the DevOps Enterprise Summit 2018. Connect with Bob on Twitter. Transcript Bob Payne: "The Agile Toolkit." [music] Bob: Hi. I'm your host, Bob Payne. I'm here at the DevOps Enterprise Summit 2018 and I'm here with Kevin Fisher from Nationwide. Kevin, we worked together an awfully long time, back from the early days of Agile, at Nationwide. I remember, actually I Tweeted, because it was in the talk with a couple of gentlemen that were from Nationwide. They were talking about the DevOps roll out that they're doing and they had this sort of Sherpa chart. It's always great to see how far you guys have come from the early days. I was impressed by their talk. Unfortunately, I didn't get to your talk, but I hear you had some pretty interesting things in your talk around metrics, and measuring flow, and that sort of thing. Maybe we can chat about that? Kevin Fisher: That's right, Bob. Bob and I worked together back in 2008 when we experimented with Scrum and XP. Bob and some other folks were our on‑site coaches. From those early days of having one Agile team, now we have 200 Agile teams. All of our work is done with those 200 teams. We think of our transformation in three distinct kind of bodies of work. The first one, obviously, is introducing Scrum and XP and then scaling that up. That took a long time, given our size of our organization. Now we're focusing on DevOps. You heard the talk from Jared and Jim. We're rolling out DevOps in a self‑service way. It's more carrot than stick. Bob: It was great to hear, because all too often it is not implemented in a self‑service way. Kevin: We want teams to figure out their local impediments and use these techniques to solve their local processing problems. We gamified the friendly competition between teams. We have a monthly DevOps challenge. All the teams can submit their progress against whatever that topic is of that particular month. We choose a winner, and they get custom stickers for their laptops. That's it. There's no monetary conversation. [laughter] Kevin: When we were exploring and doing some experiments, we had two of our teams have a friendly competition against each other, and it was simple. We didn't give them extra time. They had to complete all their normal standard work. We said, "What can you do to go faster and get your work done faster? By the way, you have a colleague team over here that we asked the same challenge. We want you to attend each other's show‑and‑tells." It was fantastic to see the friendly competition in their eyes when they're attending their colleagues' show‑and‑tell and the colleagues talking about how they just pruned 2,000 automated tests that weren't delivering a whole lot of value to 700. Now they have it integrated into their build process. They feel real good about it. They have a big visible monitor that displays the health of the build on a real timestamp. Then you can see the other team thinking, "Wow! We could do that. We could beat that." It was very healthy, and that's how we came up with the idea. Then, when we heard about the Verizon cup...Verizon has a similar program, and we said, "That is a fantastic idea. We're going to leverage that idea from the Verizon cup. We're not going to make it quite as elaborate ‑‑ they actually give a trophy. We're going to scale it down and just give stickers," and it's been a great thing. Then the third avenue for us is this whole concept around changing the mentality of our senior executives in finance, from project to product. That's a difficult turn to make. Bob: It's a huge turn. Yep. Kevin: We've had many conversations over the years. We've made some changes in IT that are putting us in the right direction, but we can't go further without the business being side by side with us. Early on, attempts at forging that conversation with our business executives and the finance teams was not received well, because we kept talking in IT terms. We want to bring Agile, we want to infuse Agile methods into our planning. We want to talk about this. We want to talk about that. They rejected a lot of that conversation because it was viewed as very IT‑centric, and just not in terms they could understand. The progress we've made on two fronts over the last couple of months is number one, we now have a very rudimentary view of lead time and cycle time within the functions of IT. It's not perfect. It's certainly fraught...You could poke holes in it if you look real hard at it. But, when we boil it up at the macro level, the law of large numbers takes hold and we actually feel like yeah, this directionally correct enough. It shows what we knew all along and that's the development piece of hands on keyboard, writing code, is not the problem. That's actually the shortest piece of our value chain. Bob: By a ridiculous amount. Kevin: By a ridiculous amount. Two and a half percent of the time we spend on stuff is actually on hands‑on‑keyboard coding. Bob: That must have been validating but also a head‑scratcher. I'm sure you took a look to make sure you've got the numbers right because that seems like something that's very... Kevin: We have the numbers. It's very low. Bob: People would want to poke a hole in. Kevin: People want to poke a hole in it. It's a very large data set so, "All right. Let's say we're off by a 100 percent." It's still pretty low. Bob: Five percent. [laughter] Kevin: We still have a huge opportunity space after the development is complete and, obviously, well before the development happens. Now we're really focused. It gives us data to have ammunition with the people that are either dragging their feet on DevOps and CICD. We can say, "No, no, no. Here's the data. We need to improve this. You need to show measurable improvement." Then it also helps us in those conversations with our business partners to say, "Look. This business‑IT relationship is really super important and perhaps we need to start thinking about things differently." The second half of this conversation that's actually been new in the last several months is our CIOs ‑‑ we have a business unit CIO lined up with each unit business president ‑‑ have been successful talking with their business unit presidents and their cabinets, made up of SVPs and other senior leaders, and trying to get them to conceptualize a future state in small increments of time. Historically, our company has made very large multi‑year bets, and a handful of them. We're going to spend hundreds of millions of dollars over the next five years and all this wonderful stuff will come out of it that's extremely difficult to measure. That doesn't allow us to respond to market conditions at all. There was an impactful trip, probably similar to most companies. We've had good success getting our executives out of the building to visit with other companies. It doesn't even have to be a financial services company. It could be other industries. Talk with peers at their same level, and learn. We used it to get progress with our IT leadership on adopting lean management techniques across how we scale. Now we've used it with other business executives to get them to think about conceptualizing outcomes in smaller increments. I tell the story that we had a group of executives take a trip out West to visit the typical unicorns of the world, Facebook, Google, Amazon. When they were on their trip, they said, "We need to go figure out how these companies do a much better job at long‑term planning than we do." They came back... Kevin: Yeah. They don't do long‑term planning. Bob: They do strategic execution rather than strategic planning. [laughs] Kevin: Correct. Yes, yes. Exactly. That's what they learned. They said, "We actually don't do that. We're just much better than you at sensing and responding to market conditions." What that trip allowed the CIOs to do is introduce ‑‑ I know it sounds simple ‑‑ language that the business leaders could rally around, that they didn't view as IT language. They didn't have an allergic reaction. When we say things like, "Small batches, iterative work," they have an allergic reaction. They're like, "You're talking IT speak. Agile, that's like an Italian term. Don't come to me with that." Bob: [laughs] It's a major word. Kevin: Yeah. [laughs] It's a major word. They don't know any of that stuff. "You're an IT folk. Don't tell me how to run my business." They have an allergic reaction to it. When we talk about sense and respond to market conditions, we actually introduced the term called "base camp." You saw it in our DevOps mountain journey. We have base camps and just tranches of work we want you to try to achieve. Those things that we listed don't have to be done in any particular order, but they needed to be done before you move on to the next base camp. That concept is now resonating with our senior business leaders like, "OK. You're saying that we can package up or at least conceptualize this body of work. You can get it done in a reasonable time frame, usually three, four months. We can deploy it to our end customer, whether that's the end‑customer, or a distribution partner, or what have you. They will get value. We'll get value. We'll measure that and then we will decide whether we want to continue or pivot. It's broad concepts that are outlined in books like "The Lean Startup," by Eric Ries and others. We are using language that our non‑tech‑savvy business leaders can rally behind and don't feel threatened by. It has been really impactful for us to get to that point. Bob: I was speaking earlier with a gentleman from Microsoft and they did a sort of long‑term study over the features that they had added. They found that one‑third achieved some improvement in customer experience, a third were neutral, and a third were negative. When you that sort of data that says if we just produce the things that we will plan to do, we're at net zero impact unless we kill the losers and double down on the investment in those things that are moving the needle. There was a huge conceptual turnaround for Microsoft. They're huge. They have a huge legacy codebase. So big, he said they actually broke Git and they became one of the major contributors to the Git source code because it was taking 12 hours to clone the Windows repository onto your laptop to make changes. It was just so a lot bigger than the Linux kernel, a lot bigger than any other stuff that had been thrown at Git to date. They developed the new virtual file system that's used in Git and they are now down to like two to three minutes for that clone. This idea of reacting to an emerging situation, I think is one that can resonate. I'm really interested to get my hands on the "War and Peace and IT." Kevin: Mark Schwartz? Bob: The Mark Schwartz book. I loved his analogy with the battle with Napoleon and the slow decision loop actually not even neutralizing, but making the decisions actively bad. We have not done ourselves much good in the community to allow this idea that Agile, DevOps, the lean terms we've been using were fundamentally IT. It's good to hear that you guys are at least turning that around. Kevin: It's the combination of those concepts that we feel are going to give us the advantage and the power. If we only focused on making our Agile machine more efficient and implementing DevOps everywhere... Bob: 10 or 15 percent, possibly. Kevin: ...it would only take it so far. Now, I will say we have an example of where...We have a particular couple of teams that support our digital online experience where customers deal us over the Web. They are probably our most advanced example. They can deploy at will. They can do safe, reliable, zero‑downtime deployments whenever they need to, multiple times a day if necessary. They are our business partner and they have by the way done a great job forging a very strong relationship with their business partner. After they had done this only for two or three weeks, the business partner remarked, "Well, maybe I don't have to test everything now." Like, "Yes." Because now he has confidence that when things do arise, you can fix it right there, very quickly. Our mean time to repair is very short. That saves him time and energy, it saves us... All good things happen when that circle gets tighter. Being able to demonstrate, not just talk the talk, but demonstrate it, you're boots on the ground with this. When we actually can achieve this, it changes the whole culture around and how to thinking around it. Bob: What has been an interesting thing that you've learned at the conference? Kevin: Focus of my talk with Nicole from Tasktop, plus many of the other talks here where they were talking about CSG, Mark Swartz's talk in the morning yesterday all around the concept of project to product, and the difficulties with that. Not a one size fits all models, not a prescriptive model, a lot of people trying to solve the same problem. There seems to be wide agreement that whether you are approaching that from technology left or from the business process on down, you're going to uncover all sorts of complicating factors. I was talking with Verizon just a few minutes ago and as they tried to move along their project to product journey, they might have success with a business partner rethinking how they are going to conceptualize work in a product way. Even the roles that go along with supporting that work, thinking about the differences between what a product manager might do, and product owner, and should they be basically sourced from the same group. All those sorts of nuances of execution. Then when they get to the supporting IT components, they figure out well, the IT components were never architected to operate this way together. I heard similar stories from Discover Card where they've done a nice job with some of their executives on conceptualizing around products not projects, and they need to come to figure out, but even then within a product realm, they have miniature silos within IT where teams either have competing and not‑compatible technology. [crosstalk] Bob: Business intelligence team. So many components. Kevin: So there's a huge ripple effect of this. I think we're very early on in these conversations. Especially if you are not a traditional CPG company. Bob: Yeah. That's what I was going to say. The future is already here, it's just badly distributed. [inaudible 17:02] . [laughter] Kevin: That's a great way to say it, yes. Bob: Yeah. Kevin: Years ago, 2004‑ish, I was a senior product manager for AOL. We did have it figured out, business and IT together, had a PL. Everything we did on a weekly basis was outcome driven, and it made perfect sense at the time. A lot of companies were not there. Bob: Were you out in the Virginia area? Kevin: This was AOL Columbus. Remember they bought CompuServe a million years ago. Netscape ran out of Columbus. We spent two days a week in Dallas, but primarily it was Columbus. Bob: OK, because we did a lot of the early work with Agile with AOL, but it was all near our scenic Herndon office. Kevin: We were doing Bluegreen employments every Wednesday morning and we didn't even know that that was a thing back then. It was just how we deployed code, yeah. Bob: That'…

Full show notes at the publisher

Mik Kersten - DevOps Enterprise Summit 2018 Nov 07, 2018

Show notes

CEO of Tasktop Technologies Mik Kersten discusses his session "Project to Product: How Value Stream Networks Will Transform IT and Business" at the DevOps Enterprise Summit 2018. Connect with Mik and Bob on Twitter. Learn more about AgileToolkit Sponsor LitheSpeed at lithespeed.com. Transcript: Mik Kersten ‑ DevOps Enterprise Summit 2018 Bob Payne: "The Agile Toolkit." [music] Bob: 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. 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? 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. Mik Kersten: Excellent. Thanks, Bob. Yeah, I think that's a great summary. Bob: Great. [laughter] Bob: Why don't you just give a little recap of the things that you were saying and some of the clients you're at? Mik: 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?" 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. Bob: 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. [laughter] Bob: I wish I had. Mik: 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. 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. 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. 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. 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. Bob: A local optimization problem rather than a system's. Mik: 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?" 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. 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. 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. 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. 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. 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. 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. [laughter] Mik: 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... Bob: Time and motion set us free example. [laughs] Mik: 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. 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. 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... Bob: Also, you were unable to exploit opportunities that come because your plan doesn't include those opportunity. Mik: 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. Whereas cost reductions can be very important, but you need to focus on value delivery. We need to measure value delivery in software. 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. 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. That's really the goal of the flow framework. Bob: 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. 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? 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. Mik: 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. 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 Bob: 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. Mik: 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. 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. 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. 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. 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. Bob: Revenue, retention, referral. Mik: 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. 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. 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. 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. 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. 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. 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. We hire people who want to deliver value, and when we get in their way of doing that, they're not happy. [laughs] Bob: 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. 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? 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. Mik: 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. Given their understanding and their frame of reference, which might be a financial background, might be a sales, go‑to‑market background... Bob: Might be a traditional project control background. Mik: 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. Bob: When somebody across the table is speaking a language you don't speak, you see risk. Mik: 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. 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. Bob: I don't know whether you h…

Full show notes at the publisher

Jeffrey Davidson, Jo Avent - Agile2018 Nov 07, 2018

Show notes

Jeffrey Davidson and Jo Avent join Bob to discuss their Agile2018 session Hunting for Diamonds: Hiring the Very Best for Your Agile Team.

Connect with Jeffrey and Bob on Twitter.

Shane Hastie - Agile2018 Nov 05, 2018

Show notes

Shane Hastie joins Bob to discuss his Agile2018 sessions: Being Agile in a Remote Team and The Foundations of Business Agility Shane is the Director of Agile Learning Programs at ICAgile, Chair of Agile Alliance New Zealand, Lead Editor for Culture & Methods & Podcast Host on http://InfoQ.com. Connect with Shane and Bob on Twitter.

Johanna Rothman - Agile2018 Nov 02, 2018

Show notes

Johanna Rothman joins the podcast at Agile2018 and discusses her sessions: You Have to Say More There: Effective Communication in a Distributed Agile Team and Agile and Lean Roadmapping: Incorporating Change at Every Level of Product Planning.

Connect with Johanna and Bob on Twitter.

Sam Guckenheimer - DevOps Enterprise Summit 2018 Nov 01, 2018

Show notes

Bob chats with Microsoft Azure DevOps Product Owner and author of Agile Software Engineering with Visual Studio, Sam Guckenheimer, at the DevOps Enterprise Summit 2018. Connect with Sam and Bob on Twitter. Transcript Sam Guckenheimer ‑ DevOps Enterprise Summit 2018 Bob Payne: "The Agile Toolkit." [music] Bob: Hi, I'm your host Bob Payne. I'm here at the DevOps Enterprise Summit 2018 with Sam Guckenheimer. Welcome, Sam. Sam Guckenheimer: Thank you, Bob. It's great to be here. Bob: 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? Sam: Well, that was no what 14 years ago or something like that. [laughter] Sam: 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. Bob: That fracturing has continued and remains as stupid today or... [laughs] Sam: 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. 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. [laughter] Bob: 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. Sam: 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... [crosstalk] Bob: It's captured a value, enlargement value. Sam: It's live in production with Telemetry that is demonstrating the value delivered. 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. 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. Bob: 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... [crosstalk] Sam: 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. 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. 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. Bob: 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. 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. Sam: 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. Bob: 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. Sam: 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. 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. Bob: 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... [crosstalk] Sam: 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. 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. [crosstalk] Sam: 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. 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. 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." 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." 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. Bob: Yeah it has been a sea change since I did Fortran on punch cards [laughs] . Sam: 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. 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?" 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. Bob: 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. Sam: 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. The latest example decide or...I don't know if that's politically correct to go there, but you see it now in... Bob: [laughs] That have been substantially politically correct on this podcast [laughs] . Sam: You see this in cyber. The Russian budget for cyber is less than the cost of an F‑35. Bob: No one could argue that the F‑35 is more costly than it needs to be but it's... [laughs] . [crosstalk] Sam: 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. 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. 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. Bob: It's actually one of the analogies I quite often use when I'm talking to people that are OK with the military analogies. 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. Sam: 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. 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. 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. Bob: You mentioned the one‑third, one‑third, one‑third, I know that was a study that came out in Microsoft. Actually... [crosstalk] Sam: 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. 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. Bob: 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. Sam: 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. 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. 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. Bob: 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... [crosstalk] Sam: I totally think that people should collaborate on design. I'm totally for that. I'm not trying to.. Bob: 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. Sam: 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. 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?" Bob: 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. Sam: 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. 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. 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. 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. 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. Fifth finally is using cloud to make infrastructure‑flexible resource. That's how I bucket it. I did one talk yesterday with my…

Full show notes at the publisher

Esther Derby - Agile2018 Nov 01, 2018

Show notes

Esther Derby chatted with Bob at Agile2018 about her two sessions - Creating an Environment for Successful Agile Teams and Clarity, Conditions, Constraints: An Alternative to Top Down Control.

Connect with Esther and Bob on Twitter.

Scott Ambler - Agile2018 Sep 28, 2018

Show notes

Scott Ambler joined Bob on the podcast at Agile2018. Hear about Scott's Agile2018 talks "Database DevOps: Strategies to Address DevOps' "Last Mile" and "Agile Architecture: Mindset, skills, and practices."

Connect with Bob on Twitter and @LitheSpeed.

Steve Mayner - Agile2018 Sep 27, 2018

Show notes

How's the Agile world growing up? Dr. Steve Mayner, SAFe Fellow and Principle Consultant at Scaled Agile, Inc. joins Bob on the podcast at Agile2018.

Connect with Steve on Twitter.

Follow Bob's Twitter and visit LitheSpeed.com for support building an Agile organization.

Jeff Sutherland - Agile2018 Aug 21, 2018

Show notes

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]

Full show notes at the publisher

Our TOPPODCAST Picks

Follow Us

Stay Connected

Related Podcasts

Links

Stay Connected