TECHNOLOGY BLOG

Gray Leaf focuses on three things we do really well: IT consulting, project management, and development. In this podcast John and Richard chat about how they successfully manage projects using the Agile mindset to project management. 

Transparency and collaboration with the product owner (client) are the cornerstones of what makes our method consistently successful. This method of collaboration inherently produces exactly what you want because you are working with us for the duration of the project. Seeing deliverables quickly and iteratively through sprint cycles puts a product in your hands on a regular basis. This is low risk and low cost because you control the spending. We prioritize your most important needs first and fail early which allows us to change course faster.

Podcast Transcript:

Richard:

[Inaudible]

John:

Well, John, how are we doing? We're doing good. Awesome. Awesome. It's Friday. It's a Friday and the sun shining and it's gotta to be 70 degrees this weekend. So how bad can it be? That's right. It's a Friday. I love Friday. I'm going to mow my lawn for the last time tomorrow. So I've done for the year. I hope I don't have to anymore. Yeah. Good, good, good deal. So yeah, today you know, want to chat, there's three things that Greeley does amazingly well. One of those is it consulting. Another one is project management and the other development. So all three of those things we do extremely well, but today I want to talk a little bit more about project management because we often get asked a lot from clients. You know, what is our management process? How do we manage these projects?

John:

And it entails a lot of different things. Most, if not every single one of them are, are amazing for the, for the client and the things that they provide. So yeah, let's chat a little bit about that, John, what makes us so amazing at project manager? Well, you know, that, that, that's a great question. And, you know, project management is one of those things. That's often under appreciated that until a project is going South, but you know, there is a challenge with project management because, you know, if, if you try to Google project management, I don't know how many millions of results you'd possibly get. And a lot, there's a lot of different philosophies. There's a lot of different ideas. And, you know, some people often think that it's, you know, the, the kind of the easiest part of it. In fact, it's, it's not easy, it can be easy, but it's not a foregone conclusion that project management will always deliver results, any kind of project management.

John:

So you know, that's, you know, and, and to talk about how we manage projects, I think it's important to kind of go through a little bit of the history of, of, of you know, our, our, our kind of history with project management, my, my personally, my history and to kind of, you know, get to the point where we are now, is that, is that a good way to, to, to, to do this? Yeah, I think that's great. I mean, oftentimes we run into that with clients where we, you know, we start off with a little bit of history, so yeah. Bring it on, lay it on us. So I got to say the, the first time that I was really exposed to the project management was I think when I was probably a manager at general motors, a distribution center.

John:

And I was, I was assistant manager there for a while. Of course, moving parts, as, you know, there's a lot involved with it. And, you know, when you're moving you know, 7 million auto parts a year, you know, shaving three seconds off of each part is equivalent of about eight months. It's a lot of time. And so, you know, we, we did things like statistical process controls, and we did things like, you know lean concepts and started, started into that, or it's delivering on time, delivering safely, all of that. We, we handled the transportation and logistics component of all these different parts. And there were a, probably about 500 GM dealerships across a six or seven state area. But what, what that, here's the problem with that though? You know, a lot of times, you know, when you're managing a project, it's more of a, you know, it's a macro effort.

John:

Like when you're, when you're looking at a single part and getting a single part quicker, it's a very micro level approach looking at, you know, when you've got all other processes, finally honed. When I went to the Ford motor company, it was even more advanced. I was a terminal manager for the Ford company, Mo motor company down in Winchester, Virginia terminal. And again, managing that transportation logistics component. I was the terminal manager at that point. And we did actually move 7 million at 2020. I think it was 2008. We had received the, we were nominated for the presidential service award because we had moved 7 million autoparts six, eight area. And we had done it with less than $600 preventable accident costs. And well we covered like 3 million miles. That's like going to the moon and back six times within a year. So w w I was very, very proud of the team for that.

John:

Our whole team got nominated, which normally isn't done. You don't nominate a whole team, but I was really happy that that's the deal. I hate to say it. But, you know, I wish I could take credit truthfully. But, but th the, the truth of the matter is you know, a lot of this was due to a philosophy that, you know, I'm kinda, I was kinda, I taught, I used to tell the guys were kind of standing on the, on the shoulders of giants here with this, with this new philosophy, this lane, total quality management philosophy. Now I'm only bringing this up because this is like, this is setting the foundation for kind of where we are and how we manage projects today. Now that the it goes, it goes all the way back to guys like w Edwards Deming and you know, shoe.

John:

And a lot of these, these guys who are very, very highly invested in, you know, total quality management and, and using statistics to analyze how we can get better. All the sounds tremendously difficult and complicated. But in truth, it, it, it was really changing the way people thought about quality. And instead of thinking about, okay, well, you know, how quickly can this part get from point a to point B? It, it largely became about understanding the entire system and Devin was a big proponent of that understanding the system. And another thing he did was recognize and promote the idea that the employee is not in control of results. Now that's, that blew the mind out of a lot of people's, you know, thinking because it's always like, well, you know, if you're having a problem, go blame, you know, go blame somebody, go fire somebody.

John:

And if you're not getting what you want, go hire a new person, right. It's a Trump mentality. You know, you're fired. But, but really, really this, this philosophy is embedded in the fact that, you know, a system that dictates your result and the only person that controls the system is the manager. All right, well, why does all this matter? Well, it matters because it, it, it came, you know, over time this, this philosophy kind of became more more formalized now. Toyota definitely had it, you know, and, and Deming had it very formalized. But in the software development environment, especially is where it's really, really gained attraction with something called the agile manifesto. Now I'm talking a lot of terms and throwing out lingo, and you're going to, I'm going to probably, you know, I'm going to show you how simple it can be.

John:

The genius, isn't the simplicity though. So, but you know, essentially what happened is this idea of this linear approach to developing things has been deeply embedded and in projects for a long time, for example, you know, it sounds intuitive. If you want to build a ship right before you lay the keel, you've got to pretty much know everything there is possibly to know about this ship. You got to know how big it's going to be. You got to know what material it's made of how much it's going to weigh. You got to pretty much know where every bolt, rivet and piece of glass and plastic and conduit and electrical, and you got to know all that in advance before you can even start the whole nine yards. You got to know it all. Okay. Well, what does that mean? You know, and I, I think shipbuilding now is getting a little bit more advanced, but, but in, in the day you had to do all this in advance. So, but the implication was okay, well, before we could even start with this, we're going to need to take a few years, right. And we're going to need to architect this and drafted, and, you know, we're going to need to, you know, create blueprints, right. And

Richard:

A very long time, you know,

John:

And people were like, well, that has to be how it's done. Incidentally, on a side note, I will, I will mention that I was reading that they don't necessarily do it that way anymore. They build ships and sections, and then they build out those sections later. Yeah. So cool, cool thing. But I don't want to sidetrack it. So anyway, but this thinking about kind of this, you got to know everything upfront. It actually translated into the software development world. You know, it's like, okay, is it software building a software or a virtual solution? Isn't it the same thing. Right. We got to know everything about this thing up front before we even start, well, the problem with this is those projects tended to go over budget. They tended to under-deliver. They tended to go past the schedule and they really did not produce optimal results. I'm not saying it didn't produce any results right there probably

Richard:

They're looking forward. Yeah. Right. And then

John:

Probably not the best results. Okay. So actually, what happened is a bunch of software developers. This is in the late 1990s, you know, there they were, they were after suffering a ton of like, I'll say, fail projects, failures, failures, they're failures. That's what they were. Right. they got together and Utah and at a, at a ski resort of all places. And they, they, you know, started to think about what's wrong here. What's wrong with this picture. And so they came up with something that is called the agile manifesto. Now I wanna, I want to, just before I go any further, I want to just pause for a minute because when people hear the word agile, they tend to immediately shut down. They're like, Oh, I know agile. Well we're doing agile right now. The common, they'll say, we're doing agile,

Richard:

Agile, already. 

Richard:

Need this. Okay. So, you know, end podcast.

John:

But I would challenge everybody to keep listening because there are so many misconceptions and misunderstandings about what agile is and what it can do, and really what it means that I wanna, I wanna just, you know, talk about this for a minute. The agile manifesto is very simple. I'm actually going to share my screen and I'm going to show you the actual website. This is from agile manifesto.org. And so can you see my screen? Yep. So this is a bare bone site. I don't think it's been changed this 1996. The early ones. It is. And, but I, I feel this information is timeless. You know, you have a lot of things, you know, for agile, you got scrum, you got Kanban, you got, you know, all kinds of flavors of agile or frameworks of agile, but really those in themselves are not really don't really encompass an agile mindset.

John:

Now that's key. So a mindset about agile is different than scrum. Scrum is a framework. Scrum is okay, well, this is our process. How we're going to do this. We're Kanban. This is a process that we're going to an agile mindset as encompassed by these four kind of values are encompassed a mindset. Now, all this is leading somewhere. So please bear with me. So you know, there's four main values with this agile mindset. It's valuing individuals and interactions over processes and tools. That's the first one. Now, oftentimes as soon as I start reading this, people will say, well, so we're don't need processes and tools, right? Or we don't need documentation. And we don't know, that's not what we're saying here. All we're saying is we value one over the other. So we're valuing individuals and interactions over processes and tools. How many times in your organization has somebody come to you and said, we need a new tool, or we need a new process. Happens a lot, happens a lot. Well, what we like to do as consultants is we, we, we, we don't even like to start with that, right. Well, we start to ask is what problem are we trying to solve?

Richard:

So where our expert consulting comes in, you know, it's, we don't always just jump to, Oh, you need a tool. And we're the developers for you. Hi,

John:

Exactly. Richard, how many times does somebody come to us and said, Hey, you know, we heard you guys build great tools, right? Can we need a tool tools? What do we do? We always say, okay, well, let's step back a second. Let's ask some questions. Right. And, and the, the questions we often start with is the question is what problem when you're trying to solve. And then what we say is, you know, they'll come up with, you know, well, you know, this things over here is not working or whatever there, you know, the thought is, and then we'll say, okay, well, how do you know that's the, the right problem?

Richard:

And the truth is most people don't, most people don't really know until they really start getting asked those critical questions that, that, that, that we asked, ask them, for sure,

John:

You peel that onion back a little bit. Right. And, and when we start peeling that onion back and we start asking questions very often, what we find is that there's been assumptions made that, you know, have, has, you know, I want to use the word pigeonholed, you know, what they believe the problem is now getting back to this, this agile mindset, when we value individuals over at interactions, over processes and tools, what we're saying is, you know, we're not, we don't start out with a tool, right. Or a process. And, and, you know, you know, there's this idea of best practices, right? This is out there, you know, okay. Let's, let's find out what we want to adopt the best practices. Well, that's, that's fine. But you know, what worked in one company may not work in a different company and a tool that works great in one company that may not work in a different company. There's there could be differences, same thing with processes or methodologies. The problem with those is they tend to be kind of rigid and fixed and, and, and to, to come in to jump in right off the bat and say, Oh, Hey, we got this methodology. We did over here for this company. They're just like you, and we're going to do the same thing, and it's going to solve all your problems.

Richard:

It's always, really served us really well is when, when clients come to us that we, you know, we, we do not cookie cutter, you know, throw it against the wall and say, yup, this is going to work for you. You know, it's always served us well to ask those questions and it all in, and, you know, it starts you off in the right on the right path.

John:

We had this just yesterday, right. And when we started asking him about that, we were just on a call, Richard, I was just on a, on a you know, new intro call sector a second call with the client. But, but you know, when we start asking these questions, they tend to, they tend to get this well, wait a minute, you know? Wow. And, and even

Richard:

Carlin changes and they take a step back and like, you know, they didn't like in that particular call, they were so appreciative of those questions that they didn't even know to ask themselves. I I'm, I'm pretty certain that, that that's a client that we're going to have for a very long time. And we haven't even agreed to anything yet. That's how certain I am. They, it serves us so well being able to do it that way.

John:

I'm a master of talking us out of work. Richard,

Richard:

That sometimes happens. I don't know why that happens.

John:

And, but when we do it for a reason, right, we want, we want the best thing for the client. And sometimes, you know, we ask these questions and we realize, you know, what, what, you're, what you think you need is really not what we believe you need, you know, or what you think you want is not what you need. So, you know, but, but really that, that's the concept here. So, you know, starting with that first one, individuals and interactions over processes and tools, we like to focus on individuals and interactions. So that's why we ask questions. We, we consult, we get to know them, right. We spend time with them and understand their problems. And that directly goes into the next one. We focus on working software, over comprehensive documentation. What we have found and many organizations have found that really have adapted this agile mindset is that spending a lot of time documenting things is often wasteful.

John:

You know, sometimes I've actually seen it and I've spent a lot of time in the government working as, as a contractor and consultants in the government space. And we have, we have government contracts now and Richard, you and I both would come from the, from a gov government world. But you know, what we do is we spend there's so much time needed to document things that often by the time you're done documenting the needs have changed, or, you know, it's like, it takes so long that, you know, we spend so much work in documentation, creating a BRD, you know, a business requirements document. And then you got to create a functional requirements document. And, you know, these things, you know, get massive and then developers are supposed to kind of open those up and build something based on those. Well, the reason it's, it's more productive to focus on working software is when you're, when you're at the beginning of the project, arguably is when you know the least amount about what you want.

John:

Right. Truthfully yes, you have some ideas, right. You might have, you might know what a problem is. Maybe, maybe not, but, you know, hopefully you're working on the right problem, but oftentimes it's like, you really don't know what can be done. And really the only way to get to that is to put working software into the hands of users. One of the most important things as, as, as a consultant and a developer that we can do is very, as soon as possible create some working software. Yes. It's not going to be totally begged, you know, and yes, it's not going to be everything right, but it's this idea of a minimally viable product. An early stage of that, even that users can use. And that's invaluable, it's this idea that, you know, you want people to be able to learn and try it out and click the buttons, because that allows us to get feedback from the client about the things they like and the things they don't and really softwares does that.

Richard:

Yeah. That's my favorite part of this entire process that, you know, that we work with with our, with our clients is that, you know, the learning aspect, you know, them getting you know, it's a very collaborative space and we'll get into the, the, the, all the different key aspects of, of how we do things. But one of those is being, you know, that collaboration between us the project managers and them, the product owners, you know, getting used to seeing them, you know, learn in and figure out things that they didn't know before. You know, they don't know what they don't know. And when, when, when they go, when we go through these cycles or sprint cycles, these review meetings, you know, and, and seeing them learn these things, that to me is the, one of the most biggest benefits of, of moving the project along and Gus in the end, giving them, you know, they're going to get exactly what they didn't even know they needed. It's going to be exactly what they want.

John:

That's right. And the concept here is to eliminate waste because you know, a lot of things, how many times Richard, have we seen that we're with somebody and they have ideas of what they want. And then as we start doing this, they realize, you know what, we don't need that after all that goes into the, you know, product owner decline column, and think of all, you know, it's, it's, it's eliminating that waste, right. And immediately saving saving costs. Now it's not saying we don't document, right. We document, you know, where appropriate, you know, sometimes you need architecture diagrams and you need certain, you know, technical documentation and user guides and things like that. And so we still document where needed. But the focus though is let's, let's build something and let's get feedback because it allows for this, you know, what, you know, what is known as the empirical process to take place, right?

John:

It's the learning the ability to learn and do by learning. And, and that's, that's key. The next point here is customer collaboration over contract negotiation. How many of us have worked in a project where we, there was a need, there was a, there was a need felt to create a very, very detailed contract, what that does, you know, you know, a lot of times the reasons those are done is because to give us a sense of security, right? Especially, you know, the executives and financial folks, right. That they, they, they get a certain sense of security with a very, very detailed contract. The problem is that it's, it could be argued that that's a false sense of security because a lot of these projects that have gone over budget and under-delivered, they had very, very detailed contracts. The government's famous for very, very detailed contracts and, and going very, very over budget.

John:

And I'm not pointing to any particular organization because we can all fall victim to it. But the focus, instead, it should be on customer collaboration. Because if you're, if, you know, when, when something isn't like when, when, when you're having frequent meetings and you're showing people things, and you're getting their feedback, the focus is okay, well, how do we change this solution in the next iteration so that we can make it better. If you have a highly detailed contract you're bound to the contract. In fact, the contract prevents change and they're intentionally designed to do that. The problem is that they don't allow for this empirical process, this learning process to take place. They're tired of even, you know, we've been, you know you know, seen and, and, and been you know, in the back end of the day, involved in projects where, you know, you couldn't change because the contracts that you could yeah.

Richard:

The contract wouldn't allow you to change. And really that is the, the, the most important aspect is, is that learning and that the ability to change course relatively, relatively quickly.

John:

Yeah. And, and, you know, there's things like change control and things like that you have in these agreements, you know, that have to go through a certain process. And they're meant to allow the contract to be somewhat flexible, still in practice. What happens is the focus is really derailed from the product and focuses on the contract and we feel that's not the right approach.

Richard:

It's definitely not optimal. And I think that's something else. I think we really Excel at being able to, to, you know, drive that focus and keep that focus on, you know, what we're trying to produce. And, you know, again, by the end of the project, they're going to have exactly what you know exactly what they want.

John:

Yeah. And, and on this last point, responding to change over following a plan you know, there's, I have a few things to say about this. You know, that, again, it kind of comes down to this concept of trying to predict, you know, if false sense of security of trying to say, you know, I want to know in advance everything that there is possibly going to happen on this project so that I can be ready for it. I have I have another slide I want to, I want to show which, which really I think gets to the heart of this. This is a.

John:

You know, we'll usually right. W you know, when you're, when you, when you have, when you're a client, you know, you have like, okay, we, you know, we have a goal, right. And sometimes you don't even really know what the goal is. You, you, most of the time, you're more focused on the problem, right. On hopefully, you know, something will fix the problem. But in any event, you know, there is a idea of a, of a destination and a product, right. It might be blurry and fuzzy, but there is this idea. A lot of times what, what the, you know, the w you know, what, what people expect is that it's going to be just a smooth, yeah, it's an uphill grade a little bit, but it's going to be smooth and consistent, and

Richard:

You got to get from a, to B really quickly, really quickly. It's kind of a boom, boom. There is no in between.

John:

Right. And you want to uncover anything. And then, you know, we've even had, you know, when we explained this to some clients, some of maybe you said, well, you've done this before. Don't, you know, you know, everything that could possibly happen. Well, you know,

Richard:

Well, we do know that we need to go through this process with them because

John:

You know, it w we do know everything that can happen. And we, you know, we, and so we want to process getting back to that fourth point is we want a process that responds to change over following a plan. So look at reality here, you know, the reality of the situation is there are things that, you know, obstacles that are in our way that, you know, we need to be aware of. And if you can't be aware of them and oftentimes you can't, right. You may not this person on this bike probably can't see over the trees, right. You probably only really see the trees in front of you, you know, this, all of these other things are really unknown territory, right. And depending on the path you go, it could vary too. So the other thing is and it kind of the key point here plans will always confront reality and reality always wins.

John:

One of the, one of the founders of of the agile manifesto was fond of saying that reality always wins. The other thing is we want a process that really evaluates what is wanted and what is needed this idea of a minimally viable product. You know, if, if, if throughout a process we're able to change the goalpost, you know, we're able to say, okay, well, we understand what you want, but, you know, through this process, we can often get to what they really need in a very, very, you know, much faster way, a much quicker way. And part of that is something we're always striving for, right? Simplicity. We want no cost solutions, low cost solutions of possible, and only do we ever want to go, you know, build and complexity only if it's really needed. And we only want to do that. You know, if we really have a really clear understanding why it's needed,

Richard:

And that's such a really good point, because it never fails with software development, you know, they're there once because of this, you know the very collaborative nature of what we do, that the client is always going to see things that they didn't know were possible. So they're going to want to go in different directions that they, they just don't know, and they can't know until they go through it. So as we go through these, these cycles together, and as they see things, you know, it's gonna, it's gonna change the course of, of what they want. They're going to see what's possible. They're going to see things they like, and they don't like, and it really, really helps drive home. The point that by the end of the project, you know, they're going to get, you know, something that much better than what they thought they could even get in the beginning,

John:

By the way, a shout out to my friend, Jimmy Butler. He's the one I stole these images from. I don't know where he got them from. So if, if there's a credit out here that I'm missing, please let me know. But Jimmy Butler and I have worked together and, and Jimmy has has you know, done a lot of work about the agile mindset, timeless agility.com is a good site. And he's got a book. In fact, I, I used to have it right next to me. It's over all my other, other in the rooms it's in the room and it's all dog-eared. And here I'll even reach over and grab it one sec.

Richard:

Yeah, yeah, yeah. I mean, the, the, the book, I mean, is amazing timeless, you know, pursuing timeless agility, you know, Jimmy, he's definitely a source, you know that's helped us out. And so for anybody that's interested in, they want to read the book, definitely go out and get it. Okay. Plug it out,

John:

We'll go over the, the, the other thing that I wanted to talk about is this idea about, you know, this idea of learning, and this gets back to that second point in the agile manifesto, these agile values of working software over comprehensive documentation. So, and also responding to change over following a plan. So let's talk about this for a moment. So this is the credit here goes to a guy named Henrik. Nyberg he's the actual, the guy that drew this. And

Richard:

10, I love this example. I mean, this is a great example of, of, of, of a client, you know, us learning what the client really wants.

John:

It really is, you know, in the top example, right. Is the traditional way, you know, of building something. And, you know, so let's say for example, a company has a, a goal. We talked about goals in the last line, so that a company has a goal and they want to get from point a to point B faster than walking. That's the goal. Okay. A good goal, right. Sometimes gotta move fast. Good goal, right. Point a to point B faster than walking. Okay. Well, in the, in the top example, it's a linear process. So it's kind of going into the, kind of the Mo the old way of doing things, right. Where you had to, somebody has to decide upfront everything that they want. And somebody has to, first of all, decide that it's going to be a car. And so, okay, well, so we have to decide everything upfront about this car, right?

John:

We have to decide, okay. Yes, we, we kind of know what's going to have to have wheels if it's a car and it's got to have a windshield and a steering wheel, and, but you also have to solve what color it's going to be. You also have to solve what, you know, how hard the seats are going to be, what the seats going to be made out of before you even have a chance to kind of touch, test them out and try them out. You got to make a lot of decisions you to make every decision.

Richard:

It's a cost too, up front with this, with this kind of process, you have to build that cost, aim to try and find out all of these things that may or may not even be relevant.

John:

Exactly. And that's why, you know, there's a frowny face here, right. You know, you have somebody, you know, we'll call them the product owner. Somebody wants a car and they don't have a car. And so they're not, you know, yes. You know, we, we can, the car is being built one step at a time. And in the end, yes. There's a car there. And yeah, the client's smiling. Yes. It's a car may be surprising in certain ways because the client gets, sees the car and, Oh, this is the car we talked about. And they sit down and be like, Ooh, wow.

Richard:

Of happiness. But then once you actually, you know, it's like, ah, yeah, this is all right. You know,

John:

And it's not the seventies, you know, about approach, doesn't deliver value. They do. And you know, it's it's, but it's not optimal. And you know, it may be,

Richard:

It's going to be more that they want more times than not. They're going to come back and there's going to be more than they want. They want to share.

John:

And oftentimes it is, let's look at this bottom example here. So same goal getting from point a to point B faster than walking, the goal is the same, but the approach is much different. So with this, what we would say is, okay, well, we want to, instead of respond to change, we want to respond to change over following a plan. So we're not actually spending all the time designing a car. In fact, we're not even deciding we want a car at this point, all we're doing is we're w we have this idea of saying, okay, well, how do we get working the working solution, something, a minimum viable product in the hands of this user quickly. So in this case, we're, we're going to say, okay, well, one way to get from point a to point B, faster than walking as well, skateboard, it's easy.

John:

It's quick. We're going to be able to incrementally, you know, in a very quick step, we're going to move to that goal. Now, you know, we are, our product owner here is looking at our skateboard and, you know, has a pretty big frown on his face. Right. Right. He's like, well, Jewish, you know, I wanted to, you know, it's a good start. Right. And so they go over to that skateboard and they're like, okay, well, let me try it out. Let me trust these guys for a minute. And they try it out on their young, you know, it's kind of fun. You know, I had been on a skateboard in the wild, but, you know, but you know, I learned something from this, you know, the, the, where I have to go those rocks and, you know, those rocks really don't work on these little wheels.

John:

Skateboard is not gonna work. The other thing is, it's really kind of hard to steer, you know, I'm getting up there and I can't really steer this thing very well. So we're like, okay, let's talk about that thing first. Let's, let's put a, let's put some handlebars on this and the second iteration. Right. We put handlebars on it. So, yeah. Okay. Well that addresses that need and the product owner might say, okay, this is a little better. I mean, I can steer, but again, the rocks are kind of a problem where like, okay, well, and he says, Oh, and he said, by the way, I need to go a couple miles. And you know, this little scooter is not really cutting it for, for going that far. It's probably okay, well then we get to a bike. Right? And you, you, you know, you get the point, I mean, what's happening is there's this process of learning that's happening. And it's this process of feedback. Now that is also happening, that allows us to, you know, incrementally deliver on a solution. But also at the same time, get feedback. Yes. We

John:

See that it's leading the same place.

John:

It's leading to a car, but here's a key point in this fourth iteration, right? Let's say, let's say the feedback from the third iteration here was, you know, they loved the bike, but you know, what about going like 20 or 30 or 40 miles now, Richard, I know for you getting on your bike, that's not a big deal. Right. You'll drive ride down to Harper's ferry and back, and that's not a thing, right. It would kill me. But you know, just, but, but what feedback that, that we might've gotten from this third iteration is I, I really need just to go a little, I need something powered. So that brings us to the motorcycle. And so, you know, when the person you'll notice a smile now on that product owner is it's huge now, right? You're not just satisfying a need, right? You're you are, you know, exceeding the expectation.

John:

Now I'm not a little careful using that phrase. Like we don't want to go and play anything, but the key is, you know, the product owner is now excited. You know, they learned something they didn't know before they love the wind through their hair. And you know, it might've brought back memories when, you know, the product owner was younger and got on a bike and, you know, but there was an, a key piece of learning that happened here that really shapes the final solution. Now, yes, we did end up with a car in the fifth iteration, but it is a different car. It is a convertible. And that's based on the learning that took place. Now imagine what would have happened if we would have said, Oh, we're we're car builders. We build cars all the time. And we built this car for this guy over here, and we know exactly what you need and don't worry anymore, just go away. And we'll be back in two years and we're going to give you your car. This solution would never have happened in that scenario. It was only through this empirical. And I keep using that word, this learning process that allowed us to get it to a solution that excited, you know, the product owner.

Richard:

And so that's part of what makes us really great at what we do is that consulting part up front, and then going through the project management, the way that we do it you know, cause I mean, a not all consultants are made equal. We know that we've learned that we've met other consultants and you know, sometimes they, they, they fall into that. You know why I did this for a client over here, and this is what you guys should do instead of listening to the clients, you know, and asking those important questions, you know, and I keep saying it, we see it time and time again with clients that we meet you know, they, it usually takes two to three cycles and they're like, I'm sold like this process is for me. And it's, you know, in the software development realm, it's, it's exactly, you know, what works and that's what makes our process work so well.

John:

Yeah. And maybe in another podcast, we can actually talk more in detail about that process. But the key is that, you know, what we try to do is allow the product owner to keep control. And so we want them to control the burn rate. We want them to control the, the, the process. We want a process that is, or you know, an approach that is transparent. We don't want this to surprise them at any point, right? You don't want to surprise them with costs that were out of line or with a solution that's not a fit, you know, it all needs to be done in a way that allows for that control, proper control and proper transparency. And you know, in a way that, you know, delivers the best solution. There's a lot of obstacles to making this happen, by the way, you know, the finance folks, you know you know, how you do a contract, for example, you know, and that's probably a subject for another podcast too.

John:

Right. But how do you do things? The finance folks are comfortable. The executives are comfortable with it. How do you do it in the way that, you know, okay, how, how does the rubber meet the road with this project management approach? How does it really work? All those things are things we can talk about, but the key is it's all based on this agile manifesto, we feel it's timeless. And we know it works because we do it all the time. And I'm going to shamelessly plug our, our, our, ourselves. We are very good at it. And you know, you don't need to take our word for that because we have a lot of testimonials that would, that would say the same.

Richard:

Absolutely. Yeah. I mean, it's, it never fails. You know, pretty much I have yet to really run across a client. It didn't really work for you know, and that's not to say we, and I'll say too, just like you've said in the beginning, we're not for everyone, you know, we're, we're not going to be, you know, we're not going to be a good fit for everyone, but every client that has never seen this, this process or gone through this process has you know, bought into it, lock stock and barrel. They, they, they love it. And what ends up happening is that trust is built and they trust us to do their other projects. And that's generally what happens is we, we help them with their other needs you know, after the first project. But you know, that, to me, that's, that's something that our project managers do really well is, you know, managing the, you know, having all this background it's it's.

Richard:

And like you said, in the beginning, it's not just, you know, manage the project and tell them what's happening and whatnot. There's, there's a lot of things that do go into it. And a lot of things that the client has provided, you know, that transparency it's just, which is huge control of the burn. You mentioned it, you know, they, they see the estimates before they actually have development gets started. So the product owner, the client is in control of the burn. So like our project management, you know, it really provides all of those those key aspects you know, to the client every time, every project.

John:

Yeah. And and you know, I think that you know, we, we talk about this sometimes about clients, right? And we believe clients are savvy, they're smart. And they, they, they can see through

Richard:

You're done with that screen. Yes. Thank you.

John:

Clients see through lack of genuineness and, you know, the, you know, we, we have this term here called radical honesty and, you know, we, we, we talk about this a lot, you know, and, and, you know, we'll, we'll, we'll, we'll, we'll re you know, we'll, we'll talk about the fact that, you know, we, we never, you know, we never spend things, you know, we never try to, you know, you know, try to try to make things look better than what they are sugar-coat or hide, you know, something that went wrong. Transparency is always better because I believe that clients, clients are smart. And I think that they see it. I think that, you know, they know when they're, when, when those types of things are done and, and, you know, we, we feel that the best approach is always to be transparent and just be upfront and honest.

John:

And, you know, the truth is sometimes we do uncover things we didn't think about and no one really can predict everything. Right. And let's, let's just call it what it is. You know, there are things, you know, you, even when you're, you're doing things the best way possible, there, there will be some things that kind of, you, you know, come up and, you know, but transparency and honesty is key here. And, and we take that very seriously. And you know, when, when, you know, when we're hiring people to our team, you know, we w yes, the technical qualifications matter, but the core values man, matter more. And you know, I've often felt that, you know, you can't, you can't, you can hire somebody to learn technical skills, but you can't hire someone to have good core values. So you know, we look for that and, and, you know, we surround ourselves with guys that share those values and it comes out, it comes out in the projects. It comes, you know, it becomes revealed and how we work. And you know, it, it's a huge part of our success. I believe.

Richard:

Absolutely. I mean, our development obviously produces amazing results, but the, where the rubber meets the road is, is in the project management management. And, you know, every interaction between project manager, project, project, owner or product owner, like that's where it happens. And that's where that trust gets built. You know, and it happens every single project. Again, you know, folks that we work with, you know, we, we bring clients in all the time that have never even touched this. They're skeptical. Sometimes it takes a meeting or two to really kind of start to show them the process where the, the they're like, okay, well, you know, that actually sounds very beneficial. And it really is because it produces results. Every single project, you know, you, you have a, you have a term you love to say fail early. We love to fail early. We want to know what doesn't work. That way you can get onto what does

John:

You're you're so right. You know, and that, that often, you know, catches people by surprise, you know, you know, fail early. And but really that's good, right? You don't want to, you don't want to fail at the end of the project and realize you've been going down the wrong path the whole time. Right. Or let's feel we want to know as soon as possible if we're on the wrong track, because the way if you're embracing change, can you change direction?

Richard:

That's right. Because the reason that's so important is because the it's low risk, this process has very low risk, which is why you can fail early. So it's beneficial because it's low risk, but it's also beneficial because it gets you on the right path, much sooner,

John:

Very true. And this holds true for any software development project. It can be web development and, you know, solutions management. It can be document management, you know I mean, we do, we do all those things. But first and foremost, we're consultants and you know, we want to match the right solution to the right problem. And we know, I want to know what the right problem is. Know, it takes a little bit to get that for Australia. Let's make sure we're working on the right problem. Yeah.

Richard:

I mean, like you said, you know, I mean, we work with MSPs, we work with clients direct. We, you know, no matter what project that we're working on this, this, this process really works. It works every time. It's immensely. It's very, very beneficial. Like, you know, this is the, for me, this is the bread and butter of what we do because the consulting piece is, is, is, is crucial. But once you actually get into the, you know, the main phases of the project, this is keeps clients coming back to us. And this is what builds that, that, that reputation and trust, you know, that's very important to both.

John:

It, it really is. And you know, the the, the other thing that I think is, is crucial, is understanding that, you know, this process is, is based on results. And, you know, we're probably getting into an area that we need another podcast for, but yeah. Right. but you know, the, the, the thing about agile that sometimes folks need help with is, you know, there's a lot of aspects, but you know, how do you, how do you, what ways do we how, you know, how do you communicate this in a way that builds trust with the decision makers in an organization like the finance folks, you know, who are used to from fixed price agreements instead of time and materials how do you do that in that way? You know, how do you really, how does this project management work? All those things are real, probably great for another podcast that we could go into more detail on those things. Absolutely. As you can tell, we're, we're, we're, we're, we're excited about this though. You know, we love, we love what we do and, you know, we can build anything, but you know, this is, you know, it's I don't know where I'm going with that except to say that you know, we're w w we love talking about it and we love doing it even more.

Richard:

Absolutely. I mean, what it comes down to is, you know, what makes us so great at it? Well, it's quite a few things working together, you know, and executing each one of those really well to produce something for, you know, a tangible thing for the client, but also the way you got to that, what, you know, was it is a great, is a great experience for the client. And that's, you know, that's what we want to provide. So

John:

Absolutely, you know, if you, if you want to learn more, you know, to anybody listening, go to go, gray leaf.com, G R G I G O G R a Y L E a f.com go gray leaf.com. Send us an email you know, info@gograyleaf.com. And, you know, we'd love to chat more because you know, and that's free, right? We don't charge anything for chatting. And, you know, even if you know, we'll talk, you know, we'll talk you out of working with us. You know, because, you know, there's other ways to tackle, you know, maybe no cost or low cost solutions, but chances are, it's going to, it's going to be an informative discussion. So we'd love to talk with you. We'd love to get to know you. And you know, we, we'd love to, we'd love to, you know, have that conversation.

Richard:

Absolutely. Go to the website, check us out on, on LinkedIn. You know, send us, shoot us a message. Well, you know, let's chat

John:

Sounds good. And start to state, stay tuned for more podcasts.

Richard:

Talk about,

John:

Thanks, John. Appreciate it. Thank you, Richard.