AgileToolkit Podcast

I had the pleasure of speaking again with Jurgen Appelo in regards to his work on the Unfix model.  He and his team have taken the work on Team Topologies and extended it with a number of organizational patterns.  As he says they are like organizational lego blocks that allow you to visualize and experiment with different organizational structures when you are designing an new operating model for your teams.  He has integrated a lot of tools from his Management 3.0 work as well and the community resources are a treasure trove of goodies.

I hope you enjoy the talk as much as I did.

https://unfix.com/

I joined Brian Milner from MountainGoat Software and we chatted on the Agile Mentor Podcast.

Enjoy this cross posted podcast from Brian.  I always enjoy speaking with him.

Join Brian and his guest Bob Payne as they discuss the principles of lean thinking and how they apply to Agile methodologies.  

In this episode of the ?Agile Mentors? Podcast, Brian sits down with Bob Payne to discuss the intersection of Agile and lean thinking. As an experienced Agile coach and host of the ?Agile Toolkit Podcast,? Bob shares his insights and offers practical tips for implementing lean thinking in your own team.

Listen in as they explore the fundamental principles of lean thinking in Agile methodologies.  They discuss managing flow, not workers, and the importance of continuous improvement and experimentation to achieve sustainable, high-quality results in your organization and success in today's fast-paced business environment.

Dana and I chat about facilitation in the virtual space, Liberating Structures and Training from the Back of the Room.  I always learn something when I chat with Dana and I hope you will find something actionable from this conversation.

Enjoy

I had the pleasure of appearing on The Scaling Tech Podcast with Arin Sime and David Alfaro.  Great conversation and I hope you enjoy their other eposodes.   We cover a lot of topics and I focus on putting agility back into Agile.   https://scalingtechpod.com/ep14-bob-payne-on-has-agile-lost-the-plot/   The YouTube video is here: https://youtu.be/i-RxivPGrAs   Enjoy.  

I had the pleasure of appearing on the Coaching Conversation podcast with my old friend Salah Elleithy. I always enjoy chatting with Salah and hope you enjoy some of his other podcasts.

https://soundcloud.com/sparkagility

If you want to watch it on youtube you can find that version here.

https://youtu.be/0mH6cZXKdKo

 

 

I spoke with Ulrich and Marie Lages at the Business Agility 2022 conference.  We talked about the radical reorganization that they undertook at Ibeo Automotive Systems.  Ulrich is the founder of this Automotive Parts Manufacturing company and developed the LIDAR system that is used in many autonomous vehicles. 

Marie and Ulrich discuss the radical reshaping of Ibeo when they blew up the traditional hierarchy and reformed around a flat team of teams approach from the bottom up.

I really enjoyed this conversation. Even though it was a noisy spot that we recorded in I hope you will enjoy it as well.

Bob Payne

I spoke with Ron and Kathleen about their AI Today podcast.  AI Today is a great podcast that covers a wide range of practical AI topics.  Ron and Kathleen talk about the Podcast, their work at Cognilytica and a wide range of AI related topics.  We also talk about the interplay of Agile Methods, AI and large data projects.  

https://www.cognilytica.com/aitoday/

Enjoy the conversation.

Bob Payne

I spoke with Evan again at the Business Agility Conference 2022.  Evan is the founder of the Business Agility Institute, runs the Business Agility Conference.  We speak about the evolution of the conference into a hybrid event.  We also talk about the research that they have engaged in regarding the 86 behaviours of Agile organizations.

I always love talking with Evan and this conversation was no different.

Enjoy - Bob Payne

I spoke with Marsha at the Business Agility Conference 2022 in NYC about her work with Team Catapult.  How facillitation and leadership play off each other in an organization.  How can we help leadership teams to engage in conversation and organizational development.

Enjoy

Bob Payne 

I speak with Pete Behrens at the Business Agility Institute conference 2022.  We discuss his approach to growing Agile Leaders and his Agile Leadership Journey program.  I have been following his work for years and really enjoyed this conversation.

Enjoy

Bob Payne

I Speak with Peter Coesmans about the Business Agility Consortium and the evolution of DSDM.  We speak about business agility, agile cultures, agile governance and agile delivery processes. 

Great conversation and I hope you enjoy it as well.

I spoke with Todd Little and Joey Spooner at the BAI conference.  We speek about the evolution of Kanban and how Kanban can drive evolutionary change in an organization. We chat about Value Stream Managment, DevOps, transformation, continuous improvement, adaptive govenrnance and the many ways that Kanban can help.

I have known Todd and Joey for many years and it was great to speak with them in person.

Enjoy

Marina Alex is the creator of SWAY (Sales with Agile system), a business agility coach and agile sales expert. I spoke with Marina about her work and the use of Agile methods in sale. Overcoming resistance, understanding risk and putting the customer first.   

Enjoy

I spoke with Ondr?ej at the Business Agility Conference 2022.  He has been working with lawyers to use Agile methods for delivering their work.  Another great example of Agile outside of IT.

I was impressed with his passion and the work he has been doing to help Ukrainian refugees find pro bono legal assistance.  He quickly stood up a site to match refugees with lawyers that can assist them.  As part of that work he is also employing his experience with Agile in IT and in the Legal profession.  

If you are a lawyer, a refugee or just interested in the work that they are doing please visit.

https://www.ua.support/

Last year I spoke with Jurgen Appelo at LitheSpeeds annual Lean + Agile DC conference.  He delivered a great Keynote on his book Startup, Scaleup, Screwup.

Welcome to this special edition of the Agiletoolkit Podcast hosted by Padmini Nidumolu.

Padmini is one of the founders of Lean In Agile for Women here in the DC area and also hosts a meetup focused connecting women in the Agile community to share their stories.

http://leaninagile.org/team.html
https://www.meetup.com/NOVA-LeanInAgile/

In this podcast he speaks with several speakers from Lean+Agile DC. Enjoy her conversation with Jessica Hall, Lisa Mabli, Christina Garnett and Rachael Bradstock.

 

Enjoy this podcast.

- Bob Payne

I spoke with Lisa Smith at the Business Agility conference 2019.  She and I chat about her use of Agile methods in Duke Energy.  She is a former executive from Duke Energy who was leading business agility transformation in 2018.  She?s left behind a true legacy of business agility within energy industrial operations.

Here are some links to her 2018 talk at the Business Agility Conference.

https://businessagility.institute/watch/business-agility-within-a-regulated-utility-by-lisa-smith/

Enjoy

 

I spoke with Pia-Maria Thorén (@piamia2) at the Business Agility 2019 conference.  We talk about her work with Agile HR and people operations.

She is the author of Agile People A Radical Approach for HR and Managers.

I spoke with @geofellingham about the Agile Business Consortium and using an Agile approach to hire an executive for the organization.

Enjoy

Bob Payne

I switch seats and let Evan Leybourn interview Sanjiv Augustine and me about the Business Agility Sparks framework we have published from LitheSpeed

We are excited to be promoting the cause of Business Agility with Evan and look forward to the Business Agility Conference in NYC.

For more on the Business Agility Sparks and the Business Agility Conference Visit the following links.

Business Agility Sparks

Business Agility Conference - NYC

Enjoy 

Bob Payne

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's great. Is there anything you're going to take back that you think will be impactful?

Kevin:  I am. We're in the midst of modernizing our tools that support program and project management and Agile life cycle management. We've made significant progress in how we organized IT, how we execute Scrum and XP across IT. We have not modernized any of the tools that people use to actually do that. We're going to fix that in the next couple weeks.

Good conversations with a lot of companies that are either a bit farther along than we are or recently made a change. It's been great learnings for us and that team that's here to do that.

Bob:  Great. Thank you so much for the chat. It's always been a pleasure working with you.

Kevin:  Bob, it's always a pleasure.

Bob:  [laughs] Good.

Kevin:  Thank you.

Bob:  Bye.

Photographer:  Can we do a picture?

Bob:  Sure.

Kevin:  Because no one will believe that I was on a podcast.

Bob:  Well, they will.

Kevin:  Was that OK?

Bob:  Yeah. It was perfect.

Kevin:  You do this all the time. I'm new at it, so...

Bob:  Well, yeah. They're all this sort of conversational... [laughs]

Kevin:  Did it take?

Bob:  Yeah.

Photographer:  Yep.

Kevin:  Cool. All right. Thank you very much.

Bob:  Great. If you're going to tweet it out, I'm @agiletoolkit.

Kevin:  Cool.

[pause]

Bob:  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 [email protected]. For more free resources, transcripts of the show, and information about our services, head over to lithespeed.com.

Thanks for listening.

[music]

 

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 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...

[crosstalk]

Mik:  It sounds like a word to me.

[laughter]

Bob:  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.

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.

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."

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]

Mik:  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.

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.

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.

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.

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.

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.

I've tried to distill it to give people a very concrete starting point. If they want to evolve the terminology, they certainly can.

Bob:  Is there something that you've learned or are going to take away from this particular conference?

Mik:  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.

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.

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.

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.

Bob:  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."

Mik:  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.

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.

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.

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.

I would personally love more conversations with people like CFOs who care profoundly what's happening with value and spend. [laughs]

Bob:  Oh my God.

[laughter]

Bob:  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.

Mik:  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.

Bob:  I often use the other Deming quote, which he was talking about, continuous improvement, "Learning is not compulsory. Neither is survival." [laughs]

Mik:  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.

Bob:  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.

We're mostly tool agnostic. We often joke that our biggest tools are your executives.

[laughter]

Bob:  We do a lot of work with executive teams and organizational transformation. I never actually make that joke.

[laughter]

[crosstalk]

Mik:  Yeah, exactly. There's rooms where that joke'll fall flat.

Bob:  Yeah, that might fall flat.

Mik:  [laughs] That's great. Thank you, Bob. It's been a great conversation. Thank you.

Bob:  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 [email protected].

For more free resources, transcripts of the show, and information about our services, head over to lithespeed.com. Thanks for listening.

[music]

Transcription by CastingWords

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 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 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.

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 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.

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.

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.

Bob:  Really?

Sam:  Yes.

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.

Bob:  Need to start again, yeah.

Sam:  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.

Bob:  That's interesting. I did not know that you guys were major contributors to the Git.

Sam:  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.

Come to the talk tomorrow.

Bob:  OK, I may. What time is it?

Sam:  11:25, I think? 11 something. The times here are weird. All these weird five?minute increments.

Bob:  [laughs] . It is five?minute increments and three hours off, because I'm an East Coast person. Are you out of...

[crosstalk]

Sam:  Along Seattle.

Bob:  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?

Sam:  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 aka.ms/DevOps. It's, DevOps and Microsoft.

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."

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...

Bob:  As a resource?

Sam:  ...open resource.

Bob:  Thank you very much. It was very nice meeting you and chatting.

Sam:  Thanks a lot, Bob.

Bob:  Thanks.

The Agile Toolkit Podcast is brought to you by LightSpeed.

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 [email protected].

For more free resources, transcripts to the show, and information about our services, head over to LightSpeed.com. Thanks for listening.

[music]

 

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 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.

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.

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 [email protected].

For more free resources, transcripts of the show and information about our services, head over to lithespeed.com. Thanks for listening.

[music]

Business Agility Institute founder Evan Leybourn shares results from the 2018 Business Agility report at Agile2018.

Connect with Evan on Twitter: @Eleybourn

Download the Business Agility Report (2018).

Add your voice to this report: Take the Business Agility Survey for 2019's report here.

Follow @AgileToolkit.

Visit LitheSpeed.com to help your organization embrace Business Agility.

 

Transcript:

Evan Leybourn ? Agile2018

 

Announcer:  The Agile Toolkit.

[music]

Bob Payne:  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.

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.

Evan Leybourn:  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]

Bob:  Is it third already?

Evan:  Third already.

Bob:  [laughs]

Evan:  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.

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?

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.

Bob:  If not surprising, what are some of the important insights that folks were questioning and that now has been borne out in the data?

Evan:  [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.

Bob:  [laughs]

Evan:  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.

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...

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.

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.

That's not really a surprise. We know from personal experience that banking and finance, every bank is trying to...

Bob:  Huge competitive pressures with dust cycles.

Evan:  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.

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..."

Bob:  Self?reporting a little higher. [laughs]

Evan:  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.

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.

Bob:  Did you get any breakout that was aggregated against those different industries? Were different moods of business agility?

Evan:  No.

Bob:  Was it really customer pitted or service or...?

Evan:  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.

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.

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.

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.

Bob:  That's probably...

Evan:  It's statistically...

Bob:  ...insignificant.

Evan:  ...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.

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.

Bob:  The client organizations.

Evan:  Yes. When the external parties assessed them, they assessed them 15 points lower. 1.5 points lower, 15 percent lower than themselves.

Bob:  That may make sense with your transformational model...

Evan:  It could.

Bob:  ...as well, because I can't really help unless I'm in some aspects better at it than the organization.

Evan:  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...

Bob:  Other people.

Evan:  ...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.

Bob:  We probably have different north stars that we're measuring against.

Evan:  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.

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.

Bob:  Was the survey both public and private sector?

Evan:  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.

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.

Bob:  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...

[laughter]

Bob:  ...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.

Evan:  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.

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...

Bob:  [inaudible 10:00] .

Evan:  ...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.

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.

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.

Bob:  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.

Evan:  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.

Bob:  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.

[laughter]

Evan:  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.

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.

Bob:  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.

Bob:  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.

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.

Bob:  Retention of clients.

Evan:  Retention of clients, yeah.

Bob:  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.

Evan:  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...

Bob:  Just trying to find the page right now.

[laughter]

Bob:  Leadership, lack of buy?in, inappropriate organizational design.

Evan:  Of course, old design. Sorry, I should remember that one. It's off my head. Basically, the value stream is broken.

Bob:  The silos.

Evan:  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.

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.

Bob:  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...

[crosstalk]

Evan:  ...is due. We've admired the VersionOne survey for years.

Bob:  It has been a valuable tool.

Evan:  It's one of the reasons we created this is to go [inaudible 15:53] .

Bob:  Number one is better ability to manage change. What do markets want? They want responsive goods and services.

Evan:  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.

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.

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.

Bob:  [inaudible 16:48] .

[laughter]

Bob:  [inaudible 16:50] is running in my head.

Evan:  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.

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.

Bob:  We get [inaudible 17:23] all the time. That's just one possible transactional character.

Evan:  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.

Banks make their money out of credit cards and all these transactions, and all these other things, so the FinTechs are coming in.

Bob:  They can be in the right market if you've got some liquid cash that you're...

[crosstalk]

Evan:  That's certainly not where the banks are making their profit.

Bob:  No.

Evan:  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.

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?"

Bob:  "How do we disrupt ourselves before someone else does?"

Evan:  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.

Bob:  We're seeing people fall off the Fortune 500 lists.

Evan:  57 percent of the 1983 Fortune 500 no longer exists.

Bob:  Not even just off the list. Just out of existence.

Evan:  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.

Bob:  We'll have the link to the report. Where can folks learn about the Business Agility Institute?

Evan:  Thanks. We'll put the links below, businessagility.institute. I love the fact that .institute is a top?level domain.

Bob:  [laughs]

Evan:  We bought that.

Bob:  .institutionalized.

[laughter]

Evan:  That's what I should be. Absolutely. Businessagility.institute, 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.

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.

Bob:  Thank you very much.

Evan:  No, thank you very much, Bob. Until next time.

Bob:  Until next time.

Evan:  [laughs] Thank you.

Bob:  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 [email protected].

For more free resources, transcripts of the show and information about our services, head over to lithespeed.com. Thanks for listening.

[music]

 

Tammy Gretz and Wendy Jacobs discuss their talk "From Self Obsession to Self Selection: A Scaled Org's Journey to Value Reorganization" at Agile2018.

 

Transcript

Tammy Gretz Wendy Jacobs ? Agile2018

 

Bob Payne:  "The Agile toolkit."

[music]

Bob:  Hi. I'm your host, Bob Payne. I'm here with Tammy Gretz of [inaudible 0:25] ...

[laughter]

Bob:  ...and Wendy Jacobs. We've chatted a bit before this, but this is the first time you guys are doing a podcast, I think.

Wendy Jacobs:  A live podcast, yes.

Bob:  A live podcast.

Wendy:  Correct.

Bob:  This is recorded.

[laughter]

Bob:  You still have had to come.

Wendy:  This is the first live or recorded podcast for me. There you go.

[laughter]

Bob:  You are doing a talk and it's related to team self?selection, From Self?Obsession to Self?Selection. What's that all about? How do you two work together? What's your back story? What's the talk?

Wendy:  I work at AEP, American Electric Power ?? this is Wendy ?? and Tammy and I work together there. She is a Scrum master on one of the teams working through our Agile partner, Cardinal Solutions. We started working together when she joined the team that we actually talk about.

Tammy Gretz:  I was coming from it from a prospective of, it was a new team and I was there to teach them Scrum. They had never done it before.

Bob:  Is this new to the whole organization or just to this team?

Wendy:  We are in a multi?year Agile transformation. The self?selection and scaling, which is another aspect of the talk that we're doing, is new to the organization. This was the experiment.

Bob:  How long have you been running Agile teams before you hit scaling and self?selection?

Tammy:  Before I came to AEP, I had been working about two or three years in an Agile environment. The AEP transformation, I believe, has been between seven and nine years.

Bob:  Usually teams don't get to self?selection until they've been doing it for a while.

Wendy:  The group of teams that we're talking about, one of them was new when Tammy came in, newly into Scrum. The other two had been Scrum teams for a couple of years.

Bob:  What was the self?obsession portion of the program?

Tammy:  [laughs] My team specifically was new to Scrum. The intention wasn't to go to scaling or do this whole self?selection when I first started. It was teach this team Scrum and figure out how to get them working with the other two teams.

We quickly realized that there were a lot of moving parts that need to have some kind of an organization or some framework to work with.

Wendy:  The self?obsession aspect is just human. We're worried about ourselves. When we're talking about having to all come together and do self?selection event that involves trying to figure out how to deliver the most value to the company, you have to shed that self?obsession, that selfishness and become selfless, because you have to see, where can I help most?

This was a journey to take the individuals into teaming, into the ability to do self?selection. That's where the...

Bob:  Also, there's team identity, which you blow up with self?selection. What is the event that caused you to say, "Hey, we need to kind of shake the snow globe here?" [laughs]

Wendy:  We took a scaling class with a very experiment?tolerant manager, we like to call her Andrea.

Bob:  Because that's her name.

[laughter]

Wendy:  Protecting the innocent, whatever. Anyway, there was a kernel of it in there. One of the gentlemen on my team, he had a white paper on self?selection for teams. We had begun talking about it. He sent her the white paper. We like to call him Greg. He sent her the white paper to just wet the whistle.

Get the juices flowing about what does it really mean to do that, and she loved it. She loved the empowerment to the teams to be able...

Bob:  It wasn't by Amber King was it?

Wendy:  I don't recall. We can check.

[laughter]

Bob:  That would be interesting. She's a good friend of ours and she did a white paper on self?selection at Cap One. It's possible.

Wendy:  Very well possible. That was the kernel of it. She got a hold of that and really embraced it, and thought, "This could..." We were in a scenario where we wanted to make sure that the teams were formed in a way that delivered the value best. We were focusing on the value delivery.

She worked with her business partners to define what those value streams were.

Instead of just saying, "OK, you're on this team, and you're on this team, and you're on this team," she decided to let the teams decide, "Where does your value heart sing? Where do you want to put your focus?" thus lead us to self?selection event.

Bob:  How many people?

Tammy:  Thirty?four.

Bob:  How many teams did you end up with?

Wendy:  Six squads. That was a very critical word in this. We went from three teams to six squads because we're all part of one team. In a scaling event, you're really part of one team. She was really very specific about wanting to call these squads up to the general team.

Bob:  How did it go? I'm sure some people were the Cookie Monster characters for the self?selection. Some people...

Wendy:  People were people. [laughs]

Bob:  ...wanted to be told where go. "Tell me where to sit." [laughs]

Wendy:  Exactly. It's all human. Think about being here at this conference. This is something we're going to talk about tomorrow, is that, how do you even select what session to go to? How do you figure out where you're going to sit? There's all sorts of reasons in your head.

Tammy:  Nobody has the same two reasons. People pick things for weird reasons. They pick them for very specific, concrete reasons. You can't plan for that.

Wendy:  The event went well. It was a two?day event. The self?selection took place the first day. We had some teaming main events on the second day to try to make sure that they were ready to go. Team agreements and let's talk about the definitions.

During the actual self?selection event, Andrea took care to really plan this. We helped her. We met for a couple months to plan this event. She made it fun. She made it seasonal. [laughs] It was right near Valentine's Day. There was a Valentine's Day theme to the whole thing. I was very impressed with what she came up with. Just the creativity that came out of her.

Tammy:  For me, I was more of a participant during this. I was embedded in the team and Wendy was a coach with the team. She was working with the manager. It was very interesting to experience what maybe my other coworkers on the team, my other teammates, what they were experiencing, even though I knew what was coming.

I still had that knee?jerk reaction to be a human, and be like, "Oh, you want me to...? Oh, I got to do this? I don't care. Just put me wherever." [laughs]

Bob:  Did you end up with any value streams that were starved of folks and then have to re?negotiate?

Wendy:  Interesting you ask.

[laughter]

Wendy:  Have you seen our talk? No.

[laughter]

Bob:  I've seen self?selection events.

Wendy:  That was actually the exciting moment. One of the exciting moments of this experience is that there were five total iterations to get to our final teams. It was after iteration four, and we had a starved squad.

There wasn't anyone on one of the value streams. The managers stood up and said, "Hey, how are we going to deliver this? How are we going to deliver this value?" It was there that the Scrum value, courage, popped up its head.

A couple of people were like, "We want that. We can take that on," and got up from where their friends were, where they felt comfortable, walked over that table and planted themselves, and said, "We got it." It was awesome.

Bob:  Was it just Andrea?

Wendy:  Yeah. [laughs]

Bob:  Was she the advocate for each of them, or were there value stream owners that were...?

Wendy:  The product owners were there and they come from the business. They were participating in this. Their management was there, too, watching, helping, and answering any questions if we had any, but Andrea was the manager of most of the people in the room.

The answer is she advocated for all the teams and wanted to make sure that we came out with something that would benefit the company overall.

Bob:  Is this a one?time event or are you periodically revisiting as the demands on value streams change?

[laughter]

Tammy:  Actually, part of the agreement was that if they didn't like where they were, they had a chance to do it again in six months. We're right about at six months right now. They have come back and said, "Maybe we didn't think about this in the right way, necessarily, and we were still self?obsessed a little bit."

Now they're starting to see where, "Oh, maybe it might have been better if these two people were flopped," or, "This value stream might be a little better tweaked." They're learning from it. We're hopeful that they'll get to do that again here shortly. Interestingly enough, we have another group here that is going to be talking about another way that they did it.

I've moved on to a different team and I've just completed another self?selection there [laughs] with that team because they were growing. They were a smaller team and they realized that they needed to hire more. They hired four more people, which made them a massive team. We had to have discussions around the same kind of thing.

We learned a lot from the first one, [laughs] applied it to this one. This one went really smoothly. It didn't take quite as long, but it was...

Wendy:  The whole company's very supportive of continuous improvement. That's part of our culture, we're a continuous improvement company. I've helped with another self?selection event not long after the one we did in February, and it was different. We've done it a couple different ways and we're learning each time from it.

Tammy has the benefit in her current team to apply all the learnings we had and munge some of that together so they would have a very smooth event.

Bob:  One of the things that I've seen in some places, as the business demands change, certain value streams will become higher in priority, where more work needs to flow through them. Have you guys experienced that yet or is that a future event?

Tammy:  We might be going through it pretty soon. [laughs]

Wendy:  With the current team you're on?

Tammy:  Yeah.

Wendy:  The current team that she's on, they are going to be sized a little differently based on the amount of stuff that's going to come through them. It is possible that that team may split again, the larger team. We're really looking at what makes the most sense. We're doing these experiments to try to understand what's working, what's not working, how can we tweak it?

The managers are just very open and very wanting to try these things to make it the best place that they can.

Bob:  One of the things that I saw one client do is quarterly, when they would do the equivalent of a cross?program planning event, would then allow people to swap chairs, or they would shuffle demand, and say, "We need more folks over here, who would like to come join?" Then people would come, and they were like, "Oh shoot, we're too short over here."

I don't know if they did five rounds. I don't remember exactly, but some number of...

Tammy:  It's funny you said shuffle chairs, because that was almost more important than which team they were on, is where they were going to sit.

Bob:  Oh yeah?

[laughter]

Wendy:  "I want the window. No, I want the window." They're, again, human.

[laughter]

Tammy:  It's all about the humans. It wasn't about the work. It was...

Bob:  The soft stuff is the hard stuff. [laughs] Agile's easy, people are hard.

[laughter]

Tammy:  It's especially the different personality types. Even if we go really high?level, introvert, extrovert, some of these things could be very hard for introverts, I think. You're speaking up and saying, "I want to go there." There's that shyness that they don't want to ruffle any...make any waves or do anything like that.

All of these events, we've been very purposeful in thinking about that, making sure that there's no one really uncomfortable to a point where...

Bob:  They could be uncomfortable, but not really.

Wendy:  Self?selection is uncomfortable.

[laughter]

Wendy:  We don't want to push them so far.

Bob:  I wouldn't pick me.

[laughter]

Tammy:  You should always pick yourself.

[laughter]

Bob:  That's really exciting. Hoping that you'll get a good run of folks at that talk. It'll be very interesting. What else has been exciting about the conference? I know it's only day two. I believe you were at the Women in Agile. Did you do any of the camp before that, or just the Women in Agile?

Wendy:  I actually didn't know about the camp before. Now that I know that they happen...

[laughter]

Bob:  They don't always happen.

Wendy:  I know there's one happening, I believe, in Chicago in October or something like that, I was told. Now I'll be looking into this because it sounds like an interesting place to share ideas, get some new thoughts about how to do some things. Improve the toolkit.

Tammy:  I'm really enjoying the Audacious Salons.

Bob:  Good.

Tammy:  Really enjoying them, a lot. [laughs]

Bob:  Were you there yesterday?

Tammy:  I was there for the leadership one, Agile Leadership. Today is The Next Big Idea.

Wendy:  We did hear the afternoon session was quite interesting. Quite charged.

Tammy:  I missed that. [laughs]

Bob:  George said they went hours over the slot. I know Lisa and George very well. George has been on the podcast many, many times.

[laughter]

Wendy:  We are in good company.

[laughter]

Bob:  We have the "Tips and Advice" series on Agile Toolkit Podcast. How was the Women in Agile event? I know you met Amanda there, my colleague.

Wendy:  Yes.

Bob:  Big Pete was there. I don't know if you met him?

Wendy:  I did not meet Pete. Did you meet Pete?

Tammy:  No.

Wendy:  Women in Agile, I enjoyed it. I like meeting people. I like meeting all kinds...

Bob:  You seem very shy.

[laughter]

Wendy:  Believe it or not. [laughs]

Tammy:  She's the connector. She knows people, and she's like, "Hey, you guys should know each other." [laughs]

Wendy:  I do. I make sure everybody meets each other. I liked hearing people's stories about where they were in their Agile journey. The table I was at was a table that had no question to answer. We got to make up our own question that we wanted to answer, which was nice.

We had a couple of folks at the table that weren't very far in their journey at all, and wanted to understand, what's the benefit of Agile over Waterfall? Those types of things. It was really very enjoyable to hear their perspectives on where they are and to try to share where I've been and where my enterprise is. It was a good event.

I really loved hearing the new voices. There were two speakers that came in. They were reasonably new speakers. They had such wonderful stories.

Tammy:  They were really great. The two new speakers, the new voices, that was a great element to that conference piece of it, is having these new people get up and speak.

Bob:  Do you remember who they were? I wasn't there. No?

Tammy:  I talked to them last night.

Bob:  [laughs] They're super new voices. Real super nice people as well. [laughs]

Wendy:  Their story was really great.

Tammy:  Their stories were amazing. The things that they went through and now the places they've been, it's inspiring. I wish them all the best of luck and hope to get to do some of the...they've gone internationally and spoken, and that just sounds really cool and really fun. Just listening to how they did that was neat.

Bob:  There's a decent conference ?? Agile India is quite good. The European conferences, I've not actually gone to those either. I'm looking forward to going internationally.

Wendy:  Maybe we should all go.

Tammy:  Yeah, let's go.

[laughter]

Tammy:  What time does the plane leave? [laughs]

Wendy:  Let's do it.

Bob:  It's a red?eye.

[laughter]

Tammy:  That's what she's on tomorrow.

Wendy:  Yeah, I've got to take a red?eye back.

Bob:  I'm sorry to hear that. I can't do it. I'm staying till Friday morning.

Tammy:  I'm staying the weekend. I wanted to get a couple extra days in just to enjoy the beautiful weather.

Bob:  The farmer's markets are actually fantastic if you like that sort of thing.

Tammy:  Absolutely.

Bob:  We had the Scrum gathering out here. I had my favorite breakfast ever, which was a sea urchin shell that had been cleaned out with micro?greens, tuna pokÈ, more micro?greens, and then the sea urchin laid out.

Tammy:  That is a very specific breakfast.

Bob:  Yeah.

[laughter]

Tammy:  It's not waffles.

Bob:  It's not waffles. I had an iced coffee with it so that made it breakfast.

Tammy:  She wants waffles.

Wendy:  I'm obsessed with waffles right now.

Tammy:  She is, yes.

Bob:  I don't know that they make sea urchin waffles, but they might someplace.

Wendy:  I'm not sure that they should.

[laughter]

Wendy:  Just saying.

Bob:  They should.

Wendy:  You do?

Bob:  Maybe a keto egg waffle with some sea urchin on would be good. What else are you looking forward to at this conference?

Wendy:  Speaking. [laughs]

[crosstalk]

Wendy:  Actually getting through that. [laughs] Yes, the speaking would be a number high on the list. Honestly, I'm just looking for new ideas. I'm focusing more into the product space, the talks that are going on. I'm looking for some of those new things that I can take back.

In my role, I am the product owner coach and I focus on the business side of things. I look for new tools I can use with them to help them understand why to do some of the things that we do, or just ways that they can do it better.

Bob:  The product discovery space, it takes almost a completely different tool set. The mechanics are relatively straightforward, but it is the divergent thinking. How do we winnow down these many ideas? How do we get it into that convergent process? Agile is a delivery process and it's a convergent one.

I love that interplay of when you can get it going. A little bit of experimentation, divergent thinking. Let's build it, test it. Let's get some data out. Let's have that drive our next set off experiments or experiences. I'm assuming you've looked at Business Model Canvas and stuff.

Wendy:  Yep. [laughs]

Tammy:  Yep.

Bob:  Impact mapping.

Wendy:  Yep.

[laughter]

Tammy:  It's all good. When I approach the coaching of product owners, I don't just dump, "Here. Here's all the tools. Try all of this at once." I layer it in, where, "Hey, I'm having a real problem with trying to figure out how to prioritize. Hey, I'm having a real problem deciding what should be our far?afield thing? Where should we be heading towards? How do I lay it out for my stakeholders?"

Things that people are probably listening to this and saying, "Well, duh." When you're new you don't know about this stuff. You can't overwhelm. Trying to find new tools that make it easier to embrace it and understand it, and may play on things they've done before, that's the things I look for to help them out.

Bob:  I'm sorry, you were...

Wendy:  No, go ahead. [laughs]

Bob:  Do you guys have user experience embedded in with your product teams or are they a separate agency kind of model, or a little bit of both?

Wendy:  A little bit of both. I'll say a little bit of both.

Bob:  That's great.

Tammy:  I was just going to say that I really like the Audacious Salon stuff because it's talking about a lot of the things we've already talked about in a new way or in a new light. I appreciate that. For me, working with the teams that I'm working with, I think they have been inundated with Agile and Scrum.

How do we talk about it in a way that they can hear it, and not that stance of, "This is the only way."

Bob:  I've always thought that was a ridiculous notion that Agile was a thing to concentrate on. It's a tool. Toyota Production System wouldn't have rested on a single process for very long without changing itself. [laughs] It's a means to great product outcomes.

Tammy:  I try to break it down for them as much as possible. Obviously, we care about the frameworks that we're using, but I try to break it down into simple questions. Answer these simple questions and that will help you get to that thing you're trying to produce, your vision.

That'll help you develop that vision. That'll help you develop that, "what's the next big thing?" I look for trying to, using Agile principles, break it down as small as possible to help them break through.

Bob:  Thank you very much. I really appreciate you guys coming in and chatting. I hope you have a great talk.

Wendy:  Thank you for asking us on the show.

Tammy:  Thank you.

Bob:  Although I think it's right at the same time as mine.

Wendy:  It is exactly the same time. [laughs]

Bob:  I hope it is not terribly well?attended.

[laughter]

Tammy:  Wow, I was going to say I hope you have a full house.

[laughter]

Bob:  Thank you. Me, too. [laughs] No, I'm sure there are so many folks. We've got 2,300 people at this conference. We're both going to have the right...whoever shows are the right people.

Wendy:  Are the right people.

Tammy:  Exactly.

Bob:  It's open space principle.

Tammy:  Thanks for inviting us.

Bob:  Yeah, no problem.

Wendy:  Thank you very much.

Bob:  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 [email protected].

For more free resources, transcripts of the show, and information about our services, head over to lithespeed.com. Thanks for listening.

[music]

CIO for Enterprise Applications at Nationwide Insurance Michael Carrel covers rolling out agile enterprise-wide at scale, becoming comfortable with failure, and the ins and outs of building a culture of visual management, accountability, and innovation at this financial services giant.

 

Transcript 

Bob Payne: [00:00:21] I'm here with Michael Carrel from Nationwide. So Michael we've worked together years ago. What are you what are you doing now at Nationwide?

 

Michael Carrel: [00:00:31] Thanks. Yeah I'm the CIO for enterprise applications at Nationwide. So what I have a responsibility for is all plan build and run for technology solutions supporting our staff functions within Nationwide's marketing, legal, human resources, investments, finance and actually I.T. itself.

 

Bob Payne: [00:00:48] Wow, so that's that's great. So that that is has expanded since we had worked together.

 

Michael Carrel: [00:00:53] Lots of stuff.

 

Bob Payne: [00:00:55] Yeah absolutely. So what trends are you seeing in the Insurance sector right now. What are the drivers that that are driving innovation, driving your use of agile, driving the business, you know.

 

Michael Carrel: [00:01:11] Yeah. So a couple of things on the short term basis a lot of the trends that we're dealing with aren't different at Nationwide compared to other insurers, specifically you know on our property and casualty side we have lost trends and a rise in the industry due to distracted driving. We have, you know, there's lot of technology in cars these days and so when cars are in accidents our last costs go up as those accidents you know cost more to repair vehicles within our financial services industry. We have a lot of the Department of Labor is creating lots of changes within the financial services industry, especially the products that we sell: new life products. We have annuities and retirement plans.

 

Michael Carrell: [00:01:53] So the deal well into the regulatory environment is changing a lot. And in some cases you can look at that as an obstacle or as an opportunity. And so related to innovation there's certainly an opportunity there, as with the other things that I mentioned in terms of ways to help prevent distracted driving in particular, technology that we could use to help make our make it safe for our customers. Longer term trends are there as well. Especially in terms of in the in the auto insurance industry with autonomous vehicles, there's a lot there will be a lot of change in revenue within our industry over time as you look at driverless cars are driving increased you know, lower claims frequency which is going to drive down revenue within the industry. So, where are we going to look at revenue sources of the future? You know so innovation plays a huge role in not only how do we create competitive advantage out of the short term challenges we have but longer term than Nationwide how do we continue to fulfill additional revenue sources for Nationwide given the you know the contraction of some of our expectations that industry especially the auto industry going forward.

 

Bob Payne: [00:03:03] Yes so certainly those are a lot of the some challenges but also opportunities that are presenting themselves. How do you strike that balance between you know this trend is really challenging our bottom line or this presents a new opportunity because there's only so much time you have to sell new products.

 

Michael Carrel: [00:03:28] That's a great question. And you know what we focus on are really our customer journeys and where we want to differentiate ourselves.

 

[00:03:34] And that really helps us focus on the innovations that are that are important to Nationwide and specifically in areas such as such as strategic partnerships and ventures. Those are types of things that we're looking at to realize that innovation that we have with the Nationwide doesn't have to only just come from you with them. How can we partner with others inside and outside of Nationwide to be able to drive innovation learn from others with strategic partnerships and ventures opportunities. A lot of companies are. Nationwide is also one of them. In fact recently announced 100 billion dollar or 100 million dollar investment in that area. So we're taking it very seriously and to make sure that we deliver a great experience for our customers. And so we prioritize our investments based upon customer experiences that we want to differentiate ourselves within Nationwide and what we can bring to bear for our customers you go through that you know a lot of it too is that the technology capabilities that we have internally and growing from what we have today and then adding and the new capabilities that we're developing to make sure that we can deliver on those those experiences. And we're looking at it heavily all customer research and focus right. Because a lot of times the customer speaks in terms of the value of innovation. So there's a lot of great ideas and so you have to understand though which of those resonate most with our customers. Which of those are kind of on point with our brand and our value proposition to our customers. So making sure that we know what our customers value for for the cost is something that we're always continually looking at.

 

Bob Payne: [00:05:13] Yeah I mean what are the challenges with an organization that is as diverse as yours. How do you get those different lines of business to understand that the customer only knows one Nationwide sort of the apple model right.

 

Michael Carrel: [00:05:27] Yeah.

 

Bob Payne: [00:05:28] It's not just one you know not just this product that they're potentially buying. There are a lot of things

 

Michael Carrel: [00:05:35] Especially in our industry you're buying experience so it's not just you know we're not creating microwaves we're not creating cars right now we're creating promises to help our customers get back on their feet in difficult times.

 

Bob Payne: [00:05:46] Yeah and customer service is an important factor. How does how do lean and agile methods play into delivery of those customer experiences for you guys?

 

Michael Carrel: [00:05:57] Great question. You know a lot of times it's really important that you deliver value to our customers quickly and so agile for us is is key for us. You know DevOps has a lot of a lot of consomme practices around agile that we're adopting but it really is moving with speed and agility in our development lifecycle. But also in our planning as well you know there is a test to learn concepts that we work with a Nationwide to make sure that we explore what that concept could look like, test it with customers we have great user experience team that helps us with research with our customers. We test those concepts in a very iterative fashion and then actually have an agile at scale across nation with combined with dev ops to make sure that we can deliver those capabilities quickly to our customers.

 

[00:06:47] So it's certainly agile it even an issue I started more as more of an I.T. effort that focused on developing software in a better way. And we have rolled out agile enterprise wide at scale putting that earlier in the pipeline of delivery of capability and working with business partners is an area that we're still growing into a habit a lot in our direct to consumer experiences specially in our and the web in mobile space and then growing that beyond that is a priority for us and things like DevOps and deploying those things out across Nationwide are helping delivery teams at the same time agile planning practices is something that we're we're adopting to be able to kind of do more tests and experimentation and drive value to the consumer more quickly.

 

Bob Payne: [00:07:37] Yeah I think it's sort of interesting that agile sort of picks up quite often when you know what you're going to build how you used innovation experimentation to sort of drive that funnel to get because ideation is sort of a divergent process right what are all the possible possible things agile works well as a convergent how do we deliver this thing that we've decided to deliver so How are you using experimentation innovation to feed into that delivery funnel?

 

Michael Carrel: [00:08:12] A great example is this a test and learn concept that we house that we have a team set up that are focused on taking our high value ideas that are based on customer research and data that we've collected on what consumers want and where they may have problems today and then where we defined those customer journeys in points of differentiation as I mentioned earlier with that then a test and learn concept to be able to quickly learn to experiment around ways on delivering on that value proposition for that user experience because it can be delivered in various ways. And so we're just learning through that test and learn concept and then quickly getting that into a build team to get that deployed. Is our model so it's that concept of experimentation with applications even of funding and time and resources around test and learn kind of separate from defined build projects to give you the freedom to not treat to learn experiment without being the confinements of a project with some pre-determined kind of outcome and set of requirements. Because you know the user experiences, customer experiences you learn as you go and you experiment and you test..

 

Bob Payne: [00:09:21] And fundamentally change the direction you're taking.

 

Michael Carrel: [00:09:24] Absolutely yeah.

 

Bob Payne: [00:09:25] Yeah. Yeah. Has it been challenging to sort of inject that level of experimentation in certain areas looking for more of a plan going in than..

 

Michael Carrel: [00:09:38] I think teams that are typically have we've moved agile wide scale the build processes

 

Bob Payne: [00:09:46] And have a very mature process

 

Michael Carrel: [00:09:49] Yeah, And I think the biggest thing is being willing to fail and have ideas fail I think with anything that you're driving innovation you have to be comfortable with with failure and ideas not working and iterating perfecting an idea and so you do sometimes have to get past perspectives around wanting to get it right the first time and get everything perfect before you take a step forward versus intuitively kind of figuring out the kind of what's the best way to deliver on the value that you're looking to create whether that be a product you in the eyes of a consumer or a service experience and really exploring versus using more of a waterfall mindset around requirements and design like getting the perfect design and then implementing it. So getting people comfortable with that learning and and quite frankly some of it. It's how we what we've done to ourselves in terms of how we fund projects so really when you take some of those constraints away and then you eyes open your eyes wide open then and people can see the fact that hey constraints that perhaps drove us towards a certain mindset are now released and it gives you the freedom to work in IT or a fashion to make sure that you can really harness the value with the right the capability to kind of deliver the value that you're looking to deliver.

 

Bob Payne: [00:11:04] Yeah I think sometimes you have to sort of flip the mindset because insurance is essentially risk management. But the thing that I think a lot of people think when they think about experimentation is it's risky but I actually like to flip that around and say your biggest risk is that you're going all in on a single bet like real risk management is about.

 

Michael Carrel: [00:11:32] Yeah

 

Bob Payne: [00:11:33] Iterating ideating validating those ideas with your with your customers is right and you know the people that need to deliver those services.

 

Michael Carrel: [00:11:43] And at Nationwide are right we talk about being "on your side" and "on your side" as a is a commitment that we made to our customers and it's a lot. And it comes with expectations. So for us you know that you know while you were in the business of managing risk there. There also is a large accountability we have for delivering an on your site experience to our customers.

 

Michael Carrel: [00:12:05] That is important to us and that gives you get you know to be a little bit more creative with how do you kind of drive that and learn about what does it mean for a customer to be on your side. And when there are a vast amount of products and services and channels where we provide service it is hard and it's difficult requires experimentation. But I think our commitment to our customers is often gives us enough of that energy to kind of overcome the inertia sometimes of the risk element that is kind of the nature of what we do at Nationwide.

 

Bob Payne: [00:12:42] Yeah. Yeah so that's great because you know you've had a lot of lean agile methods throughout the whole organization. Now it's starting to move into ideation and I know you're also working a lot of dev ops initiatives too. Once you have that idea you can build it iterate on it quickly then how do you how do you get things out to out to those consumers to really close the loop because the million dollar idea is not it has no value if it doesn't actually start to solve customers problems or deliver on that value proposition. How are you guys using DevOps at Nationwide has that been a big initiative.

 

Michael Carrel: [00:13:28] Yeah it's a huge initiative for us. We're starting a very carefully to make sure that we are getting the model right before we have larger scale adoption. Know we have elements of dev ops across all of Nationwide but what we might consider more of like a gold standard of dev ops kind of fully embracing it. You know it's mindset. It's also automation.

 

Michael Carrel: [00:13:55] It's even some tooling that we put in place so we have some some model teams that have demonstrated kind of our recommended kind of full integration into dev ops that we have. We've worked through and now we're working on ruling that out across all our teams and many of them are which will have elements of dev ops both the full package which most importantly is the mindset right. It's not it's not just about the tooling. We have lots of tools lots of automation even amongst those tools to make it to make it easier to be able to you know to manage code migrate code build drive builds and do all that through automation. But it really is a mindset a mindset of teams to continue to even evolve our dev ops and perfect it you know with new learnings that come out of foods team so we're right now in the process of rolling that out more broadly across Nationwide through some model teams that have kind of perfected our model.

 

Bob Payne: [00:14:56] Yeah. And then ultimately how do you the loop with measuring customer behavior those ideas that you had that you narrowed down you built them. Now automated you push the deploy out. But getting that full loop measurement to really really achieve business agility and to your goal of DevOps.

 

Michael Carrel: [00:15:18] Yeah. And to your point we actually have a lean vision management system that's in place across all of I.T. and Nationwide starting out with local teams all the way up to the A level so I have my visual management system and so tracking key metrics of value there. So how long is it take from a requirement to get to production.

 

Michael Carrel: [00:15:38] You know how long you know how much of a backlog there are key metrics around velocity and speed that is in our visual management systems that we are you know we track and we are expecting certain lift from as we continue to get even more mature and dev ops as we roll out kind of our model structure across all of our lines and Nationwide development lines. So that's that's something we're very keen on is measuring the Emperor fighting. So where we have it's a learning opportunity to use metrics as you see pockets of matter X that in certain areas where ... in favor ability perhaps even over a norm let's learn from that we are what are they doing so we can continue to kind of learn from each other across the organization. But metrics on speed and agility are working in own management system. So we're also being held accountable for the value that we're looking to create. And quite frankly understanding where we're not meeting those velocity targets those speed targets of a driving value directly out you know getting into production as quickly as we can through through new lean practices and DevOps.

 

Bob Payne: [00:16:46] Yeah and you know I'm particularly passionate about visual systems so I'm always very very encouraged when I when I came out to visit to see the implementation you guys have. The thing that I think is most interesting and probably most important about the visual management systems that are some examples that I've seen is you have them at all layers.

 

Bob Payne: [00:17:12] And there are linkages and if something is measured the people that are supposed to change their behavior or maybe not change their behavior but whose work is being driven by those metrics are responsible for the metrics and that that is an area where I think lean organizations and I consider you as one I think are much better than most organizations. Just look at agile as just a delivery model or visual management. That's just for the team. You really have created an umbrella that spans the whole organization.

 

Michael Carrel: [00:17:57] It's really a mindset that has from all the way from the top down into our local teams and my own visual measurement system as a CIO is visible so people can come in and see my accountability section on my board. Our planning initiatives are our key project to build build metrics and that all of our metrics that through sequenced review cross all the dimensions of our key performance indicators are all in plain sight. People can associates can see those and see what we're talking about as a CEO candidate. So it's not. There's also that transparency their risk associates it's not just what they're they're not just working with the leaders or management system but my team is as well conducting other stand ups. Yeah how often do you do your standup. So we do our standups weekly with within our team and then we do an extra section even once a month on some deep diving into metrics that whose update frequency or more monthly versus versus weekly type checks that we do but we go through quick run checks our build projects our planning initiatives every week and then our accountability sections always looking at Voice of Customer problems sections. You know there are problems that we need to be doing a 3s on across our organization.

 

Michael Carrel: [00:19:13] And then also kind of keeping track of our releases coming up and the capability maturity within our teams as well.

 

Bob Payne: [00:19:20] Great. Yeah that's exciting. I know that you quite often do. You're doing a more formal A3 Lean continuous improvement process. Has that really are you getting a lot of things bubbling up from teams in the way that say a Toyota would have a continuous improvement bubbling up from the folks doing the work or is it that innovation.

 

Michael Carrel: [00:19:51] Theories are happening at all levels. No we don't. I wouldn't say I have a lot of escalated to me where they are blockers. You know we try to empower local seems to be able to drive improvement in their areas but items do that are more you know a systemic type things they do get bubbled up actually through the official management system so through blockers that we have and I actually do Gemba walks of the lean management systems of my direct reports and they do it levels down as well and and sometimes actually to be quite frank I will have a team that will want me to attend one of their gambles to be able to learn about a block or something where they might need my help as a CIO even if it's one of our delivery lines. I've done that on occasion. One of them team going through some agile transformation and really wanted me to kind of see some something that they were working on to be able to help drive that forward. So also a ton of gemba of a line to be able to also have firsthand experience with what they're dealing with perhaps an innovation that they need some support for.

 

Michael Carrel: [00:20:57] Or it could be a process change or a blocker that they need my help with.

 

Bob Payne: [00:21:02] And that establishes a lot of trust throughout the organization to really have that level of transparency. What's what do you see coming down the road that's exciting for you for the next five years? I know that's an awfully long ways to look out.

 

Michael Carrel: [00:21:17] I think with a lot of organizations you know we're focusing on legacy platform modernization so you know Nationwide we'll be celebrating 100 years as a as a company coming up here soon and so we are we have several transformation initiatives going on to really modernize some of our core platforms across our business so there are nimble going into into the future. And so that's a key focus for us. Clearly data analytics expressed in our business. We have done a lot of work there continue to do more extending that into even greater cognitive solutions with AI. So we're definite have a definite focus there is so much opportunity in that space and building that into the fabric of our solutions our mindsets is going to be important as we move forward as well as well as us continue to digitize organization. Their key priority for us. And then you with with all the innovation that we talked about before you know I think I'm excited about you know the businesses that Nationwide will will be in even 10 years from now.

 

[00:22:25] You know we've been a company who's innovated especially in areas of financial services kind of being a traditional PNC Insure and innovation that got us kind of really defining you know the annuity market a leader you know a company wide or country wide leaders and Pat and in 457 retirement plans we have a company who is a fabric of innovation has spurred new products new businesses for Nationwide. I'm very excited about new products and new businesses that we're not in today that we will be in you know 10 years from now as we continue to kind of focus on our core purpose of protecting what matters most to to our consumers and also helping people prepare for and live in retirement so excited about what that future is going to hold and things like our enterprise hackathons, local hackathons we do within our organization and then Chief Innovation Officer within Nationwide and all the partnerships that will kind of continue to grow to kind of continue to fuel the innovative spirit at Nationwide is exciting. I'm happy to be a part of it and I think you know I think we're really kind of getting the business in general and are going through this huge cycle I think many businesses are or the next 10 years of being another kind of transfer kind of transformation in terms of the technologies today AI cognitive type solutions and businesses I think are going. All this is going very different Ten years from now I think we're going through this next kind of revolution of with that technology is enabling. So I'm excited to figure out new ways of leveraging your technology new processes concepts to be able to drive that value for our customers.

 

Bob Payne: [00:24:02] Excellent I hope I'm as vital at 100 as Nationwide is. And I thank you so much for doing the talk.

 

Michael Carrell: [00:24:08] Thank you.

 

Agile at scale can get you to code very quickly, but then sometimes everything comes to a screeching halt.  The biggest bottlenecks are often found after teams are done with the code.  Dan James of Icon Agility Services joined Bob Payne on the Agile Toolkit Podcast to discuss Dan?s session at Lean+Agile DC 2018: Building a Lean Enterprise with DevOps.  Dan and Bob explore ?shifting left,? creating a pipeline of smooth handoffs, and decoupling release from deployment.

 

TRANSCRIPT

 

Bob Payne: [00:00:01] Hi, I'm your host Bob Payne I'm here at Lean+Agile D.C. 2018 and I'm here with Dan James from Icon Agility or is that Icon Agility Services. 

Dan James: [00:00:13] It's the whole name.

Bob Payne:  [00:00:14] It's the whole name? Okay great. And your talk is on DevOps Transformation, scaling and and other things.

Dan James: [00:00:24] Yeah, Extending the Lean Enterprise with DevOps. 

Bob Payne: [00:00:27] Uh huh.What does that mean when you say that, Lean Enterprise? 

Dan James: [00:00:31] Well we know that agile at scale can get you to code very quickly and it comes to a screeching halt because we have a wall of confusion - agile wants us to go fast. Business wants us to go fast. But the systems team wants stability right and reliability and security. And so you know our code comes to a screeching halt and may go into a black hole for weeks and months before it is finally releasable. And so what what we help enterprises do is work out the strategy and the tactics before we even talk about tools we get into the tactics and the strategy of creating a pipeline that smoothes out and leans out the handoffs yet to in order to get something delivered. And so we do a deep dive with our clients we go in and do a full technical assessment of of how they're delivering value now. And we show them that their biggest bottlenecks are usually after the agile teams are done with the code and and help them get releasable a lot sooner.

Dan James: [00:01:35] And we give them strategies to protect their their product as they're developing it by having you know green blue strategies you know delivery you know being able to separate or decouple release from deployment so we can go to production every day. Right. But it may not be releasable until the business decides we have accumulated enough real value share and then that becomes a business decision. So by separating it also gives us more time to smoke test and do canary releases and other things to ensure that what we have put out there is is sound before we release it to the public.

Bob Payne: [00:02:15] Yeah. So..feature Toggles those sorts of... 

Dan James: [00:02:17] Exactly. And then we also teach the discipline of shifting left in the pipeline back to the teams. The responsibility for initial quality.

Bob Payne: [00:02:26] Right. 

[00:02:27] So we don't want to them to just throw their code over a wall and expect a testing team that had no input on the context of what they're building right to think of all the possible edge cases to test this stuff. And so so we instill in our assessment we uncover all the the practices that need to be fixed before we automate anything and making sure that initial quality I mean if if if you think you can deploy quickly but you're not unit testing your code then we have a big problem.

Bob Payne: [00:02:58] Yep.

Dan James: [00:02:58] You know the way that agile and scaled agile goes fast is by focusing on the quality.

Bob Payne: [00:03:04] Yeah.

Dan James: [00:03:04] And then we all go fast, And so that's that's the biggest thing.

Bob Payne: [00:03:08] Okay. For me I actually I actually believe the. So if you can't get stuff out it doesn't matter what your strategy is. I believe a lot of that the last mile work will allow us to shift lefter because ultimately I think one of the big problems that most organizations face in any sort of real agility they can get the wrong thing out faster but real business agility would use to use that for learning and it would have huge fundamental impacts on intake funding. You know lots lots of things that at least in the skilled agile framework they talk about but I don't see many organizations actually pulling the trigger on that. There are certainly some in those sort of leading leading organizations will be the the sort of models that that people look at for a little while until it becomes more common.

Dan James: [00:04:14] Right.

Bob Payne: [00:04:16] A lot of people fail to understand the organizational possibility and the organizational impact of DevOps if done right.

Dan James: [00:04:26] Yeah and very often we go into an enterprise and we have to start with the real basics the fundamentals because they want to jump in to Agile because they've heard about it and it's you know their competitors are already doing it. And so they're at a tipping point. But they don't even understand Lean. That's where agile came from. And until they understand Lean and the waste that occurs in all the handoffs between each step in our in our operational value stream they don't they don't understand you know that agile alone isn't going to get you it only gets half of I.T. fixed. But DevOps is the other half of I.T. and. And we're going to show that in our in our speaking slot today we're going to actually show here's the here's the the elemental chart of I.T. in general here all the departments that make a typical enterprise I.T. work only half of it is addressed by agile at scale.

Dan James: [00:05:21] So even a scale that only addresses half maybe 53 percent. Right.

Bob Payne: [00:05:25] Right.

Dan James: [00:05:25] It's the other half that we're trying to get which gets us time to market fixed it gets our products out the door gets the feedback from the customer that we are desperate to get. And it helps us learn and the whole principle of lean is is out learn your competition and then improve them. Share with you with what you learned. And if you can't do that then you know we have to go all the way back to fundamentals. And so sometimes in our transformation engagements we have to we have to go back to the Stone Age of a year 75 years ago and talk about lean to get them to understand. You know it it still applies today and we can't just say OK all our teams are gonna be scrum or all our teams are going to be Kanbun and expect it to solve all their problems and yet it only addresses half of the problems. You know what helps us get to code quick but it doesn't do anything else. No it doesn't. It doesn't get the code out of the black hole you know before it gets released so. So we're here to do that. We go into companies we do a deep dive a discovery an assessment of their of their DevOps side many of which are many of these companies are already doing agile at scale and doing it well but they're still frustrated because nothing's going out the door. And so we we helped uncover what most.

Bob Payne: [00:06:43] I might Argue that they're not doing well if they're.. if it's not Going out the door.

Dan James: [00:06:48] That that's true. And you know and you know Nirvana here is that the teams themselves have the power to release what they deliver or what they create.

Bob Payne: [00:06:56] Sure. Or to have an efficient way for that to that too certainly you know that may be an ideal to aspire to.

Dan James: [00:07:06] Sure. The Amazons of the world can do that.

Bob Payne: [00:07:08] Right. Well we are actually was just talking with Jeff Payne a little while ago which for us for the podcast listeners doesn't make much of a difference. It's on a different episode. But you know I think the potential for getting something out and getting it out. And you clearly articulated that those can be decoupled.

Dan James: [00:07:34] Yes. And and I think there's a lot people are they are way too quick to say ooh that's the next silver bullet teams team managed deployment. And for some organizations it is the perfect solution right. Lean Thinking looks at the entire ecosystem and is and tries to say what is the best solution for this organization. This team at this time with this technology and in so icy team managed deployment as a particular practice that may or may not be optimal in a given situation. So few people are looking in a lean way. They're looking at other people's recipes and that's especially in size fits all right. I think this probably solves a ton of problems that we have with you know safety and risk profiles and and regulatory regulatory.

Bob Payne: [00:08:42] Yeah but you know looking at it as the next silver bullet I know I'm always caution even though I to work with organizations help transfer them towards this goal but only in the in in so far as we set a target we move along and steer and bright you know.

Dan James: [00:09:01] And I don't know if it's luck or curse that in the last three or four years most of my clients have been in the financial services industry which is highly regulated right. So so I banks and lenders and investment companies and so forth that that are under such regulatory burdens before they can really say anything to the public. And they're under audit the threat of audit constantly and they're scared of the audits that they use that as a wedge issue to prevent agility to prevent improving and and reducing the handoffs between the steps and getting value.

Bob Payne: [00:09:38] Even though you have much more closely auditable compliance.

Dan James: [00:09:41] Transparency, all that. Yes exactly.

Bob Payne: [00:09:45] You know, What I want the the developer to need root password to production to debug a production issue.

Dan James: [00:09:58] Right.

Bob Payne: [00:10:00] I think I would like the new way is a lot safer and more auditable and you know immutable immutable infrastructure networks are certainly those things provide a higher degree of safety audit ability than we've ever had before.

Dan James: [00:10:19] That's right.

Bob Payne: [00:10:20] The problem is we need to ensure that teams are actually quite often that that the technique of audit and the things that you need audit need to change compliance are actually more compliance to the the spirit of those regulations than might have been when you had a big stack of documentation right which was only looked at when you need to practice for the auditor.

Dan James: [00:10:47] Yes. Yeah and we didn't exactly exactly .. Static documents are obsolete that the day they're published.

Bob Payne: [00:10:54] Right.

Dan James: [00:10:55] Yeah. So we found many of our clients have they're so afraid of of the regulatory side.

Bob Payne: [00:11:01] Yep.

Dan James: [00:11:01] That that they're just reluctant to release some of them might release once a year once or twice a year at the most. And they go through this long hardening period where they're there waiting until the code was already written months ago before they even do a threat modeling penetration test against it. You know. 

Bob Payne: [00:11:20] Thanks for making me snort. You know this hardening thing you know is there some sort of quantum stabilization of the bits in the silicone that I don't understand.

Dan James: [00:11:33] And they don't either probably.

Bob Payne: [00:11:34] Yeah I always think it's just the bureaucratic way of leaving time for people to raise their hand and say we shouldn't go.

Dan James: [00:11:41] Yeah and it comes down to fear. Right. You know that fear of release because they've been burned once or twice in the past when their technology wasn't as good as it is today. And they get burned and now they're they're reluctant to release until they are just 100 percent of you know feeling secure. And so we show them methods of ensuring that the quality is there the threat modeling is already embedded that you know long before it gets even staging.

Bob Payne: [00:12:05] Right. And so with the proper strategy you can ensure your quality in smaller pieces and get it to staging or in production but not to release until you have enough business value that you can trust that what's in production is clean and meets the security requirements meets compliance meets all those things. We're just going to have to work in a more agile way to cut things up into smaller chunks

Dan James: [00:12:28] Make sure it's tested upfront and early and often through the pipeline both both on the development machines and in the Coupée environments and in system integration environments.

Bob Payne: [00:12:39] Yep.

Dan James: [00:12:39] And that's what it ensures multiple chances to smoke test this stuff and and make sure it is ready for release and we can be confident in. And then after they've seen a few frequent releases you know then their confidence builds as a as an organization. And the fear diminishes and they realize okay lean and agile and a scaled agile with with not necessarily the brand name Scaled Agile but agile at scale and DevOps is working. And then they they start feeling better. The auditors in many cases you sit down with the auditors face to face they're going to audit on what you say you're going to do great. So it's good to show them that you're going to do a new thing you have to sit down and talk to them and you know work. We're going to do this a new way to please audit us on the new way not on the old way and the transformation becomes less fearful. 

Bob Payne: [00:13:34] Right. It Can,. 

Dan James: [00:13:35] It can. 

Bob Payne: [00:13:35] Depending on your auditor. 

Dan James: [00:13:36] Exactly so. So we're in the business of helping that transformation and it's a lot that a lot of the transformation is a mindset. It's not so much the practices and the philosophy and the principles and all that even though we do we do preach that. It's just it's more of a mindset. And so we focus on the vertical structure above the teams to make sure they're on board and they understand how to support this. 

Dan James: [00:14:01] Yeah because a lot of agile failures come from the lack of support from above the teams you know so they the teams are constantly being injected in an artificial deadlines imposed and all the stuff that that kind of ruins Agile you know it ruins Scrum. You know okay, we're right mid Sprint we're going to be changing things. Well, The teams are frustrated and their productivity goes down because we haven't properly trained management and that's what scaling it helps us do it provides the training and the understanding above the teams. 

Bob Payne: [00:14:29] Yep yeah at LitheSpeed we are focused a lot on leadership and transformational leadership as well. So most of our transformations start with with that sort of sponsorship but we've also started to try to create a path because management and leadership we're not as well represented in early agile thinking mistakenly. I mean Sanjiv wrote the managing agile projects in 2005 and you know we started the agile leadership academy and then follow on. You know we created that. Now we're starting to see things like Certified Agile leadeR and other programs for organizational leadership to really understand this which lean always had nice and is odd that that agile has taken as long to yes the teams and the ecosystem that the teams live in. 

Bob Payne: [00:15:34] That's right. And speaking of LitheSpeed we're going to be there tomorrow and Friday my cohort from Icon Brian Aho and I are going to be at LitheSpeed. 

Bob Payne: [00:15:42] Doing the DevOps.

Dan James: [00:15:42] And and training the SAFe version, the Scaled Agile version, of the DevOps course, which they accumulated from Icon. Mark Ricks for the last two years has been developing this and he and I and Brian have been teaching this now for the last nine months. But now we get to teach the SAFe version of it.

Dan James: [00:16:01] It's now fully integrated into the Scaled Agile Framework they've added a few things to make it integrate a whole continuous exploration. So we turn DevOps into a scientific experiment.

Bob Payne: [00:16:10] right.

Dan James: [00:16:11] And small experiments just like Toyota did 75 years. 

Bob Payne: [00:16:15] back to the future, i'm charging my flux capacitor even as we speak. 

Dan James: [00:16:19] Exactly 

Bob Payne: [00:16:21] Well thank you very much Dan great great having you here.

Dan James: [00:16:24] My pleasure.

Bob Payne: [00:16:25] Glad you're able to speak at the conference and come to Agile DC as well if you're interested. That's the large local cross vendor conference.

Dan James: [00:16:37] And that's in October right? 

Bob Payne: [00:16:39] Yeah it is yeah. I'm the chair.

Dan James: [00:16:41] Yeah and I'll be out here for the Scaled Agile Summit as well, the global summit in October so.

Bob Payne: [00:16:45] Great. Well we'll see you at both those events and thanks. 

Dan James: [00:16:48] awesome. Thanks Bob.

Bob Payne: [00:16:49] You're welcome.

 

After coding live at Lean+Agile DC 2018, Ben Scott of Ippon Technologies joins Bob Payne to talk code craftsmanship and getting proper feedback from the business side.  Ben explains a way to quickly build a quality demo from scratch ? creating the first demonstrable piece of value.  Bob and Scott walk through their opinions on (shudder) best practices, living in ambiguity in agile methods, and bridging the gap between IT and business.

Bob Payne: [00:00:03] Hi I'm your host Bob Payne. I'm here at Lean+Agile D.C.. I'm here with Ben Scott and we're listening to "Stand in the Place Where You are" by RBM played on the music fiddle version which is really disconcerting for me. It's like Fugazi. You know elevator music which is definitely elevator music. But country elevator music. So Ben we were talking earlier about lots and lots of things but you were talking about sort of your experience here trying to do live coding and talk. What was your what was the gist of your talk? What were you talking about with.

Ben Scott: [00:00:56] So, let's start with the problem statement: Whenever you start a project from scratch mainly it's really hard to get good business demos and keep the business interactive with getting proper feedback. You'll see a lot of demos with terminals. Hey let's see what my code can do and you have to look at log statements or use post postman to demonstrate APIs. And then the business kind of glazes over it. And I think a lot of issues stem from developers trying to recreate everything internally. Someone has to provide a demo that even started a presentation with zero code I could provide a business level demo with a front end application backend with database usage deployed to the cloud. All within the same presentation within 45 minutes. So that was kind of the gist, some people really liked the felt it really demonstrated well what could be done now. They're probably unsure how to adopt down to their own organization but it's mostly a show that it is able to do that and you don't have to buy it. It's FREE. 

Ben Scott: [00:02:14] It's opensource a tool that I use is called J Hipster and I think overall great. 

Bob Payne: [00:02:23] Yeah I mean for those of us who've been familiar with play or Rails or any of the generative frameworks you know that it was not should not have been surprising but I realized how how painful it is for most organizations to get to that first demonstrable piece of value. 

Ben Scott: [00:02:50] Yes. 

Bob Payne: [00:02:51] It is a little a little insane. 

Ben Scott: [00:02:53] It is. The key differences are with J hipster is it really tries to adopt the enterprise level technology.

Bob Payne: [00:03:00] You see the full stack you've got full size containerized deployments. 

Ben Scott: [00:03:05] You can you don't have to but it sure does generate Docker containers. I use the docker file to let you generate a Docker container from your code. It will generate your CD pipeline script. It supports multiple privacy circles C.I. Jenkins obviously and a few other really really kind of handhold you through the whole process of getting a code from scratch all the way to diploid and ready. It can't do anything about your business level code that's on you right. But all the bootstrapping and plumbing it generates according to best practices of the time with us. 

Bob Payne: [00:03:45] I winced on the inside. I don't like the phrase best practices but best that I'm okay with.

Ben Scott: [00:03:54] Yes well it's always a big debate. What is best practice. Like for depending on where you are which technology you're using and your opinion because it's a hotly debated topic Your Domain Driven Design or you don't. Some people really love it some people hate it. Yeah that type of thing. 

Bob Payne: [00:04:12] Yeah I try to stay away because people always ask us for as consultants are always asking for the answer and there really only is know fee here given your situation. Here are a few options that we've seen people be successful. Yes you know and you know I always sort of try to steer people away from that. Like calling people resources. There's a few you like hot button words that I can't make can move resources around us our projects exactly rituals and scroll to find that I hate things that that pull it out of the somewhat grey world that we actually live in. 

Ben Scott: [00:05:05] Yes I actually like to prefer I prefer to live in this ambiguity. I don't like to define what scrum is definitely. I don't like too dear to a Agile philosophy per se or implementation whenever somebody dresses. Hey what is ads out to you. To me it's you delivered a piece of software that was correct at the right time and how you got there might differ based on the people working in your company. Yes we might use Scrum or not. It depends if it's a good fit with that place and sometimes it's now or sometimes they just decide as long as we do what scrum says we are agile and we just get away from what they really mean. 

Bob Payne: [00:05:50] Yeah. Defer to authority. There is a good strategy. 

Ben Scott: [00:05:55] So I don't like to prescribe things. 

Bob Payne:[00:05:57] Yeah. 

Ben Scott: [00:05:58] When we hire Scrum Masters always ask me what's your process. What tool to use. You know you use Jira. I don't prescribe - you use what you like to use right. 

Ben Scott: [00:06:07] Well your client will let you use yes whatever you is best for your situation which will change. 

Bob Payne: [00:06:15] So how do you so I know you've been doing a lot of technical coaching coaching. What do you what do you find most rewarding. Because sometimes it's it's you know it's it's a tough slog sometimes and there are always those little nuggets that just say yeah you know that will keep me going for a few months banging my head against this team or this wall or whatever.

Ben Scott: [00:06:43] So I really enjoy bringing upskilling developers on where they lack and I'm not a awesome developer. I'm a very niche developer who understand the agile practices so I can do their job testing frameworks Cucumber, or perform sensing as a Gatling I know how to do them and the basic forms right and the tools to know how to use them. Eventually it clicks at first like I don't want it. It is what QA is for but eventually it clicks and it's really fun to see a click. Likewise I work a lot with the business side on bridging the gap between developers and the business we actually start working together instead of the whole campus. This is the business that we need to take to go on like what we need is. Of course we do to this refactoring. We need to adopt this technology or just trying to bring them together so they actually work as a team and we'll stack clicks which is much harder than it was going developers.

Bob Payne: [00:07:40] Yeah.

Ben Scott: [00:07:41] That's that's really fun. 

Bob Payne: [00:07:42] Yeah that is. Yeah. We like speed we have that sort of mission of making people's lives more valued fulfilling and productive. It's kind of our or our mission if we can do that on an individual basis or you know we health and organization so that it helps the folks. But it all fundamentally comes down to you know people people in interactions and you know hopefully making a you know a decent world for them to sort of grind away at the code code is an unforgiving. 

Ben Scott: [00:08:21] Yes we'll spend days looking for that tiny little mistake. 

Bob Payne: [00:08:27] Yeah yeah. So what's the other big dogmatic thing you're railing against. I don't know that you're actually railing against any big dogmatic things but you seem like the sort of person that might.

Ben Scott: [00:08:41] There are some things I'm very strict on and it's is code craftsmanship to the detriment of sometimes I'm actually delivering value and I understand that. But there are times to be fast and dirty. You have a production bug. 

Bob Payne: [00:08:55] Yep.

Ben Scott: [00:08:56] There's a feature that needs to go to the market right away. OK we can do that fast and dirty. But if that's every time there's a problem. 

Bob Payne: [00:09:06] Right. 

Ben Scott: [00:09:06] And at that point I don't have any issues slowing everything down and I guess focus on craftsmanship. Let's focus on actually teaching what solid principles mean because over time you're going into being faster more maintainable code. The sustainable pace and that takes time to learn. It might take six months a year to really get there. It's a huge investment and it's the responsibility of the entire organization to to foster that. So just like we have the Center for agile excellence or you go to an agile coach organization talk about processes. 

Ben Scott: [00:09:39] You should have a software craftsmanship as well a new way to mentor the developers. And that practice that's probably where I'm the most strict on. 

Bob Payne: [00:09:51] OK yeah no that's ... Yeah. That's a good place to be strict I think. I often think of the three things that can make a great team. It's discipline, continuous improvement, and play the long game you know not the short term gain necessarily but product delivery is is not project right now.

Ben Scott: [00:10:16] And I completely understand there's times we have to go really fast for whatever reason it is. Maybe there's a bug that's costing thousands of dollars. When it's in production. 

Bob Payne: [00:10:23] Yeah.

Ben Scott: [00:10:24] And yes. Quick and dirty fix but then think about it and fix it again the right way.

Bob Payne: [00:10:30] Yeah. Well everybody. It's interesting because that the current understanding where the current sort of popular understanding of technical debt is that it is a bad thing and you know when they first started talking about it Ward Cunningham and and you know some of the folks on the first XP team actually used it in more the financial term debt. Sometimes you do take down. You know you go fast to be quick and you might incur some debt. You got to pay it down. Always cost a little bit more to pay it down. But sometimes that's the right decision. But when you're paying off the credit card with another credit card you're in drips. 

Ben Scott: [00:11:20] That compounds quickly.

Bob Payne: [00:11:21] Then You need to re platform the whole thing.

Ben Scott: [00:11:26] And then it just never ends. 

Bob Payne: [00:11:27] Yeah.

Bob Payne: [00:11:28] And that's what the craftsmanship comes in play because if you instill those values when you build a new software and maybe you'll be a little bit better and last longer. 

Bob Payne: [00:11:36] Yeah. So is IPPON primarily you know do you or most of the folks steeped in XP stream programming and. 

Ben Scott: [00:11:47] So I would say most of us are what I would consider like Premier consultants as far as developers. Most of us are developers. So in that sense we're a bit different from most agile consulting companies. We focus a lot on the engineering aspect of agile versus the process and most of our developers don't always subscribe to Agile values. They like to get their stuff done and they're like good code and beautiful aspects that don't always adhere to delivering to agile way which is fine. But you couple that wish people would truly understand agile and you've just multiplied yet the actual value of it. It's like the cross-functional needed agile deep expertise to guide the ship but you still need a technical deep expertise on what good coding practices look like. Yeah and we also like to embed with our clients. We don't always like to take the whole project and then deliver at the end. We like to develop right and while we could develop we'll pair with them or we'll teach developed practices how to test and how to automate the whole thing and the whole the whole package. I think that's where our values will be different than other places.

Bob Payne: [00:13:07] Yes. And we've you know at LitheSpeed we've been happy to be able to partner with the guys periodically because we focus primarily on the people in the process and you guys can focus on the technical chops. 

Ben Scott: [00:13:25] Yes.

Bob Payne: [00:13:25] Yeah. I'm primarily a PowerPoint engineer and there is no PPT unit. 

Ben Scott: [00:13:34] No I'm really bad at PowerPoint. 

Bob Payne: [00:13:39] I wouldn't say I'm good. But the reason I'm not very good is because there's no there's no unit test framework to how to get good. I was talking to somebody earlier because I I was when I was developing you know I got immediately test infected like TTD like real TDD not the ATDD or BDD. Not that those things are bad but that thinking and design process of TDD was an amazing force multiplier for me as not a terribly great developer. It allowed me to focus know where I was know that I hadn't broken something else because I couldn't keep every esoteric detail from the entire system.

Ben Scott: [00:14:38] Yes. 

Bob Payne: [00:14:39] In my head some people love that they loved the challenge of I've got every single detail in my head. But that doesn't scale. It does and test. 

Ben Scott: [00:14:52] It's a good thing you brought TDD like I have my own opinions about it. And you're right. Some people love us some people hate it. And to me there's a lot of focus from the process scores to do TDD when developers aren't ready for it.

Bob Payne: [00:15:06] Yeah yeah yeah. 

Ben Scott: [00:15:07] Just like everything will be fine if you just do TDD. 

Bob Payne: [00:15:11] Yeah I don't believe that to be true. Everything will be fine if you have engineers that are that are that really you know there I sort of look at the code and you can see the thought process of the developer in the code and that is much easier for me to read to read tested code than it is to to create an elegant you know you start throwing in some Lambda's there and we're we're we're parked. I mean because I struck part of my psychosis if you will. And I think it's reasonable to call it that around TDD as I started in Lisp and I don't know if you've ever tried to debug lisp or scala. It's probably easier now and in scala but there's just the interpreter. Back when I was doing this so you had a command line and you read in a file and something pops out and it is the most amazing black box in the world because it's just it's interpreted. It's a functional language and 42 is the answer, right? I forgot the question we asked in end. So unless you knew that those little pieces worked. Yes pull that out throw it into an interpreter and see if it give it some some values in and see if it makes sense because all it takes is a misplaced pen. It could be anywhere and it will usually evolve out to something that still works. 

Ben Scott: [00:17:04] And I guess where I differ what it is like or I'm strict on tests in the same commit as the code. 

Bob Payne: [00:17:11] Yeah. 

Ben Scott: [00:17:12] I don't prescribe to. You must write a test first.

Bob Payne: [00:17:15] Sure. 

Ben Scott: [00:17:16] But it must be in the same commit. Yeah that's that's kind of where I differ. And some people are really good at writing tests first. Some are not.

Bob Payne: [00:17:24] Yeah.

Ben Scott: [00:17:24] But everybody should be able to write before or after, there's not. Never does ..That's Not allowed.

Bob Payne: [00:17:31] Yeah I think it's a reasonable place to be strict. I think for me just I.

Bob Payne: [00:17:39] I loved Arlo Belshee. I think it was our Arlo Belshee that coined the term test infected because some people either are or are not. And it's like you know that zombie strain virus. And I don't know which side is the zombie in which is the not here but I think the TTD folks are probably the zombies. But if you were when you find yourself on one side of that divide I think that the folks that actually like TTD and I know it is not universal. It's it's one of the more powerful and least used agile engineering practices. 

Ben Scott: [00:18:15] Yes.

Bob Payne: [00:18:16] I mean Pairing, people say they pair, but nobody pairs. I mean not like.

Ben Scott: [00:18:21] Well not like extreme program where you must pair. Right. We like to pair for occasions like right. Here's a difficult piece of code. Let's work on it together or for mentoring. We'll pair for code reviews the type of thing we'll do some pairing for writing prose not so much right. How hard is it to write Pojos. You know it's so many people go down this rabbit hole to we test the setters and getters like I don't care. Like ok. Probably not. I'm OK. But really how long would it take you to actually do it if you said if everybody said we need to. 

Ben Scott: [00:19:09] So. So interesting thing. So the debate by just writing a piece of code using reflection finds a perjures sets the value gets the value a certain done. So all my pages are tested automatically.

Bob Payne: [00:19:25] Yeah. and now with generative frameworks it is it is relatively easy. I was cured of that debate because I'm not a great programmer. When I misformatted the way I created a Java date. And so when I made and I always know how to make your assertion not against the same constructor that you used. So I use distracted at this other date class add some other stuff in and misuse the constructor and when I assert it against the string format it value, i'm like "Well that's not right." And I don't know that I would have found that regular regular test or I would have I would have found like f'd up dates in the database or in the persistence layer or in the front end and I'm like I might not know. Then I've got a whole different problem but because I knew it I found out early that it didn't work like the debugging. For me it was just so much so much easier.

Ben Scott: [00:20:36] And eventually you have to use common sense. You look at your POJO like well maybe I don't need to test every single one of them. But if you're serializing a date you should test that because for whatever reason it's so strict that the date format it will kill you application is different for might just use a whole AI behind it to be able to extract data and decide what date it is. 

Bob Payne: [00:21:00] You guys likes you know you guys like screw up the order of the month and the day like what is this?

Ben Scott: [00:21:05] It has Slashes no slashes.

Bob Payne: [00:21:07] Dashes no dashes, dots.. 

Ben Scott: [00:21:10] Or you add milliseconds and you expect no milliseconds and it still won't truncate it'll just die right there.

Bob Payne: [00:21:17] Yeah.

Ben Scott: [00:21:17] So testing that. That's a good test. Typically also have a serialization test if it's data layer i'll serialize or deserialize back to the object, validate, but I might not validate. 

Bob Payne: [00:21:30] You know that was that it was more important when he had to write her own serializer.

Ben Scott: [00:21:37] Well I don't write my own serializer but I do write my own test for the annotations like for date format for example did you do the right format right. Does the precision matter or those type of things you have and I'm working on a project right now that for whatever reason the order matters. The order should not matter but whoever was sending it to they got that code where the order of your serialization matters and they can't just construct the object they actually validate it in its raw format first. 

Bob Payne: [00:22:05] Okay.

Ben Scott: [00:22:06] So then we have to validate that we send in the right Json format but in the right order each field. It shouldn't matter. At least in my opinion it should not matter. 

Bob Payne: [00:22:15] No. But yeah well unless you want strong coupling in implementations which I'm shocked at how many are organizations really like strong coupling.

Ben Scott: [00:22:33] I'm not sure they like it or just live with it.

Bob Payne: [00:22:36] Yeah it's Like oh my god. It's like it's like the old Korbo or SOAP. Oh man.

Ben Scott: [00:22:42] This is how we've always done it so we will continue.

Bob Payne: [00:22:44] Yeah. Yep. So what else would do you. What's interesting to you in what hobbies do you have besides like?

Ben Scott: [00:22:56] Kids.. Does that count as Hobbies?

Bob Payne: [00:22:58] Yeah.

Ben Scott: [00:22:59] It takes a lot of my time - it's fun time, it's really interesting and enjoyable to watch and grow. But I did find my most of my hobbies dropped away little by little.

Bob Payne: [00:23:10] Yeah.

Ben Scott: [00:23:13] When I did become a parent.

Bob Payne: [00:23:16] I picked up new hobbies like I had never watched soccer before because I didn't like sports because those were the people that beat up the geeks. And now I'm doing like Magic the Gathering which I avoided in college like the plague.

Ben Scott: [00:23:43] I never got into that.

Bob Payne: [00:23:43] Because I was more of a punk than a D&D. There's a reasonable Venn diagram there. But but. Now I'm going to Friday Night Magic with my son.

Ben Scott: [00:23:55] So that's a very fun but very expensive game.

Bob Payne: [00:23:59] It is. Like you know a lot of people like do sports gambling. I think that's even worse. You know.

Ben Scott: [00:24:06] Yes.

Bob Payne: [00:24:07] Liaisons in a Russian hotel. Let it get very expensive very quickly depending on what you're doing.

Ben Scott: [00:24:17] And I also do gaming video games typically do single player story type games.

Bob Payne: [00:24:23] Oh really? given your military background. You've had enough First Person Shooter..

Ben Scott: [00:24:31] We'll it's more that to play online takes dedicated time whereas a single player. I can stop anytime. Pause and walk away.

Bob Payne: [00:24:39] Yeah.

Ben Scott: [00:24:40] I find that sometimes as a parent it's really hard to get an hour dedicated time.

Bob Payne: [00:24:43] Oh yeah yeah.

Ben Scott: [00:24:44] straight to play, it's like no I cannot help you to do anything because I'm in my game. If I'm doing single player I can quickly pause and do something else. That's how I mostly got into it.

Ben Scott: [00:24:54] Before kids I was mostly into Dota.

Bob Payne: [00:24:59] sorry?

Ben Scott: [00:24:59] Dota Which is a different type of game.

Bob Payne: [00:25:02] OK.

Ben Scott: [00:25:03] League of Legends. Very similar as the birth of League of Legends. Was one of the first of those types of games. 

Bob Payne: [00:25:11] Okay. But that's when I decided it would be hard for me to play because it requires 1 hour blocks. 

Bob Payne: [00:25:19] Oh yeah. Yeah.

Ben Scott: [00:25:22] Couldn't dedicate that anymore.

 Bob Payne: [00:25:23] I know, yeah. So there's there's probably a game waiting for me this evening when I go home. So let's see. But.

Ben Scott: [00:25:35] Let's see what else now spend time with family. Every Wednesday we have.

Bob Payne: [00:25:42] Long walks on the beach and.

Ben Scott: [00:25:43] Ah.. Not that, Just cook and eat and and drink and be merry. Revolves around food, and every Wednesday we have big family dinner. 

Bob Payne: [00:25:55] Wednesday?

Ben Scott:[00:25:55] Yeah Wednesday just because weekends are crazy. We also do on weekends. But we found that doing it in the middle of the week it kind of cuts the week and half.

Bob Payne: [00:26:04] Yeah. You talk about work a little bit the stress and excuse to escape the daily grind of get up go to work. Come back do homework or other things. It's another event middle of the week that's a bit unusual but yeah it works for us.

Bob Payne: [00:26:22] Yeah Wednesdays are not that exciting, it's dessert day. So.

Ben Scott: [00:26:26] I like family Wednesdays. It's fun.

Bob Payne: [00:26:29] Ok cool. We'll have to we'll have to do dessert/Dota/.

Ben Scott: [00:26:37] Well I haven't played that game in so long i'd probably be terrible at it now.

Bob Payne: [00:26:41] It's ok. You're better than I am 

Ben Scott: [00:26:44] Probably.

Bob Payne: [00:26:48] Thanks a lot, Ben Really appreciate it.

 

Carlos Rojas, Director of Technology and Operations at Fannie Mae, sat down with Bob Payne at Lean+Agile DC 2018 to discuss Business-Driven Agile Engineering.  Carlos shares thoughts on Fannie Mae?s trailblazing Agile transformation ? from prioritizing agility-supporting corporate shared services (recruiting, contracts & procurement, and facilities), to machine learning and a mantra of ?Automate Everything.? 

 

Transcript

Bob Payne: [00:00:01] Start there.

Carlos Rojas: [00:00:02] OK.

Bob Payne: [00:00:03] Hi I'm your host Bob Payne. I'm here with Carlos Rojas. And Carlos you're talking about transformation. We were chatting you mentioned how to how to use shared services. So tell me a little bit about your your your talk here today at Lean Agile DC.

Carlos Rojas: [00:00:24] Absolutely. So couple of things to highlight right. One is you go and change a culture, Most people start with the processes. Most people start with their methodology and then they say we're Agile. And I think that part of making it a transformational for an enterprise you know when you're talking about 10000 people when you're talking about 300 product teams that are developing software you know you have to take into account what we call the corporate shared services as well. You know think about the recruiting recruiting efforts. Think about the procurement. How do you write your contracts. Right. Think about your facilities you know. Do you have an open space that will be a reflection of what your mentality looks like. So you have to account for those things. Otherwise you know you end up with a great process but the culture is not impacted by what you're doing. So that's one of those things that I encourage companies to always think about.

Bob Payne: [00:01:16] Yeah. And we just I just recently talked with Jose from from from Fannie. And I know you guys are doing a very large transformation over there lot of DevOps. We do some some training with you guys. 

Bob Payne: [00:01:34] And I'm am extraordinarily pleased to see how how big the transformation has been over it over Fannie because I worked there on a couple of early Agile projects in the early 2000s and it was it was bureaucratically painful to do it.

Carlos Rojas: [00:01:56] I know exactly wh at you're saying. It was six checkpoints hundred twenty five deliverable is about nine months for a single release just to put a line of code in production. Now we've made a huge progress in terms of you know time time to market an average of about 30 days a month. We've got some project teams that are ready to deliver every two weeks. But again it comes down to Hey we incorporated our corporate shared services into the mix and then we think we we we instigated this concept of automation you know everything so far as he wasn't even called them up so to begin with. How do we automate it. You know if it doesn't make sense if it makes sense. How do we automate it and that's when we come up with this concept of that paved road so far as the pay really was. What tools are we going to use that will help us expedite or automate some of those controls that were holding us back. Right. So great transformation. Tons of work behind the scenes but you get the point here is we haven't finished. We're not done yet.

Bob Payne: [00:02:58] And lean, Lean never sleeps.

Carlos Rojas: [00:03:03] Exactly exactly. So right now for example one of our key you know tunnel vision eye vision items that we're trying to chase is agile engineering practices right. 

[00:03:15] How do we turn code that is maintainable how do we create applications of 19 applications that are going to help us with you know a cloud-ready approach not necessarily how do we go about the methodology what tools that we use now but how do we make that an engineer solution that is like the ultimate driving machine for us. So we're trying to look for that not perfection but that high performing team that will look into those proses areas that we'll tap into the business for example that's not a mission that's going to help us have more quality right provisioning of environments that's going to help us get faster at some point in time I think that we're going to be looking at how do we do infrastructure as code so that we have a fully blown solution where you build your own servers if you deploy your own servers as development team and you're responsible from beginning to end. 

Bob Payne: [00:04:11] Hundred percent audible and nobody has the password to production exactly one per cent cut off. It's not the engineer.

Carlos Rojas: [00:04:20] Exactly. But at least you can know who what when and you're not having a checklist to do it. It's all part of a creation of the solution right. Software. 

Bob Payne: [00:04:30] Yep yep you know I think it is. It's ironic and oddly a common theme and I don't know whether it's me or just the folks that are coming up to talk on the podcast today but almost every one of them we've talked a little bit about governance and how how this drives you to be more governable auditable reduces risk profile you know rather than being a risky play to be able to deploy twice a week or once every two weeks or it actually improves your risk profile considerably makes you much more audibly compliant with the controls. You say you have in place.

Carlos Rojas: [00:05:23] Yeah. You know it's interesting you mention that when I started my journey at Fannie Mae I ran a governance organization over SDLC and I was in charge of connecting with at risk partners like legal audit you know Architectural Review Boards change control boards and all of that. And instead of fighting through the system what we did is we partner up with all of the governance groups and we said you know you can do it the way you're doing it. But what if we do it this way and let's just compare let's explore let's figure out if there's a better way and if there is a thought that if it doesn't work on the exploration says that this doesn't make sense then we just go back and keep doing it the way we used to do it. I guess what the answer was always yeah that works better than the way we do it and we get more data. Thank you. So they were actually embracing it and promoting it for us. 

Bob Payne: [00:06:12] Yeah. I don't know if you're familiar with Mark Schwartz from Citizenship and Immigration Service. He's sort of a firebrand CIO and he said when he first got there you know coming from Silicon Valley like you don't tell the CIO it can't be done. But what he got to government is people would say well you can't do that because of the far no federal acquisition of election.

Bob Payne: [00:06:39] And he said first he was angry and then he said I'm going to become the expert on the far and and what he what he did was that same approach was like ah here's what you wanted. You know here's the safety that you want from this regulation. And here's how we do it better. Right. It's sort of you know 

Carlos Rojas: [00:07:02] The approach works. You know where you partner with the groups that are supposed to be the roadblocks or supposed to be the longest pole in the tent. If it works you know.

Bob Payne: [00:07:12] Well it's, They're there to keep the organization safe safe.

Carlos Rojas: [00:07:19] Yeah you know if you don't do it it goes against what you're trying to accomplish anyway because you're not just trying to produce code faster you want it to be reliable maintainable with quality compliant. Right. So. So it's a matter of just you can argue whether the legislation is right.

Bob Payne: [00:07:35] But you still need to comply with it.

Carlos Rojas: [00:07:36] Exactly. But sometimes the legislation or the government has the right intent. It's how we approach it.

Bob Payne: [00:07:42] Yeah it usually does.

Carlos Rojas: [00:07:43] Exactly. So you know hopefully for those teams that are struggling with you know the governance aspect of this I'll also just take one thing at a time.

Bob Payne: [00:07:53] Yeah.

Carlos Rojas: [00:07:54] Because you know I've seen people trying to cover it all, oh we're going to fix all these problems right now you can use your theory of constraint was the biggest one. I just tried.

Bob Payne: [00:08:04] Protects the constraint, concentrate on that one.

Carlos Rojas: [00:08:07] Yeah. Did you read the goal.

Carlos Rojas: [00:08:10] Absolutely. That's what I got that from.

Bob Payne: [00:08:12] Yeah the Hurby or the Brian in the Phoenix project. Yeah. Put water where the fire is and in small increments it pops up. Yeah great.

Bob Payne: [00:08:27] So what are you looking forward to over the next couple of years getting accomplished.

Carlos Rojas: [00:08:33] So it's a phenomenal question.

Bob Payne: [00:08:35] It is also a journey it's not an end point.

Carlos Rojas: [00:08:37] It is a journey. It's not done so I'll say maybe three things that we're looking at right. So one is becoming a high performing team in terms of all the agile engineering practices. So really just looking under the hood and figuring out do we have the right automation and we have the right you know called brunching do we have the right techniques that are engineering techniques that will create a great product. That's one. The second thing that we have started working on is the AI machine learning so introducing much learning to our software development lifecycle.

Bob Payne: [00:09:09] Okay 

Carlos Rojas: [00:09:09] Right so right now we've been using some regression basic algorithms with machine learning to be able to look at the data on the history of releases that we have so that we can do two things one we can predict when a release is going to fail interesting. And then the second thing is if it fails you know we can start looking at the deployment scripts. Figure out hey this might be that two or three things that the reasons behind why that release is failing. Right. So we're piloting some of that solution right now. And I think that aspect is cloud. How do we turn these applications to be called cloud ready right when we know in some cases we have monolithic applications that have been around for 23 years.

Carlos Rojas: [00:09:49] How do you take that and move it to the cloud and get the benefit of it not just a lift and shift, but saying Hey lets triangle that application that are more functionalities to micro services I think those are the three components that we're going to be focusing on the next two years.

Bob Payne: [00:10:02] Yeah the the predictive analytics side that's very that's very interesting to me and I'm super curious how that sounds complex but it is probably something that I started while I had a sort of field career as computer architecture free I so far as I was doing that and then decided to go to procreate. So it doesn't sound that complex. I think the interesting thing for me is that you need a reasonably large dataset for that to be able to to really start to bear fruit. But I'm excited to hear you guys would have it so. 

Carlos Rojas: [00:10:52] So we have a reasonable amount of data on releases that go back you know years okay. But interestingly enough when we started training our morals we use a subset of six months. And when we started with that subset of data we identified about 150 fields that were important and then we had the model train for a few weeks and then we test that we said let's just see that confidence level and we put real data against that model and then our success rate was about 10 percent. It was really bad. It's no surprise right. So instead of saying instead of saying let's get more data more fields more of features we say let's take those hundred and fifty and gotten our way down to 50 and then we have a smaller subset of fields and we have a smaller subset of data for 3 months and then we trend the model again.

Carlos Rojas: [00:11:56] And then now we can tell you that we're you know successfully predicting with a 90 percent certainty certainty rate. So we went back to the model with less data less data elements are more precise data set and our success rate went up.

Bob Payne: [00:12:12] Well I mean look at you know what we're starting to see genetic markers for you know in biology that have a very large effect. So once you find the targets I think I think that level of that that that is amazing that you were able to how long did it take you to go from 10 to 90.

Carlos Rojas: [00:12:36] So it was about a 12 week project. But then thinking about thinking about the project I'm thinking about the data said it took us about 6 weeks. So I would say you know quarter a quarter and a half worth of you know.

Bob Payne: [00:12:49] That's amazing, are you using, what are you using back end engine?

Carlos Rojas: [00:12:52] So we're using TenserFlow. It's an open source from Google, using Python to write the scripts and to be quite honest with you because we're exploring our capabilities are just basic you know we're not building a beautiful website that people can access. We're just enabling the developers to say hey gone check this page and then you know pick your acid I.D. your application I.D. and some information on the model is going to give you the answers. So it's basic. Right. It's still in the exploratory mode. We've done a couple of good successful use cases and now we're trying to roll it out to the company.

Bob Payne: [00:13:28] I am I've been pleasantly surprised at the resurgence of Python.

Bob Payne: [00:13:37] I was in some of the early Python conferences Python back when they were here in Northern Virginia and D.C. and now running into it in the large corporations that they also have micro Python which runs on a microcontroller. So you can you can you can do hardware programming. You were always able to buy it you needed a heavy heavy thing. Now they're doing you know arm processors isn't super lightweight.

Carlos Rojas: [00:14:12] But the difference is you know the user experience at the end of the day you know when you started developing maybe you know in my case 20 years ago with Cobalt or C++ or even Java. Right. You have to have some sort of computer science background to be able to kind of like and understand that and and do something with it. Nowadays with Python, It's more of a English type of you know development where you don't have to be computer science guru to learn it and apply it so I think that's why it's being so helpful for the adoption of those techniques. 

Bob Payne: [00:14:49] I mean it was, there was a certain, well there's a whole philosophy around you know Python and you know people people do argue whether they achieve that but they wanted it to be an easy learnable right. You know part LAMDA part object part you know and be able to drop down to the metal pretty quickly with assembly or see you know the whole idea that you could tie in those when you needed to if you needed to program and see were able to easily tie it in with Python.

Carlos Rojas: [00:15:30] Exactly. And to be quite honest with you we're leveraging some of the open source you know libraries to execute on some of the you know projects that we have. 

Carlos Rojas: [00:15:43] So it's not like we're building something from scratch anymore right. So that's helpful as well.

Bob Payne: [00:15:48] Yeah. Well great Carlos. Thanks for coming in. It's a pleasure chatting with you and I wish you guys all the well you don't need luck all the hard work in the world. 

Carlos Rojas: [00:16:02] Thank you for having us here, appreciate the opportunity. Thank you so much.

Bob Payne: [00:16:05] Thanks.

 

Modern Agile stickers everywhere are helping Modern Agile stick.  Dean Chanter of Capital One recalls his Accidental Experiment with Modern Agile (cake for every release!).  Bob and Dean talk through the power of the laptop sticker, evolving and ?upskilling? ScrumMasters, and Lean roots.

 

Transcript

Bob Payne: [00:00:05] Hi I'm your host Bob Payne and i'm here with Dean Chanter and Dean you're from, You're at Cap One.

 

Dean Chanter: [00:00:11] Yeah, Currently at Cap One.

 

Bob Payne: [00:00:14] You're doing some work with scaled Agile and you're saying you sort of accidentally started applying Modern Agile. I'm super curious about that journey.

 

Dean Chanter: [00:00:25] I did it was very interesting so I joined Capital One about seven months ago, was with Intel for about 13 years before that, and when I first got to Capital One everybody had a Modern Agile sticker on their laptop there was actually a bunch on my desk. So I just slapped one on my laptop. I had heard about it before I got the Capital One but Intel was a big SAFehouse and so that was kind of how we did things there and made a lot of sense and so, maybe three or four months ago, my gallbladder decided that it no longer needed to be in my body and so's listening to Josh's podcast and listen to things and he and John Cutler were talking.

 

Bob Payne: [00:01:02] Okay, yeah I've had Josh on my podcast.

 

Dean Chanter: [00:01:04] Yeah. So Josh asked John -he's like What do you think about Modern Agile. What do you mean to you. And John was like you know what. It really makes me feel like we can try anything and we don't have to stick to one framework another. And I realized then that some of the things I have been doing it kept on with my teams was just that right. I had a lot of teams that were Scrum Teams and Kanban teams and we had ARTs so we had you know single teams but they needed... They were looking for a refresh right.

 

Dean Chanter: [00:01:37] You know some new ways of thinking about things that we brought in things like product discovery. We started looking at cycle time. Right. We just we started celebrating everything. Right. We had cake for every release we had you know just how.

 

Bob Payne: [00:01:54] Dangerous when you're a real DevOps...

 

Dean Chanter: [00:01:56] Exactly. Exactly. Well that was one of the things we went from releases that were on average and they say average because it wasn't a true cadence of about six to eight weeks. We're now releasing twice a week. OK. You know just because of trying to setting audacious goals right. Right. Using that we want to really use more frequently. Right. And once we set that goal we started working through the different things and different challenges that it takes to get through. We actually even if we don't have content for release on a particular day that we're supposed to be released, we'll still do the release. The reason is is because it allows us to go through those motions right and should identify more ways to we found things by doing that that maybe we should leave - blue green releases right. So maybe we should leave green up a little bit longer so we could fail back if we need to. Eventually, you know the goal there is eventually getting to where we could do continuous delivery if we wanted to.

 

Bob Payne: [00:02:56] Yeah. That's great. So I'm so curious how you got the big batch of stickers. Did Josh come to CapOne and.

 

Dean Chanter: [00:03:03] He did.

 

Bob Payne: [00:03:04] Okay.

 

Dean Chanter: [00:03:05] So Josh came to camp while he was a keynote speaker. CapOne does a technology agile conference internally once a year.

 

Bob Payne: [00:03:13] I've spoken that years back yeah.

 

Dean Chanter: [00:03:15] I wasn't there for that yet but that's how the stickers ended up on my desk. So.

 

Bob Payne: [00:03:21] Yeah I have been doing a series of of of talks using modern agile as a sort of framework to look at Lean and depending on where I go and how how I either call it. "No one gives a shit about your practices" or "disrupting the cult of the cult of practices". I'm a scrum trainer but fundamentally believe that scrum is a starting place and the goal is not to like do scrum. The goal is to get into this. You know this idea of experimentation learning and changing and and so you know I was an old XP extreme programmer guy. So you know I've known Josh for a long time and you know that talk really. It was actually that sticker was the deflowering force.. It's probably not appropriate to say but I had always had Virgin Macs with no stickers on them until that one made it on my last Mac.

 

Dean Chanter: [00:04:31] That was the first sticker I put on my cowpat on issue laptops. Have it if you have a habit of putting stickers on stuff for me is like yeah I'm fine. I agree. I agree. You know that's actually one of the things so I do manage a group of Scrum Masters right, and ScrumMaster is fhe title that Capital One gives them you know I looked at, look at them more than just that, right? They're team coaches, I've got a couple that work as a scaled coach right? As well, and so-

 

Dean Chanter: [00:05:05] That was one of the things that we spent a day together back in March you know kind of strategizing you know our improvement areas that we wanted to go with the team right. And so that's one of the things that I mentioned to them right is that you know if you look at it from that Modern Agile lens you know then I'm asking you to balance that coaching and the delivery right and ,. And one of the things we talked about is like sometimes as you know agile coaches all too often want to wait for that big moment and that big huge coaching opportunity, that next retro or their next delivery, right? So one of the things I talk to them about is sometimes coaching in the moment and being a player with your teams is actually the best opportunity for that coaching moment. I actually got one of my Scrum Masters now who is actually a performer on the release. So since we've got teams that are applying good DevOps practices right the teams are the performers on the release and so she's actually the performer. What.. and the reason for that is that it allows him to have an extra person separation of duties or his since she's not coding that she can have that access to that prod environment. But it's a lot harder to identify a lot of areas of waste that the teams were seeing because she's got that different lens.

 

Bob Payne: [00:06:20] And when you get when you get even further down the dev ops path you'll be able to deploy without access to prod.

 

Bob Payne: [00:06:27] Exactly. Have an auditable..

 

Dean Chanter: [00:06:33] Yes. That is the goal.

 

Bob Payne: [00:06:35] Yeah.

 

Dean Chanter: [00:06:36] But in the meantime it's allowed the ScrumMaster to provide value in ways that they haven't in the past.

 

Bob Payne: [00:06:43] Right, You know just you know I like to poke at stuff. It's kind of what I do.

 

Dean Chanter: [00:06:50] Oh yeah.

 

Bob Payne: [00:06:52] So you were working with. Well my friend Beth Wong.

 

Dean Chanter: [00:06:58] Yes. So that's another interesting thing. So Beth and I are actually kind of paired together with the teams that we're working with. OK so where I'm providing that more tactical delivery focused management of the scrummasters, Beth is actually paired with me as a true coach. Right. And so she doesn't have that accountability to the product. And so she she and I are able to do things that having a single RTE in a scaling house wouldn't be able to do. So Beth is able to run workshops and you know she was able to bring in someone and worked with them and that's how we started our lean product discovery is because I was able to stay focused and she was able to coordinate those types of workshops. Another thing that Beth is is able to do. She's actually run in a technical coach and so that's one of the ways that we're accelerating that automated release goal that we have for this.

 

Bob Payne: [00:08:00] Yeah. Yeah. I loved working with Beth and I know she's she's excited to be the guys now.

 

Dean Chanter: [00:08:05] So yes it's a great partnership.

 

Bob Payne: [00:08:08] Yeah. Super. So what else is exciting for you lately?

 

Dean Chanter: [00:08:13] I mean definitely as we're evolving you know our scrum masters you know and what we call upskilling them. Right.

 

Bob Payne: [00:08:21] So we've got some folks on my team that you knew six seven years ago as CapitalOne went through its original agile journey right went to see some class and you know they're great at following those rules.

 

Bob Payne: [00:08:35] You probably are not aware of. In 2005 they started a huge agile journey.

 

Dean Chanter: [00:08:43] I've heard that.

 

Bob Payne: [00:08:44] It's been swept out and then.

 

Dean Chanter: [00:08:46] Exactly as a multiple and in depending on what Capital One is a large organization depending.

 

Bob Payne: [00:08:52] Are we talking card?

 

Dean Chanter: [00:08:53] So I'm in card, right. Exactly. So different journeys there but the teams I've been working with I've been five or six years is kind of about as far as they can look back.

 

Bob Payne: [00:09:05] Right.

 

Dean Chanter: [00:09:05] And so again kind of going back to that me asking my team to be that more player coach. So we're looking at different ways of kind of seeing the way the teams work right. Right now they're working through Mary Poppendick's original book.

 

Bob Payne: [00:09:22] Yeah.

 

Dean Chanter: [00:09:23] Right. So one of the interesting things about me and my journey started with Intel and so Intel being also not only a product development team but also a manufacturing to Jamie Flinchbaugh in the intel years and years ago long before I started there.

 

Bob Payne: [00:09:40] Right right.

 

Dean Chanter: [00:09:40] And turn into a lean house.

 

Bob Payne: [00:09:42] Right.

 

Dean Chanter: [00:09:42] And so

 

Bob Payne: [00:09:44] Lean manufacturing. It's always ironic to me that many of the organizations that do really amazing lean logistics are lean manufacturing and I'm not saying this about Intel because I don't actually have firsthand knowledge. They look at agile they're like you know we can't do that. That's not it's not you know it is really ironic that it is they do have the same same roots.

 

Bob Payne: [00:10:10] You know clearly manufacturing is a different is a different thing than product development.

 

Dean Chanter: [00:10:18] Right.

 

Bob Payne: [00:10:19] And. But but lean product development has also been around for you know almost 75 years.

 

Dean Chanter: [00:10:27] Exactly. So and that's where my journey started right. Is is in then so. It's almost like if you talk to the folks at Toyota about Lean manufacturing right now. What is lean? this is jus t what I do. So, at Intel, for me that's what it was right. You know I.

 

Bob Payne: [00:10:43] They don't fetishize lean in the way that scrum teams fetishize Scrum.

 

Dean Chanter: [00:10:47] They don't.

 

Bob Payne: [00:10:53] My Precious Scrum.

 

Dean Chanter: [00:10:53] Exactly. Exactly. And so you know I you know we you know when I was running a team.

 

Bob Payne: [00:10:57] I'm the agile golem.

 

Dean Chanter: [00:10:59] yeah yeah yeah exactly. So when I was running at my first team team ride of developers and we had daily stand ups and we committed to you know we committed to the goal for that day and the next day we talked about you know how we go towards that goal right. Even if we were working on a bug right. We didn't commit to finishing the bug. We committed to the experiments that we were going to run that day. Right. So when I transitioned to Agile you know it just kind of made sense for me right now come in the CapitalOne that I think it's kind of flipping the coin. I feel like that's a lot of the things that we're working through as a team evangelist. At least in my area is bringing some of those thought patterns.

 

Dean Chanter: [00:11:41] Identifying the waste and running experiments right and less about any one particular process or and other. Metrics is another thing that we are bringing and doing which has been very interesting as well.

 

Bob Payne: [00:11:55] Cool experiment to learn rapidly.

 

Dean Chanter: [00:11:57] Absolutely.

 

Bob Payne: [00:12:00] And in fact the only one I have a little trouble explaining to executives is the make people awesome, because they don't care. Many of them don't. If they could go to the boards and saying yes we're we're we're we're selling the customer crap, we're torturing people and we've got higher revenues you know.

 

Dean Chanter: [00:12:25] And that's definitely a shame but.

 

Bob Payne: [00:12:27] It is. It is. But I've I've enjoyed I've enjoyed you know Josh's poke in the eye and you know I think it's going to stick.

 

Dean Chanter: [00:12:41] I think so too.

 

Bob Payne: [00:12:42] Yeah because it's a sticker because he often makes a joke how do you make. How do you make an idea stick? Turn it into a sticker.

 

Dean Chanter: [00:12:50] Turn it into a sticker I haven't heard him say that but I like that. Well I like what he's been saying lately. right. He was at LeanAgile US in February and I got a chance to see his keynote there right. He opened the keynote. Are you curious as I say that's what I took back to my team. Right. You know are we curious? You know and another one of the things he said there is I know have you identified a ceremony or practice on your team and just gotten rid of it to see what would happen. Right. And that's another one of the challenges that I gave to my team as well.

 

Bob Payne: [00:13:24] Yeah I mean you know Toyota doesn't.. They'll throw stuff out left and right that you know. Lean is the machine that eats itself to make itself better.

 

Dean Chanter: [00:13:37] Yes.

 

Bob Payne: [00:13:37] And I don't think Agile is there yet but that's that's one of my goals. So I really love you know he framed it in a way that pulled together many of the thoughts and conversations a lot of us had been having. And so I'm happy to carry that torch for him for a little while.

 

Dean Chanter: [00:13:58] I almost kind of I don't know if it came on the cusp of or maybe there has something to do with it but I feel like a lot of the fights that you see you know on Twitter or blog spaces you know around Scrum vs Kanban, estimates or not... I feel like a lot of that has calmed down recently. I don't know if it's if there's a correlation there. But at least for me that's what I see.

 

Bob Payne: [00:14:25] I think there's more correlation than causation would be my guess. I think people are just worried about you know foreign policy being run on Twitter. So no estimates or mob programming thing is just..it's like Oh my God I can't believe we were arguing about that stuff.

 

Dean Chanter: [00:14:40] Yeah maybe.

 

Bob Payne: [00:14:46] So thank you very much for coming in and appreciate it and hope you have a great talk.

 

Dean Chanter: [00:14:52] Yes. It was fun.

 

Bob Payne: [00:14:53] Great.

 

Agile didn?t work as your silver bullet?  Not a surprise, according to Very?s Dan Fish, Product Manager & Agile Coach, and Gabe Weaver, Chief Product Officer.  Dan and Gabe joined Bob Payne at Lean+Agile DC 2018 to talk Agile methods, holacracy, and the hard work required to solve organizational impediments after adopting Agile.

TRANSCRIPT:

Bob Payne: [00:00:01] Hi I'm your host Bob Payne, i'm here at Lean+Agile DC. Why don't you guys introduce yourself since. 

Dan Fish: [00:00:08] Sure. I'm Dan fish I'm a product manager and agile coach at Very.

Gabe Weaver: [00:00:14] And I'm Gabe Weaver I'm the chief product officer at Very 

Bob Payne: [00:00:17] Excellent. So you guys are here talking about why agile might not be the silver bullet everybody everybody's been making it out to be. And you also do Holacracy at Very so I'm excited about both of those things. I like to blow stuff up and I love you know experimenting with self managing teams and strategies. So those are a couple of things I'd like to talk about. So what sucks about agile?

Gabe Weaver: [00:00:51] I don't think it's necessarily that it sucks. I think companies suck.

Dan Fish: [00:00:58] Honestly it's very subtle ,  Gabe.

Gabe Weaver: [00:01:00] Yeah. No but but really if you look at some of the some of the data that's coming out stated the agile from today's seventeen's survey is a 4 percent in the company's report that it's not actually enabling them to have more market agility to respond to changing market conditions adapt and really move more quickly in business. So if you start to like peel back the young into why that is it goes pretty deep but I think a lot of it goes back to the construct of how we structure organizations

Dan Fish: [00:01:31] Yeah. And I'd say it's sometimes too much of a silver bullet or a you know it's like a salve you can sprinkle and everything will kind of go away. And the work really comes in after you've put some of these processes or or roles in place you know where do you go from there and how do you solve the organizational impediments that are there. That's the hard work and that's the real I think substance behind this sort of movement of responding to change and empowerment and bottom up stuff. How do you how do you actually make that happen particularly at large organizations that are used to top down management or centralized decision making and yearly budgets. Those are the hard problems to solve.

Bob Payne: [00:02:10] Yeah.

Dan Fish: [00:02:11] Rather than just you know what's you know a sort of a small scope problems that are just affecting one team. I think we've kind of seen them seeing that and solve that in a lot of ways that they are not. Not completely but it's you know how do you change the organization. How do you change the mindset and the culture and culture gets undervalued a lot

Bob Payne: [00:02:29] Yeah. So culture gets undervalued. A lot of talk a lot of talk about culture but not a lot of work and culture is fundamentally hard work. You know the old adage that culture eats strategy for lunch so you know if you want to create an agile environment that the current culture in the organization is going to resist resist those changes even if there are changes for the good. So I think the culture gets absolutely undervalued and the agile practices get overvalued. I 

Bob Payne: [00:03:12] Absolutely.

Bob Payne: [00:03:14] I mean I get a rash when people .. I get a lot of rashes.

Dan Fish: [00:03:20] Sounds like a personal problem.

Bob Payne: [00:03:20] It really is. I should care less. That would be easier. But you know I see people talking about you know the scrum rituals and like these are their meetings they're not rituals there's nothing.

Bob Payne: [00:03:34] You know if if if Taiichi Ohno came back to life and saw that Toyota was using the same processes that they that he and Demming came up with. You know 75 years ago he would freak.. He would freak out, he's like you you do not understand what we were going for there because the practices and processes are subordinate you know to getting stuff done creating value for our customers following work flowing value through the system. I mean the practices are just- they need to change and evolve then people were they put agile in here. They codify it make it a little precious little thing and then they don't change the intake to the three year strategic plan. One year funding competitors come out with new stuff. Well we're on the strategic plan will react to that in three years.

Gabe Weaver: [00:04:33] Yeah I don't even ant to get started on scrum and my disdain for it. But I think what's really interesting is that most companies treat is a way to gain efficiency. So but really what it is in the heart of it of where the Agile Manifesto came from was enabling people to work better with people in a more efficient and sane way.

Bob Payne: [00:04:56] Right.

Gabe Weaver: [00:04:57] That's more stable basically but the opposite is happening whereas companies are valuing processes over people and it's not sustainable and it's not working.

Bob Payne: [00:05:09] Yeah. So I won't lay it all out. So I live in that tent so I'm on the inside peeing out rather than the outside peeing in... So I do a lot of scrum training but I always start it with. Here's lean.

Gabe Weaver: [00:05:25] Yes.

Bob Payne: [00:05:26] Here's- it is OK to start with scrum scrum is not the goal. I really put in some slides recently with Bruce Lee. But. So. So it's discipline. It is continuous improvement in playing the long game. You can start there. But once you get disciplines then you can start to improvise in the system and then at some point when you get really good the systems fall away right. And ultimately you should be tying back to lean and lean eats itself. Yeah it never does it never sleeps it it's the whole goal is to change yeah.

Dan Fish: [00:06:11] One thing I like asking Scrum teams that have been doing it for a little while is how a scrum become an impediment. How does how does the framework of scrum and the rigid roles of scrum become an organizational impediment for you. I've seen some really strong mature teams move beyond scrum you know and get into continuous flow and it's so a beautiful thing because they've kind of taken the best elements of it the mindsets and the cultures and and the and less about the rigid rigid ceremonies or you know sort of straight lines of separation

Bob Payne: [00:06:43] Even the roles of product owner and development team in the scrum masters the you know the arbiter between those two opposing powers. Well what if they're not opposing and they're both working for the same thing you know like Motley Fool you have these little micro feature teams and there's a few engineers and business folks and they're just building value right there. The distinction is getting a go.

Dan Fish: [00:07:16] Yeah the guys at Gilt have a nice way of saying it which is this was in response to the Spotify movement from to you know 10 years ago or so.

Bob Payne: [00:07:21] Right. 

Dan Fish:[00:07:22] You know tribes and guilds just great stuff. Gilt had a nice paper saying we we think that stuff is cool but you know some of it's an antique pattern you know in particular separating prioritizing of work and doing the work right. Right. How do you separate those two things. Fundamentally it's you know that they really didn't believe in that I think. I think there's there's truth in that. I also think though there is you know a personality there is a you know a right of someone to say yeah I care about the business and where it's going. Up to a point and I just want to focus on doing a great job and I think I think I think there's a balance there.

 Bob Payne: [00:07:55] Well everybody has you know their particular proclivities are specializations and that's OK. This idea that we should somehow be you know there should be a level of homogeneity is .. i don't think Generalizing specialist means that, right? And I don't know that that's something that it's not some pure beautiful thing you know some people are going to have a deep interest in the the customer in the business somebody is going to have a deep interest in breaking shit and they're going to be really testers and some people are going to be really interested in building stuff but when they Windu people can have a rich dialogue and make better products make better decisions make faster decisions. I think that's the goal. Scrum can be an enabler. Josh Kerievsky calls it sort of the training wheels foragile in you know you can't always ride with the wheels on forever right.

Gabe Weaver: [00:09:00] Yeah. My observation I've noticed is in our projects even trying to get our clients to participate in their own product development. They hire us to build that is how often do business owners or are onsite customers or whoever the sponsors actually participate in regular weekly meetings with the team provide ongoing regular feedback and unlike a predictable cadence and more often than not it doesn't happen they don't they don't see the value of it and it's hard to shift that mindset and think beyond anything else. That's part of the primary reason why scrum why XP why anything will fail and does fails because there isn't that healthy participation from the business with the actual team building the product. Sure that was such a good game because it reminds you of a George Carlin joke about voting where it's like you know you don't get to complain about who's elected. If you don't vote right. Right. And George Carlin's like oh I sat home on Election Day. You know I don't want any part of this. I'd say one of the things I've seen over time consistently is that separation between the sponsor and the team doing the work. I know whether you know I did product development for years at Very, we're consulting for for for companies. But the problem is when you have a sort of proxy product owner right or something better than the team who doesn't have budget authority doesn't have sort of that that level and they're the ones though privatizing the backlog. Also for our ally that separation can be a real a real killer.

Dan Fish: [00:10:35] And then you lose empathy right because then the person who has the budgetary responsibility doesn't have the empathy of how hard it is to build software or other organizational challenges and impediments.

Bob Payne: [00:10:44] Yeah but also if they if they're making decisions without the information they're flying blind you know as well I mean it just is. You know it always surprises me when they don't care how hard it is to Bill will you'll care when it's late or we've gone over budget

Dan Fish: [00:11:02] Or their expectations are wildly off because they haven't engaged right. And that's where they get to sort of sit back and you know kind of sit in judgment of it without actually participating. I think that's frustrating.

Gabe Weaver: [00:11:12] Yeah that's one of the interesting things is another survey by Gardner. Basically 51 percent of organizations have no plans to establish refactoring as a core principle and how they build products and software. And they're not. They're not investing in the long term and stability and they want to go faster quicker. And I think that's where even a lot of business owners they don't want to hear that it's going to go slower or they don't care. They want to get to market quickly but they don't realize that by doing that they're actually short circuiting the speed later on and rendering more or less useless. Right. Oh by the way we're running a free platform the whole thing and you can't have new features for eight months. I think the only opposing force there is you know is there some over optimization there. Right.

Dan Fish: [00:12:00] Is is is creating in a really sophisticated tooling and some of the you know test driven development stuff you know doing that too early before you know your product market fit. I could see that being an opposing force. But I think once you've gone to market right once you have customers once you know you're going to be around for a while right. You want to be sure that all of the stuff you put in place before you know is at a certain level of maturity.

Gabe Weaver: [00:12:25] We disagree a little bit.

Bob Payne: [00:12:27] So for the folks that came up test infected the TDD is not only free it go you go faster because it's not a testing it's not a testing activity. It's a thinking activity. But

Dan Fish: [00:12:47] Sure I got a different way which is you don't actually need bulletproof Hice high scalable high you know responsive software when you have no customers.

Bob Payne: [00:12:54] Right.

Dan Fish: [00:12:55] Right now that's all trying to say there.

Bob Payne: [00:12:56] There are people that absolutely agree with you and there they are well respected. So Dave Thomas a pragmatic programmer Dave says you know I don't write many tests anymore. I don't know that he does a ton of production code anymore either but

Gabe Weaver: [00:13:15] He's also like elevated past level mastery and some some other force of nature that is amazing.

Bob Payne: [00:13:22] Me i'm just trying to ..i'm doing the best I can. I need a crutch right. I'm not a free climber. I need to attach my ropes as I get up the walk on the one I'm talking about. But I only see the tests there to help the cycle ocracy.

Dan Fish: [00:13:45] That's a good one.

Bob Payne: [00:13:46] Yeah. So how's that working for you?

Dan Fish: [00:13:50] Peaches and cream

Bob Payne: [00:13:50] And you know some people say What if I don't like peaches and cream when the holaocracy revolution comes, You will like peaches and cream.

Gabe Weaver: [00:14:03] I will say it's not perfect but it's better than what alternatives there are. They are well documented and easy to adopt an organization. Yeah it's certainly a little bit heavy handed and it feels that way. But once you do it for a while you realize the intent behind the heavy handedness is to protect everyone from waste and it's almost like a kind thing where you have efficient meetings instead of it being nice human you have very human interactions. But when you go to like a tactical meeting which is basically a stand up is very quick fire very rigid about the process because you don't want to have 20 people cross talking in a room

Bob Payne: [00:14:41] And when you just starting out like scrum you need rules. Yep yeah I mean I see that those sorts of structures as supportive of instantiating the first first steps.

Gabe Weaver: [00:14:55] I think the most important thing about it is there's no rule in the Constitution which is kind of what we adopted. You can't change the constitution. Right. So. So the board of our company ratified the Constitution and basically ceded their authority to governing the organization according to the rules. Right. But it can be updated and changed and evolved over time. And I think that's the whole intent behind it just like it's continuous improvement in software. You apply the same principle as the organization and you can change it to how you need needed change but we're trying not to do that until everybody understands the responsibility of self-management.

Bob Payne: [00:15:33] Yeah until you can do it well until you can demonstrate that you can execute it's what qualifies as an I'm not pointing at you guys... You can take a you know what qualifies you to say this way who would be better until you've least tasted what you know the ability you can't deliver. You can't improve your delivery. Right. So but I don't think you need to go too far down the line. You know you don't have to be the perfect scrum team before you start making minor macro level changes to the process that takes you off scrum so be it or it takes you out of the official official ocracy. You know you've got to make contextually appropriate choices and and it's your your team your company. This period of time this competitive landscape and assume that it will evolve in the same way that Toyota evolved and maybe they're at some plateau. But I suspect they'll have disruptive change that they'll want to adopt. I will say it was not perfect. 

Gabe Weaver: [00:16:44] We had our our company wide meet up a couple of weeks ago and I reiterated the fact that everybody in the company is considered a partner. Yep and everybody's empowered to make changes and improvements. And it's actually the responsibility of every partner within the organization to do that and that's the evil that is.

Bob Payne: [00:17:03] And That's the thing that's sometimes difficult for folks they don't want the responsibility of changing the system.

Gabe Weaver: [00:17:09] But we've been pretty good about hiring to let people know what they're coming into. And the interesting thing is we haven't had any voluntary turnover in three years.

Gabe Weaver: [00:17:18] And it's not just because of velocity but I think it's more because of the shift in how we're approaching people and putting people first and organization like we made it clear we're happy to ditch it if it doesn't work but only do it if there's something better to go to that keeps the same spirit of putting people first in empowering people and allowing people to become their ideal selves.

Dan Fish: [00:17:40] Yeah and I see some of the things that have really resonated with me and with hypocrisy is transparency. Yeah you know that's one of those things put people put on a white board or a slide. It's hard to actually do right. How do you give transparency to organizational strategy and performance and things like that

Bob Payne: [00:17:56] And gain alignment in a non-centralized system.

Dan Fish: [00:17:58] Absolutely. Particularly if things aren't quite maybe baked right that idea that there's a kernel of an idea that needs to be developed a little bit more and that's when you know if there's too much sort of transparency to it it can die or die quickly before it's ripe and so getting that right balance you know that's not easy either. That's not some idyllic paradise that we're swimming in every day. Right. So that's something we we've been spending a lot of time in the last six months to really figure out OK how do we get enough transparency to things that are happening on decisions in progress or big strategic shifts. And I think that's really important when you want an engaged team and you treat your people as good or better as your customers. I think that's that's an important piece.

Bob Payne: [00:18:34] Great. Well I am excited to see companies going down this path we're.. at LitheSpeed we're kind of you know thumpin away and taking maybe more experimental using some techniques from some from Buurtzog and some from Morningstar. But yeah congratulations and it's going to be fun.

Gabe Weaver: [00:19:00] I appreciate that

Bob Payne: [00:19:01] Will not be peaches and cream. May you live in interesting times. 

Gabe Weaver: [00:19:04] Maybe some vanilla ice cream on the side.

Bob Payne: [00:19:06] Yeah. Excellent. Thank thank you very much for coming in. Thank you VERY much.

Gabe Weaver: [00:19:13] I see what you did there.

Dan Fish: [00:19:13] Yeah.Thank you. It's a pleasure.

BUSINESS AGILITY: Evan Leybourn, founder of the Business Agility Institute and Conference, has been screaming into the void about Business Agility, and the void is finally screaming back.  Evan is building a strong community around business agility across diverse industries, and plans to reclaim business agility from the consultants and marketing folks that keep using the buzzword.

Evan sat down with Bob Payne of the Agile Toolkit podcast to discuss.

How do you define Business Agility?  How do we de-buzzword it?

Hearing so many stories, I came to the position that we don't want a definition.  In this formative stage of Business Agility around the world, whatever definition we put on it is going to limit its ability to be more things to more people, and right now I think that's more important.

What we did is we actually put together a Model of Business Agility, about 60 of us working with the community on all the different domains and dimensions that make up Business Agility.  I think that is a better way of visualizing the totality of what it is rather than a sound byte.

Outcomes: In the context of software delivery, Agile has been only about the build for a long time and misses the mark of real outcomes for customers, stakeholders, etc...

I like to talk about changing the questions. It's not about what something costs, it's about what something is worth.  It's about putting the customer at the center of what you do.  If your KPIs are about earning money, about revenue, you're missing the point. The intent behind why we're in business is often forgotten.

An Agile organization is one that has clear measures and KPIs around why they are in business and customer intent.  If you address the customer's need effectively and efficiently, and the customer likes what you're doing, and your reason for existing is sound, customers and profits will come.  Traditional organizations measure the wrong thing.  Agile organizations measure the business-customer outcome.  That's a very clear distinction.

What does Business Agility look like?

I've been working with industries from banking to mining to retail to IT.  Business Agility is relevant to everyone, it is the next generation of company models.  We talk about matrix organizations, that's the 1980s mindset.  We now that these Agile organizations, dynamic and structured in a way that teams own outcomes.  In fact, in the Business Agility model, one of the key domains is structural agility, and that's incredibly important. If an organization doesn't have the right structure, it's actually going to lose its ability to be Agile.  Every time there's a handoff, every time that a team is created around a function, it loses its ability to be agile.  An Agile organization is one that aligns work and teams to outcomes.  If you have clear organizational outcomes, broken down into achievable outcomes by teams, once you have these ideas of "We're going to change the world of work" or "We're going to get rid of diabetes," whatever your vision is, we can break that down into outcomes.  You might have very tangible ones like "We want to be a great place to work" - how do you measure that?  Retention, staff satisfaction.. and once we have the measures and a proper outcome profile, measures, KPIs, cadence of the measures, feedback loop.. let's create a team that fundamentally works on that outcome.  Literally cross-functional.  I can bring accountants, BAs, developers, and engineers, into a single team if they have the right skills to achieve that business outcome.  Once you have that team, and the team is owning and accountable, I don't care what they do.  The work and projects that they build are irrelevant.  (That's not strictly speaking true...it's actually very important)  But, at an organizational level, that's not my responsibility anymore.  As an organization, it's that team who owns that outcome and that feedback cycle of continuously doing all that is necessary to achieve that business outcome.

What big changes have you seen in your client base as you support more companies from a non-IT background?  Where is Business Agility taking root for your clients? 

There's a continuous change that's occurring, the evolution of a continuous culture that has emerged around the world.  This idea of continuous change, continuous feedback, continuous delivery, continuous everything.  Companies that are able to work in this model are fundamentally able to be Agile, to be an Agile company.  Traditional companies that have not had that mindset are being disrupted by this continuous culture and change.  They are the ones who are most likely, most in need of making this transition toward business agility.  So from an industry perspective, Banking and Finance is huge right now. When we do their organizational strategy and we help them define their key business outcomes, and we look at "Who are your competitors?"  They don't say other banks. their competitors are Google, Apple, Alibaba.  These are not even secondary competitors, these are their primary fear-based "we are terrified of these companies."

Software is eating the world, and every company is becoming a digital company.  There are banks out there saying we want to be a digital bank, or an agile bank.  I've worked with companies, financial institutions, where the traditional functional structure of IT and Business has gone.  They have gotten rid of the IT team- because all of the developers now sit in the business.  So, I own a credit card function, the credit card product, and have 20 developers and BAs and testers working in my team, because technology is now the business.  There's still an IT thin slice around the infrastructure, because that does tend to be common, but everything else, pass that into the business and own that in.  Even if you don't fully restructure towards fully agile outcome teams, this reducing the amount of handoff, this idea of i'm a business function I shall write my requirements and pass it off to you, dear IT please build this for me, those days are gone.  It is now this continuous change of value and value creation.  The closer you can make those lines of communication, and it doesn't get much closer than the same team, the better.

 

LitheSpeed is a corporate member of the Business Agility Institute.  Explore the Business Agility Institute to get involved with the global community and visit lithespeed.com for Agile training & coaching.

The Agile Toolkit Podcast I always say that DevOps in one sense is really an extension of agile principles out to everybody on the ship. -Jeffery Payne Bob Payne chats with Jeffery Payne, Founder of Coveros, at Lean+Agile DC 2018.  The Payne Cousins (not really) chat DevOps and tips for pairing developers and testers.  The discussion covers moving toward a generalized specialist model, testers showing up like a demolition crew, and the true meaning of pairing. [caption id="attachment_7988" align="alignnone" width="2024"] Jeffery Payne sits down with Bob Payne (not cousins..)[/caption] TRANSCRIPT Bob Payne: [00:00:02] Hi I'm your host and technical idiot, Bob Payne. Just struggling with the equipment there for a little bit, making making the the the big newbie mistake of hitting play instead of record. So I'm here at Lean + Agile DC 2018 and I'm here with Jeff Payne of Coveros. Jeffery Payne: [00:00:25] Your cousin right. Bob Payne: [00:00:26] Yeah. Cousin Jeffery Payne: [00:00:27] Yeah. Bob Payne: [00:00:27] Yep. So Jeff what what are you talking about here today since I am out here in the hall and not not in the talks. Jeffery Payne: [00:00:38] Yes I'm talking about dev test pairing. Okay so trying to get developers and testers to work together better. We find that that's one of the biggest issues we see on teams when it comes from engineering perspective. Bob Payne: [00:00:52] Yeah I mean I think the early agilists were a lot of XP teams that sort of did away with testers because everybody was considered to be a tester. I think it was also sort of a chemistry of the particular group of folks that were on that first team. And you had folks like Elizabeth Hendrickson, Lisa Crispin. A lot of folks sort of brought testing back into the Agil fold. Yeah what do you think the biggest problems you see with testing and agile teams or trying to get testers and coders to pair? Jeffery Payne: [00:01:31] Yeah I think obviously one of the biggest problems is that they historically haven't worked well together. They're kind of on different sides of the fence as a check and a balance in some organizations right. Jeffery Payne: [00:01:42] And and a lot of organizations even they prefer that their testers not even talk to their developers they want them to be independent speak because they think it's kind of like an editor if if you haven't seen it and then you review it another set of eyes you're not you know you're not influenced by the development. The other sort of clean room actually that's the traditional approach. Of course it's always been very late lifecycle and very manual right. None of those things work well on edge. All right. Bob Payne: [00:02:11] Well none of those things actually work well in life. It's not just an agile thing. Jeffery Payne: [00:02:16] So you know how do we change that? Bob Payne: [00:02:17] Shoot, it's not secure and doesn't scale. I'm glad we have 12 hours to fix this before production. Jeffery Payne: [00:02:22] Yeah, Exactly. Here you go have it done by tonight. So yeah. And so what we try to help teams fix that. Bob Payne: [00:02:30] Yeah. Jeffery Payne: [00:02:30] Address those issues. Bob Payne: [00:02:33] What are you what do you think has been most beneficial recently for helping you in that in that quest of getting folks to pair together. Jeffery Payne: [00:02:42] Well we have some techniques and approaches that we like to use to try to get them to work together and also learn from each other because you know if you're moving toward a generalized specialist model on your teams we like that model. Yup and you want collective code ownership and you want a whole team quality all these you know motherhood and apple pie concepts that we espouse too. You've got to get everybody productive during the entire Sprint or whatever you're doing story development or whatever. And the only way you can do that is that people start learning from each other and cross fertilize. Historically you know I was a developer developers aren't great testers for a number of reasons. Jeffery Payne: [00:03:20] Just you know out of the gate they're not very good testers and testers oftentimes particularly if they are manual testers they don't have a very strong technical background they don't know code they can't write automation right. Those two things together don't work very well. So we've found that by pairing Dev and test they can help learn from each other and become stronger teammates and collectively on the code better. Bob Payne: [00:03:43] Now do you find that tools like cucumber or other. I don't know if you're running into teams using fitness but are early on fitness is one of those tools cucumber most recently specked flow help bridge that gap so that testers can blow out those scenarios a little more directly after the fixtures are done or even before the fixtures are done. Jeffery Payne: [00:04:09] Definitely. Yeah I mean the the BDD oriented. Bob Payne: [00:04:12] Yeah Jeffery Payne: [00:04:12] Cucumber with Gherkin, kind of natural language approach is a great way to start moving particularly manual testers toward understanding how to automate without having to dive right in and start like you know trying to write good maintainable selenium scripts for instance or whatever. I mean it's hard to write maintainable any kind of scripts. Bob Payne: [00:04:33] Write would be better then record -those are a nightmare to maintain Jeffery Payne: [00:04:39] No doubt, or record any test is a bad idea because that's how they're sold often so. Bob Payne: [00:04:44] Right. Jeffery Payne: [00:04:45] That's how you know people think you're supposed to use those tools. We definitely like those kinds of tools that we think they help move a a tester toward being more capable of providing automation support. Bob Payne: [00:04:57] What sort of behavioral, I mean, You mentioned the word pairing. What does that mean when you say that because I see a lot of I see a lot of misuse of the word. I'm assuming you're not but the mis use of the word pairing Jeffery Payne: [00:05:09] I Might be, who knows. Maybe you'll tell me i'm wrong, Bob. Bob Payne: [00:05:11] And TDD, I see a lot of people misusing or not really understanding TDD. That's most common but Jeffery Payne: [00:05:17] Yes. Yeah. So I mean to me I'm basing it off of the definition of pair programming. Go you know getting two people together to work together collectively on some task. When you talk in dev test you're really either talking about those two people working together on code almost pair programming and one of our techniques is to use a dev test to pair program yet which is a little different right because one of them maybe doesn't actually know how to write code. So what does that mean. Right. In pairing. The other thing we use it for is to review each others tests. So if you're going to ask developers to do a unit test you want them to learn how to write good unit test meaning think through not just happy path but you know the errors and boundary conditions exceptions and all those kinds of things they usually inherently don't know how to do that a tester can by working with them help them understand how to do that better. Second if you're asking your testers even if it's manual to create tasks for integration for system for you know kind of the combinations of things across use cases and your business flows they often don't they often won't load the design. Well enough particularly if they haven't been involved in those activities they should be but often aren't. Jeffery Payne: [00:06:34] Yeah and the developer can help them think through and understand how does this software all pieced together to meet the you know the flow that we're looking for in our application and how users use it so they can help each other from a testing perspective we found. Bob Payne: [00:06:47] And one of the other things that I think a lot of a lot of testers can help with as well is what are the business rules like oh yeah if you're doing an under UI test which quite often happens in the developers domain you know what are the what are those conditions you know the happy path is easy and that's usually where developers go because they know the happy path works but they don't necessarily test those boundary conditions as or that or the business rules right if I had a whole bunch of J rules or other stuff I wouldn't test that through the UI right. Jeffery Payne: [00:07:26] Yeah no doubt. Bob Payne: [00:07:28] Yeah. Jeffery Payne: [00:07:28] And to your point about a happy path. The other thing we've seen is not every developer's like this but you know a lot of developers consider what they're building to be a work of art. Right. They're like Michelangelo creating the Sistine Chapel in their in their mind. Yeah and they're all about creating this beautiful incredible thing that's going to last forever and just people are going to you and all over it even if it's just their peers. Bob Payne: [00:07:49] Yep. Jeffery Payne: [00:07:50] And then the tester shows up testers like a demolition crew. Bob Payne: [00:07:52] Yeah Jeffery Payne: [00:07:53] Right. They're trying to poke holes in it and figure out what's wrong with it and it's kind of like calling your baby ugly. If you're asked to test your own code because you know you might have every intention but in the back of your mind you might be thinking I don't really want my Sistine Chapel to have problems in it or look bad and changing that mindset is part of getting Dev and tests to work together to understand the best way if you want to build something great is to find any issues as fast as you can see eradicate them. That's really about what it looks like when it gets delivered yet not what it looks like. You know while you're making the sausage right. Bob Payne: [00:08:27] Yeah. I find a lot of people use the term Pairing and they're really talking about working together on just acceptance criteria or something like that that's necessary but not sufficient. I think that deeper level of the deeper you can go in interaction and an understanding the better off your team is clearly Jeffery Payne: [00:08:52] We've had good success getting developers involved in doing some exploratory testing as well. Bob Payne: [00:08:57] Sure. Bob Payne: [00:08:57] You know a lot of times testers get together and do you know session based exploratory testing across stories or whatever. What about the idea of just getting the Dev and test together for a story they're working on and having an exploratory testing session where they work together and explore the product and talk about it and identify bugs. Again that gets the developers a little bit more comfortable doing testing and knowing what to look for thinking critically about the app. And of course it helps the tester better understand the app because if they're they don't understand something about what they're testing they've got the developer right there they can ask Hey what was this supposed to do or how was this supposed to work. Jeffery Payne: [00:09:32] Now I think the story is maybe vague did we really build the right thing or are we testing it properly. That dialogue's very helpful. Bob Payne: [00:09:38] Yeah. What else is exciting in your your world right now Jeffery Payne: [00:09:42] Nothing Bob Payne: [00:09:42] No? Jeffery Payne: [00:09:42] Nothing. Well as you know we do a lot of DevOps work. Bob Payne: [00:09:47] Yeah sure. Yeah it's the new edge issue. Jeffery Payne: [00:09:51] Yeah exactly. Bob Payne: [00:09:52] Yeah. Actually you know we were going to be talking later with some folks talking about sort of you know in many ways Agile is sort of hit a ceiling and I'm hoping this will open up gaps where we can get to real real agility and real cause. All too often it's seen as a fix for the delivery team not right. Not a systemic change that can build better value faster. Jeffery Payne: [00:10:23] Yeah and I totally agree. I mean I think one of the mistakes that the founding fathers of Agile made is you know they were all about collaboration getting everybody to work together. But they forgot a key piece of the lifecycle which was delivery and release and production and production oriented. Bob Payne: [00:10:41] And actually intake in the business side. Jeffery Payne: [00:10:45] Exactly. You know it's funny this group that was all about collaboration and getting everybody on the same page left all these people out right by mistake. Obviously they were creating it as they went so I understand. So I always say that dev ops in one sense is really an extension of agile principles out to everybody on the ship you know involved in the software delivery process in the full lifecycle software. Bob Payne: [00:11:09] Yeah and agile and dev ops are both the you know great grandchildren of lean which was all about that base that whole process right. Jeffery Payne: [00:11:21] Yes. Bob Payne: [00:11:22] Yeah. You know this reintroduction of the concept of value streams and value team and stuff - It's like back to the future. Jeffery Payne: [00:11:32] I'm sure you've studied up on the history you know all the way back through Demming and you know all the way back to you know statistical process control and even beyond that I mean it's clearly standing on the shoulders of giants like everything we do. It's amazing how many people don't understand that or take the time to find that out or understand. Bob Payne: [00:11:50] And the idea that that actually Devops, Yeah there's a whole bunch of cool technical stuff going on, but it's about closing the loop to be able to learn. And my favorite Demming quote about that was learning is not compulsory. Neither is survival. Jeffery Payne: [00:12:07] Here's some great pithy comments. You know we're in this. You know there was an article I read that compared it to an extinct extinction level event you know where we've got you know Internet of Things and big data and and organizations being able competitors being able to go extraordinarily fast and learn and reintegrate that learning. The end for the many organizations that will that will mean their doom and not going to pretend that DevIps or Agile is any silver bullet in allowing them to survive. But I just know the status quo is not the strategy I would take. Jeffery Payne: [00:12:56] Yeah. Well yeah I mean if software is really eating the world which I think we would agree it is then you'd better figure out how to optimize how you build deploy deliver and feedback information fast because otherwise you are going to be out of business. Yeah eventually. Bob Payne: [00:13:15] So what's happening over at your company Coveros. Jeffery Payne: [00:13:18] Coveros, yes! So We're busy little busy little beavers helping people with Agile and devops just trying to get it right. And when we focus more on the engineering aspects of both of those things but I often get asked to you know help pull teams together and figure out how to make it all work. Bob Payne: [00:13:36] Yup Jeffery Payne: [00:13:36] But we really like the the engineering aspects as I call it you know Automation doesn't solve all your problems right. I always say a tool with a fool is still a fool. Right. So you have to know what you're doing and you have to collaborate work together. But automation can help and as long as you take that philosophy you can leverage test automation and then you see ICD Automation and other types of automation effectively. If your view is that automation somehow solves all your problems it's a magic bullet right. And it all you know takes culture or you know magically make it all work then you're going to be really upset right because it's not going to work so that's kind of what we're focusing on. Bob Payne: [00:14:16] Magical thinking is a strategy has also proved to be not the greatest.. Jeffery Payne: [00:14:21] Hope. Hope is not a strategy. One of my favorite sales books and I use that a lot. Yeah everybody says it's not grounded in reality I would say just remember hope is not a strategy. Bob Payne: [00:14:30] Yeah yeah yeah exactly. Well great. What what's exciting you coming up. What do you see coming down the pike in the next. You know what I know prediction is tough especially about the future. Jeffery Payne: [00:14:47] Yeah the future because if I could I wouldn't be in this business or I'd be retired long ago. Bob Payne: [00:14:52] Yeah exactly. Jeffery Payne: [00:14:53] Well I am I'm excited about. Bob Payne: [00:14:54] What do you actually see that's here. Jeffery Payne: [00:14:56] Well I was very skeptical at first but I am a little bit excited about what's going on with integration of A.I. into Dev and test. There are some interesting things going on around how you can leverage AI capabilities to build better tests for your applications. Do testing in a better way. So what actually look interesting. Are they going to scale or are they going to work right we've been talking about AI and you know robots take over the world forever which of course is not going to happen. Bob Payne: [00:15:30] The joke is AI is the next big thing and always will be. Jeffery Payne: [00:15:34] Yeah it's very true because you and I we probably are same same relevant age and we were coming up through the techie ranks. AI got really hot for a while. Bob Payne: [00:15:43] I was in the computer architectures for AI master's program so Jeffery Payne: [00:15:47] Yeah! It was hot hot hot, VR - the first VR systems came out and everyone was talking about these awesome things and how we were going to live in alternative worlds. And all that stuff and of course then like a lot of things that it didn't really happen and kind of disappeared but it bubbled along and now it's kind of popped its head up again. Bob Payne: [00:16:05] And so I'm not familiar with the uses that folks have been you know the application in the testing area what is the is this especially for like I mean if you look at big data you don't know what's in there necessarily. So you don't know know what to test for like where's the where's the current application of. Jeffery Payne: [00:16:33] Well there's a couple. One is of course everybody's trying to figure out how to even test AI-based systems whether it's B.I or or whatever it is you know how do we know the answers right. Right. That's the age old problem in the systems is you know how do you actually know whether what you got is true or not because you kind of need that testing right. But the other side of it which which we're more focused on is other ways to build better approaches to automation that analyze the product analyze what you're building and not completely write the scripts for you but take a step toward providing you test automation capabilities and scripting without having to do that on yourself. There are some new tools out on the market really small startup stuff that's trying to take a different look completely at how we create automated tests and how we maybe do that automatically. Yeah and the software is a really hard problem. Bob Payne: [00:17:37] Yeah I can I can I can extraordinarily easily imagine doing like really good deep progression by looking at sort of big data. Big data user behavior. You know we've kind of done that to heatmap. You know we really need this piece to be bulletproof because of risk. I'm sure there are folks out there that are mapping the the usage. But I could also imagine very easily just observe what folks are doing and and learn from that. I mean it's the way to go. [00:18:20] You know Al p haGo learned how to play go and meet you know with you know the vast majority of the learning in a system like that is not from the ruleset right. The initial ruleset it's actually playing another copy of itself Veriga and and and going through the database of previous games which for go is actually harder than chess but apparently it never played go. But yeah it sounds easy it's go go. How hard could it be. Jeffery Payne: [00:18:53] Just go right. Just go. So what. What's up with that. Just sounds a lot harder. four letters. Just kidding but Bob Payne: [00:19:04] It is four letters is twice as many. Jeffery Payne: [00:19:08] That's fine. We're just having a great time here right. Bob Payne: [00:19:15] Yeah. Jeffery Payne: [00:19:16] So yeah that's what what I'm interested in that is just you know trying to take the dev ops concept to the next level. You mentioned round trip. Right. Which is you know a lot of people spent their early instantiations of automation just focusing on how do I get code you know from a change in their production as fast as possible with quality and stability as well. You have to balance those. But now I think the more sophisticated companies are saying OK well it's great to get there but what happens if you get there and something's wrong. What's the fastest roundtrip approach to fixing that and addressing that. Is it rolling back. Is it going roundtrip and coming through. You know because the the other thing that's and people say why is that important if we're not the kind of company like you know say and Amazon who's pushing code out every 11 seconds right. Jeffery Payne: [00:20:05] Why do you need that we need that for security and stability and performance service level agreements. I mean if you've got a problem in production it cost you money every minute every second it's down or that there is a risk out there with a security perspective you've got to figure out how to round trip change as fast as possible. And that's an exciting area I think has been under looked at. You know it hasn't really been the focal point of house is now I think starting to be. I mean this it is really ironic that the safest way to go is to be able to go fast. Bob Payne: [00:20:41] I mean Jeffery Payne: [00:20:41] Oh yeah. Bob Payne: [00:20:43] I mean the level you know I remember those days where company would have to fail over to their dark side and emphasis on fail right because it would be days hours just downtime before they could you know oh shoot the Oracle logs didn't replicate. Yeah. Or whatever. And in like extreme programming and some of the techniques there early on they were seen as risky and the real practice in the same way that drove up seems risky. If you're doing it the way you and I think they should be doing it. It's actually the least risky way of behaving Jeffery Payne: [00:21:37] Right. Yeah it is. Yeah of course there are some apps that you'd like to be able to push into production quickly but maybe can't ever fail. So you know you can't you know this you know the Amazon concept of roll something out there doesn't really work. Jeffery Payne: [00:21:53] Roll it back and tune it roll back out and you're kind of using your customer to test test and give you some time to live life critical for that. So there are certain ones that you need. You know just double down on your assurance process during your dev ops capability because it can't fail on the field.. For a lot of others you know. Bob Payne: [00:22:10] Well one of them one of the things that I've been thinking about because I quite often talked about high quality and the key is and someone came up to me and said what you're really looking for is expected quality. So and he had an example that was was a big oil and gas company and one of the things that they said is your labels are too good. He's like What do you mean said we need the labels to start to deteriorate immediately said we do not want to see someone pouring a lubricant into a cooking pan in Africa or in some other area where this is unfortunately a common practice with a brand spanking new company logo on the outside of that thing said is we actually need that to deteriorate. And I start to think about that because as you mentioned you know some fine you know I may not have critical transactions push something around or find a roll it back. You know that might be fine. You know canary roll out on Spotify right fine right. Jeffery Payne: [00:23:39] Yep. Bob Payne: [00:23:40] Canary Roll out on the firmware and in a medical device maybe not so fun. Jeffery Payne: [00:23:46] Yeah Bob Payne: [00:23:46] Because the Canary dies Jeffery Payne: [00:23:48] And it's a big Canary. Bob Payne: [00:23:48] . Oh yeah yeah Jeffery Payne: [00:23:55] Yeah. No. No doubt Bob Payne: [00:23:56] Yeah. Jeffery Payne: [00:23:56] And that and that is something that I think people misunderstand about dev ops. [00:24:00] You know when I speak about DevOps at conferences I always well attended everybody's interested in the topic because it's hot Bob Payne: [00:24:06] Right. Jeffery Payne: [00:24:07] People have this perception and unfortunately senior management does that Dev ops means speed and speed alone. The goal no fast can I push things into production. Bob Payne: [00:24:17] But imagine a life critical system where you could have test automation every single infrastructure. Code line Change is auditable in and you can get that level of safety. We used to put two you know extraordinary manual testing. Jeffery Payne: [00:24:44] Yes it was very expensive. Bob Payne: [00:24:45] And it's prone to possibility of non repeatable results. Somebody makes a mistake. Somebody configurations off. And now with you know with tools that where you have immutable infrastructure you have software configured network you can actually know to some a greater degree of certainty than we were able to in the past that you have a Conformance Test system. And that adds a lot of safety. Jeffery Payne: [00:25:24] It does and it helps with regulatory is yes right. I mean the one of the under the under represented aspects of dev ops is CM Bob Payne: [00:25:34] Right. Jeffery Payne: [00:25:34] Because if you're doing it right everything you're dragging your entire manifest of your software your test your environments your even your rollback your recovery procedures your monitoring capability. Dragging that all the way through production in a way that you know where everything came from and everything takes and ties together. And that's what regulators want. Right. Bob Payne: [00:26:00] Those that know they actually want safety they don't care about the stack of documents they use sadly to hopefully inspect that you knew what you're doing. Jeffery Payne: [00:26:08] Want you to demonstrate that you have a process that delivers quality and they want to see that there's relationships between the various things that you're using to do that. And dev ops gives you all that if you do it right. Bob Payne: [00:26:20] Yeah. Jeffery Payne: [00:26:21] If you do it wrong it just you know throws your code down through there and everything around it is changing constantly and you're never really going to get the speed or quality that you want. Bob Payne: [00:26:30] Yep well great so anything you'd like to close out with Jeff for Jeffery Payne: [00:26:36] Well just thanks for the chance to talk. I know you've been doing this a long time and it seems like a great podcast and we're really enjoying the conference. Looking forward to the rest of it. Bob Payne: [00:26:49] And if you can stand to hear me talk then they listen to some of the older ones I think Bob Payne: [00:26:55] Definitely. Jeffery Payne: [00:26:56] Ok cool Bob Payne: [00:26:56] I'll get some popcorn and listen to early one's .. I wish you had started it maybe five years earlier than that right. I mean. Bob Payne: [00:27:03] Yeah yeah Jeffery Payne: [00:27:03] If you had started like right around 2000. Bob Payne: [00:27:05] Yeah Jeffery Payne: [00:27:05] Then Bob Payne: [00:27:06] Yeah. Jeffery Payne: [00:27:07] You know you would have had some interesting.. Bob Payne: [00:27:08] There's a there was some gap years as well. Jeffery Payne: [00:27:12] But Well thank thank you very much for having me. Bob Payne: [00:27:14] Thanks.

I sat down with Manjit Singh and Antonio Medina to talk about details of their new book The Lean Playbook. See more below and subscribe now. 

 

Fresh off the release of their The Lean Playbook book. Most books were very theoretical and didn't show how to practically implement these techniques and tools, so what we did was collect a set of experiences from many teams in which we achieved some specific business outcomes. It's actionable. You can jump to a tool or challenge you're trying to address and that's what makes it a good reference book. 

We aren't just focusing on IT - also Lean for Services (Pharma, government, finance, sales, and more). When people think about Lean, they think about IT and manufacturing, but the techniques can be applied in every industry. 

Even though people want to apply Lean, the ask isn't always clearly defined. In the book, we look at it holistically and look at the delivery of value and how it flows through the systems. There are a lot of opportunities to reduce waste:

Empower people to make more decisions. Create a cross functional team to shift quality earlier in the process Eliminate handoff between teams.

We've also given two different ways to go through the book:

Depending on where you are, you can pick your path through the book Jump directly to what you're trying to accomplish

You can find out more details and grab a copy of The Lean Playbook at theleanplaybook.net

Need help implementing these tips into your own organizations? Give us a shout at lithespeed.com or reach out at [email protected]

I spoke with Business Agility Conference organizer Evan Leybourn on some of the inner workings and the future of the conference. 

 

The people are the best part of the conference. 40% of attendees were from over seas and 95% of all attendees flew in just for this event - which is incredible! Truly a global audience. 

We really approached our topics differently this year. It was designed specifically to have "ah-ha!" moments constantly where everyone tells us a story. We weren't looking for theory, we wanted them to tell us their "why," - to leave us inspired. 

In the coming years, we really don't want to grow too big - 350-400 might be the max. Primarily because the intimacy of the conversations is important, but we want to go broader. We want small, focused events all of the world to give people opportunities and the chance to join the conversation. 

4 Pillars in the Business Agility Institute:

Community Outreach Guidance Leadership

And LitheSpeed, as one of our first Institute Partners, has been doing and will continue to live out and uphold these pillars. 

This is my "try to take over the world" moment. What we're doing will influence and touch every business in the world in the coming years. 

The next conferences will take place in Fall 2018 in Australia. Learn more at businessagilityconf.com

 

Need help implementing these tips into your own organizations? Give us a shout at lithespeed.com or reach out at [email protected]

I sat down with Ellen Grove and Sue John to talk all things facilitation. See more below and subscribe now. 

 

 

Facilitation essentially is holding people safely in a space to express themselves is critical. It isn't just about the fun thing - it isn't just about playing with Lego's. It's about the debrief and helping the participants reflect and think about "what did we just learn here." And that helps them to get better at reflecting. It let's them ask "how are we going to do this thing," and "how are we going to be better at doing that thing." 

Lego Serious Play, and other similar techniques, allows everyone to get their ideas on the table and that's how you get people talking, collaborating, and making decisions as a team. It's easier to talk about this Lego on the table than that department is run poorly or I don't work well with that person. 

Facilitation for Decision Making Exercise:

Set up a meeting for the entire morning - We'll be exploring until maybe lunchtime THEN we see the impact Make a decision in a separate meeting. This exercise is for "thinking" about it and the next meeting is for "doing" it.

Questions to think about during the exercise:

Are we getting the right discussions? Have we analyzed the impact? Are we making the right decisions?

A facilitator's job is to hold you back for a little while. Learn to say just enough, hand the control to the team, and be silent until someone else to initiate the conversation. 

 

Need help implementing these tips into your own organizations? Give us a shout at lithespeed.com or reach out at [email protected]

People make agile seem pretty complicated when they first hear about it. There are clear successes when you implement agile if you are able to incorporate a few things. If you don't understand the underlying philosophies of scrum, you may have a harder time being successful. Listen with Bob and George Dinwiddie as they give advice and tips on how to organize your work, do it, and work as a team. 

 

1. Organizing the work

Goes hand in hand with the body of scrum.Have a clear goal, work in iterations, don't plan too far in advance. For some, that's enough, but it might not be enough by itself to deliver regularly and reliably. Here are some tips on organizing your work:

Break the work down into chunks to complete in short iterations.   Measure progress by the end result's value, rather than the time spent on the work

2. Doing the work

Teams already know the work that they're doing to some degree. Sometimes they aren't doing it well, sometimes they are. 

Having deadlines might shine a light on some fundamental issues your team might have. They might be signing on for too much, not know how to test, find discrepancies in what to build, or a host of other underlying problems.  Integrate testing into the work - don't wait until you need to deploy! Have "not started", "in progress", and "done" as your columns on a visual management system

3. Working as a team

A lot of companies expect to throw people into a room and exter them to magically work well together. We know that doesn't actually happen, so here are some tips to have your team work better together.

Collaborate! Have your testers and developers talk throughout the entire sprint, instead of waiting until a testing phase to work out bugs.  Make sure your team supports each other. Respect opinions, have dialogue instead of arguments, and adjust to the personalities in your team. Have ongoing organizational support. perhaps try integrating team level performance and individual level performance together 

Need help implementing these tips into your own organizations? Give us a shout at lithespeed.com or reach out at [email protected]

I talked all things Lean Startup with Teague Hopkins of the Teague Hopkins Group at the Agile DC Executive Summit. 

 

Enjoy

Bob Payne

I speak with Sevatec's Josh Seckel, formerly at USCIS, at the Agile DC Executive Summit. 

 

Enjoy

Bob Payne

John Hughes from Sevatec keeps popping up at virtually every conference, so I think I'd snag him for some podcasting. 

 

Enjoy

Bob Payne

I sat down with Amber King from CapitalOne Innovation Labs at the Agile DC Executive Conference. 

 

Enjoy

Bob Payne

 

This podcast brought to you by LitheSpeed. 

I sat down with Lymari Castro from DoD and Warren Smith with Rein LLC to chat about their talk, Infusing an Agile Requirements Backlog in a Large DoD Program. 

Enjoy

Bob Payne

Since SAFe 4.5 was just recently released, I decided to ask the creator what's new. Listen to us talk new configurations, better integration of DevOps, and continuous improvement with SAFe creator Dean Leffingwell.

 

Enjoy

Bob Payne