Why Predictability Beats Features with Ivan Gekht

What happens when you need to ship software in environments where failure isn't just expensive, it's catastrophic? Ivan Gekht, CEO of Gehtsoft, joins Peter and Dave to challenge how we think about agile delivery in high-stakes, regulated systems.

Forget the innovation lab. Ivan argues that real innovation happens 10 minutes at a time, every day, at your desk. He shares why learning without outcomes is just an expensive distraction, why retrospectives reveal more than sprint planning ever will, and how the biggest transformation killer isn't resistance, it's apathy.

Plus, the dinner party analogy that will change how you negotiate scope vs. time, and why organizations that obsess over features are asking the wrong questions entirely.

Key Topics:

• Why "nobody cares" is the hardest transformation problem to solve
• The reversed iron triangle: hitting dates by flexing scope
• Theory of Inventive Problem Solving (TRIZ) and structured innovation
• Goals vs. features: reframing conversations with leadership
• Why agile fails when it becomes anarchy

This Week's Takeaways:

• Language and framing matter more than we think. Finding the right words and the right way to present ideas can genuinely shift how change happens in an organization.
• The Theory of Inventive Problem Solving deserves a deeper look. Innovation isn't the big thing happening in the cool kids area; it's the thing that happens every day at your desk.
• The dinner party analogy is going straight into my next executive presentation. When sales want locked dates and fixed scope, this framework shows why that's wishful thinking, and what actually works instead.

We love to hear feedback! If you have questions, would like to propose a topic, or even join us for a conversation, contact us here: feedback@definitelymaybeagile.com

Chapters

• 0:00 Framing High-Stakes Agile
• 1:08 Why “No Agile” Is Riskier
• 2:59 Agile Done Well Beats Predictive Plans
• 4:19 Retrospectives As Risk Controls
• 6:10 Learning With Outcomes, Not Outputs
• 8:20 Engagement vs Apathy In Change
• 10:55 Predictability, Dates, And Scope
• 13:29 The 6 P.M. Dinner Metaphor
• 16:44 Innovation With Structure, Not Chaos
• 19:06 Goals Over Features
• 21:02 Connecting Quarterly Goals To Work
• 23:05 Everyday Innovation Habits
• 26:12 Final Takeaways And Close

Transcript

Peter: 0:04

Welcome to Definitely Maybe Agile, the podcast where Peter Madison and David Shark discuss the complexities of adopting new ways of working at scale. Hello, it's good to be back. And here's my good friend Dave. And we've got a guest today. Ivan, would you like to introduce yourself?

Ivan Gekht: 0:21

Yeah, thank you, uh Peter. So my name is Ivan Gecht. I'm the CEO at GetSoft. Uh we are a software delivery partner for high-stake environments, working inside existing systems, constraints, and basically making change predictable, explainable, and safe.

Dave: 0:38

Ivan, as you're describing it, and it's the second time I've heard you describing it, I love the way you describe high-stakes environment because I never describe the work we do as working in high-stakes environment. I will from now on. I think it's a really great way of calling attention to those changes that have to happen, and they have to happen without anybody really being impacted by it, right? There is obviously lots of software, lots of systems that are being becoming obsolete and need to be replaced and so on. And the thing that goes into my mind immediately is I've been in so many conversations where the immediate reaction is, therefore, we cannot use agile methods. We need to project manage this. And I'd love to get your insight. I have a view on this one, but I'd love to get your insight. What do you when that happens? What's your response? What are you thinking? What do you say?

Ivan Gekht: 1:31

You know, I usually I ask why, right? Why do you think that? Because it's it's interesting, agile to a point, uh created, agile community, maybe. I don't want to play the blame game, but uh agile has a little bit of uh controversial meaning behind it by now, right? And but in its essence, agile delivery is about being more predictable, being more consistent, and reducing risks in in transformations like that. So well done agile would work actually better in a complex environment than any project management uh predictive methodology just because of its essence, right? So that's why agile exists.

Peter: 2:16

Yeah, reducing the size of the change allows you to reduce the amount of risk, which is I mean, it's yeah, that's uh that's typically how we end up in those conversations. It's like so so you you say you don't want to do agile, but you what you want to do is way, way riskier. That's true.

Dave: 2:31

But it's but it's recognized and it has some to Ivan. You were just saying there's a lot of experiences of something that is in name agile, but actually is less predictable, ignores risk or or is is a little you know sort of cavalier with how they're dealing with risk. And I think to your point, it's it's so true. Agile is ideally suited to complex risk, risky environments if it's done well. So so maybe if we go into the if it's done well, what do you look for? What do you expect? If are you are you providing the delivery teams or do you work with existing delivery teams and help them apply agile practices? How do you look at it?

Ivan Gekht: 3:14

We uh as a business, we do both. We do uh consulting and coaching and training, and we actually do full-cycle software development and managed service uh as well. So uh when we look at agile, we look at it as uh as what it is. It's it's a framework or approach, certain approach uh to software development or actually to any kind of implementation that has certain pillars built into it. And you use it when you work in a complex environment. If you do in a simple project, if you do in a complicated project, you don't use agile. If you're working in a chaos, you don't use agile, right? So it's a tool that has its application. And uh when we look at it, what what I see a lot is that it turned from uh system that guarantees delivery in a complex environment into anarchy of sorts, right? So it's it's a freedom to a point of anarchy, and it's not, and agile never was supposed to be that. So, yeah, when when when we look uh, for example, in in consulting, right, the very first thing uh I would look at was would be retrospectives, not planning, not uh delivery, it would be retrospectives to see how the feedback is handled within the team. How do they give feedback, how do they take feedback, and how do they work with the process? So yeah, I hope that that answers your question.

Dave: 4:47

I I I love where you're going on that one because it's are they learning, right? Is the uh agile fundamentally is a learning practice, and so you you're stronger if they're able to receive feedback, give feedback, they have the conversations that are necessary, not the comfortable conversations. And there's a lot of things that you can see through a retrospective. I think that's just such an insightful point there.

Peter: 5:08

The I I think going to the the point of it's helping that uh executive understand like why uh they why is this important? Why do we need to learn? Because when we start when we're right at the beginning, we don't necessarily know how to solve the problem. So we've got to learn how to do the problem. And to do that, we really need to try a few things and see what works and see if we can uh learn a few things about how this might be. Are we going in the right direction? Do we need to course correct?

Ivan Gekht: 5:35

Yeah, so I think when it comes to learning, there is a big misconception that uh a lot of teams are missing, especially when agile uh started to be implemented in large organizations with a lot of financial backend. Because if you strip away everything, let's take a singular agile team in a vacuum, a startup, and let's say you have $10,000 of salaries to pay out at the end of the sprint for the team, right? So you need to make $10,000 within this next sprint to make sure that everybody gets paid. And right now you are making eight. So the next sprint conversation, the next sprint planning is about two things like how do we make it $10,000 instead of eight so we can all get paid and not lose 20% of the salary? And now you you can add the learning conversation, right? So, do we want to spend an entire sprint learning, not make the money, but hopefully it will help us make 12,000 next sprint and we can pay pay us back uh that extra 2K, right? And then have a very good life moving forward, because now it's a 12,000 instead of 10 that we need it. But it's a conscious decision of the team to actually risk their money, risk the salaries that they are getting to learn something that would make them work better in the next step. So now if you remove that part of a feedback uh mechanism, right? The direct tight coupling between the money they are getting and the work uh they are putting in, suddenly you have all of these conversations like, hey, we need to waste the sprint learning something because it will maybe help us do a better job uh next time around. Is that an outcome? Learning is not an outcome, in my mind. It's an output at best. It should lead to an outcome that you should be able to show uh in in the future. So so when we talk about agile as like agile is about learning, yes, it is, but with with a lot of constraints around it.

Dave: 7:34

Yeah, and it's as you're describing that, Ivan, it's it I love the context that you're describing just about you know that there has to be a real outcome at the end. That monetary, I mean, money is an easy thing to count generally in most organizations. It's not always purely money. There are lots of different outcomes that you can be chasing. But the conversation isn't about, hey, I learned this or I've I've delivered this or I've I've worked on this for X hours. It's about did we get these outcomes coming out? That's that sort of piece that comes in, or something that that is very easily forgotten as you start scaling across many teams because there's always another team that we would have had the outcome, except it was Peter's team was supposed to do that final piece, which raises a whole bunch of other things that we can come to. Um, can you talk a uh a tad about what are the organizations that you look at where you go, yeah, we're not we can't help you? What are the things that are are the the red flags that tell you this is an organization that has high stakes as this is, we're not in the right place to come in and help.

Ivan Gekht: 8:33

You know, it's it's an interesting question. I wouldn't say that uh any organization is beyond help, but I think that organizations that are the most challenging to work with are the organizations where no one cares. And and that's just as simple as that, right? So if you don't have people who care enough to make the change, uh it's very hard to push the change through because because status quo is the biggest enemy uh in in the majority of the situations.

Dave: 9:06

I I I was not expecting you to say that, I have to say. Peter, what were you gonna say?

Peter: 9:11

The uh yeah, it's uh it's hard to change people if they're comfortable with what they're doing, and if there's there's no incentive for them to change, which is kind of what we were talking about earlier, is these are incentives. This is what colors how they're doing things. So sometimes they need a stronger incentive. Um, or you need to look at uh are they the right people in the right roles? And that uh that conversation can be uh an interesting one to have.

Ivan Gekht: 9:37

Agile transformations from what we've seen in a lot of organizations. Uh I I was looking at the statistics like five, six years ago, uh, so it might not be as as uh relevant now, but then it was uh that about 50 to 60 percent of the people would change during the agile transformation.

Dave: 9:56

I don't remember the numbers as high as that. The the sort of rule of thumb in many transformation conversations when I was working with a lot, you know, a lot of these sort of enterprise coaches was you typically expect to turn over around 20%. Didn't surprise me the 50 to 60 percent, especially as you move into larger organizations with a much more uh stay, you know, less entrepreneurial sort of mindset or less innovative, that that would increase for sure. And uh I'm still just just thinking about the nobody cares comment because it is I was actually thinking we'd be talking about leaders that that don't want to let go of decisions, or that there are there are lots of different things that make it awkward, but then again, all of us are in that space of we'll find a solution. But that that comment about people not really caring, and that expresses itself in so many different ways. It's it's a sort of passive resistance. Everybody nods their head, definitely we'll we'll do whatever it is, the commitment that they make during a sprint planning session, some sort of a planning session which never gets followed through on, and there are no consequences of missing your commitment, uh, and things like this. So there's a lot of differences that that can come out of it. I thought that was a really interesting.

Ivan Gekht: 11:05

Yeah, I but like personally, I would much rather have a team who are proactively fighting me uh on the transformation and uh but talking to me and and making sure that uh you know they they can try and understand what I'm saying and and give their arguments and and maybe we can we can talk about it, help them find a way because it shows that they care, over a team that's just quietly sitting down and not saying anything, right? Uh and then going and not doing anything as well.

Peter: 11:34

Okay, it's can be useful sometimes to look at like why that is, because it it quite often is cultural. It's the the way not always, but sometimes it's simply that the that's the way that they've been treated. They've tried fighting and they fought and they fought and they fought and they've been told no, no, no, no, no, and they're now just play out what oh yeah, it's just yet another person coming up with yet another way of doing this, and nobody's gonna listen. It's not gonna change anything, it's just gonna be the same thing. So why should I? And that's um that can happen.

Dave: 12:03

Can I can I explore um Iron With Wells? You said at the beginning about the high-stakes environment about predictability, and and I think this is something, and again, we we've worked with great agile teams, and they're all about predictability. You get lots of predictability from it, and yet many organizations I work with, the thing that they struggle with the most is long-term predictability over short-term planning. Right? So, how does that what do you see? What are the things that maybe looking at from a leadership perspective? Because they get very, very they want to know dates, they want to have commitments that are, you know, strongly 100% this is going to happen by this time. But we know that in a complex environment, there's a lot that you can move, but it's very possible that without just having lots of buffer in case something goes wrong, you don't necessarily have the the commitment, the the predictability in the sort of accuracy levels that leadership might be expecting. What sort of conversations do you see? How do you get kind of make that palatable?

Ivan Gekht: 13:03

So when it comes to predictability, what always surprises me is that agile as a as a as an approach or you know, this whole reversed iron triangle mechanism, if we if we look at it, right? It's all about making sure that you hit the date and the budget. You can be very flexible on the scope, yes, because you need to trade off on something. But for some reason, people forget about that. And and once they start working in the real environment, everybody is now trading on the on the budgets and on the timelines. It's literally goes against the the great principles uh that that are built into the a lot of agile frameworks, right? So it's about some constraints that exist. It's the budget and the time. So uh one of the metaphors that we use very often is you have a 6 p.m. dinner tonight, right? And you need to cook something. And you know that you have the family members coming in, you have so you you can't really go out and say, like, hey guys, you know what? Uh it was a very complex uh situation, so the dinner is gonna happen next week. So you all are gonna go home hungry tonight. Like it's not an option, right? You have all the people coming in. Uh you don't want to look stupid. So, but do you have to really follow through on a on a six-course menu uh that that you had in mind, or maybe you drop a couple of things to make that 6 p.m. commitment and make the budget that that that you have in mind, even if you lost your wallet on the way back and lost half of the cash that that you had on you, right? So you can still manage. This is dealing with the complexity in an agile way. It's achieving the goal, but maybe with a little bit different of a scope, but still making sure everyone is fed, not hungry, and uh and it happened exactly at 6 p.m. as you promised. In some organizations, yes, uh, it can be challenging to have some of these conversations because they really want to see the scope done exactly. But if you really want to have the scope done exactly, don't use agile. Because if you have a well-defined scope that you need to implement, it's not complexity, right? So you it's it's it's complicated at best. Go out, use use um uh use PM Bok uh and and do a great project, add the buffers, add the risk management, like do all of that, and uh you'll be happy. And everyone will be happy.

Peter: 15:35

Unless you've made your six course meal very, very complex and you've never made any of them before. And no matter what buffers you put in, you've created so much risk in it that you're still not going to end up serving dinner until 10 o'clock at night.

Ivan Gekht: 15:46

In that particular case, yeah. That's that's why I agile.

Peter: 15:51

Yes, which is following through on the analogy there. Uh that some of those courses may have to be like tuned down a little in in terms of I I do like that analogy. I think that's a good way of explaining it. And it is it is one of those those pieces. If you if you do have a particular scope that has to be delivered, you can still use Androids just when are those bits going to be delivered. The problem comes when you set the scope and you set the date. Because now that's just wishful thinking. You're especially if it's not if it's something you've never done before, the chances of getting that exact scope on that exact date. Uh yeah, that's gonna be very, very tricky. For anything that's of any sufficient complexity that it's gonna be uh take some time to do. If uh if you can reduce it down though, I I completely agree, then yes, you can solve this in different ways. Imagination helped.

Dave: 16:42

Now, how about what are you seeing? I I love the analogy. I'm just thinking as I'm listening to Peter describing this, the the analogy uh summarizing it, it described my Christmas day perfectly because we had a plan of six different different uh settings, and we didn't get to all six, let's put it that way. So there was some complexity that happened early in the afternoon. Um but uh yeah, uh the there there's there's an element around things like innovation and learning. And we touched briefly on you can't be spending the whole time learning, but retrospectives are about how organized you know how a team is is addressing the things that go wrong. But another aspect of learning is innovation, and especially you're working in a field where maybe you're moving away from legacy systems, there's a lot changing in the technology space, always a lot changing, but right now even more. So, how does innovation roll into it, into how you approach those problems? Where do you create space for innovation? How does that relate to the overall problems that you're trying to solve?

Ivan Gekht: 17:47

Yeah, so you know innovation is a great topic. We can have a whole uh another uh podcast for uh, I don't know, talking an hour just about the innovation. But what's interesting is that if you look hard, then you will find frameworks and approaches that make innovation predictable, too. One of the my favorite personal uh favorites is theory of inventive problem solving. It's a pretty old methodology. It it initially was developed in I think uh 60s, late 60s, early 70s in the Soviet Union. But basically, uh Al Schuler and his team of research scientists took uh about 15,000 uh patents that were filed with the uh Bureau and they analyzed them to see if there are any commonalities and how people approach innovation. And they actually developed a whole set of uh laws, nature laws they call, and a whole set of approaches that you can take, you can apply to your situations, and uh you can make innovation way more predictable than just brainstorming or relying on uh uh collective crowd uh minds to maybe come up with something uh during a sprint. So so you put structure into the innovation, and then you could then you can put innovation into a structured process to I was gonna say, how do you go about making space in organizations for that?

Peter: 19:16

Because quite often, I mean we're back to that, hey, what where should I be spending my time problem? It's the should I be spending it on uh on the innovation piece, or I've just got to deliver the next feature and get the next feature out the door.

Ivan Gekht: 19:30

I personally don't like talking about features at all. Uh it's it's a very uh misleading conversation, always, right? What so so I much rather prefer to talk about goals because goals is something that organizations understand, that actually something that they measure, and a lot of executives or managers are actually being evaluated based on how effectively organization. Is the goals, not on how effectively organizations, uh organization is shipping new features. Right? So when the team is trying to talk about features or finding space uh between delivering features and and and something to the management, that's it's a very comfortable space for the team because they talk about what they understand, but it's very uncomfortable space for the management. So if you reverse this conversation and you start to talk about the goals and you start to talk about how to make goals be achieved more predictably, then suddenly you have way more open and uh way more engaged managers to include innovation into these conversations because you're coming with a commitment uh and accountability to help them reach these goals instead of coming in with like what is being heard as hey, we want to have fun and we want to innovate and we want to do a hackathon and uh people need that for moral support, and you do you when it comes to goals, we're gonna do us when it comes to all of these events. So you shift the frame of the conversations and suddenly the the conversation really changes.

Dave: 21:14

Again, some great things to drill into there. Goals kind of come from some strategic direction, hopefully, and they cascade down. Uh, at some point, the goal's not going to tie directly to a feature, it's going to tie to some sort of behavior change that we want to get from a customer or some other thing that we're providing a system for and so on. Goal on a sprint-by-sprint basis, or in that tiny, you know, feature level, small kind of cog part of that goal, is very different to a broader goal over, say, a few months of trying to see subscription subscriptions go up on a service or something like this. So, how what happens in that gap between we have a sort of a quarterly goal that's a business goal that we're trying to achieve versus the actual technical work that's being done? How do you cross that gap?

Ivan Gekht: 22:01

I actually very big believer of not creating the gap in the first place. Because if if the team or a number of teams are accountable for reaching a goal, a certain goal, that goal should be visible. That goal should be uh in front of their eyes every single sprint planning. It has to be in front of their eyes every single day they're doing the work. And then uh it shifts the conversation from implementing a feature to to a certain point uh a validated hypothesis innovation to track, okay, so if we're gonna implement this and this and this changes, we should see subscriptions go up by 10%, right? They're not gonna go up overnight from zero to two extra 10%. It it never happens, right? So probably you're gonna make one change and it's gonna affect 1%, and then you're gonna make another change and it's gonna affect another two percent, and then you're gonna slowly build up to that 10% that that you wanna see. So keep tracking, and then it it again it helps shift the conversation from feature implementation into the reaching the goal.

Peter: 23:08

It's a good use of uh language, uh, and I like it because it's uh very much it's a bit of a shift from the language we often end up speaking about in this space. So I think it does it ties in nicely. Uh we we have we often talk about uh goals, making sure the goals are measurable, how those then get cascaded into teams, how we align teams to those, what we what we see as a consequence of that. Um, so I do like the way that you're framing that. It's uh I think it works very well. What other questions might we have, Dave?

Dave: 23:35

I have so many questions I'm trying to give some space. So just I I enjoy the like this is a great way of kind of kicking off my year because it's a reminder of yeah, this is what great agile organizations look like. They they don't focus on you know outcomes and how many features you're gonna deliver in the next month and things like this. They focus on are we achieving our goals? How do we work together to get there? Are we developing the skills and the tools and so on we need to be able to move forward? So there's a lot that we're coming out of that. I just what maybe the the question I'd like to explore, or the space I'd like to explore more, is around innovation. And you said you've hinted at it, you mentioned the um theory of innovative problem solving, but innovation, like we're in a space right now, organizations are in a space where innovation is their lifeblood. They have to be innovating continuously. It's something that that so many, and and Peter and I are kind of probably in that space where there's a lot of organizations go, I need all of these features as fast as you can. And by the way, um, you can't miss any deadlines and so on. And we have to innovate and achieve these goals. And of course, you can't do all of those things together. It's a recipe that is guaranteed not to be very tasty, to go back to the sixth the meal that we were talking about. But uh in a in a space where vibe coding is you know endemic and there are people who have no technical background are going to start coming in and going, but I built this just using large language models, and we've got this, that, and the other. How do teams innovate? How do teams really kind of balance getting business outcomes while at the same time somehow staying close to or on top of the many, many changes happening in the space? What do you look for? What do you encourage to kind of enable that?

Ivan Gekht: 25:25

So actually, uh it's it's a very interesting question. Thank you for that. Innovation comes in in many shapes and forms. So what I really dislike in in the whole innovation conversation is that uh innovation usually being put aside as a as an uh a monstrous animal that you need to fight or you need to conquer and uh have an entire separate journey for the innovation. While in reality, innovation is in everyday work. Like you spend 10 minutes a day, you can always find 10 minutes a day, right? Always. It's it's as simple as that. You spend learning something new, and then you immediately apply it in this uh small safe space, like a sandbox environment. And if it works, you immediately apply it into the uh actual uh product, right? And then it doesn't make a humongous change. It's it's not uh uh an innovation to the scale of inventing a wheel, obviously. But this small changes suddenly uh in a matter of year transforming your team, transforming your product, and they transforming the entire organization in a lot of cases, and then everybody looks back and nobody can pinpoint a singular point in time where that transformation happened, it just happened over time. So uh I I love our our CTO always like there are no boring projects, there are never boring features to develop. There is never something boring unless you are boring, unless your approach is boring. Like I can make interest interest in any kind of of project you you give me, because I can always find a way to to build in something new, to try new approaches, to evaluate new technologies within that project that I can scale then into uh a multitude of other uh other work. And when when you have this mindset approach in the the innovative work, suddenly there is much more space for it to happen than than you think.

Peter: 27:30

Yep, I think that's uh that's a very good way of uh framing it. Uh we often one of the things I hate is when we see that innovation is a separate department. I think we did an episode on that ages ago. It's like the innovation department. No, no innovation happens anywhere else. It's like just just like the I think we're at the point where we're just about ready to be able to wrap this up for the for the session. It's been a fascinating conversation. We've covered a lot of different areas. So at this point, uh we normally like to ask everybody to provide like what's the main takeaway they would uh like our audience to take with them. Uh so uh Ivan, would you like to go first?

Ivan Gekht: 28:07

Yeah, I actually uh wrote it down for myself. And uh you uh you mentioned it multiple times uh about the language and framing, and and I think that I tend to forget how important finds in the right language and the right words and uh the right ways to present things uh can can really affect the the change. So so yeah, thank you. Thank you for that. Most welcome. Uh Dave.

Dave: 28:35

There's as you can probably tell from the questions that I've had coming in, there's it's been a really interesting conversation. I really appreciate it just for that sort of revisit of just how powerful that agile mindset can be and the agile approach can be for the right context. And sometimes we get worn down a little bit by situations where it's just it's it's difficult to get that moving. Having said that, the thing that the bit that I've written down is the theory of innovative problem solving because I want to drill into that a little bit more. As Peter was saying, innovation, and as you were describing, but innovation is not the big thing that happens over in the cool kids area. It's the thing that happens every day at your desk. And I'd love to, I'll be looking into that to look at some of those laws that were coming out about how to build innovation into the problem solving that we're doing. So I'll definitely be following up on that. I like it. I'm gonna be looking at the problem. Yeah, thanks for that. Uh inventive, theory of inventive problem solving. So there's a link to looking for tips to um theory of inventive problem solving.

Peter: 29:34

That that's definitely uh one we'll make sure we put that in the show notes too. I'll add it to my list of hey, I've got to go read up on that a little bit. Amusingly enough, I've got to give a uh an executive presentation next week to a bunch of executives. And the big topic of the conversation is exactly that. It's that the sales team wants predictability and they want people locked into dates, and the the rest of the organization is like, well, we're not gonna be able to do this the way that you're doing it. If you're fixing scope and fixing time, then the delivery isn't gonna happen. So I thought it was very uh your your framing was good for that, and I think I might borrow your uh your dinner plans uh because I think that'll work uh nicely for this particular audience. Uh and I'll I'll add it to some of the other examples I have prepared. Uh so thank you uh both for a fascinating and engaging conversation, and uh I hope uh everyone enjoyed it and uh we'll look forward to next time. Absolutely. Thank you, Peter.

Dave: 30:27

Ivan, thanks again. Thanks, Peter.

Peter: 30:29

You've been listening to Definitely Maybe Agile, the podcast where your hosts, Peter Madison and David Sharak, focus on the art and science of digital, agile, and DevOps at scale.