Agile contracting and planning

Join Murray Robinson and Shane Gibson as they break down the differences between agile and waterfall patterns.

During our conversation, we’ll delve into:

🔸 Real-world experiences with agile and waterfall ways of working
🔸 The hidden costs of waterfall projects
🔸 Issues with current project procurement processes
🔸 Team structures in agile and the organisational limits to agility
🔸 The pitfalls of ‘water-scum-fall’ and unethical practices by large vendors
🔸 How to plan an agile initiative effectively
🔸 Tackling fixed price and fixed time in agile ways of working
🔸 The role of project managers in promoting an agile mindset

Tune in to gain a deeper understanding of these two popular  approaches, and to better understand the factors that can influence their success.

Read along you will

Shane: Welcome to the No Nonsense Agile Podcast. I’m Shane Gibson. 

Murray: And I’m Murray Robinson. 

Shane: Hey, Murray. I’m really looking forward to us starting this podcast series where you and I have some robust conversations around agile and cooling out some of the bullshit we see and. Enhancing some of the things that we 

Murray: believe are important.

Yeah, that’s what I wanna do. I’ve seen too many podcasts that are just lightweight, sales oriented intro things, and I want to explore some of the issues and some of the negatives and the better ways of doing things. 

Shane: Yep. Given the same with me are listen to lots of podcasts over the years and some of them, uh, basic 1 0 1 intros, which are.

But getting into those deeper dives into some of the things that we think are important is a good start for me and for our listeners out there. You may notice that our accents sound completely different. That’s because I come out of a little country called New Zealand, and Murray comes out of a big country to my west called Australia.

Murray: So let’s talk about who we are then so people know where we’re coming from. Shall we go first? So, I have been in the digital industry since the beginning. I started my career as a software developer in the mid eighties, and I’ve been a business analyst, a project manager, a scrum master. I’ve been a product manager, non-technical product manager.

I’ve been a program manager. I’ve been a general manager. I’ve had C level roles. I’ve worked in digital agencies, giant telcos, financial sector. I’ve done a lot of contracting, a lot of permanent work. I’ve managed teams of uh, hundred people and budgets of 20 million, and also small teams without budgets.

I started with Agile 15 years ago at a large Australian online jobs board. Agile for us was xp and we had great success with it, so I absolutely loved it. I found it a far better experience for me as a project manager than traditional project management. And so I have been carrying the flag for Agile ever since.

But back in those days, even 2010, it was still pretty odd for somebody to be saying, Let’s do Agile, and now it’s all the rage. And I’m not just interested in Agile, I’m interested. Digital product development lean. So when I talk about agile I’m, I’m often mixing in lean and design thinking and all that other, other stuff.

Shane: Yeah. So for me, I started out my career working for a government agency here in New Zealand. I got a job in the accounts payable team, and I quickly. Processing invoices wasn’t a love of mine, but I was lucky enough to fall into a group of people in that organization where we were replacing one of our financial systems.

And as part of that, I got this love of technology, this love of software and processes. So after doing a couple of financial implementations for different organizations, I moved on to the vendor side and I spent 12 to 15 years on that side of the fence doing sales engineers. Our job was to convince the cu that our software would solve the problem they had, uh, and then let the sales guy close and then get the hell outta Dodge before the consulting team went in to try and make it work.

After that, I went to work for a small startup for a very short amount of time, which I loved. And from there I moved on to doing consulting in the data and analytics space and started a small consulting firm here in New Zealand where we went in and helped customers solve their data and analytics problem.

And that’s when I’ve heard this word, agile. I’ve seen it around eight, nine years ago, about 2013. Um, and I saw these hippies out there doing these agile dancers and kumbaya. Saying how good it was. I was always open to experimentation. So we started experimenting a little bit with using Agiles ways of working for the work that we did, because we knew that a lot of the way we worked as a consulting company was broken.

This idea of large requirements front. We would spend six months doing a whole lot of work to how long it was gonna take. 

Murray: That’s a business model of those large consulting companies I reckon. We know that there’s gonna be huge numbers of changes, and we know that the customer’s only gonna engage us if we come in with a very low price.

So we are just gonna price it at half what we think the cost is, and then we are gonna screw them on the change request by charging 10 times the real cost for everything. I mean, that seems to be the business model for a lot of the big consulting companies. Oh, even the small 

Shane: ones. So we talk about the consulting pyramid scheme.

The most senior people go in at the beginning and then exit as fast as. And then the least experienced people go in and and try and do the work, and then the people at the top of the pyramid fly back in when things go wrong. No, transparency is one of the rules or that way of working because you don’t want the customer understanding the lack of value they’re 

Murray: getting.

Yeah, I agree. And waterfall’s actually essential for screwing your customer in that way because having a fixed scope upfront, which. Inevitably going to change makes it really clear what the changes are. And then if you have a really tough change control process, you can, you can hit the customer for it and they have to pay for it.

Because inevitably what’s gonna happen is that they’re gonna find that what they said they wanted and what they actually need are two different things. Yeah. So 

look, 

Shane: I think Waterfall actually has a place. I know we all in the, in the Agile world, love to slack it off, but I think it’s fit for purpose.

When the things you want to do have a high level of certainty. 

Murray: I’ve actually done a lot of Waterfall project management because I’ve been required to buy big firms that engage me as a contractor in the past, and it works well when there’s a lot of certainty. I agree with you there. It’s just that the change management process is slow, expensive, and difficult.

Everything ends up becoming. Very expensive. I don’t think I’ve ever done a waterfall project on the original time and budget and scope. There’s always been extra time required, extra dollars required and some reduction in scope and not Cause I’m a bad project manager, I’ve actually been told I’m an excellent project manager, but just cause it’s inevitable.

Cause the problem that your stakeholders thought they had often turns out to be different to what they expected and the solution. It’s not the right solution once you get into coding. Like it could be 70% right? But changes are inevitable, which is where agile, uh, and design thinking and stuff like that really shine.

Yeah. Uh, 

Shane: customer will normally get a number of vendors in to do a bit of a shoot out of some sort, whether it’s an RFP with lots of written words or a bunch of demonstrations or a proof of concept, but they’re really. Spending a minimal amount of time to let the vendors understand their problem and then experiment, iterate on how they’d fix it.

They’re asking for an outta the box answer, and so it’s always fr 

Murray: right. It is tough for the vendor. I know I’ve been on the better side as well. You’ve got four weeks to put in this really complicated fixed price, fixed scope response for millions, sometimes hundreds of millions of dollars. It’s really tough.

You just gotta make a lot of assumptions. So that process is broken, I would say. Yeah. It’s not an agile 

process. 

Shane: It’s not based around inspecting and then adapting and then iterating what you’re doing. So it’s, here’s a bunch of words, thrown it over the fence. You read them and then you come back with a whole lot of certainty and that’s just crazy.

Murray: Exactly. It is crazy. And also it’s strongly favors the incumbent provider who’s in there and actually knows what’s, what’s really going on. Yeah, all of the 

Shane: person that guesses wrong, the person that guesses the lower number and then manages, like you said, through change control to get to the number, but they’ve got the work.

Murray: So I’ll give you an example of this. I was consulting to a major Australian insurance company. That, uh, was doing gigantic digital transformation with several of the big four consulting companies and it was going badly, but that was mainly cuz it was being run as waterfall with scrum water, scrum fall.

And I heard a story from one of the QA managers who was telling us that they had problem and the vendor quoted. 30 days to fix the, the defect or the problem. It was a missed configuration that senior technical people thought that just couldn’t be the case. And they were going on a course run by the vendor to learn how to configure the product.

And one of the guys made the configuration change during the course in an hour just after he’d learned it. So there you. How long did it take? Let’s say two hours. How much did the vendor quote? 30 days. That’s the sort of thing you can see in these sort of arrangements. Yeah. I’d still want to understand what else they had 

Shane: estimated and effort into that.

If it really was 30 days worth of effort for that one hour change, then that’s an. But if they were factoring in all the QA testing, the release, the update training material, maybe not 30 days, but you can see that there’s a lot more effort to to get a done, done product out the door than just making that one conflict change.

No 

Murray: doubt. They had no idea what it was. So they probably said it’s gotta be 30 days. At the time we factory and all the analysis, the design, they’re going backwards and forwards. Our management time, your management time arguing over whether it’s 30 days or. Going through all of our different teams, one after the other, then going through all your teams, one after the other.

Maybe they just had the experience that nothing’s less than 30 days. So they just said 30 days. Yeah. Well 

Shane: maybe they fixed price and fixed scope, the initial delivery, and now they’re just back profit out 

Murray: of the work. Oh, well they had, It was a very legalistic type of situation. 

Shane: It’s interesting that when we talk about agile, we often focus.

The team delivering how we can make will often miss the agility of the organization. How fast can we get those contracts through? What happens when we want to make a change that costs time or money? Those kind of things. Often people don’t focus on and I think they’re just as important. 

Murray: I totally agree with you.

A lot of people I encounter think that Agile is Scrum, which is not. It’s not that Scrum isn’t agile, Scrum is an agile hammer in your toolbox. But agile is a whole workshop and you can do scrum at a team level while doing waterfall. I see a lot of water scrum fall, and nothing really is changing in the organization except the team is doing standups and sprints.

So 

Shane: when I work with a new team, I will often get them to start by adopting some of the Scrum practices. I think they. Light enough and easy enough to understand and to start to experiment with, and they add value. But it’s not the final answer. But to your point, I often see a team start off, you know, start to adopt some of the agile ways of working in some of the Scrum patterns.

And then they really love it, right? They really start to rock it, and then they hit the organization or knowledgeability. Where actually they start to question now, well, why can’t we make these other things as easy or as streamlined or as changing as as the way we work? And they just hit the ceiling, this 

Murray: barrier when they get outside their team.

I find Scrum is a really good starting point for teams. It’s a way for teams to learn how to manage themselves. The retrospectives and the reviews, I think are the most important part of it I’ve found. Teams where I’ve implemented Agile that they have started to perform really well, but as you say, they can improve the things that they are in control of.

But pretty soon they’re going to be coming up with blockers that are outside their control within a couple of months that they’re gonna be hitting those sort of blockers, and that’s where they need management support and they often don’t get. In fact, managers can often be quite negative when teams raise issues in retrospectives about the the way things are organized outside the team.

One that picked my interest is we 

Shane: were talking, if you’re an external vendor and you are working with an organization that says they’re agile, but they’re throwing an RFP document over the fence, we’ve written words for you to answer and then give price certainty. What do you do about it? What have you seen that people do to reduce the risk?

Without walking away, have you seen any good things I’ve yet to find a good example of an agile contract that doesn’t just say time and material. Cause that’s obviously the most agile of all. Cause you could change anything with the relevant cost and consequences. But have you seen some good ways that vendors can engage with organizations to a, have a contract but leave a bit of agility in there when they’re doing the work?

Murray: Yes. I got stuck in the contract writing when I was. General manager at a digital agency. We moved to agile ways of working to save the company. It was in big trouble due to over promising and under costing. I ended up having to spend a lot of time with clients and procurement people negotiating contracts.

So what I ended up doing was saying, We are selling you a team for a number of sprints and. We think that this work will take X sprints, like let’s say 10 sprints or 20 sprints or. And the goal is to achieve these business objectives, but the scope is going to be defined one sprint at a time by agreement between us as the vendor and the client represented by the product owner.

So the scope will vary depending on what we learn along the way. And we’ll only agree on the scope for each sprint at the beginning of that sprint, and then we’ll review it at the end. There’s a price of X dollars per sprint for a team, and we will work with you to get the best business value out of the time and money available, but we are not going to be extending the sprint to meet last minute Skype items.

That’s the way I did it, and the procurement people actually. Accepted that, although they did wanna know what the deliverables were. So I said, Well, each sprint we’re going to give you a sprint plan and we are going to complete software with tests and we’re going to have completed user stories and management reports and working software.

And I said, Oh, okay, good. I like 

Shane: that idea because when I’m coaching data and analytics teams, we use a similar approach. So the idea that you have. A bunch of work that you could do, it gets prioritized. One of the differences with data analytics teams is our product owner tends to change over a number of iterations.

So we may have to deliver a pricing profitability model with a dashboard. So we will typically get our product owner out of that financial marketing team, and then we may have to deliver HR leave dashboard. And data to support it. And so we’d get a product owner out of the HR area that’s really focused on, on the value of that.

So our product donors kind of come in and out and we’ve got the same problem, which is, well, how long do they get? It’s almost a contract. We use the same technique where we say, Well actually it’s the product owner you, you’re allowed to use three iterations. To get as much work as done as possible, and then we’re gonna move on to the next product owner, the next highest product for the organization.

And that time boxing. That ability for the product owner to know they’ve only got this amount of time really helps them make value decisions and trade off decisions of what they’re gonna get delivered and what they’re not, because they know that there’s that fixed wall coming at the end of that term.

I thought I kind of heard that same pattern coming through with the way you were doing it. 

Murray: That’s how I dealt with the delivery contracts. But before then, there’s gotta be some basic analysis, design scoping. I came up with an initiation approach, so two weeks of customer research, design and prototyping, and then two weeks of architecture estimating, planning, and prioritizing to really size it and get a preliminary.

Product backlog. Yeah, so, so 

Shane: as you started talking, I heard sprint zero, which I think’s bullshit, but then as you keep talking, I, I heard groom the backlog, which I love. So I think people have to be careful that they’re doing the, the grooming of the backlog at the beginning, cuz that’s important. They’re not doing a sprint zero, which is, you know, six months of everybody just randomly building some stuff cuz they think they might need it in the.

So for me, I, I about you, I still see a lot of people talk about Sprint Zero, and I’m 

Murray: not a great fan of it. So development is very expensive. It takes a lot of time and effort is very complicated. So I think developers need to, to be effective and efficient, need to have a pretty good idea of what they’re gonna do before they start doing it.

And certainly you need that before you can say, this is gonna take about 10 sprints for a team of. So I think that there’s a need for project initiation that helps the client build up their business case. And from the client side, I need that to go and ask for money. So 

Shane: I’m hearing a bit of project words coming through the business.

Case one is one that’s always been a struggle because there’s a tendency for lots of planning and estimating and guessing what’s gonna happen. To go and get permission to do that work. But then somehow our stakeholders treat that as a promise, a promise of what will be delivered for that amount of money.

So we have to balance out having a, a quick guess upfront. Versus that behavior of lots of analysis, which will never be used to get, you know, an estimate that we get held to, even though we all know 

it 

Murray: was a case. Yeah, I agree with you, Shane. I’ve run waterfall projects where we’ve spent nine months doing analysis, design and planning for 10 million project, big, big telco waterfall methodology.

They were helpful to get the money and stakeholders. But it wasn’t that accurate. Things changed a lot. I felt there was a lot of waste. Problem I have is when people say, Oh, you said planning, therefore your waterfall, therefore you are saying 12 months, and that’s all. Wait, there’s something in between a month planning with a subset of the team for a big project.

I think that’s very helpful and just have no planning at all. It’s just. It’s just not viable. 

Shane: Don’t get me wrong, I’m not saying no planning, just like I, I never say no documentation, which is number one of the little things people try to use when they go down the agile path is we don’t do documentation, and that’s s we do the right documentation at the right time.

And it’s the same with planning. When a team are walking into a piece of work that it’s been well grouped, they are much more effective at understanding what that work is and how they’re gonna deliver it. And so, you’re right, it’s that balance between. The right amount of planning upfront at adds value because walk in with no plannings a nightmare.

Nobody actually knows what they’re gonna work on and spend a lot more time discussing there. But also that 12 months of planning is not great either. So it’s just that balance of the right amount of planning upfront. So there is this idea of three Amigo, the idea that actually there is a small team of people that right at the beginning do some light planning to set the scene and the vision and the prioritization, and get that ready before the rest of the team start onboarding for the delivery of it.

And I’ve seen that as a good way of balancing out the cost of that planning. 

Murray: See, here’s the question. How many developers do you need and how would you know that if you didn’t do any planning? Yeah, 

Shane: so this is where I have a preference for what I call the pipeline. Uh, and it comes back to that vendor conversation.

So my view is outsourcing the work to somebody else is a project behavior. Having a team of people that can do work as part of our organization is an agile behavior. And so we form teams of people that can work together to deliver something. They have the T skills to do all the work themselves. And then our conversation now is, Okay, squad A are coming free because they’ve finished the last piece that they were asked to deliver.

Is this work that’s within their domain? Can they deliver it? Yes. Here’s the description of the work as a team. What’s it gonna take 

Murray: to deliver it? How long is it gonna take the team or Shane? Cuz I have a marketing launch I’ve gotta do. Yeah, 

Shane: so what we’re doing is we’re putting artificial constraints in place.

I have picked a date for that marketing launch based on pulling something up. My bu. And now I’m gonna tell the team that they have to make 

Murray: it, but I have to have it launched on that date, Shane, cuz that’s when our big annual sales and marketing conference is. And also, I know my competitor’s gonna be launching something at that conference.

Shane: Yeah, so you then pick a team of people until ’em to start, and then you start descoping. You start trading off what you’re not gonna get to meet that date. Because what we know is scaling teams on the same piece of works hard. If we have a team of five and then we add three other teams of five to work on that same product, that actually gives us a real problem From a scaling point of view, it doesn’t make us a lot faster.

By adding more people, we get a whole of other problems we have to deal with. So while we often have to do it, we should ideally plan in advance to say, We have this marketing launch. It’s really important we have this date. What’s the line amount of planning we can do front to give us a guest of how many 

Murray: people, 

Shane: how many squads for how long?

And then it started on time. What tends to happen? People leave it to the last minute and then expect everybody to move heaven and earth to deliver this thing in an unreasonable timeframe. 

Murray: I agree with nearly everything you said there. I, I actually really like the product model where you have a permanent, cross-functional, co-located, hated client focus team or product focus team that has everybody you need.

To deliver a product, including all the business and marketing people. So the user experience designer, product manager, and an operations analyst, and all the business people, some project management supports, make sure they get the money they need. And as the developers and everybody else, I’m a big fan of bringing the work to the team and have the team focus on a product or a client or maybe a market.

But I know. It’s really difficult to get business managers to approve a budget for something or a time for something unless you are able to give them some envelope. Now, that doesn’t mean a fixed scope, and this is where I think a lot of agile people start immediately going, Oh, you are saying you want an envelope, So that means it must be fixed scope.

No. I’m a big fan of variables, scope, agile projects that have a fixed time and cost, cuz that’s actually really easy. It’s actually much easier to deliver an Agile project on time and on budget. Where the set of goals, if the details are, are variable, which they should be. If you’re doing something like Scrum.

Yeah. So 

Shane: again, use that project word. And so with the project word comes a whole lot of behaviors that I see when I deal with large organizations. It’s this idea that we fund projects, we don’t fund teams to consistently deliver value, and then we just prioritize which values. We see projects as beginning and ending.

Yet most teams are building something that has in life. It has to be maintained. It has to be reinvested in, especially in the software or data space. I 

Murray: agree with you. I just don’t think projects are going away and not ever, They will never go away. Although products and permanent teams, Great projects are not going away.

I think it’s bullshit to say that projects are going away cause they’re not. 

Shane: So you are saying that the behavior of organizations that can be deemed as a project isn’t going away, or we’re just gonna keep using the word project for pieces of 

Murray: work. Where you coming from? Well, I think this is stupid to say, Oh, we don’t have projects anymore.

We just have large epics. Well, you know, come on, it’s you’re treating them exactly the same way. So 

Shane: I think terminology is really important. I think terminology is where a lot of us get held up when we are talking to each other in the agile world. And so, again, I wouldn’t use the word epic because for me, Epic has a whole description definition, which probably doesn’t match yours.

But I’m with you. I just don’t like the term project because it comes with so much baggage. So I think a term needs to be used, which talks about a piece of work being. But it can’t be bound to that concept of a project because of all the baggage that 

Murray: comes with. I don’t agree. I think that you can have agile projects with a variable scope.

The project management industry’s been talking about this for a long time. There’s something called rolling wave planning. There’s something called adaptive planning and evolving and evolutionary planning. Rolling wide planning is pretty much the same as scrum and continuous adaptive planning is pretty much the same as can.

The project management community has actually been quite good about bringing in agile ideas and making them much more part of project management. The Empire State Building was built with a rolling wave planning approach, quite Scrum like. It’s always been possible to do projects that way. It just never saw them very much.

Yeah. Look, 

Shane: I, I agree that a lot of the agile patterns that we adopt have been around for years. I mean, you mentioned doing XP and we adopt a lot of the XP processes. We adopt a lot of the lean thinking because it has value. We adopt the car bar on board when we do scrum. What’s your view then on Agile project managers?

When somebody is actually advertising on job board things says we want an agile project manager. Cause that that gets my go up. You’re confusing me. Are you running waterfall or are you having an agile way of working or you trying some kind of hybrid? If you’re doing a hybrid, what is it? Right. 

Murray: I don’t have a problem with Agile project management.

I think that’s completely fine. Some things have to be fixed in a project. It typically has a fixed time and a fixed budget. Agile works very well with fixed time and fixed budget. If you have a goal and you allow the scope to vary through a product backlog, I’ve done lots of it and it works well at business.

Managers want that and they’re not gonna stop wanting it. And if you say, We don’t do that anymore, they’ll just say, Well get somebody else. So you’ve got a choice here. Do you want to. Do agile the right way within those kind of constraints? Or do you want them to go off and choose some idiot who’s just gonna pretend and actually do water scrum fall?

Cause that’s what will happen. So I think if I’m in the client’s shoes, I don’t have a problem with saying to my business stakeholders, Yeah, we can do a project for you, but I wanna do it in an agile way. And then do it properly in an agile way. I think that’s fine. But I think what happens though, Shane, is that there’s a really large amount of fake agile water scrum fall out there.

But that is coming from a mindset problem. So there’s a lot of project managers who are very controlling, hierarchical. They just don’t trust their team. Those people are sometimes scrum masters. I’ve met Scrum masters who are just horrible because they’ve just carried over that traditional project management mindset.

But I’ve also worked with quite a lot of Agile project managers who genuinely have a servant leadership mindset. So it’s really that mindset that is the issue, not whether you are. In a project or if you’re working as part of an ongoing product delivery stream. 

Shane: Yeah, so I think you know there from right of the.

Because I was not on the journey until the last bit where you said that you’ve seen project managers who have behaved as servant leaders enabled the team to get the work done and unblock the barriers that the team strike on a regular basis. And if we look at the definition of a scrum master, that’s what’s written down.

So if there are people that have behaved, uh, as agile leaders, For their whole careers working in a, in a project or in a waterfall construct. But there are also people that have been taught that command and control behavior through that waterfall construct and then try and apply it. And when a team’s working in an agile way, and that’s where we cause the 

Murray: problems, I think.

When I was at a digital agency, we were working with a, a large company and they employed a agile project manager who was a certified scrum master, and this person spent their entire time trying to micromanage us in a traditional project management way, which was completely unnecessary. What we wanted them to do was to liaise with the rest of the organization on our behalf and make sure that all the other teams involved, like the ops teams and various interfacing.

Teams were able to provide us with the interfaces and the environments and other things we needed, and this person just didn’t see that as being their role. And they were a certified Scrum Alliance scrum master, but they were just a traditional hard ass. Project. Managers saw their job as giving the vendor a hard time, and the Scrum master certification didn’t make any difference.

But on the other hand, I’ve worked with some brilliant servant leaders who were project manager. So it’s not the title that matters, it’s the mindset. It’s the philosophy, It’s the frameworks that you use. That’s what matters. Yeah, and that’s why Agile’s 

Shane: not Scrum. I think we get into these religious wars of project versus agile, whereas we often see some agile behavior and projects, and then we’ll often see some project behavior with agile teams.

You know, 

Murray: Scrum was a project management methodology. Ken Schwaber wrote a book called Agile Project Management with Scrum. It’s released in 2004, and he as described Scrum as a project management process, and he uses that sort of terminology over a hundred times. So first of all, he says it was a process and now they say it’s a framework.

And he said it was all about managing projects and now say’s about products. So that’s what he said. Then now saying something different, so the Scrum people will say that it’s evolved and that’s good. It’s good that it’s evolved. But you know, that’s where it started 

Shane: from. Okay. Well I think we’ve done our time, so let’s close this one out.

We can talk about that 

Murray: more another time. There’s a lot of strengths in Scrum and a few weaknesses, and I really like Scrum band, so we can talk about that another day. 

Shane: Yeah, so look, summing up for me, I think we get stuck on the terminology. We get often stuck on the word, not the behavior, and I. That needs to change.

We need to be able to look at how people are working, understand the principles they’re applying and the patterns they’re using, and then figure out how we can help them do it better by iterating, rather than saying, We’re Waterfall, where project management or Scrum or, I think they, or have values when used them the right way.

So the, the most important thing is to call bullshit. When people say those things are good or bad, it. Things we can use to work in a better way. 

Murray: What about you? I think there’s some ways of working, which are definitely much better than others. I really hate water. Scrum fall. I think it’s bad. Do Waterfall or do agile?

The mix is probably worse. I think what we’re trying to do today is just learn a bit more about each other. One thing I forgot to say at the start is I have a small consulting company called Evolve, and I help people, help managers with all of this. 

Shane: Well, look, I think we’re gonna be good. I think we both come from different backgrounds and different experiences, but on the, on the same philosophy and the same path.

So I’m looking forward. 

Murray: Okay. Thanks Shane. Excellent. Catch you later. That was the No Nonsense Agile Podcast from Murray Robinson and Shane Gibson. If you’d like help with Agile contact murray evolve.co. That’s evolve with the Zero. Thanks for listening.