Agile Contracting and Planning
Wed, 7/14 5:21 PM • 49:29
Join Murray Robinson and Shane Gibson in a no-nonsense discussion on agile and waterfall. In this podcast, we talk about our experience with agile and waterfall projects, what really happens when you contract out a project, why waterfall costs clients a lot more, why project procurement is broken, agile team structures, organisation limits on team agility, water-scum-fall and other bad behaviour by big vendors. Planning an agile initiative and fixed price fixed time agile projects. Project Managers and the Agile mindset.
Listen to the Podcast on your favourite app
Shane Gibson
Welcome to the no-nonsense Agile podcast. I'm Shane Gibson.
Murray Robinson
And I'm Murray Robinson,
Shane Gibson
I'm looking forward to starting this podcast series where you and I have some pretty robust conversations around Agile, call out some of the nonsense we see and enhance some of the things that we believe are important.
Murray Robinson
That's what I want to do. I've seen too many podcasts that are lightweight, sales-oriented, intro-level things. So instead, I want to explore some of the issues, the negatives and better ways of doing things.
Shane Gibson
The same with me. I've listened to lots of podcasts over the years. And, some of them, for me, are basic one on one intros. 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 different. That's because I come out of a little country called New Zealand, and Murray comes out of a slightly big country to my west called Australia. So let’s do some intros.
Murray Robinson
I have been in the digital industry since the beginning. I started my career as a software developer in the mid-80s. I've been a Business Analyst, Project Manager, Scrum Master, Product Manager, Program Manager and General manager. I’ve had C level roles and worked in digital agencies, giant telcos and the financial sector. I’ve managed teams of 100 people and budgets of up to 20 million and small teams without budgets. So I feel like I've done a lot in the industry. I started with Agile 17 years ago at a large Australian online jobs board, where the architect and I talked about it and then implemented it. Agile for us was XP. We had great success with it. I loved it, and 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. Back in those days, even until 2010, it was still pretty odd for somebody to be saying, let's do Agile. Now it's all the rage. I should say that I'm not just interested in Agile; I’m interested in all things in digital product development. So when I talk about Agile, I'm often mixing in Lean and Design Thinking.
Shane Gibson
I started my career working for a government agency here in New Zealand, and I got a job in the accounts payable team. I quickly learned that processing invoices weren’t a love of mine. But I was lucky enough to fall into a group of people in that organisation who replaced 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 organisations, I moved on to the vendor side. It's been around 12 to 15 years on that side of the fence doing what we call pre-sales or sales engineer roles. Our job was to convince the customer that our software would solve the problem they had. We let the sales guy close and then got the hell out of 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 short amount of time, which I loved. And from there, I moved on to consulting in the data and analytics space and started a small consulting firm here in New Zealand, where we help customers solve their data and analytics problems. And that's when I heard the word Agile. I saw it around, and I thought it was this peculiar religion. It was probably eight, nine years ago. So it was about 2013. And I saw these hippies out there during these age-old dances and Kumbaya and saying how good it was. But it was always open to experimentation. So we started experimenting a little bit using Agile ways of working and Agile patterns for our work. Because we knew that, a lot of the way we worked as a consulting company was broken. This idea of large requirements upfront and six months guessing, doing a lot of work to guess how long it would take, was flawed.
Murray Robinson
I think the large consulting companies like Waterfall. They know that the customers will only engage them if they come in with a low price. So they price work low and then screw clients on change requests by charging ten times the actual cost for everything. That seems to be the business model for a lot of the big consulting companies I've seen.
Shane Gibson
Or even the small ones. We talk about the consulting permit scheme. That's where the most senior people go in at the beginning and then exit as fast as possible. Then the least experienced people go in and try and do the work. And then the people at the top of the pyramid fly back in when things go wrong. So no transparency is one of the corner rules with that way of working because you don't want the customer understanding the poor value they're getting.
Murray Robinson
I agree. Waterfall is essential for screwing your customer in that way. Having a fixed scope upfront makes it clear what the changes are. Then, if you have a strict change control process, you can hit the customer for all the changes, and they have to pay. Because inevitably, what's going to happen is that they will find that what they said they wanted and what they need are two different things.
Shane Gibson
I think Waterfall has a place. I know we all in the Agile world love to slag it off. But I think it's fit for purpose when you have a high level of certainty.
Murray Robinson
I agree with you. I've done a lot of Waterfall project management because companies required it. It works well when there's a lot of certainties. And it does have a change management process in it; for dealing with changes. It's just that the change management process is slow, expensive and complicated. And so, everything ends up becoming very expensive. I don't think I've ever done a Waterfall project in the original time, budget, and scope. There's always been extra time required, extra dollars required and some reduction in scope. It’s not because I'm a bad project manager; it’s because it's inevitable that the problem that your stakeholders thought they had turned out to be different from what they expected. The solution that the architects and the pre salespeople came up with is not the right solution. Once you get into coding, you find that the plan could be only 50% to 80% right. Agile, Design Thinking and other new ways of working shine when there is any change.
Shane Gibson
When you're on that side of the fence, if you think about the process we use, a customer would typically get several vendors and do a bit of a shootout of some sort, whether its an RFP with lots of written words or a bunch of demonstrations or a proof of concept. But they're spending a minimal amount of time to let the vendors understand the problem and then experiment and iterate on how they'd fix it. They're asking for an out of the box answer. And so, it's always fraught.
Murray Robinson
It is challenging for the vendor. I know, I've been on the bidder side as well; you’ve got four weeks to put in this complicated fixed price, fixed scope response for millions, sometimes hundreds of millions of dollars. It's tough. You’ve just got to make many assumptions. The RFP process is broken.
Shane Gibson
It's not an Agile process. It's not based on inspecting and adapting, and iterating what you're doing. It's, here's a bunch of words thrown over the fence, you read them, and then you come back with a whole lot of certainty. It’s just crazy.
Murray Robinson
It is crazy, and it strongly favours the incumbent provider who's in there and knows what's going on.
Shane Gibson
Or the person that guesses wrong. The person that assumes the lower number and then manages, through change control, to get to the correct number once they've got the work.
Murray Robinson
I'll give you an example. I consulted with a major Australian insurance company doing a massive digital transformation with three of the Big Four consulting companies. It was going pretty badly because it was run as a Water-Scrum-fall program. One of the QA managers told us that the vendor quoted 30 days to fix a missed configuration. The architects and the Senior Technical people thought that just couldn't be the case. 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 in an hour when he knew how to do it. So there you go; it took two hours, and the vendor quoted thirty days. That's the sort of thing you see in these engagements.
Shane Gibson
I'd still want to understand what else they had estimated. If it was 30 days worth of effort for that one hour change, then that's important. But if they were factoring in all the QA, testing the release, updating all the training material, maybe not 30 days, but you can see that there's a lot more effort to get a done product out the door than just making it.
Murray Robinson
No doubt, the supplier had no idea what the estimate was. So they said it's got to be 30 days by the time we factor in all the analysis, the design, the going backwards and forwards, and our management time arguing over whether it's 30 days or not. Going through all our different teams, 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.
Shane Gibson
Or maybe they fixed priced and fixed scoped the initial delivery, and now they're just clawing back their profit.
Murray Robinson
They were. It was a very legalistic situation.
Shane Gibson
It's interesting that when we talk about Agile, we often focus on the team delivering and how we can make them Agile. We often miss the agility of the organisation. How fast can we get those contracts through? What happens when we want to make a change that costs time or money? Those kinds of things often people don't focus on, and I think they’re just as important.
Murray Robinson
I agree with you. Many people think that Agile is Scrum, which it’s not. It’s not that Scrum isn't Agile. Scrum is like an Agile hammer in your toolbox. But Agile is a whole workshop. You can do Scrum at a team level while doing Waterfall. I see a lot of water Scrum fall. Nothing is changing in the organisation, except the team is doing stand-ups and sprints.
Shane Gibson
When I work with a new team, I will often get them to adopt some scrum practices. Because for me, I think they are light enough and easy enough to understand and to begin to experiment with, and they add value. But it's not the final answer. But to your point, I often see a team start to adopt some of the Agile ways of working and some of the scrum patterns, and then they love it; they begin to rock it. And then they hit the rest of the organisation that isn’t Agile, and they start to question, why can't we make these other things as straightforward or as streamlined as the way we work? And they just hit this ceiling, this barrier, when they get outside the team.
Murray Robinson
I agree with you. I love Scrum, although I’m also quite critical of it. I find Scrum is an excellent starting point for teams. And the best part about it is that it's a way for teams to learn how to manage themselves. The retrospectives are the best part of it. I've found that teams where I've implemented Agile have performed very well. But as you say, they can improve the things they are in control of, but they will soon be coming up against blockers outside their control. I would say within a couple of months, they’re going to be hitting those sort of blockers. And that's where they need management support, and they often don't get it. Managers can often be quite hostile when teams raise issues in retrospectives about how things are organised outside the group.
Shane Gibson
Let's pick one of the podcasts and do destructive behaviours of managers when they're engaging with Agile teams because I think it's a whole no-nonsense conversation we could have. But I'm thinking about this one that piqued my interest as we talked, and that's this idea of if you're an external vendor. You’re working with an organisation that says they're Agile but are showing behaviours like throwing an RFP document over the fence with written words for you to answer and then give price certainty. What do you do about it? What are the things you’ve seen that people do to reduce the risk without walking away? Have you seen any good stuff? I've yet to find an example of an Agile contract that doesn't say time and material. A time and materials contract is the most Agile of all agreements because you can change anything with the relevant costs and consequences. Have you seen some good ways that vendors can engage with organisations to have a contract but leave a bit of agility in there when they're doing the work?
Murray Robinson
I negotiated many contracts when I was a general manager at a digital agency. We moved to Agile ways of working because the company was in big trouble due to overpromising and underestimating. I ended up spending a lot of time with clients and procurement people negotiating contracts. What I ended up doing was saying that we're selling you a team for several Sprint's. We think that this work will take X sprint's to achieve these business objectives. The scope will be defined one sprint at a time, by agreement between us as a vendor and the client represented by the Product Owner. So the scope will vary depending on what we learn along the way. 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. We will charge you sprint by sprint at 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're not going to be extending the sprint to meet last-minute scope items. That's how I did it, and the procurement people accepted it, although they wanted to know what the deliverables were. So I said, each sprint, we're going to give you a sprint plan, we're going to complete software with tests, we're going to have completed user stories, and we're going to have completed management reports and working software. And they said, okay, good, done.
Shane Gibson
I like that idea. When I'm coaching data and analytics teams, we use a similar approach. You have a bunch of work that you could do that gets prioritised. One of the differences with data and analytics teams is that our Product Owner tends to change over iterations. So, we may have to get a Product Owner out of the financial marketing team to help us deliver a pricing profitability dashboard. Then we may need a Product Owner out of the HR area to help us design some HR leave dashboards. So our Product Owners come in and out. And we've got the same problem, which is, how long do they get. It's almost a contract. And we use the same technique where we say, Well, actually, as the Product Owner, you're allowed to use three iterations to get as much work as done as possible. Then we're going to move on to the following product or the next highest priority for the organisation. It’s easier for the Product Owner to make value and trade-off decisions when they can see a fixed end date coming. I thought I heard that same pattern coming through in the way you're doing it.
Murray Robinson
Yes, but before that, there's got to be some fundamental analysis, design and scope. So, I came up with an approach of a sprint or two of initiation. Two weeks of customer research, design and prototyping and then two weeks of architecture, estimating, planning and prioritising to get a preliminary product backlog.
Shane Gibson
So as you started talking, I heard sprint zero, which I think is nonsense. But then, as you kept talking, I got out of that and heard starting to groom the backlog, which I love. I think people have to be careful that they’re grooming the backlog at the beginning because it's essential. They're not doing a sprint zero, which is six months of everybody just randomly building some stuff because they think they might need it in the future. I still see a lot of people talk about sprint zero, and I'm not a great fan of that.
Murray Robinson
Development is costly. It takes a lot of time and effort and is very complicated. So for developers to be effective and efficient, they need to have a pretty good idea of what they're going to do before they start doing it. And you need that before; you can say that this initiative will take about 10 Sprints for a team of 10. You need to have some idea to build up some trust and some confidence. 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.
Shane Gibson
I'm hearing a few project words coming through and business case words. The business case is one that's always been a struggle because there's a tendency for lots of planning, estimating and guessing what's going to happen to get permission to do the work. But then stakeholders treat that as a promise of what will be delivered for that amount of money. So we have to balance out having a quick guess upfront of what this will take versus that behaviour of lots of analysis (which will never be used) to get an estimate that we get held to even though we all know it was a guess.
Murray Robinson
I agree with you, Shane. I've run Telco Waterfall projects, where we've spent nine months doing analysis design and planning for a $10 million project. The results were helpful to get money and to get stakeholders on board. And the organisation required it to be able to give you any money and allow you to engage vendors. But it wasn't that accurate. Things changed a lot. So there was a lot of waste. But we have to be careful not to get into black and white thinking. There's a lot of that in the Agile community, particularly in Scrum, where there's no planning before you start. You just start planning on the first day, and the alternative is thought to be 12 months of Waterfall. So people believe planning means Waterfall, which represents 12 months of wasted planning. But there's something in between, like a month of planning with a subset of the team. For a big project, that's very helpful, and just to have no planning at all is not viable.
Shane Gibson
So don't get me wrong. I'm not saying no planning, just like I never say no documentation, which is another one of the little things people try to say when they go down the Agile path is that we don't do documentation. And that's rubbish; 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 has been well-groomed, they are much more effective at understanding what that work is and how they're going to deliver it. So you're right; it’s that balance between the right amount of planning up front that adds value. Because walking in with no planning is a nightmare.
Nobody knows what they're going to work on, and they spent a lot more time discussing that. But also, 12 months of a massive amount of planning is not great either. So it's just that balance of, have the right amount of planning upfront. So, there is this idea of three amigos. A small team of people do some light planning at the beginning to set the scene, the vision and the priorities before the rest of the team come on for delivery. So, I've seen that as a good way of balancing out the cost of that planning. But also making sure it's available when the team are ready to start work.
Murray Robinson
Well, here's the question, how many developers do you need? And how would you know that if you didn't do any planning?
Shane Gibson
So this is where I have a preference for what I call the pipeline. And it goes back to that vendor compensation. My view is that outsourcing the work to somebody else is a project behaviour. Having a team of people that can do work as part of our organisation is an Agile behaviour. So we form teams or squads, or whatever you want to call it, of people that can work together to deliver something. They have the T skills to do all the work themselves. Then our conversation now is okay; a squad is coming free because they finished the last piece that they were asked to deliver. Is this work that's within the domain? Can they deliver it? Yes. Cool. Here is the work description; as a team, what will it take to deliver it?
Murray Robinson
How long does it take the team, Shane, because I have a marketing launch?
Shane Gibson
So again, 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 out of my bum. And now I'm going to tell the team that they have to make it.
Murray Robinson
I have to have it launched on that date, because that's when the big annual industry conference is, and I know my competitor will be launching something at that conference.
Shane Gibson
So you then pick a team of people and tell them to start, and then you begin descoping. You start trading off what you're not going to get to make that day because scaling teams on the same work is complex. If we have a team of five, and then we add three other groups of five to work on that same product, that same deliverable, that 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 lot of other issues we have to deal with. We need to find the right amount of planning to do upfront to guess how many people or squads we need for how long and then get started on time. In my view, what tends to happen is 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 Robinson
So I agree with nearly everything you said. I like the product model, where you have a permanent, cross-functional, colocated client or product-focused team with everyone you need to deliver a product. The product team has a user experience designer, a product manager, an operations analyst, business and marketing people and some project management support to make sure you get the money you need. And it has the developers and everybody else. I'm a big fan of bringing the work to the team and focusing on a product, a client, or a market. But I know that it's challenging to get business managers to approve a budget for something or a time for something unless you can give them a budget envelope. Now, that doesn't mean a fixed scope. And this is where I think many Agile people believe that a limited budget means it must be fixed scope. No. I'm a big fan of variable scope Agile projects that have a fixed time and cost. It's much easier to deliver an Agile project on time and budget with a set of goals if the details are variable, which they should be if you're doing something like Scrum.
Shane Gibson
So again, you use that project word, and with a project comes many behaviours that I see when I deal with large organisations. It's this idea that we fund projects. We don't fund teams to deliver value consistently. We see projects as beginning and ending. Yet most teams are building something that has a long life; it has to be maintained, it has to be reinvested, especially in the software or data space.
Murray Robinson
I agree with you. I just don't think projects are going away, not ever. They will never go away. That's my view. Although products and permanent teams are great, projects are not going away. I don't care what people say. I think it's nonsense to say that projects are going away.
Shane Gibson
So are you saying that organisations’ project behaviour doesn't go away? Or we're just going to keep using the word project for pieces of work? Where are you coming from on that one?
Murray Robinson
Both. So I've worked for digital companies that built and maintained a product over a long period with internal Agile teams. And they talked about projects and did their work with projects. The reason was that, apart from the technology people, there were a lot of other people who had to be organised to help. So one particular type of project needed customer service people and business development people. Then the next one after that wouldn’t need them anymore, but it would need more time from the technical performance people.
Shane Gibson
So if we said they had to develop a bunch of features in a limited term. Is that what you're talking about? Because it's saying that there's a beginning and an end to a piece of work.
Murray Robinson
If you want to call it a big epic, you can call it that. But that's just linguistics. I think it’s stupid to say, Oh, we don't have projects anymore; we just have large epics. Well, come on, your treating them the same way.
Shane Gibson
I think terminology is essential. I believe language is where many of us get held up when talking to each other in the Agile world. So again, I wouldn't use the word epic because, for me, an epic has a description and definition, which probably doesn't match yours, but I'm with you. I just don't like the term project because it comes with a lot of baggage. So again, a term needs to be used, which talks about a piece of work being done, but it can't be bound to that concept of a project because of all the baggage that comes with it.
Murray Robinson
I disagree. I think that you can have Agile projects with a variable scope. The project management industry has been talking about this for a long time. There's something called rolling wave planning, and there's something called adaptive planning and evolutionary planning. Rolling wave planning is pretty much the same as Scrum, and continuous adaptive planning is pretty much the same as Kanban. The project management community has been quite good about bringing in Agile ideas and making them part of project management. They were doing it back in the day. For example, the Empire State Building was built with a rolling wave planning approach that was quite Scrum like. So, it's always been possible to do projects that way. You just never saw them very much.
Shane Gibson
I agree that a lot of the Agile patterns we adopt have been around for years. I mean, you mentioned doing XP. And again, we adopt a lot of the XP processes; we adopt much Lean thinking because it has value. We adopt the Kanban board when we do Scrum. What's your view, then, on Agile project managers? What do you think when somebody advertises on Seek for an Agile Project Manager? Because that gets my goat up. You're confusing me. Are you running Waterfall, or are you having an Agile way of working? Are you trying some kind of hybrid? If you're doing a combination? What is it? Where do the chips lie? Which of the Agile techniques are you adopting, and which of the Waterfall techniques are you adopting?
Murray Robinson
So, first of all, you know that the majority of Scrum masters are ex project managers.
Shane Gibson
I didn't say that wasn't true; I just said I don’t like it.
Murray Robinson
I don't have a problem with Agile Project Management. I think that's completely fine. I think you can have Agile projects with self-managing teams with some things that are fixed. The main difference between a project and a product is that a project has a set time and a fixed budget. Agile works very well with a fixed time and fixed budget. You have a goal, and you allow the scope to vary through the product backlog. I've done lots of it. And it works well. Stakeholders, managers and business managers want a fixed time and budget, and they're not going to stop wanting it. If you say that we don't do that anymore, they'll just get somebody else. So you've got a choice here. Do you want to do Agile the right way within those kinds of constraints, or do you want them to go off and choose some idiot who's going to pretend they know Agile and do Water-Scrum-fall? Because that's what will happen. If I'm in the clients’ shoes, I don't have a problem with saying to my business stakeholders; we can do a project for you. But I want to 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, is that there's a considerable amount of fake Agile and Water-Scrum-fall out there. But that is coming from a mindset problem. There's a lot of managers and project managers who are very controlling and hierarchical. They just don't trust their teams. And those people are sometimes Scrum masters. I've met Scrum masters who are just terrible because they’ve carried over that traditional project management mindset. But I've also worked with many Agile project managers who genuinely have a servant leadership mindset. So it's that mindset. That is the issue, not whether you're working with a project or if you're working as part of an ongoing product delivery stream.
Shane Gibson
I think you nailed it for me right at the end. I was not on the journey until the last bit, where you said that you’d seen project managers who behaved as servant leaders and enabled the team to get the work done and unblock the barriers that the team strike regularly. And if we look at the definition of a scrum master, that's what's written down. So for me, there are people that have behaved as Agile leaders for their whole careers, working in a project or a Waterfall construct. But there are people taught that command and control behaviour through that Waterfall type of construct who then try and apply it when teams are working in an Agile way, and that's where we cause the problems, I think.
Murray Robinson
When I was at a digital agency, we worked with a large company that employed an Agile project manager who was a certified Scrum Master. This person spent their entire time trying to micromanage us in a traditional project management way, which was utterly unnecessary. We wanted them to liaise with the rest of the organisation on our behalf and make sure that the other teams involved, like the ops teams and various interfacing teams, provided us with the interfaces and environments we needed. This person just didn't see that as their role, and they were a Scrum Alliance Certified Scrum Master. They were just a traditional hard arse project manager who saw their job as giving the vendor a hard time, so that's what they did. The scrum master certification didn't make any difference. On the other hand, I've worked with some brilliant servant leaders who were called Project managers. It's not the title that matters. It’s the mindset. It's the philosophy and the frameworks you use that matter.
Shane Gibson
And that's why we say Agile is not Scrum. Scrum is valuable when you're trying to adopt an Agile way of working. We get into these religious wars of a project versus Agile, whereas we often see some Agile behaviour in projects. Then we'll often see some project behaviour with Agile teams.
Murray Robinson
Did you know that Scrum was a project management methodology? Ken Schwaber, one of the two founders of Scrum, wrote a book called Agile Project Management with Scrum in 2004. He describes Scrum as a project management process, and he uses that terminology over 100 times. Now they say it's a product development framework. The scrum people will say that it's evolved, and fair enough, that's good that it’s developed. But that's where it started.
Shane Gibson
Okay, well, I think it looks like we're we've done our time. So let's close this one out.
Murray Robinson
We can talk about that more another time. There are many strengths in Scrum and a few weaknesses. I like Scrumban. So we can talk about that another day.
Shane Gibson
To sum up. We often get stuck on the terminology; we often get stuck on the word, not the behaviour. And I think that needs to change. We need to look at how people are working, understand the principles they’re applying and patterns they’re using, and figure out how to help them do it better by iterating. Rather than saying, we're Waterfall or were project management, or we're Scrum, or we're Lean, I think they all have values when used in the right way. For me, the most important thing is to call nonsense when people say those things are good or bad. They're just things we can use to work in a better way. What about you?
Murray Robinson
Look, I think there are some ways of working which are much better than others. I hate Water-Scrum-fall. I think it's terrible. Do Waterfall, or do Agile, the mix is probably worse. I forgot to say at the start that I have a small consulting company like you, which is called Ev0lve. I help managers with all of this. So if anybody's got to the end of this, they can always ask for my help. Same with you, Shane, I'm sure.
Shane Gibson
All right. Well, look, I think, I think we're going to be good. I believe these discussions are going to be fiery. I think we both come from different backgrounds and have different experiences, but we are on the same path. So I think we will be calling nonsense quite a bit over the next while as we record some more, so I'm looking forward to it.