Join Murray Robinson and Shane Gibson in a no-nonsense agile discussion. In this podcast, we talk about our experience with planning agile initiatives. How to do just enough planning just in time. We discuss the team you need, user stories, UX concepts and technical architecture, how to develop a release plan and estimate time and cost in a 2 to 4-week timebox. We also talk about the common traps, pitfalls and bad patterns we see in planning agile initiatives.

Read along you will

Murray: This is the No Nonsense Agile podcast. Join us for weekly discussions on Agile product development and leadership with world class experts who provide valuable insights and practical advice for industry professionals. Subscribe now to learn the latest trends and best practices in the field. 

In this episode, we talk about planning agile initiatives. How do you do just enough planning just in time? We’ll discuss the team you need to plan your features, user experience and technical architecture. And we talk about how to develop a release plan and estimate time and cost in a two to four week time box. 

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

Murray: And I’m Murray Robinson.

Shane: Hey, Murray. Good to see you again. It’s our second one of these. And today we’ve decided that we’re gonna talk about agile initiation and I think project initiation. So for me, it’s the work we do early, the work we do up front, the big chunk of work that if we get it done, makes life easier in the future. But we don’t wanna spend, six months on a sprint zero or a year on, a waterfall type beginning before we start building some stuff that has value and learning from that experience.

Murray: Yeah my experience shows that organizations normally spend half their time and a third of their budget doing planning and initiation work before they start coding.

Let’s say you have an initiative and you end up spending nine months doing development work. Other people will probably have spent the same amount of time and a large amount of the budget working out the requirements and so on. Was talking to somebody yesterday who’ve been working with one of the big consulting companies who just spent six months and, had a team of people doing initiation for a digital project. It’s a long time and a lot of money. And in my experience, a large amount of it is wasted .Because there’s a lot of uncertainty about the requirements and the solution. So when you get into it, you find that you have to start changing quite a lot of things.

Shane: Yeah, I call it the big guess upfront, whether we are doing requirements upfront or we are doing cost estimation upfront, or, we’re building out that perfect roadmap of whatever iteration’s gonna deliver and what date it’s gonna deliver. We’re, we have a mound of uncertainty and we’re guessing upfront, so let’s do a guess, but let’s make the time we spend on the guests equals the value we get outta that guess. I suppose one of the other antipas I’ve seen though is when we use the word agile, but we’re behaving ad hoc and that’s the idea that we do no planning. We just magically walk in and a team start building stuff and deliver, and there is no plan, there is no work done upfront. And for me, that’s as bad as those large big guess upfronts initiation processes. It needs to be a balance. What’d you say half the time and a third of the budget, was that the number you use?

Murray: That’s normal.

Shane: What should it be? Does it depend on how long the piece of work is, if we are thinking about something that we are guessing will take 12 months to deliver with what we know, should we time box our planning phases at the beginning? Based on that, is there a minimum viable number of weeks or months we should always do regardless of how long the work is?.

Murray: Yes, we should time box it. I have a way of planning, a six or 12 month project in two weeks by getting a team of people together. But, it has an assumption that you understand what the customer problem is, and you’ve done some customer discovery and some market research. 

But sometimes you haven’t done that at all. All you know is that you are not getting enough leads or something like that. So you need to go and do some, customer interviews to decide amongst a number of options what you’re going to potentially build. In that case, you might take another two weeks to do that, but certainly no more than a month, Shane, somewhere between two weeks and four weeks is plenty in my opinion. For planning out your initiative and developing your business case, working out , your high level user experience design, your customer journeys, your architecture roadmap, that sort of thing.

Shane: So what should the initiation cover. I think you talked about customer acquisition is a problem you wanna solve. For us in the data world, we’re often talk about, we have a bunch of data we know sits there and we are thinking it can help us make better decisions based on profitability or lifetime value . And we often get pushed to define the scope, cuz we should have some idea of what we will and won’t deliver, but we don’t want to go down into a hundred page PID document. So I tend to use visioning statement that came out of Jeffrey Moore as a way of really quickly getting, a one page sentence that gives us an idea of what’s in and outta scope and we can do it relatively quickly. What do you do in that two to four weeks, how do you typically get an understanding of scope at a level that makes sense without over baking it?

Murray: So I use a combination of design thinking and agile, so I’m going to assume here that we know what the custom problem is that we need to solve.

Shane: One of the challenges I find is we often think we do, but when we articulate it, somebody else has a different view of that problem. 

Murray: Yes, I would do it in two steps. The first step. find out the problem that you need to solve and the second one is work out how to solve it. So if you don’t know what the problem is that you need to solve, then you need to start by agreeing that it’s worth putting some time and effort into it. You get a group of people together and you start by defining your objectives and the kind of, outcomes you wanna see. And then you need to start talking to customers and subject matter experts within your organization and doing some market research . Then you can come up with a whole lot of ideas. You Can do prioritization to work out which ones are best to pursue. Then I would come up with some user experience design concepts. I’d probably mock up some advertising and I’d do a customer journey. And then within a few days I would be putting that in front of customers. and I would be saying, okay, here’s what we want to do. Here’s what we understand. Your problem is, is this really a problem for you? If so, can we just talk through what are you doing to solve it now? And what could be done better? And then let’s just talk through some ideas we had, see what you think, get your feedback, maybe show you some stuff we’ve got on paper. Maybe show you an ad that we’ve mocked up for a potential couple of products or solutions and get your feedback on that. So that sort of thing I think can be done by non-technical people. So I would do that with say a user experience designer, a product manager some sort of agile coach or facilitator. Probably a team of three or four people could do two iterations of that in two weeks. So I like to say on every Thursday we wanna have real customers coming in and, asking them what they think. So I’d probably go through about. Three or four possible solutions in two weeks to see which gets the best feedback from customers and users.

Shane: And so you treat that as initiation. 

Murray: That’s what I would call discovering the right problem to solve. Usually when I get engaged, people have already gone well beyond that and they are pretty certain on the customer or business problem to solve. And what they want to do is to work out, how big is it? How long is it gonna take, how much is it gonna cost? What are we gonna do, what’s the scope? In that case, I would take a different approach and I would have a much more technical people involved. I would have the user experience designer, the product manager, and some sort of agile coach or facilitator. And I would add to it, technical architecture architect, subject matter experts, some other key technical people. And we would flesh out the product solution and at the same time we would flesh out the user experience and we would flesh out the technical solution by doing architecture models and point to point proof of concepts. 

Shane: So what I think I heard was, initiation could include understanding the outcome that they want to achieve and the problem that it’s gonna solve, so we have a shared understanding of what good looks like if we deliver this thing. Then I heard that sometimes the initiation phase may involve some early prototyping, where we want to go and do some research spikes or get an understanding of what’s possible. Put those in front of some of our customers to understand what has value. And then after that we have a better idea of what we should build and who we are building it for. So we’re doing that early to make sure we’re building the right things. And that can be done in an initiation.

Murray: Yeah, that’s about the business problem, the product, and the customer problem. 

Shane: Yep. .And then the third one is that whole platform technology getting ready to run, so if we go into a green fields and there’s nothing in place, we need to do some agile architecture around what are the moving parts we need? My world, it’s what parts of a data platform do we have to have him in on day one for the team to start executing? And what can we build as they’re going? From an app dev point of view, I’m assuming that’s things like, what framework are we gonna build the front end and what’s our back end? What kind of microservices architecture, if that’s what we’re doing, are we gonna do so some early guesses on that, so that we can start that work. 

And so all those things can be done as part of an initiation phase, you just have to be clear which ones you’re gonna do early and which ones you’re gonna do as the teams are developing the value.

Murray: Yeah, And it’s done by time, boxing everything, so my view is that, a perfect solution is gonna take an infinite amount of time, but a good solution can be done, in a couple of hours with people who know what they’re doing. So you need to plan on the basis that, you’re just coming up with something which is good enough to get you in the right direction, in the right ballpark, with the right amount of money and the right sort of team, and then you’re gonna re-plan that as you go.

Given that, I reckon you’d come up with the solution architecture model, the first version of it by the end of day two. So day one I would do what’s a business challenge and, how are we gonna work together? Then what are the business objectives and the results you expect? and who are the customers? What’s their journey? What do we think the product features are? What is the service gonna look like? I’d do that on day one. Then on day two, I’d be, exploring the current technical environment and the potential solution model.

Shane: And is that based on a team of experts? A team of people that have done similar things before. So there’s a level of certainty in that , once they know the problem statement and once they know the type of thing that needs to be built to solve it, they’ve done that kind of thing before. They’re not going into an area where they have no expertise. They’re having to learn a whole lot of new things, because if that’s the case, that’s unlikely to be done in a day. 

Murray: They do need to be very experienced people. A solution architect, a senior user experience designer, senior agile coach, a business domain expert, a product manager, a technical domain expert, that sort of person. Probably about half of the team are gonna be in the company already because they have to understand the business, the current technical domain, and , the customer. And then usually I find that a number of those people need to come from outside. Particularly somebody to facilitate and, organize the whole thing cuz people usually haven’t done this sort of initiation quickly before. And often a solution architect and, user experience designer if the company doesn’t have , senior enough people. So I’m all about having a cross-functional team that works together full time for two weeks to get this done.

Shane: Yeah, I agree with you on the cross-functional. I talk about T skills, so making sure the team have a breadth of skills amongst themselves that they’re self-sustaining. They’re able to do all the work themselves rather than having to hand something off to another team or another group of people. So you need that. , the ability for, each of the team members to deep dive when they have to on the bits they’re really good at, they have expertise in, but they also need to have skills in the other areas so that cross-functional team is there. 

So, Nirvana for me is a bunch of people who are permanent, who are dedicated to doing this work for a long time. If we’re building out data products, they’re gonna build data products for the next couple of years because there’s lots of data products to be built and that’s gonna be their focus.

But often we deal with organizations that are project oriented. They don’t have a team of people that are sitting there who are gonna do this work and learn how to do it. They have this theory, they’re gonna start the work, it’s gonna take some time, and then they’ll stop the work, or the work will be handed over to a B A U team. And when we see that behavior, we get asked a question, how long and how much? 

Murray: Yeah. 

Shane: And that’s before we’re allowed to go in and do that initial discovery stuff. 

So do you say to them we need to do the discovery first. It’s gonna be two to four weeks of effort of this type of team. And then we’ll give a guess of how long it is. Do you do an initial guess early based on your experience and say, we need to do the discovery work to, do a little bit more investigation and refine our guess a bit better? How do you approach it?

Murray: So I approach it with a fixed price and fixed time to do the discovery work, fixed price, fixed time, fixed team time boxed. And the outcome of that includes an estimate, a plan, an architecture, a user experience design concept, product concept, and a whole lot of feedback from customers and testing of a technical poc. So bring it all together at the end with a plan. And also during that process I take the stakeholders on a journey of understanding what it means to do an agile project. That the detailed scope is not fixed. What we do is we say, okay, the scope is defined by the goals that we’re trying to achieve and by a certain limited amount of time and money and team but the detailed requirements and technical design solution are not part of any sort of fixed scope. They are variable. We’re gonna develop a plan for you but that plan is gonna change every two weeks based on what we learn.

Shane: I hate the word plan as much as I hate the word project, but if I, if replace the word plan with roadmap. Then I get exactly the same behavior. 

Murray: It’s basically the same thing, shane. 

Shane: No, because I think that when we use plan, we get a game chart. We worry when the plan changes, versus when I use the word roadmap, people seem to be more open to the fact that it’s a guess and we can reprioritize and it’s okay cuz we are just changing when things happen in the roadmap. And yeah, I know it’s semantics, for me changing the term, to a different shared language somehow makes it easier.

So if we think about that discovery, So we’ve both seen it when large consulting firms use the discovery phrase as a weapon. Everything’s a discovery phase. It’s three to six months of discovery. 12 to 15 novice consultants come in to do the discovery using techniques that they’ve never used before. They create a raft of documentation that looks like requirements. And it doesn’t really give us a lot of value. 

What’s your experience in that? Cause I’m liking this idea of time boxing it, if discovery of two to four weeks means you have to be pretty clinical about who you’re gonna engage with, what artifacts you’re gonna create, cuz you just don’t have time to create too much.

Murray: Yeah, time boxing is critical, but what’s also critical for me is getting real feedback multiple times during that two weeks, real feedback from customers and real technical feedback by developing a a technical POC and actually implementing elements of it. So for example, if a client or company said that, they really needed a new e-commerce platform and the thinking of some sort of cloud solution, you do some work with them, you work out what they’ve got, you come up with something.

But by day three, I want the technical architects hands-on implementing staff and connecting to real data. So by the end of the first week, they’re able to say things like the data you need is not available, or It’s very difficult to access, or this particular person is a bottleneck because they’re the only one who knows anything. Or , we realize we need to use some different, interface modules on the cloud to integrate with your particular Microsoft Dynamics database. I’ve got a particular example in mind, actually, I won’t say who it is.

Shane: I thought you might have you were getting quite specific there. 

Murray: and, Adobe Experience Manager cost an absolute fortune, so why are we even thinking about that? And so on. I was helping the client out on their side and they’d engaged a large design agency. And we tried to take them through all of this, and I kept saying all this sort of stuff, but it wasn’t until quite far into the project that we could actually get any of the technical people in that supplier to do any sort of technical POC where they were getting onto real data and using it. And when they did, they had these major shocks and discoveries and roadblocks. I wanna find that out in the first week or certainly the first two weeks, Shane not later on.

Shane: Yeah. And I suppose it depends what technology you’re using. So , I think when you’re doing your initiation piece, you’re really wanting to identify the ones that are just there and easy, and then the ones that you’re gonna burn some time on. So I think it’s the same thing you are saying, do that prefer capability.

Murray: And try and get a narrow, thin proof of concept that goes all the way through. 

Shane: yeah. Steel thread.

Murray: Yeah. To go back to what you were saying, what’s my experience with big consultancies? Spending a lot of time. I saw one of the really big famous consultancies had spent an enormous amount of time and money, in initiation with a large team of people. And they wrote all of these very, very detailed user stories. And the client told me that they’d found that the same requirement was developed over a hundred times because they had so many people. Every time somebody mentioned it, a different person would write a story for it. They did have a big picture but this big picture and the detailed user stories just didn’t connect at all. Nobody could work out what the connection was between them. It was just a real waste of time and it was extremely confusing for everybody and caused a lot of problems.

Shane: Yeah, and I think we see that in documentation, so I’ll go down the documentation part and then I’ll come back to the initiation view of it. One of the things I really hate, one of the antipas that I call bullshit on is when people say Agile says there’s no documentation, there’s just crap. If we are building stuff, we need to document it, we need to document it in the right way at the right time. And so then the question comes back to what does that mean? And for me, what it means is we create a document that has value because it’s gonna take effort. And how do we know what the value of the document is? We should be able to articulate what action’s gonna be taken with that document. So if somebody reads the document, what are we expecting them to be able to do as a result of reading it? And by doing that, we can understand the value that document has, and therefore decide whether we need to create it right now or not.

So if I take that back to the initiation piece of work, we should say we are gonna produce this thing and this thing’s gonna be used for this action during the delivery. And so therefore, let’s do it, but let’s make sure it’s, fit for purpose for that.

So if I go back to what you were talking about, user stories have value. They are a great pattern because they’re well known. So documenting some really high level user stories that map back to that strategy or roadmap or architectural blueprint. That probably has value, because we are getting a set of high level features that we can use to understand what will be done first versus second versus third. Some real t-shirt sizing maybe on how much each one would take to give us a timeline of how long this might take if all things go well. But if we’re down to, user stories at a really low level and they’re rolling up to features and they’re rolling up to epics and we’ve got, 200 user stories now in the initiation piece, we’re probably over baking it, we’re we do one or two things. If we’ve time boxed it, it means somebody’s bought out their user story catalog and ticked the box to generate the user stories for you without engaging with anybody. Or we are spending three months with 12 people creating those user stories.

Murray: I don’t create user stories at all during project initiation or this sort of initiative roadmap planning. What I do with people is I get them to identify the features of the product that we’re going to build and any technical components that we need to build to support those product features. And then we estimate their size and their value and their likely cost. So we end up with a kind of prioritized product backlog at a feature or a technical component level, much higher than a user story. And maybe we will have a hundred things in there. 

I have a way of doing estimation very quickly. I can take a team and estimate a hundred things in an hour, quite easily, using a process called Affinity mapping or silent estimation. Have you heard of that, Shane? 

Shane: It sounds familiar and I’ve probably done something along the lines.

Murray: Look what stakeholders want out of an, out of some sort of initiation is they wanna know how long is this gonna take to achieve my objective? How much is it gonna cost? How many people have to be involved. So you have to answer that question. And you can do that by focusing on the objective and not the detail of the solution or the requirements.

But what I do is I’ll brainstorm with people what the features are and components. And then affinity mapping works like this. You put out your Fibonacci sequence on the table the old 1, 2, 3, 5, 8, 13 type of thing, up to say 40. And then we’ve got this group of people who’ve been developing these ideas about what it is we are gonna be building. And we’ve got all of the, things we’re gonna build on individual sticky notes. And I just ask the group, what is the simplest, easiest thing for us to build. Let’s agree on what that is and we’ll call that a one. So that’ll be our baseline of our ruler. And then what is the most, biggest, most complex thing, most unknown thing? Let’s call that 40 . It usually doesn’t take long to agree on that cuz we’re not actually trying to get dollars or anything. We’re just trying to say relatively, what’s the smallest, what’s the biggest? And then I just divide up all of the features which are on cards. Everybody’s got maybe, 10 or 15. , I just say silently put them down where you think they should go without talking to other people. And then once you’re done, we’ll step back, we’ll all look at it. And then I want everybody to pick up something and move it if they think it’s wrong. Just move it to where they really think it should go and what we’re trying to do. And if the person who put it down disagrees, they can put it back. But what we’re looking for is those things that there starts to be disagreement about and things starting to bounce out around. And then we’ll take those out and we’ll define what they are and what our assumptions are in more detail. And then once we’ve agreed, we will put it back in. 

Often it’s because somebody will say you said you want product search, but what is it? Is that out of the box or do you want some special thing or, I’m assuming that we don’t need to do anything cuz this product already has search in it, so I’m gonna give it a one, somebody else says, no, we need to set up the data categories and tags and things for it. So that’s like a medium and somebody else says, but I assumed that it had a unique three level search and that’s huge. So they’re just a quick agreement on what it is. And then maybe we agree it’s the middle one. Estimation is always based on assumptions so let’s just make some assumptions, write it down, make the estimate, and then if the assumptions change, we’ve got a good reason to re-estimate, but all we’re doing at this point is just doing what I would call relative estimation. So you can easily do that in an hour with a hundred things using this approach chain. 

Shane: and you’re doing that at a feature level, 

Murray: Feature in some technical components, that are not part of a feature. What I would call enabling components.

Shane: Okay. So that goes on the assumption that the team that are doing that work have done this type of work before. So they’re using a shared language. So when we know we’re building an e-commerce store and somebody goes, we need product search, everybody knows what that is. They’ve all seen one before and

Murray: That’s correct. Yes. So we’re doing this towards the end. So the technical people in the team have had, a week and a half of digging into this and doing POCs and reading stuff about things that they didn’t know.

Shane: Ah, so they’ve already done some hands on research work to get to this stage. Okay, that makes sense.

Murray: Yeah.

Shane: Cool. And then for feature, so let’s take product search, is the only artifact we produce are sticky with the word product search or is in the initiation piece is they’re a little bit more behind it. is there anything else 

Murray: I’ll write it up as a feature. It can be in a spreadsheet, it can be in Trello or Jira or something like that. Or it could be in MIRO or Trello or whatever you want, but basically what you’re doing is you’re writing down the assumptions you made about it as you were going through this time boxed initiation. 

You’re not trying to write detailed user requirements. You’re not trying to write it as a user story. You’re just trying to write down what you thought it was when you were estimating it based on the kind of planning you’ve been doing. So just usually bullet points. And you put it somewhere so people can come back to it later.

Apart from that, I would put a business value and a size. So, You know how he said we are doing affinity estimation. How big is it? I also get people to write the size of it on the sticky note. And then we say, all right, now we’re gonna do the same thing. From the point of view of business value, what has the least business value and what has the most business value, in business value points?

Shane: So just going back, so what I think I heard you say around the documentation of those features is, that you are documenting the features in a way where there is future value, there’s an action you can take, and the action you were saying was, When we looked at that feature call product search that we said was 13 points. We’ve got some bullet points that told us what we were thinking. It was what our assumptions were to create it. And so that documentation has value, because it allows you to remember the conversations you had. So for me, that’s good, that’s a light piece of documentation that has value cuz there’s an action we expect to take with it later. 

So coming back to business value. So again, you are just creating a series of buckets from low value to high value, and then you are crowdsourcing a bunch of people to then decide which bucket it feels right in. And that’s enough. You’re not going down to return on investments, you’re not going down to total cost of ownership versus anything. You’re not going to any real level of detail because it’s just not valuable yet, 

Murray: exactly. It’s just not valuable yet. And it’s, it would take a lot of work to go down to that level. It’s just not something that’s worth doing during initiative planning. If you’re going to do return on investment, you should be doing it on the whole product not on features

Shane: And the outcome the outcome that product will have, not the features it’s got. 

Murray: Yeah. Exactly. Yeah. So you we’ve started at the beginning in this scenario by saying what’s the business problem? What’s our goal and what are the outcomes we wanna achieve? And those outcomes should be in things that are measurable. New customers sales leads, customer engagements, cost reductions. So that’s a goal. But it’s also a way to justify what you’re doing. And then what you’re doing is you’re working out well, how can we achieve that goal, in a reasonable time? What’s the best way to achieve it? 

Shane: so when you’ve got your ruler for value with low value and high value, you’re using a lens of, given the goals and outcomes we want to achieve. 

Murray: yep.

Shane: This feature is less likely to get us to that goal than another feature, or more likely to get us to that goal than another feature, if we do this feature first, we’re more likely to achieve that outcome, to achieve that value that we defined upfront. Okay, so that makes sense to me. 

Murray: So we just do business value points, and then what we do is we do release planning by saying, let’s do the things that have the highest value for money first. So I’ve got something that’s 10 points of business value and two points of size. That’s a five to one ratio. So I wanna do that early, but then I have a technical person who will say, no, you can’t do that until you put this component in. So I’ll say, from a product point of view, I don’t really understand the business value of that technical component, but I do see that we have to have it before we can get this thing I really want, so we can go put in that technical thing first.

Shane: Okay, so you allow the team to override it with a sequencing where the sequencing makes sense from efficiency of delivery. 

Murray: Yeah. So what I basically do is then say, all right. We’ll do a, release roadmap now. Okay, so we’ve spent an hour, we’ve got hundred things. We’ve got the business value estimate, we’ve got the size estimate. Now we can spend another hour. We can do a roadmap, which is, first I get people to do all the highest business value for money first, and then we’ll gradually work our way down to lower value for money at the end.

Then I’ll ask them to say, all right, now does this make sense? Could you actually do it this way? And we do it by sprint. So is there a theme for the first sprint? Is this work together in the second sprint and so on? And I ask the technical people to go in and start moving the things around. Cause what will happen is the business people will just ignore the technical things and say, I don’t know about this. So they’ll just won’t put it on their roadmap and then ask the technical people to come in and just put, the technical things where they need to go. Often though, technical people will want to do these huge technical platform pieces before any business value is delivered.

Shane: Sprint zero, give us six months and we’ll build the best shiny platform that does everything you want. I actually had one of those was working with a team and they had a legacy data platform and they were building a new one out. They were really experienced people so their initial behavior was, give us six months to build the platform out. And I said, yeah we tend not to do that anymore because there’s a chance you’re gonna guess wrong. And, they said no, we know exactly, what we need. And I went, okay, let’s shorten it a little bit. So I think they did a month or two. And that was all good. So they did a great job. And then we had to bring in our first source of data and they had assumed that the first source of data was gonna be the major source system for that organization, which happens to be based on a relational database.

So they’d put in the technology that allowed us to connect to that database, suck that data in. Unfortunately, the organization had just gone live with a contact center application that was cloud-based. And that project had descoped all of the operational reporting for that contact center. So it goes live, the call center agents are able to take the calls and type in all the notes, but they have absolutely no visibility of how many calls they’ve taken, how long the queue is, all those really good things that you need as a call center to operate well. So the data team got told right highest priority right now from a business value point of view is bringing that. Unfortunately that data was based on a cloud application. That re only way to get to it was through a bunch of APIs, and they hadn’t built the component on the platform to be able to call data from an api. First thing they did is go away and build. That did a great job. But again, it was that whole idea that you can guess what the most important thing is and get it right every time. And often you can’t. So , I’m a great fan of doing some planning and some work upfront if it makes us more efficient in the future. But if we have to timebox it.

Murray: Also, Shane, the business priorities, as you say, can change during that time. so if you spent millions and six months building some platform, then everything could’ve changed around you and business, people could’ve lost interest cause you haven’t delivered any value to that they can see. And so they pull your funding, 

Shane: Or technology changes. The thing that you’ve spent a month crafting because you couldn’t find anything three months later, a software as a service thing turns up that’s good enough to do that for you without you doing all that effort. Again, it’s that plan for a horizon that has value. Time box it, but don’t plan for the next three years cuz really it’s a waste of time.

Murray: Yeah. So let’s say we’ve got some product features and the technical people say, okay, but we gotta spend six months building a platform first. I would say, this technical platform is too big. Break it down into a whole lot of relatively independent components. I wanna see components that we can do in the sprint, and then let’s just do the components that we need to deliver the first piece of business value. And when you do that, I’ve always found that there’s some parts of that technical platform that you can do in two weeks that will allow you to start delivering business value. And then you do the rest of the technical platform stuff just before you prioritize the product features that are gonna use it. And then if things change, you haven’t wasted all your time building it.

Shane: But that’s hard. That art of decomposing something that’s complex down into smaller chunks, that is a hard thing to learn. I was at a meetup last night and I was talking to somebody that, comes out of one of the large legacy data warehouse database platforms and is working in a large financial institution, been working on a data warehouse that must be eight years so far for that technology to be implemented. And he said, they went agile a year ago, and he really struggled to decompose the work down so it could be delivered in an iteration in two to three weeks. But over time they got better at it and they are now, doing small chunks, delivering it into production in a two week cycle. But it was hard. It was hard to learn. It was hard to do. But they got there and I think it takes time and effort, but it’s worth it.

Murray: I actually haven’t found it hard to get people to do this or to show them how to do it. It’s only ever been a problem of one occasion, we had a solution architect, with a client who just refused to break something down and refused to estimate it. And it turned out that it’s because he didn’t know how to do his job. He wasn’t the expert he claimed to be. He had no idea. We didn’t say anything to him about it at the time. What we said is we’ll just take it off the table and do a spike and we’ll get some people to help you and we’ll spend a week digging into it. And then they came back and, he was then comfortable to accept what these technical advisors were telling him about how to break it down. But if people have strong technical knowledge and a good idea of what they’re doing, even if parts of it are completely new to them, they can usually break it down quite easily into its components. You’ve got all the various interfaces each one of those is obvious, relatively independent component. And you’ve got the technical components within the product package that are usually can be, turned on independently. So there’s lots of ways to doing it. The only way AI would advise not to do it is not to do it by layer. This idea, first we do the front end, then we do the middle, then we do the data. That’s just a disaster. Nobody should ever do that.

Shane: Yeah. And I agree. Yeah. We have a habit in the data world of wanting to grab all data from all source systems and land it first. And only when we’ve done that do we then go and do , the chunky work to interpret the data and make it for purpose. And only when we’ve done that do we start putting the visualizations on top. And yeah, I’m with you. We have to steel thread it all the way through from beginning to end in small chunks because it’s that final result in front of our customer that gives value, gives us feedback, and helps us iterate. So I’m with you on that. Yeah.

Murray: So we’ve done that planning and experimentation and investigation. Those are the spikes. We’ve worked out what the product and the architecture’s gotta look like at a kind of feature level. We’ve worked out what’s high value, what’s low, what’s big, and what’s small. But we haven’t worked out how much it’s gonna cost. And that’s what our business people need to know cause they need to give us some money or some resources. 

So what I do then is I ask this team of people, I say, okay, given this release plan, does this first re first release, like the first month or the first two weeks, does that look doable to you? Just think about what you’ve worked on before. Do you feel confident that you could do that? Let’s assume that apart from the people who’ve been doing this planning, we’re also gonna get in, another four developers and, a quality engineer and a UI designer. So a typical, rounded team. A good team to do this work. And then just in your experience, you reckon that this first two weeks is achievable and they’ll go, ah, move things around. Usually they can tell you really quickly and I’ll say, move some things into the second one. Yeah, it’s the second one. Do you think that’s reasonable? Okay, now what we have is a velocity. We have a team and we have a velocity estimate, which is, let’s say it’s 50 points of size and it’s, all right, we’ve got like this big prioritized backlog of these hundred features and components. Now we know we can do 50 points in the first sprint and the second one let’s spread it all out. So now we know that it’s gonna take this team of 10 people, in six months. They can get this far right, discussing it all again as a team. Do we feel comfortable with that? Do we feel confident? Let’s talk about how we’re gonna do this and the kind of assumptions. Ah, we’re assuming we can deploy ourselves into production, but actually. There’s this deployment group that always takes forever, okay, let’s talk about that. But basically we come to an agreement amongst the people about what’s, quite comfortable. And so then we say, okay, it looks like in six months with a team of people, we can get this far with the goal. The product manager’s there, the customer’s there listening to all this. So you don’t need to explain it again. And , all right that’s how far we think we can get. Maybe it’ll be a bit less, maybe it’ll be a bit more. But if you look at the business value points, we’re getting, 70% of the business value in the first six months. And so that’ll be our plan. And then basically you just write it up.

Shane: and it’s guess good enough, 

Murray: it’s a good enough guess.

Shane: know, Because any more work, any more estimation at any level of detail below that is just, wasted effort. And there’s a high chance that in the next six months something’s gonna change, but at least you can visually see when something new comes in or there’s a major change, you can then show, this is what we guess we were gonna do. We’re now putting something else in there so the stuff at the end’s gonna even drop off. Or it’s in month seven,

Murray: Yeah. It’s a forecast, not a commitment.

Shane: Yeah, it’s a guess. Yeah. 

Murray: you can say it’s a guesstimate, 

Shane: a guesstimate. That’s my favorite term. Because that’s what it is. And that’s okay. 

Murray: It’s a guesstimate by a bunch of experts who should know what they’re doing. 

Shane: Yeah. It’s a good guesstimate,

Murray: Yeah, it’s as good as any, you could spend six months and you wouldn’t get a better guesstimate than that. 

that 

Shane: No. And you’ve lost six months. I think we covered a good chunk there, but I’m liking that process that you use. I think what we’ll do is we’ll put a link in the podcast back to the medium article you’ve written. But takeaway for me, I think is this idea that, time box share, initiation piece of work, because doing some planning upfront has some value. But time boxing, it means you really focus on the things that are most valuable depending your process in terms of how you define what the scope and the goals that you want to achieve are, and the problem you’re trying to solve. And then how you identify who’s gonna do the work and where the gnarly gotchas are gonna be. You may use a , differing bunch of artifacts as part of your initiation piece of work. But that’s okay. And the goal is within two to four weeks, we have a really good guess and have done enough groundwork that we can start running. And therefore that has value. That’s what I’ve taken away from this. What about you, 

Murray: Yeah. Shane before we go I wanna talk about , the other alternative of, we don’t do no planning around here cause we are agile. We’re all scrum . It’s like jazz. We’re a jazz quartet. We’re just improvising as we go. And what’s the problem with that?

Shane: There’s no problem with it. It’s perfect. We don’t have to do a whole month of sitting in meetings doing bloody stupid talking. we’re just coding. 

Murray: That’s it. You’ll get what you want when it’s done.

Shane: Yeah, just gimme, let me code. I don’t wanna be doing this eerie, fairy, fluffy, sticky stuff. Give me the coding window. 

Murray: What’s all this about? Business cases and money. I don’t care about any of that. Yeah, there are people like that. And Scrum doesn’t have a sprint zero. But on the other hand, scrum assumes that somebody has done this kind of work in some way. Scrum assumes that you have a development team and you have an objective, and a goal. And you’ve got a product manager and a product owner, and you basically have a good idea of what you’re trying to do when you start. And then the first sprint, developers just start, exploring it. I guess you’re probably doing technical spikes and things.

Shane: Yeah. So I’ve done that, and , the interesting thing for me is how brutal it is to the team, to the delivery team, to the sprint team. Walking into that room with absolutely no background work done with a product owner sitting there telling them what they want. It is just brutal for the team to be able to catch up and get up to speed and then start doing that work. I think. A small amount of planning upfront has value. I don’t like calling it Sprint zero because again, like a project plan, sprint Zero has a whole lot of inferred behavior that I think is bullshit. But, I like the idea of initiation or a roadmap or, something that talks about, initial planning getting us ready,

Murray: Yeah. I, think that the people who are paying us need to have some idea whether they’re gonna get good value from investing in us or not. They need to know that they’re gonna spend X dollars on achieving some outcome, and it’s gonna be in some reasonable timeframe.

Shane: Excellent. All right, well good to catch up as always, and , I’ll catch you next time.

Murray: All right. Keep it real, Shane. No bullshit.

Shane: No bullshit.

Murray: That was a no nonsense. Agile podcast from Murray Robinson and Shane Gibson. If you’d like help to build great teams that create high value digital products and services, contact Murray evolve.co. That’s evolve. With a zero. Thanks for listening.