Sustainable Speed is Essential to Avoiding Tech Project Failure with Ivan Gekht

Have you ever heard the phrase, "If you are not moving fast, you are already behind"? The reality is, the average tech project takes 23% longer than planned. And in this industry, that kind of delay can cost you everything. In a market where 80% of new projects fail within the first year, It's clear that slow teams don't just lose, they get wiped out. So what's holding you back? Bureaucracy? Fear of sacrificing quality? Welcome back to Mastering Tech Growth, where we interview industry leaders to bring you actionable insights and inspiring stories. I'm your host, Mike, and today we are not just talking about speed as a nice-to-have. We are talking about it as your best defense in a complex tech landscape. Joining us today is Ivan Gekt, CEO of GetSoft, a custom software development powerhouse that's delivered complex solutions across the industry for over 20 years now. Ivan's background is as diverse as it is impressive, from aerospace engineering to agile software innovation. He's led transformative projects from both startups and billion-dollar enterprises. Ivan, it's a pleasure to have you on the show. Thank you for joining us today.

Thank you for having me over.

Thank you for joining us today. Again, it's going to be awesome. So Agile, value stream mapping, any type of project management for speed. It's a, it's a never ending battle. Let's say it like this. Before we jump into the topic itself, we have this question we ask every single guest in the spirit of the show. When I say mastering tech growth, What comes to mind?

Continuous education.

Okay, continuous education. So that's for the mastering bit, right?

Yeah, absolutely. And, you know, as to the tech growth, the majority of the organizations, even if they realize that or not, are technical organizations in these days. You know, digitalization, internet, it really changed things up. So you have to run your organization as a tech organization, even if you're your core business is in something else. Otherwise, you are not as scalable and you cannot move as fast as your competitors.

Okay, I love that. What if I rephrase this question and, and re-ask like this? If you can choose one factor, and it's only one, what would you choose for the scaling of tech?

You know what? It's ability to solve problems. And solve problems fast.

So, all right, so, so we still have intrinsically we have speed as, as, as a main thing for, for scaling. And then, and if we're choosing one from all the spectrum of things that influences scale, we're saying that ability to solve problems at speed is the one.

Yes.

Okay, I love that. All right, so, so why speed matters? Like, why, why is it important?

Yeah, we live in a complex world right now. Uh, you know, a few years back there was a very viral, uh, infographic, uh, how fast does it take to reach 1 million users? How fast did it took for the phone, for the train, for the car, for the airplane? And it was a matter of decades, right? And then if we look at, for example, Netflix in 1999, it took them about 3.5 years, I think, to reach 1 million users. ChatGPT, it took 5 days.

Yeah, it was like—

Threads on Instagram, it took less than an hour. So the scale of, you know, rapid market acquisition has significantly changed even in the past 100 years. So now you have to move fast and leverage your business. Otherwise you will be behind really, really fast.

Okay, so how does the speed affect the way teams approach challenges then? Like, like coming back to your point about problem solving, like here's a day, here's a big, here's a big challenge. You have 2 days. Like, how does that really change how the team approach these challenges?

You know, it's more than just the team. It's how the entire business approach challenges. Right now, you have to think about it holistically throughout the entire value stream of your business, because just the tech or just the development team cannot really solve everything for you. Right.

Okay. I mean, we'll be touching on value stream mapping a little bit later in the conversation. So So what we're saying, if you zoom into an area of a business or, you know, a department of a business, that's effectively a mistake. Like, you have to zoom out and look at the whole value stream map of how the business produces the value to the market and zoom out and look at everything to really gain speed. It's like, why would I care to zoom out? Like, what's the value of that?

Because the speed, like, we need to define speed, okay, right, uh, in, in this particular case, because time to market, uh, ideally should be measured from the moment that the problem appeared or the idea appeared to the moment that when your users can actually, uh, benefit from, from, uh, that problem being solved or that idea being implemented. And these steps include much more than just, uh, development, right? So if you look, for example, if your development team took 2 days and developed a perfect solution, and then your legal department took 2 months to update the licensing agreement, then in all the reality, your users will be able to use it in 2 months and 2 days instead of just 2 days, right? So that's why we need to look at the entire process from when the idea appeared to how it was how it's going to be financed, how it's going to be implemented, how it's going to be marketed, how it's going to be sold, how it's going to be supported by legal, by other departments.

I love that. That's a very good, that's a very good example, and it actually comes close, close, close to heart when it comes to, okay, well, we have speed over here, you know, development can be done in a couple of days, But, you know, some other departments, you know, they'll take months, which removes the whole point of you being fast at your own local area. So coming to that, can we say that then these areas are not agile enough? And agile being speed definition rather than, you know, agile frameworks. It's like why someone would take 2 months and development would take 2 days. Well, like, that's a big difference, right?

Yeah, absolutely. And, uh, it is true that Agile, uh, was contemplated as a software development methodology for so long, uh, that a lot of departments never really looked into it. And they can benefit from it. Look at the sales, look at marketing. They continuously work with a complex problem, right? They cannot really predict the outcomes of their exact actions. And that's where the complexity comes from. So they need to leverage different kind of approaches than traditional, conventional, you know, planning and predictive methods to define what we need to do, what we're going to have, and then go and execute on it.

So if I'm listening and I'm like sitting maybe in like legal or something like that, or maybe in, you know, commercial teams and I'm like, ah, I know what you guys saying, you know, we do things upside down and takes so long. Like what's a tactical approach towards the teams which don't really leverage agile in the sense of understanding how to do it? Maybe they say they do agile, but I mean, realistically speaking, I've seen a lot of people using this word as just a buzzword. Yeah, yeah, we do agile. It's like, okay, well, how you do it? Explain to me how it actually works. You know, what's the process? You know, what data are you capturing? How you sort of look at? And people just go like, I don't know, which means you're not really doing Agile, right? So someone listening and going like, I think we could do better, what would be like a takeaway they can do today of just looking at the teams and going like, are we actually Agile in the sense of speed?

Agile is more than just speed, you know, and the whole idea of Agile is about working in complexity. So if you look at the thing that's called Kinnivan framework, uh, that was developed by the, uh, one of the guys in the IBM, uh, a couple of decades ago. So, uh, they look at different, uh, complexity of the systems from like clear to complicated to complex to chaotic to just, uh, undefined, right? So agile is there to help you solve issues in the complex environment. So if you are in a clear, uh, situation, right, you know exactly what needs to be done, you know exactly how to do it, and the outcomes are predictable, you don't need Agile, right? You just need proper deadlines, prioritization, and just move faster, and that's it. But if you work in complexity That's where the agile comes from. And, you know, there is no single easy tool to start being agile. It's a mind shift. It's a mindset shift that needs to happen to really be able to be agile.

Okay. I love that, actually. So we think we're having a complex process of getting things done. So this is where agile comes in and it goes like, okay, How do we look into this to make it less complex? Like, like, what's the step one? Like, are we, you know, doing the value stream mapping? It's like, what would be the step one to trying to, you know, inject clarity into that complexity?

You know, uh, it's actually interesting. Agile is not to change the complexity, it's, it's, uh, to deal with complexity. Okay, so if you actually can, uh, start and, uh, clarify the parts of the system and make it less and less, uh, and, and less complicated and make it clear, it's, it's more on the right side of things. Because so, for example, building out the plane, it's not complex, but it is complicated, right? There are a lot of moving parts there, a lot of things that go, uh, into that, but it's all is predictable by the, uh You know, physical laws and stuff like that. So, but if you encounter complexity, right, you just approach it step by step, right? You go through the scientific method. So you have a hypothesis, an educated guess, right? You run an experiment to validate or reject it. You observe the results and then you adjust and adapt based on what you saw and what you measure.

All right, so we raise a hypothesis about how we could do things better. We run some experiment, which means executing of that hypothesis. We look at the numbers and we just iterate. And that's effectively what helps us to, to deal with the, with the complexity, right?

Yeah.

Okay. And that, by doing this, we can then say that we're actually doing Agile?

Pretty much.

Very much, right?

If, if you, if you really run a scientific approach and you run it continuously and you apply it to both the product that you develop and the process that you're executing. This is the definition of a true agile.

Okay. I think that needs to land to the listeners and to the market in general, because I've seen people taking agile as a keyword and just simply going like, you know, we're doing whatever comes to us in a very reactive mode and we always try to be as fast as we can. Aka we're doing Agile, which is really not true, right? And it's like, I've seen good talks about this, and it's important to do Agile in the right way. And I want to read this. So, so according to McKinsey, companies that adopt Agile practices see up to 60% improvement in speed to market and project success rates, which can be a game changer in, you know, in any sort of environment, in any business. And that goes— it doesn't mean its development, right? It can be compliance situations, it can be sales situations, it can be marketing situations. By really understanding how to do Agile, then you can expect these, you know, good numbers and good values to come out, come out. But if you think you're doing Agile and it doesn't work, you're probably not really doing Agile, right? So, um, absolutely. Uh, sorry about—

yep, yeah, I just wanted to add, and, and yet the, the same studies show that during the Agile transformation They expect the turnover is about 50% of the people in the organization.

People just leave because they don't like Agile.

People either leave or they have to be replaced by somebody because Agile implies that people who are doing it are motivated professionals with a growth mindset. And a lot of people have fixed mindset and they're just not willing to make the change.

Yeah, that's— yeah, I get that. Change in general is such an interesting topic, like change management within big organizations. When you fundamentally looking to have a mind shift or mindset change, which you mentioned about Agile, some take it on as a growth exercise and, you know, they become your champions of that change. And then some just, just don't accept it and the environment becomes so difficult for these people, then they either leave by themselves or they start performing so poorly that they get asked to leave. I mean, we're sort of side-drifting, but it's a very interesting observation you can see when you have big changes happening. Okay, so I think we established speed is important. Agile can give you that speed if you do that in the right way. So, If speed is crucial, are we sacrificing quality if we're actually moving faster?

That's a decision that you have to make, uh, because you don't necessarily have to sacrifice quality to move fast. Uh, you need to sacrifice, uh, comfort. You need to sacrifice, uh, expertise to a point, right? So you need to start doing things differently. Because if you, if you come with the mindset of, of, hey, we've been doing that for, for 20 years, right, why change now? Then speeding the process up will definitely affect quality. But if you start doing things differently, then speeding up can actually lead to higher quality.

It's a very interesting positioning. I always hear that for us to move faster, we need to jump over some, you know, some of the lanes which exist in, you know, agile, like Scrum or Kanban, whatever we're doing. We have swim lanes, you know, through the process. And people will always look at the quality and goes like, we could just not do QA and, you know, we'll release things faster. So there's always like this trade-off which made against the quality, but what we're saying, like, you don't have to— like, you can actually gain speed, remain with the same quality assurance processes. But how, like, how, like, how tactically you would approach this?

So, uh, there are a couple of, of, of phrases that I, I really love, is, is slow is smooth and smooth is fast, right? Uh, that's kind of a little bit counterintuitive And the second one is— I don't have the exact numbers, but this just comes from experience. The majority of the time is wasted not on doing the work the wrong way, but rather on doing the wrong work. So you lose more time doing the things that nobody needs than actually, uh, you know, lose in inefficiencies.

Okay, so we're saying basically projects are ineffective. Like, when they look at work, they talk about efficiency, like, how can we do this faster? But they oversee the effectiveness of raising the question, should we be doing this in the first place?

Yes, yes.

Okay, I think that, yeah, that, that's— yeah, okay. So it becomes like prioritization exercise then, like when you do your planning.

Absolutely. That's why one of these, for example, if we take Scrum, right, one of the most important elements in Scrum is a product backlog, which should be prioritized by value, right? So you should be working on the most valuable items first, right? And that's where it comes from.

So I want to challenge this from a perspective of my own observations, is that You get the backlog and you get someone managing the backlog. They do the priorities, but they very often do those priorities by someone, you know, above them from the business or commercial teams telling them what is the most important thing to do. And it becomes one of these, you know, things where I'm prioritizing how I'm being told what is the most valuable. But then that definition of the values is very really not the real value because, you know, the commercial teams, they, they look at things like, you know, can we sell this? You know, can we, you know, open some partnerships? We need this feature to close this deal and things like that, which might be defined as value, right? But then at the same time, it's such a volatile environment when it comes to these. And then you start a project which has, you know, was defined as valuable. You do it a little bit, maybe 1 month or 3 months, and then priority changes and you never finish this. Which means that the whole, like, months you just did that, it just goes to waste, and it's just the work which shouldn't have been done in the first place. How do you, like, how do you take a step one to fix this?

So it's, it's an interesting, uh, question that you're raising, because if we look at the Scrum Guide, uh, it, it explicitly says that the product owner, and, uh, should be the person responsible for prioritization and accountable and should be trusted by the entire organization and should be empowered by the entire organization to do that. So, uh, step number one is that in, in the case that you described, it's the wrong person, right? So the organization selected the wrong person to be the product owner. It should be somebody else who actually can make that decision, right?

So, so we're saying that the product owner should have enough— let's define it as power— within the business to basically challenge commercial teams and go like, no, no, no, like, what you're saying over here is actually wrong. I know this project will not, you know, get finished. I know it's gonna get pivoted to something else because I see something you know, else happening in the backlog. Effectively, they shouldn't be taking the advice or guidance from commercials. They should be part of the commercials and guiding the commercials towards the right backlog. Is that like a right assessment?

Uh, more or less. More or less. At least they should be trusted by the commercial to make these decisions. And if commercial department doesn't feel like, uh, product owner knows the customer better, or at least at the same level as they do, then again, something's wrong with the product owner.

Okay, that's a very strong positioning. I'm just running some businesses I've worked through my head, and I'm like, I never seen that picture before, like where, you know, they sit at the same level as commercials. It's always like a top-down where commercial tells the product owner like, this is coming, get ready.

So Product Owner needs to be skillful enough to work with a variety of stakeholders, right? And different stakeholders very, very often have different priorities, and sometimes they pull in the project into completely different directions. So a good Product Owner should be able to navigate these challenges. But, but again, in the end, the decision should be on the side of the Product Owner.

Okay, you're saying this, Ivan, and I'm thinking that we're not giving enough credit to product owners. I mean, that seems like a, like, like a very big role because you have to talk commercials, you have to talk product, you have to talk development, you have to talk quality assurance. There's such a, you know, um, like a role which sits in between all of these other roles, right? And you need to have a little bit of expertise in any of those areas then.

Yeah, absolutely. And, and that's, uh, a lot of organizations made the mistake by, uh, taking, uh, for example, they were running some traditional waterfall process, right? So they have the project manager and, and people feeling, uh, in different roles, and they just, okay, now we are agile, and they just renamed the roles. So, okay, you were project manager, okay, now you're a product owner. But you do the same job, right? So you do all the same things, and, and this is inherently wrong because Agile is a different approach and it requires different, uh, roles and different set of mindsets and different interaction than, than a traditional project.

Okay, should we have some type of like, um, Agile advocates within the businesses who can always remind us of the right way of doing Agile?

So that's supposed to be agile coaches, okay? Right. So there is a role of agile coach, and there were a lot of agile coaches going around. And over the past, uh, year, I think there were a lot of, uh, cutbacks, and a lot of people lost their jobs, uh, you know, organizations scaling down, uh, from like having 8 agile coaches to like maybe having 1 or just having none. And it's not just an organizational issue, it's an agile community issue too. So we can talk about that more if you want.

It's interesting. I mean, the market is definitely not in a great place. I mean, once, once we enter this big layoff season, which happened, I think, like what, like a year and a half now where we had Meta, laying off a lot of people, AWS laying off a lot of people, you know, Google, all the apex tech companies laying off a lot of people. The whole market went in into this like hiring freeze and really not sure what's going on. And I don't think it's even recovered. Like if you look at the job listings and you talk with the recruitment people, it's still, you know, that feeling of uncertainty exists. So it makes sense that these roles are getting cut, but it raises this question like, why exactly these roles? Are businesses looking at the Agile coaches and going, we don't think you are the core role for this business to keep, you know, moving or maintaining or growing, and that's why we're cutting this? Is that like— because that's not a right approach, right? Because that's the literally the ultimate role responsible for the smoothness of the whole processes.

That's the, the whole point, you know. I think, uh, at Agile became, became very popular. And when Agile became very popular, it became kind of a social movement, right? It— the focus went from the, the core principles and the goals of Agile to like making it fun, making it, uh, something that it actually isn't, right? So, and, and the, the weight of that Additions practically crumbled the process, right? So we start talking more about beanbags and, uh, you know, uh, booths and, and, and this like, uh, zero, uh, sense pods in, in the offices than, uh, actually producing the value. And Agile is about producing the value when you encounter complexity. Right. So, and the agile coach role, right, it's about ensuring that the entire process works to bring value. So if the organization doesn't see value from it, right, it started to cost more, it became less, uh, you know, producing, etc., etc. They don't see the value in, in people who are running it.

Yeah, but then you can raise a question, you know, does this process actually work for us? But we know agile, if applied well, works for any industry and literally in any product development. I mean, it's any industry, any department, any function within the business. Like, we know it works. So if you're hiring and putting in a team who's responsible to running your business processes, and then ultimately their responsibility is to make sure the processes are effective and efficient, and then you're going like I think we're going to be laying you off. So you're effectively just leaving all your business processes unsupervised. There's no like key person looking if they're running smoothly. And then you're like, I'm not sure why the business is struggling. That's such a like counterintuitive layoff in my view.

Well, it's, uh, it's, it's a balance. You, and, and it's not just, uh, like the word responsible, it's actually the word accountable. Right, so you, you need to keep people accountable for fulfilling their, uh, roles within the organization. So if they don't, you got to make a change. If they do, you have to empower them and, and let them do their, their work.

Okay, I love that. All right, let's talk about value stream mapping, Iman. So I feel like value stream mapping is finding its way into Agile. I never— like, from the books I read and the process I know, it was never an agile tool such as, you know, like Scrum is or Kanban is. But I feel like it's finding its way into this, uh, you know, capability toolset with agile. Not sure what your opinion is, but for the listeners who don't know what the value stream mapping— can you give us a quick definition in your mind? What is the value stream mapping?

It's literally what it says. It's taking, you know, pen and paper and drawing out steps of your entire value creation process, not just within the particular department, but throughout the organization. Like, what steps do we need to do from the moment customer picks up the phone and calls us or walks into the doors of our business all the way to the end when the customer paid, got the value and left. So if we take a simple example of, let's say, a coffee shop, right? So your value stream would be like customer walks in, customer comes to the counter, customer makes an order of a tall latte, then the cashier takes the money, the order goes into the system, the barista makes the coffee, The barista puts the coffee on the counter and calls the customer name. Customer picks up the coffee and walks out of the door. That's your entire value stream.

Hmm. And then so we can do this in a very zoomed out view. So we can do a value stream mapping session, which is literally with the whole stakeholders of the business. We can have commercial team in that session, developers, QAs, like everybody, to understand a very, very zoomed-out view. But at the same time, we can zoom in, isn't it? Like, we can go in and have our own localized value stream mapping, right? As a team, we can go like, okay, how do we produce value? Who's our client? Okay, it's going to be our PO, right? He's our client. He's going to tell us what we need to be building.

Well, actually, actually, the, the end user is your client.

The end user is always—

it's always you. Your client is always somebody who pays, who brings money into the business. Even if we do like a zoomed-in VSM, if even if you look in, for example, at the Scrum development team. Yeah. They have to think about the end user.

So any time you're doing VSM, you're thinking about who's going to get that value at the end, which is always the customer, right?

Yes.

Okay, I love that. So for the listeners, yeah, I want to read this. So the Harvard Business Review reports that organizations using value stream mapping can identify bottlenecks that lead to 30% improvements in operational efficiency, which leads me to the question, how does the value stream mapping surface bottlenecks?

Transparency and measurement, right? So two tools that are cornerstone of agile, right? It's, you In order to be able to deal with an issue, the issue must be visible. Uh, there was a quote, uh, the— in, uh, EOS, Entrepreneurial Operating System, that, uh, problems are, are like mushrooms, right? They, uh, grow and multiply in the dark and wet environment, and they, uh, don't under the bright sun, right? So, uh, that's kind of the, the approach, right? So when you draw out the entire value stream and you put in measurements in place, you can look at it and see like, okay, so we are moving from here to here in like 30 seconds, from here to here in like 2 minutes, and from here to here in 2 months. What happens right here, right? Why it's taken us 2 months, right? So you can go in and start looking into the ways to improve the efficiency.

Okay. So we're talking about when you look at the value stream mapping, you have the stages. So let's say to our listeners, who's, you know, most likely a lot more tech, we're going to have a stage where maybe we're creating a backlog or something like that, and it takes us, uh, you know, lead time is like 2 weeks, and, and mostly we're just waiting for information to come from like commercial teams. So, so that's the lead time. And then we have a process time, which actually, you know, is the creating the stories. So that's our process time. So once you have these measurements and you go through the whole value stream, you're gonna see where you have the most lead time, you're gonna see where you have the most process time, and you can zoom into these and ask the questions like why these are bottlenecks, like why we have these numbers so high over here. Is that, is that the right assessment, right?

Yeah, that's, that's accurate. And moreover, like what we saw, uh, in some cases is, is that Yeah, you, you can have a, a huge gap. You start looking in, uh, into it, and then you realize that, for example, there is a sign-off process. So there is one particular person in the organization who has to sign off, for example, on, on all— every user story, right? Give, give a final visa that, yeah, I approve, right? And, and that person goes on vacation for 2 weeks, and the entire process just collapses.

Yeah. Okay. Yeah, I love that. Single point of failure, isn't it? It's like, yeah, I see over and over. I've seen this in small businesses and big businesses and it's always like, why is that happening? And the only explanation I have is that someone comes in, whatever their accountability and responsibility profile is, they are hyperperformer, so they outwork everybody. And they're performing so well that they just, as a big sun, they just, you know, just the gravitational pull of these like tasks just come to them and they're knocking them down, knocking them down because, you know, because they're high performers and eventually people around them just disappear because they are capable to managing everything. And after some time, they literally become the only person doing all of this and just become single point of failure. Because the business don't tend to manage that as a risk. They just go like, oh, we have this person, he's capable of doing all of these things, let's just give to him. That's the only explanation I have.

But that happens and that happens in a lot of businesses. And addressing the bus factor as a risk is incredibly important.

I do agree, because then they decide to leave and they go like, oh, it's been fun, guys. You know, it's been 3 years now. I'm going to go look for some other roles and then and suddenly like the whole value chain, the whole value stream, yep, gets a much, much bigger lead time because now you need new people. They, they're definitely not going to be as good because they're not going to have the local knowledge which took years to develop. By default, they're going to be slower, uh, you know, they'll need knowledge transfer and things like that. And the whole lead time around that area just goes through the roof. It is definitely a huge risk. Okay, so we defined a little bit of the lead time. So For the listeners who don't know this but go like, oh my God, that sounds amazing. I know we have bottlenecks. I just don't know how to surface them. What is a tactical advice? What they could do like next week? Like, is it difficult to run this session? How one would run the value stream mapping session?

You know what I like? Like any meeting, this would require some kind of facilitation, right? So I would I would suggest to start with simple things and, you know, find the webinar on how to run an effective meeting, right? So define who needs to be there, define who in what roles, define the agenda, define the goal of the meeting first and foremost, right? Make sure that everybody who participates understands the goal and then just do it. Just start doing it because it might not be a perfect value stream at first, and you might realize, you know, 2 weeks down the road, hey, we forgot something here. And that's okay because you can always go back and update it and refine it. And that's okay in agile process. We continuously refine what we are doing. We continuously learning on the mistakes that we've made and adapt either the product or the process to not repeat these mistakes in the future. But once you start doing it, it will start raising the issues. Once it starts raising the issues, you can, uh, get a taste for small wins, right? So you fix something here, you fix something here, and situation got better a little bit, right? And we, we don't strive for perfection. We strive for continuous improvement here. And once we achieve that, in a year, you're going to turn back, you're going to look at your organization, and you're going to be like, I would never even dream of the change that happened over the past year, even though in the moment every single adjustment seems insignificant.

Yeah, I actually love that very much. The compounding effect of small wins. Is a highly, highly underestimated approach because you always look at these big, you know, big influential initiatives to change a lot because it just feels like that's going to be the game changer. But if you constantly look and compound these small wins, low-hanging fruits, you need time. But once you reflect it back, you're absolutely right. It's like, okay, well, we we made a lot of changes which are positive over here, which I want to ask this. So we did the value stream mapping, so we recognize some of our bottleneck. How do we actually now go and, and create initiatives, projects, uh, to actually get that fixed? Like, is that as simple as project management? So meaning that after value stream mapping, it just like someone takes on and goes do it?

So, uh, there are multiple ways to approach that. If, if you— if we talk about the agile way, right, uh, we have, uh, three major constraints. Uh, we have a goal, right, something that we need achieved, or the scope of what we need to do. We have time, um, and we have resources. Right, so how much money do we have to spend, right? So if we look at the, uh, that's, that's what's called Iron Triangle, right? So, uh, if we talk about Agile Iron Triangle, uh, it, it look reversed. So we fix, uh, the time and the, uh, and the resources. So we say, okay, yes, we have 2 weeks and we have, let's say, $10,000. What is the best we can do to improve a particular metric or solve a particular problem within these constraints? In traditional project management, you have like, okay, we need to improve this metric by 15%. How much time and money do we need to achieve that? So the, the whole mindset is, is reversed in this case. Right, so you no longer have this unlimited funding and unlimited time. Okay, but you do have a flexible scope, and that's actually getting back to the very, very beginning. That's why McKinsey's study showed that, uh, I think combined it's, uh, 79% of the projects or something like that goes either on, uh, over on budget or on time or both. It's, it's because we're trying to predict, uh, a very complex scope with, with a, a 100% degree of certainty, and it's just impossible. So if we reverse this conversation, uh, we, we guarantee that we will not go over the time, we will not go over the budget, and we're going to do the best we can to solve as much of the problem that we see as possible. And that's, that's what agile actually is in this scenario.

Now, when you're saying this, Ivan, I'm like flashbacks in my mind, and it's always like we, we make that push. So I just want to give the story. So, you know, business, here's a project, we need this done. Commercial sold something, get it done. And then development looks at this and goes like, 'Not possible, not enough time.' And the business goes, 'Scope doesn't change, tell us what you need.' And, and that's still an Agile environment. So how, like, how do we make— how do you fix this? Because I've seen this so many times, it's, it's, it's insane. The scope comes first because it's a top-down, you know, approach. So the Whoever sits at the apex of the business, which is usually like sales and commercial teams, they set the scope because either they sold it or they're trying to sell it, or they have some predictions of, you know, a future set which will bring some type of revenue. So they set that scope and then it goes down to actual execution of scope. People who actually will deliver that look at it and go like, we're never going to make that in like 3 months, right? We can hire more people, which means, you know, the cost has some type of, um, lock-in as well. And then the question becomes like, okay, what do you need? Like, you can hire more people, but what else? Like, what else do you need? We still need to hit that scope. So it always feels like it's that conversation. But what you're saying is it should be upside down. Yeah, but how do you talk to commercials like upside down? Like, I'm just trying to feel like Is that PO?

Yeah, so, uh, it's, it's, uh, it's, it's an interesting, uh, conversation here, uh, you know that Christopher Columbus went to, to India, right? When, when he discovered, uh, America. Yeah. So, so this is kind of what happens in the complex world. So, uh, he got the budget He got some time to do that from the King of Spain, right, I think, and he discovered the wrong thing. It was for good in the end, but so when we approach the complex problem, we witness project where the top-down management would give the requirements and the scope, like, this is what we need. And then we go to the actual end users and we sit down with them and we go through their process and we discuss what they do, how they do it, and what do they actually need. And the difference can be like 80% of the requirements. They don't need that stuff, but they need this stuff. And, and that would really help them. So The conversation should be, uh, about, again, what problem are we trying to solve and what goal are we trying to achieve, not about what exact steps do we need to perform or exact features we need to implement to get there. Because you, in Agile, you basically rely on a complex system which is a team of diverse individuals with a different skill set, with the wide range of knowledge, because we continuously say like T-shaped specialists, like the agile team should be T-shaped. What's a T-shaped specialist? It's, it's what's called a polymath or a Renaissance man. It's somebody who have a deep knowledge in one area and maybe not so deep but very wide area of knowledge in other areas. So they can leverage that, uh, knowledge and that understanding of more than one area of expertise to find solutions to problems that nobody else would think about. And then you have safe environment and constructive criticism within the team, and that actually helps build up. Like one person said something, another person added something, and then in that dialogue, in, in sometimes even in, in a small fight The truth is born with a much better solution than anybody could think of on their own, and that solution might be much faster and much cheaper to implement than what you originally planned for. And that's what helps, uh, you achieve the goal while still staying on the, uh, budget and timeline, and yet not implementing the exact scope that that was given to you.

Okay, so, so if we have a cost locked in, which is our headcount, people who work on a project, they get salary, that's our cost. We get a scope, we looked at it, and we just go, well, how, how much time do we actually have? Like, what, what's the, what's the deadline? What we're trying to do here? Oh, we're trying to hit this for Christmas because we're gonna run a Christmas campaign 2 weeks out or something like that. Okay, you have 3 months. The cost is the team's effectively salaries. We have a cost and then we basically go like, okay, what we can do in this time is that much. And we just remove some elements from a scope. That's the way we should be thinking about the Agile Triangle.

Yeah, absolutely.

Okay.

And then again, it doesn't really prevent somebody from commercial, for example, team is saying like, okay, if that's everything you can give me within that time frame, then I'm not ready to spend that amount of money.

Yeah.

And that's okay because, because that's an actual conversation now happening. So somebody who is a sponsor in this particular case, somebody who is investing the money needs to be happy with the return on the investment. So You have a lot of checks and balances in place to do that.

Yeah. Okay. I love that. I want to read this as well. According to the Project Management Institute, agile teams that prioritize balancing time, cost, and scope, which is the, which is the Iron Triangle, reports 30% higher success rates than traditional teams, indicating the importance of structured framework approach. So effectively what we're saying, don't just take the scope given by commercial teams, you know, get— take your time from finger in the air and go like, I think we can make it in 2 months, and then be one of those teams which impacts the statistics of always not coming on time, underestimating by 60%, 80% or 30%. You actually reverse the conversation going like How much time do we have? 4 weeks. Okay, this is what we can do in 4 weeks from all that scope you're giving to us and allow commercial teams to actually decide if they want to chase this or not.

Okay. So one thing that I would add here for the consideration is Pareto rule or Pareto principle.

Yeah.

So, so it can be applied in a variety of ways, but if you think about it, About 20% of the features in any application actually bring about 80% of the value. So that's just Pareto principle. So if you focus on delivering this 20% that delivers 80% of the value, in the majority of the cases you will be successful and, and people will be happy that, okay, we spent that amount of money and we got this 80% of value, even if it was just 20% of the features and they didn't get 80%, uh, of the rest, and yet they still happy. That's why Agile, for example, Scrum framework, uh, as a tool there, or disciplined Agile or whatever you take, will tell you to prioritize the highest value items first because this is the driver. And then you give the control to whomever is a sponsor to make decisions about how their money is being spent. So let's say, uh, I gave you $100,000 and 3 months, and you delivered me, uh, and you couldn't deliver me 100% of the scope. That happens, right? But you delivered me 20% that was the most valuable, and you delivered to me another 30% that, that were less valuable. So I got about half of the features and I got about 90% of the value out of the project. So now you can come to me and say like, okay, give me another 50 and I'm gonna finish it up and give you the rest. Or you don't. If you don't care about this low value features, don't give me that 50. And, and that's okay, right? So, so now I'm in control And I have a working product every sprint that I can take to the market and I can say stop, right? This is enough. And you know, in— it's almost always about not making it perfect, it's about making it enough to hit the market and get the value. That's where you get the speed.

I love the Pareto principle. Um, I use it Well, pretty much everywhere. It is more difficult than it sounds because the difficulty it actually is to identifying that one, that's 20%. Like, you have complex systems which we talked about, and there's always a lot of complexity in tech. The, the bigger the product, the more complexity you're gonna have. So sometimes— not sometimes, actually quite often— it's, it's, it's quite hard to identify that 20 you need to you know, dig deeper and understand, do like some spikes around that, you know, just to get some more information. But you're right.

Yeah, I was watching the podcast with one of the founders of Netflix, and I love the example that he gave. It was the, the idea worth nothing until it's validated. So, so if we talk about being truly agile in the matter, Very, very often you don't need to put all the work to validate the idea. So yes, we work with the complexity. Yes, we work with a lot of unpredictability happening around us. But you can run small, quick experiments to validate your ideas and to help you define what is the most valuable. And the ideas can be as simple as taking a piece of paper and going out on the street and finding whomever is your consumer and just asking a question like, hey, if we do this, would you use it? Do you really need it? How valuable for you, uh, would it be? And by just asking these questions, you can get the data that can help you validate the idea and help you to actually do this prioritization. So on one hand, you need to empathize with the user, you need to be able to put yourself into your shoes, into their shoes, and you need to know what they need and why they need it. But on the other hand, you can always just pick up a phone and actually ask.

I love that. And to our dear listeners, If you scroll to our library, we actually had a couple of episodes where we talk very tactically about idea validation phase. And there's some great tips from surveys to actually putting meetings to actually making these calls and to actually these guerrilla tactics where you just walk in an area where your potential customers are and you go like, what's up? Tell me this and that. And statistically speaking, which I was surprised, Apparently you only need just 5 to 8 people to validate a hypothesis around the idea. My understanding, which is pure, you know, statistics and math, is that you need a sample of 30 to make sure that hypothesis you're pulling out from this is actually statistically viable. But apparently there's a— I can't remember the name, but some big product person who has many books who said After 5 to 8 people, if you're doing like product interviews to validate idea, it's diminishing returns. The same will be said to you. So here you go. So it's actually not that difficult. And I can tell you an example of what I did after that episode. I walked into London's— we have— there's a company called— I forgot the name— who basically rents offices to anybody. You can buy like a subscription and go, you know, to the offices to do work. I think it's like Workday or something. No, it's not Workday. WeWork. Here you go, WeWork. So yeah, so I bought like a trial and I went to the biggest of London offices and there's plenty of startups over there, right? Because, well, they don't have offices, they rent offices to meet, you know, face to face and things like that. So I just walked in there and I was like, Are you listening to any of the tech podcasts? Why are you listening? What topics are you looking to explore? Which gave me good ideas about where we want to take the show, right? So it's a very—

love it. Yeah.

So it's a very simple way of validating your ideas. And surveys as well is not actually not that expensive. You know, you can run surveys. There's companies who give those surveys to people who want to make money by filling the surveys, and they, you know, quite honest about the questions. So you can get as well quite cheaply some type of understanding of what your idea is about. Okay, so that was great. Um, I want to take us into this almost like a must-have, I want to say like this, which is the user story. So just be a little bit more tactical about Agile. I'm sure everybody listening went, oh my God, user stories, I deal with that every single day. But at the same time, I've seen user stories which is literally just a title. Give me this, that's it. And I've seen some user stories as well, very properly written user stories with acceptance criteria and giving you context about the outcome it's looking and stuff like that. Can you tell us, Ivan, what is a, a terrible user story? What is the most common user story you've seen as well? And what is an actual good user story?

Uh, so I think that, uh, the most important, uh, approach to the user stories has to be around, uh, understanding that your personal opinion doesn't matter. It's not about you, it's about the end user. So a good user story will be written from a perspective of, of a user by a person who understands and knows that user, or at least who went and asked, asked that user. And the worst user stories that I've seen were written by the people who, who, who thought they knew the user, but they actually didn't. And that actually can drive you your project into, into the weeds because, uh, you waste your time implementing things that nobody actually cares about.

Okay. What about technical user stories? What, what if I'm like a technical architect? My opinion matters, right? And it's my opinion, it's not going to be the customer. I'm going to tell you how to build this API endpoint or whatnot. Do— are we saying then that you have different type of user stories?

You know, from, from my perspective, user story is just a tool. And like any tool, it can be used in a variety of ways. I love the saying that when you have a hammer in your head and in your hand, everything starts looking like a nail. And I think user stories, to a point, is, is overused, uh, in, uh, we need to have all the user stories and like user stories is, is the value that we are generating. It's not. So, uh, user story have to have enough information for your particular team to do the job well, and they will be different, uh, between different teams. So you can have a brand new team, nobody knows each other, nobody actually knows the user, and their user stories should be different from the user stories of a team who's been on the project for 2 years and they know the customer really, really well, and they can actually bring more value if you give them less instruction. Same way with the, uh, architect, right? So if you have a proper DoD in place and your team is capable of following the definition of done for the project, uh, you don't need an extensive user story for every technical decision that you are making.

So it almost becomes— it's not a user story, it's just a task. So, you know, I'm Like, I'm giving you some guidance at the technical architect level of what is the best technical solution to implement this so we, we don't have, you know, technical debt and we can manage that code better. But that's not a user story, that's an actual instructional guide. The user story itself, it has to have a customer in mind and it needs to really define what is the outcome for the customer with that then it, then it's a user story. Is that like a right assessment?

Yeah. And, and again, if you look at Scrum, for example, uh, there is no defined role for a technical architect. Moreover, they have a, a concept of emerging architecture. So the architecture in the project emerges as, as, as the project emerges. So if you write code well, if you have good baseline principles, uh, that you follow when writing the code, you're actually creating a good foundation to make the changes when needed to adjust and adapt to the changing environment of your application. And then you continuously refine, you can do the code refactoring, you can do changes whenever you see fit.

So are we saying that Scrum teams don't have— should not have like a technical architect baked into the team.

So it's a, it's a very complex question.

Okay.

The role has to be fulfilled. So you cannot run the project if nobody is making that decision, but the team is accountable for that decision to be made, not a particular person. So in Scrum, you rely on the team to be able to work as a team to make that decision. And in some cases, it can be a particular person. For example, hey, you know what, I have this great experience. I, I know this area, uh, very, very well. And, you know, I did the project, you know, 2 years ago that had the same issue. We used this, and everybody's going looking, okay, we can try that. That can happen, right? But the moment you start, uh, building out a traditional top-down team, you, you start really affecting some of the processes. Okay, so you need to be very mindful. And, and, uh, again, I don't want to say that like, let your team do whatever. Uh, so if we look at, for example, uh Agile maturity concept, uh, they have 5 stages of team maturity levels, and the first stage is actually top-down approach. You tell, they do. And you step by step, you elevate the team to get to a point where they can make all these decisions and maybe consult you or maybe just keep you informed. But that's a road that, that needs to be walked before you, you get there.

Okay, so effectively we're saying you absolutely have the role of technical architect if you're dealing with complex systems, but the team needs to be at the level to make the decisions and then effectively go, here's what we're thinking, and sort of get like a sign-off from, from TA, uh, or something like that, and then just move on with the work. But it's not like top-down, it's more like the whole team.

So that's the whole point of Agile. So when you work with the complexity, uh, the theory of complexity says that you need a system of the same complexity or higher to be able to deal with the complexity. One person is not complex system enough to be able to do that. So the moment you put one person who makes all the decisions in a certain area, you create an inherent risk of that person failing to do that, to do so.

Mm-hmm.

Just because of the complexity. There was a great example that Airbus A320, I think airplane has about 150,000 different parts in it. And average mobile application has about the same. So the complexity of, of your regular application is almost the same in, in the number of parts as, as a whole freaking airplane. So, so when you think about that, now you put one person, one singular person who have to have all of that in mind to make that decision. Is that viable? Not always. So that's why, uh, in, in a lot of cases, again, technical architect defines the core principles that the team needs to operate with, so-called definition of done, right? So our product has to comply to this to be considered done. But how you get there you actually leave to the team because you need that emergent knowledge and emergent decisions come up through the teamwork process to be able to actually deal with the complexity.

I love that. It's a very good one. Gave me some ideas as well of examples of where I've seen that actually being done otherwise. And then you can question if it's actually agile or not, right? Okay, sorry, my mind just left my body for a second there. Um, we drifted a little bit from user stories, and I want to read this one, which, um, hopefully resonates. So the Scrum Alliance notes that well-defined user stories can boost productivity up to 25% as they help teams stay focused on specific user needs. So I think that's what you were meant by saying, that this— does the user story has to be has to keep the customer in mind when it's asking for things to be done. Can we, can we make a customer to be not the paying one? Can we, can we have a user story and say that the user needs which are being kept in mind with this story is someone else's, like developer needs, technical architect needs, PO needs, or it's always the customer?

That's, that's a great question. Uh, it highly depends on how you look at these things, because as a business owner, my response to you would be like, yes, and then you can also go and ask these people for your salary. So don't come to me to get your salary if you want to ask— if you want to work on fulfilling their needs. So, okay, uh, that's kind of from a business perspective. It's a question of why. It's, I'm not doing a project for the developer to be comfortable. I'm doing the project for the user to be comfortable, even if it means some comfort for the developer. Uh, but from, from another perspective, can you use this kind of user stories to define some limitations and approaches and, and for example, define, hey, this feature needs to be implemented so I as a developer in a year can go in and make changes within, let's say, an hour, uh, if, if these changes, uh, are required. You can use it, but I would rather again use it through the Definition of Done. Or like, why do you want to put it in, uh, in as a user story.

Yeah, I get you. I, I, I do tend to agree. Otherwise, uh, but I've seen stories like that. I do agree. And at the same time, I've seen stories like that where it's like, me as a, you know, super admin of the system, you know, I would want to have this outcome, blah, blah, blah. And it's just like, okay, so the, the story got written from a needs of you as a admin, right? So I've seen this, and I actually seen this a lot. That's right. Yeah.

Again, sometimes you have stakeholders, uh, in the project whose, whose needs, uh, need to be addressed in some way. You, you can get out of it because, uh, one way or another, the stakeholders will affect how your project is going. So, so you have to address it. It's, it's just a question of how. So in some cases, yeah, if you have an operations team heavily involved in the project and they're gonna be managing something on the backend, then, uh, on the backend you might have a few user stories on how they should be able to work with the backend, uh, part to make sure that it's efficient for them, it's reliable, and they can do their job really, really well. But, but after all, it always can be tied to the end user because operations don't do their work just for the sake of their work. It means something. So for example, if, if you need to create, uh, you create a KYC system and there is an application that user fills out, and then there is somebody on the backend who need to process that application. There is a big difference between that person taking, uh, an hour to process an application or taking 2 minutes to process an application. Both— it has impact both on the costs of running that system, so total cost of ownership, but it also affects the user experience. So if, let's say, you submitted an application and have to wait for a week for it to get processed, versus if you submitted an application and in 2 minutes you get a response like, hey, you're good to go. That's a completely different experience for the user. So you need to balance both. Sorry.

Okay. I love that. So we're going to those areas where there's likely some opinions, maybe some biases, but I think, yeah, it's— I'm like having people in mind who would probably go like, I think differently. But can we say Agile has that flavor of people's opinions, or is that flavor there because a lot of people just don't really understand Agile and they do their own thing?

I think it's both, right? So, uh, Agile, like any system, evolves over time, and the Opinions of, of people is something that helps, uh, the system evolve. Like, you have some thought in mind, you go, you execute on it, and that changes the, the entire system. Uh, but on the other hand, you have people with inherent biases who are not being aware of these biases. They bring some perspectives. That contradicts the core principles of Agile, or they contradict the metrics that people are seeing. So that's why Agile, uh, first and foremost is a scientific method approach. So you have to rely, like when we talk about hypothesis, it's an educated guess, not just a guess. So a good hypothesis is always based on something. And it's not just my experience or my idea or my thoughts on the matter. It's ideally it has to be, it has to have as a foundation like a scientific theory, for example. Right. So, so it's not I think the user will benefit from, from this. Ideally, it's like psychology tells us this, this and this. So if we leverage this concept from psychology, we should get these benefits. This is a good hypothesis. So same with Agile. It's good for people to have opinions. It's good for people to have unpopular opinions. Because when you have the conversation between people who disagree on something, there's almost always a little bit, like 10%, a golden nugget. I love that from a person I work with, uh, Brent Robertson, he introduced that concept to me, uh, a golden nugget. So try to find that golden nugget of truthfulness and, uh, something that makes sense even if you hate what the other person is saying. So, and once you start looking for these golden nuggets, you really can build up the system to to something awesome.

Yeah, such a good summary, Ivan. It's so— yeah, it's, it's almost like a closure of a book, of a chapter. Like, we'll have that recorded, you can copy-paste that out, right? So to sum up, user stories aren't just tasks, they are a roadmap that keeps everyone aligned with the ultimate goal.

Absolutely.

Yeah, that's that. So I want to touch a little bit of sustainability as well on performance or velocity, which is very often used. Team velocity. What's the team's velocity? What's our velocity? Team velocity.

Worst metric ever.

Yeah, well, here you go. You will be able to share this. But where I go with the question is a sustainable performance of a team. So if you look at the burnout charts or any metric which sort of implies this is how much we can do in any given sprint, I've seen a lot of volatility and it's always like comes in, comes out. I've seen volatility happening because people don't actually do sprints well. They allow sprints to be, you know, to be broken, things being added or taken away, which skews the numbers. But if you're doing sprints quite well, you're doing the planning quite well, you have the same team, the volatility comes in maybe if you change the members, but if everything is static, you still see the volatility, which in theory should not exist. You should have a sustainable way of sort of predicting the future and going like, here's the team metric, here's our, you know, best numbers, it's sustainable, there's no burnout risk, you know, people are not overworked, there's That's literally a sustainable way of going forward. Hence, we can, you know, likely predict our future much better. So that, that, that, that point of sustainability is like, how do you set up things in such a way that you can have your teams continuously working well in a sustainable way? That's a big question. I just realized.

Yeah, let's separate into two things because there are two things, sustainability. And predictability, and they are not one and the same. Okay, so yeah, when you work with complexity, predictability is not there. So you work with the complex tasks, and even if you solved problems 1, 2, and 3 today, it doesn't mean that you're gonna solve problem 4 tomorrow. And it might take you a week to solve problem 4, while problems 1, 2, and 3 took you only 1 day. So, and that's okay, there is nothing wrong with it. Uh, there are ways to deal, uh, with it. So for example, uh, why Agile implies, like Scrum for example, implies, uh, daily stand-ups. That's one of the reasons. So if somebody gets stuck Uh, they need to be able to, to stand up and say, hey guys, I'm stuck, I have no idea how to solve that, I need help. And in a lot of cases, if you have truly diverse team, you're gonna have something like, hey, let's take, let's sit together, take a look, and then the solution will be there in, in 10 minutes or half an hour. Uh, but sometimes even that doesn't happen. It can be the entire team is sitting there, it's like, and how do we do that? Like, we tried everything. So, and then there are tools that can help you deal with that, from the theory of inventive problem solving to different, uh, methods of running like brainstorms, uh, and everything. So, so you can get predictability necessarily every single time. What you can get is sustainability, and you're absolutely right here. Uh, burnout, uh, I think I saw some statistics, uh, that, uh, a person who works 12 hours a day versus a person who works 8 hours a day, the productivity, I think, 6 to 8 weeks in the total productivity, uh, actually is higher the less you work.

Mm-hmm.

Yeah, because, because it's, it's just you, you're getting into a rut. You, you, you stop functioning as well as you should. So, but burnout is more than just that, right? So there are multiple different triggers, uh, of, of, of the burnout. So a lot of different things can, can lead to the burnout. And burnout is actually a little bit of an overused word. Right now because burnout is a psychological condition that can be, uh, diagnosed. A lot of people say like, oh, I am burnt out, when they just tired or feel in a rut or something. So, uh, so we need to be able to deal with the burnout, deal with just people being in the rut. And just making sure that we are working on the things that are needed. Because I think one of the biggest issues that a lot of teams have is when they put a lot of effort and they achieved something and they did something and it ended up not being needed by, by anybody.

Okay.

And that's, that's what can lead to, to a big dip. Otherwise, velocity, again, velocity is, is, is a metric that doesn't really bring a lot of value because you, you're measuring something that, uh, not necessarily can be measured. So you have a guess in points, for example, how, how long this, this, and this is gonna take. And that's a guess. It might be an educated guess, but still a guess. So this number fluctuates. And then the number of points implemented within the sprint fluctuates because of the complexity of the work, uh, and then you try to make sense out of two numbers that continuously change and why. Use throughput as a metric. Use approaches from Kanban. Look at the work in progress. Look at some other metrics that are way more controllable.

Mm-hmm. Okay. So we have predictability, which is really not there for complex systems anyway. So you can only try to take it apart and see at the, you know, closest goalpost. Sustainability effectively, we're saying there's no point to chase the ghost in the sense that let's push it, guys, for the next 4 prints, let's put ourselves to the point of being tired and eventually less productive, and then realize maybe we did something which no one needed. So to actually be sustainable let's work in a, in a, in a pace which where we don't burn ourselves out or make ourselves tired. And let's just work on the things which really matters. So that's just priority thing. And that's the way towards the sustainability. I think you, you mentioned this smooth is slow. No, slow is smooth, smooth is fast. That was the saying. Yeah. I heard that before. I don't know where, but I definitely heard that before.

I think it's Navy SEALs. I might be mistaken, but I think it's inside the Army Special Forces or Navy SEALs.

Yeah, definitely, definitely on point over here. That is that, that smoothness element is you actually knowing what you're doing, you know why you're doing, you know the value which is going to come out of it, and you're just working in such a way that you can sustain your pace for, you know, for years to come, and, and you just compound that value forward. I don't like, you know, that notion of sprints. I mean, it's the saying, it's just sprints is two weekly, you know, segments of work, but it implies that we're going to be running faster than we should. Like, for me, that naming is somehow like, what are you saying? Are we going to be like sprinting for a couple of weeks and then we're going to go back to pacing? Like, are we going to name the next phase pacing for two weeks? Like, just somehow throw it.

Go with iteration. Call it iteration.

Yeah, exactly. It should be just iterations because it's just— and I've seen project being measured like— not measured, but positioned like that. Let's do 3 months of actual pushout. Let's go to markets. Let's hit that date, you know, Christmas, Father's Day, or whatever. And then we're going to take it slower. And that slower never comes in. And I've seen teams, you know, crumble, not being sustainable in that way because they just get tired. They just go like, you know, oh my God. This again. And that was, you know, the sort of context of that question is just like, how do you, how do you just approach it in sustainable way so you can just do the same thing, rinse and repeat, and get good numbers? Yeah.

Yeah. And I think it's important to, to, to notice that, uh, actually pushing and working overtime hurts, uh, Scrum, for example, and it hurts actually Agile because It, as I mentioned at the beginning, the core is transparency and metrics, right? Measurements. So if you cheat the system, you basically destroy the opportunities. So let's say we go into the sprint and we fail. We work 8 hours a day and we fail. It's bad. Nobody likes failing. Right, but let's create an opportunity to learn from that failure and to understand what went wrong and what the next time we can do better, uh, so it won't happen again. If you work an extra 2 hours a day throughout the, the entire sprint and then you successfully finish it up, the thought process is, is Well, I mean, it's just, it was like 2 hours a day. It's like, it's next, next, next week is going to be better. We didn't really fail. We just like took one story point more of work than we should have. And that the opportunity is not there anymore because failure is, is one of the biggest drivers for change. And if it's not, then you have wrong people, uh, on, on your team. So You, you need to create these opportunities for, for failure. And sometimes, again, we live in the real world. Sometimes you have to push through and work overtime and hit that date because it's really important. It just shouldn't be every week.

Hmm. I love that. Fear of failure. That's probably a big one. Just people just don't want to fail. They don't look at the situation. Okay, we're going to fail this time. We're going to do retrospective, we're going to realize why we failed, we'll try to improve the processes, or whatever comes out of this. People look at this and go like, okay, well, what do we need to do to make it happen? And they, they, they try their best to make it happen. Sometimes they do make it happen, or they close— come closer to making it happen. And what we're saying, that at that point in time, you remove the opportunity for yourself to be better in the long run. Because you don't really know where you would actually have failed and why. Okay. I love that you mentioned measurement, Ivan. Like, yep, yep.

I just— about failure, I want to add one critical notion that I think we don't talk enough about. There is, there is a big difference between mistake and negligence. So when we talk about fail, and failure and creating opportunities. We talk about mistakes. Agile does not, uh, act as an indulgence to, uh, to be negligent, right? So fail safe. Learn to make safe experiments that doesn't hurt anyone, and then fail within these experiments, and then learn from these experiments, and then apply it. So that's why there are a lot of concepts like sandboxes. Right? So don't experiment with the new technologies on live project. Create a sandbox, make sure that you know how to work with it, then apply it to a real project. Because this is a safe experiment. Applying it to real project is not safe. You can hurt actual users, actual business. So, so that, that's just a very important concept for, for people to understand. Uh, you, you need to fail, but you need to learn to fail safely. Otherwise, it won't be safe for you, for the organizations, for the end users. So don't expect business to, to be okay with your negligence when you failed. It's not what agile is about.

I love that. Okay, so Ivan, if our listeners could take away just one lesson from today's discussion, about the importance of speed and efficiency, what that would be?

Start with two simple things. Make sure that everything you work on brings value to the people who are paying for it, uh, and make sure to shorten time to market. If, if I was to, to select one metric to implement tomorrow, I would start with time to market. So once you start with time to market, start looking for the opportunities how you can change your internal processes to support the time to market without losing quality. So if we talk about tech, right, uh, there are multitude of tools. Start using unit testing, start using, uh, automated testing, start using, uh, static code analysis tools like SonarQube or something like that, uh start using other tools to validate the work that you're doing, it will help you to improve the pace without losing the quality. And then make sure that, yeah, you, you solve, solve real problems with what you're doing. So focus on what's most important and do it well.

Okay. I love that. Time to market. Put that in your OKRs. Never stop measuring. That's going to be your North Star. How quickly you actually put value into the market. That's a great one. So if people want to ask more questions about or want to understand maybe more about the business you guys have, how can they reach you and kick off that conversation?

Absolutely. So first and foremost, I'm on LinkedIn, Ivan Gekht, I-V-A-N-G-E-K-H-T. You can always connect with me, shoot me a question. Or you can find our company website, GetSoftUSA. It's g-e-h-t-s-o-f-t-u-s-a.com and just use contact us form.

And for the ones who cannot combine the spelling into the links, just scroll down to the show notes. We'll have the links there for you. Click on them, get in touch, Ivan. There was so many golden nuggets in this conversation, which I feel like it's only scratched the surface. If you really want to just do better when it comes to Agile processes, value stream mapping, and in general understanding the speed around deliveries, get in touch with Ivan. And for our listeners, a quick reminder, you can find us on any podcast platform— Spotify, Apple Podcasts, CastBox, pretty much anywhere. YouTube as well. It would be excellent if you guys would share the show with your network. We would love to hear your opinions. Thank you very much, and as always, until the next time, stay safe. See you online.