Agile initiation and planning
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
Shane: Welcome to the No Nonsense Agile podcast, im Shane Gibson.
Murray: And I’m Murray Robinson.
Shane: Hey, Murray. Good to see you again. Um, kind of our second one of these. So, uh, I think it was last one. The first one was interesting. Uh, we kind of went all over the place talking about lots of really exciting things. So I think as we’ve agreed, we’re gonna kind of start off with a topic.
No doubt we will go over the place a little bit, but, uh, come back on track every now and again. And today we’ve decided that we’re gonna talk about initiation. For me, um, it’s the, the work we do early, the work we do upfront, the big chunk of work that if we get it done, makes life easier in the future.
But we don’t wanna spend, you know, six months on a sprint. Zero. A year, a year on a a, a waterfall type beginning, uh, that we are waiting for everything to be perfect before we we start building some stuff that has value and learning from that experience.
Murray: Yeah, I’ve, I’ve actually written about this quite a lot and I have an article, um, on my medium blog, um, on project roadmaps.
And, um, I’ve, my experience, and I’ve been doing this for a long time and, and some research I’ve done in the industry shows that organizations spend half their time and a third of their budget doing planning and initiation work before they start coding normally. So let’s say you have an initiative and you are, you, you end up spending nine months, uh, Doing development work at other people will probably have spent the same amount of time and large amount of the budget normally, uh, working out the requirements and so on.
And, and, um, I’m was talking to somebody yesterday who’ve been working with one of the big consulting companies, had just said, spent six months and, you know, had a team of people doing initiation for a digital project. And, uh, you know, it’s, it’s a long time and a lot of money and, and in my experience, a large amount of it is wasted because there’s just quite a lot of uncertainty about the requirements and the solutions.
So when you get into it, you find that, um, you, you have to start changing quite a lot of things.
Shane: Yeah, and I mean, I call it the big guess front, right? Whether we’re doing requirements front or we are doing cost estimation upfront, or, you know, we’re building out that perfect roadmap of whatever iteration’s gonna deliver and what date it’s gonna deliver.
Um, you know, we’re, we have a amount of uncertainty and we are guessing upfront, so let’s do a guess. But let’s make it, uh, at the time we spend on the guess equals the value we get outta that. Guess, I suppose one of the other antipas I’ve seen though is, is to, you know, when we use the word add agile, but we’re behaving ad hoc, and that’s the idea that we do no planning, right?
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, as those large big guess upfronts initiation processes, right? So, you know, it needs to be a balance. So, You know, when you talk about, what’d you say? Half, half the time and a third of the budget, is that the number you use?
Yeah, that’s normal. Um, you know, what should it be? You know, does it depend on how long the, the piece of work is? Right? If we are thinking about something that we are guessing will take 12 months to deliver with what we know, you know, should we time box our, our planning phases at the beginning? Um, based on that, is there a minimum viable number of weeks or months we should always do regardless of how long the work
Yes, we should time box it. Um, I, I have a, um, way of, of planning, you know, like a six or 12 month project in two weeks by getting a team of people together. But it, it, it has, it has an assumption that you understand what the customer problem is and you’ve done. Some customer discovery and some market research, right?
But sometimes you haven’t done that at all. Like all you know is that you’re not getting enough leads or something like that. So you need to go and do some, you know, customer interviews, um, to decide amongst a number of options, what, 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.
Um, for, uh, planning out your, your, your initiative and developing your business case, working out your. You know, your high level user experience design, your customer journeys, your architecture roadmap, that sort of thing.
Shane: Yeah. So, um, I was just about to go off on a sidetrack around business case, but I think what we’ll do is we’ll put that one on the backlog and we’ll we’ll spend one of the sessions having a chat, um, about business cases.
Um, so we go back to what should the initiation cover. And, and you know, I think you talked about, uh, you know, customer acquisition is a problem you wanna solve. Um, for us in the data world, we’re often talk about, you know, we have a bunch of data we know sits there, um, and we think that it can help us make better decisions, you know, better decisions based on profitability or lifetime value, those kind of things.
And, uh, so we often get pushed, uh, to define the scope. Um, cause 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 pi document. Um, so I tend to use, uh, visioning statement that came out of Jeffrey Moore, um, as a way of really quickly getting, uh, a one page sentence that gives us an idea of what’s in and outta scope, and we can do it relatively quickly.
Um, what do you do? I mean, how do you, in, 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: Um, sure. So I use a combination of design thinking and agile, so I’m going to assume here that we know what the problem is that we need to solve, right?
What the customer business problem is.
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, right? That that’s okay.
Murray: Well, yes, but I’m, there’s, I would do it in two steps. First, the first step is find out the problem that you need to solve, and the second problem, second one is work out, you know, do some planning around how to solve it, right?
So if you don’t know what the problem is that you, you need to solve, then you need to start by, you start internally 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, your objectives, um, and the kind of, you know, outcomes you wanna see.
And then you need to get pretty quickly into. Um, customer research and market research, cuz if you dunno what the problem is, well could be almost anything. So you need to start talking to customers and subject matter experts within your organization and doing some market research straight away. Then you can come up with a whole lot of ideas.
You can boil it down to, you know, you can do prioritization to work, work out which ones are best to pursue. Then I would come up with some user experience, some design concepts. I’d probably do, I’d probably mock up some advertising and I’d do a customer journey and uh, then within a few days I would be putting that all in front of customers and basically saying, Hey, you know, in face to face interviews or on web these days, I suppose I would be saying, Okay, well here’s what we wanna do, here’s what we understand.
Your problem is. Is this really a problem for you? If so, can we just like talk through what are you doing to solve it now and you know, what could you do, 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 and you know, maybe show you an ad that we’ve mocked up for potential couple of products or solutions and, um, get your feedback on that.
So that sort of thing I think can be done by, uh, non-technical people. So I would do that with, um, say a user experience designer, uh, product manager, um, you know, some, some sort of agile coach or facilitator or somebody like that. Probably a team of three or four people, um, could do that in. Two iterations of that in two weeks.
So I like to say on every, every Thursday we wanna have real customers coming in and, you know, asking them what they think. So I’d probably go through about three or four possible solutions in, in two weeks to see which gets the best feedback from customers and users. And so
Shane: you, you treat that as initiation.
Murray: That’s the, that’s what I would call discovering the right problem to solve. Right. Usually when we get in, when I get engaged, people have already gone well beyond that. And they are pretty certain on the customer business problem to solve. And what they want to do is to work out, you know, Like, how big is it?
How long is it gonna take, How much is it gonna cost? What are we gonna do? What’s a scope? Like you said? In that case, I would take a different approach, um, and I would have a much more technical people involved. So I would, I would have the, those initial people, the user experience are the product manager and some sort of agile coach or facilitator or somebody like that.
And I would add to it, you know, technical architecture, architect, subject matter experts, some other technical key technical people. And we would con, we would flesh out the product solution and at the same time we would, uh, flesh out the, um, user experience and we would flesh out the technical solution by, um, you know, doing architecture models and then, you know, proof of point to point proof of concepts.
Shane: So, yeah, so, so yeah, as I kind of break that down, um, cuz again, you, you come from a different background to me, Right. In terms of, uh, the, the types of things that we’re delivering with the techniques we’re using. So what I think I heard was, you know, initiation could include really the, the initial understanding of the, the outcome that they wanna achieve and, and the problem that it’s gonna solve in writing that up, right?
So we have a, a shared understanding of what, what good looks like if we deliver this. Um, then I heard that sometimes the initiation phase may involve some early prototyping, right? Where we want to go and do some research spikes or, or get an understanding of what’s possible. Uh, put those in front of some of our customers to understand what has value.
Uh, and then after that we have a better idea of what we should build and who we are building it for. So we’re kinda doing that early to make sure we’re building the right things. And that can be done in a, in an initiation part of
Murray: the, the process. Well, yeah. That’s a non-technical activity. That’s about the, the product, the business problem, the product and the customer.
Shane: Problem. And then the third one is that whole, uh, platform technology getting ready to run, right? So we have some, you know, if we go into a greenfield and there’s nothing in place, we need to do some work, we need do a bit of agile architecture around, well, what are the moving parts we need? So, you know, my world, it’s how, you know, what parts of a data platform do we have to have them in on day one for the team to start executing?
And what can we build, um, as they’re going. Um, you know, from an app dev point of view, I’m assuming that’s things like, you know, what framework are we gonna build the front end in? What’s our back end? What kind of microservices architecture, if that’s what we’re doing or we’re gonna do so some early guesses on that, right?
So that we can start that work. Um, and so all those things can be done as part of an initiation phase, right? You just have to be clear which ones you’re gonna do, uh, early and which ones you’re gonna do as the teams developing the value. Is that, Yeah, I
Murray: agree you, yeah. And it’s done by time boxing everything, right?
So, so my view is that, uh, a perfect solution is gonna take an infinite amount of time, but a good solution can be done, you know, in a couple of hours if, with people who know what they’re doing. So a good enough solution. So you need to plan on the basis that, uh, 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, as you go. So given that, I reckon that you can, from a technical architecture point of view, 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, uh, what’s the, what’s the business challenge and, you know, 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? You know, what, what do we think the product features are? What is the service gonna look like? Um, I do that on day one. Then on day two I’d be doing, you know, exploring the, uh, current technical environment, um, and then exploring the, um, the potential solution model.
Shane: And is that based on a team of experts? Right. Uh, team of people that have done similar things before. Um, so there’s a, there’s a level of certainty in that they, you know, once they know the problem statement, uh, 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: Yeah, I’m talking about, I dunno if they have to be like international experts, but they, they do need to be very experienced people.
So, you know, a solution architect for example, is generally kind of level of experience I’m talking about. Um, you know, a user, a senior user experience designer, senior agile coach, a business domain expert, a product manager, a technical domain expert, that sort of person, like probably about half of the team are gonna be in your, in the company already because they have to understand the business, the current technical domain, and the, you know, the, the customer.
And then usually I find that, uh, a number of those people need to come from outside. Um, Particularly somebody to facilitate and, and, you know, organize the whole thing. Cause people usually haven’t done this sort of initiation quickly before. Um, and often a solution architect and, and, you know, a user experience designer if, if the company doesn’t have enough, you know, senior enough people.
So I’m all about having a, what I would call a cross-functional team that works together and, um, you know, it’s pretty intense work. You’ve gotta be able to do it pretty much full-time for, for two weeks to get this done.
Shane: Yeah, I agree with you on the cross-functional. Yeah. I talk about T skills, so making sure the team have a breadth of skills amongst themselves that they can, they’re self sustaining theirself.
Um, they’re able to do all the work themselves, rather having to hand something off to another team or another group of people. So you need that ability for, you know, 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, uh, you know, that cross-functional team is is there.
So, so if we go, go one step before that though, So again, Niana for me is on working with a customer who has a bunch of people who are permanent, who are dedicated to doing this work for a long time. Right. And effectively have a pipeline of. That’s how I call it. So, you know, if we’re building out data products, you know, they’re gonna build data products for the next couple 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 initiative oriented, right? They’re, 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 BAU team mm-hmm.
And when we see that behavior, we get asked a question, how long and how much. Yeah. Um, and that’s before we’re allowed to go in and, and do that, uh, initial discovery stuff. So, What do you do, do you say to them, Well, we need to do the discovery first. You know, it’s gonna be two to four weeks of effort of this type of team.
And then we’ll give you a, a guess of, 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, uh, to, you know, kind of 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, um, and the outcome of that includes a, an estimate, a plan, an architecture, a user experience. Design concept, you know, product concept and a whole lot of feedback from customers and a whole lot of testing of a technical poc. So bring it all together at the end with, um, basically 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, um, you know, the, the detailed scope is not fixed. What we do is we, 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 and, uh, but the detailed requirements and technical design solution are, are not part of any sort of fixed scope.
They are variable. We’re gonna develop a plan for you that, that looks like this cuz we’ve gotta have a plan to start. Otherwise, who knows what direction we’re going in. Um, but, uh, that plan is gonna change every two weeks based on what we learn.
Shane: Yeah. And so, again, um, I, I hate the word plan as much as I hate the word project, but if I, if I replace the weird plan with roadmap Yeah.
Then I, I get exactly, basically thing Shane. Well, no, because I think that, uh, when we use plan, we get a whole lot of behavior. We’ve been taught over many years of what a plan is. You know, it’s a game chart. It’s something that doesn’t, we, we worry when the plan changes. Right. Versus when I use the word roadmap, people seem to be more.
To the fact that it’s a guess and we can reprioritize and it’s okay cuz we are just changing when things happen on the roadmap. And, you know, I know it’s semantics, but you know, for me, uh, changing the term, you know, to a different shared language, uh, somehow makes it easier. Um, so if we think about that discovery phase, so we’ve both seen it when large consulting firms use that, uh, the discovery phrase as a weapon, right?
They go, Oh, everything’s a discovery phase. It’s three to six months of discovery. You know, there’s 12 to 15 novice consultants come in to do the discovery, um, using techniques that they’ve never used before. They create a raft of documentation that looks like requirements. Um, and it doesn’t really give us a lot of value.
So, yeah, what’s your experience in that? Cause I’m liking this idea of time boxing it. Right? With 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. Cause you just don’t have time to create too much.
Murray: Yeah, it’s time.
Boxing is critical, but what’s also critical for me is getting real feedback during multiple times during that two weeks, real feedback from customers and real technical feedback by developing a, uh, a technical POC and actually implementing elements of it. So, for example, if a client or companies said that, you know, they really needed, um, a new.
eCommerce platform and, uh, they, they’re thinking of some sort of cloud solution. Then you, we’ve come, you, you do some work with them, you work out what they’ve got. You come up with something. But then what I wanna see the technical architects doing is, and the technical people, by doing, by day three, I want them hands on implementing staff and, um, connecting to real data, right?
And so by the end of the first week, they’re able to say, uh, things like, uh, 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, um, you know, uh, we, we realize we need to use some different, you know, interface modules on the cloud to integrate with your particular.
Microsoft Dynamics database. I’ve got a particular example in mind actually I heard is
Shane: thought you might have you getting specifically
Murray: and Adobe Experience Manager cost an absolute fortune. So why we even thinking about that and um, uh, so on. But, you know, I want, I wanna get real connections. I was working on a, a project with a client with a, where I was helping the client out on their side and they’d engaged a, quite a, a quite a large, um, consultancy, more one of the design agency types.
Um, and we tried to take them through all of this and I kept saying all this sort of stuff, but it wasn’t until, um, quite far into the project that we could actually get any of the technical people in that, in that supplier. To do any sort of technical POC where they were getting onto real data and, and using it.
And when they did, they had these major shocks and discoveries and roadblocks. So, you know, I wanna find that out in the first week or certainly the first two weeks, Shane. Not, not later on.
Shane: Yeah. And I suppose it depends what technology you’re using, right? So I remember the, the bad old days cuz being in New Zealand where at the end of the world, um, you know, whenever we wanted to add some more compute to our data centers, it was six to eight weeks for, you know, rack servers to be shipped from Singapore.
If, if they manage to manufacture them on time and ship them. Um, so we’ve moved to these cloudy things. But I don’t think we are there yet. I think there are, you know, cloud solutions that are currently available and mature and outta the box, and they really are. You know, go to a screen, click a button and you can start using it.
But I think especially in the data space, we still have a number of components that take. Too long to turn on to architect to make work. Um, so again, I think when you’re doing your initiation piece, you’re really wanting to identify the, the ones that are just there and easy, you know? Yeah. And then the ones that you’re gonna burn some time on.
So I think it’s the same thing you are saying, Right. Do that proof of capability. Right.
Murray: Yeah. And try and, and try and get like a, a, you know, what, what do they call it? Like a narrow, thin proof of concept that goes all the way through. Yeah. Steel thread. Yeah. Like a steel thread. Yeah. Yeah. Um, to go back to what you were saying, what’s my experience with big consultancies?
Um, spending a lot of time. So, um, yeah. I, I saw not that long ago, one of the really big, famous consultancies, um, had spent an enormous amount of time and money. You know, in initiation with a large team of people and they wrote all of these very, very detailed user stories and, um, they were rushing around all over the place.
And, uh, the client told me that when they were doing a review, 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. And there was no, there was no, uh, big it, the big picture.
They did have a big picture cuz they’d engaged another consultancy to do the big picture like two years before. But the, the big that, this was an agile project by the way, and this, um, big picture and the detailed user stories just didn’t connect at all. Nobody could work out what the connection was between them.
So, um, It was just a, a real waste of of time and it was extremely confusing for everybody. And of course a lot of problems.
Shane: Yeah. I think we see that in documentation. Right? So I’ll kind of go down the documentation part and I’ll come back to, to the, the initiation view of it. So, you know, one of the things I really hate, one of the anti patents that I call bullshit on is when people say Agile says there’s no documentation, it’s just crap.
Right? Um, you know, if we are building stuff, we need to document it, right? 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, um, because it’s gonna take effort. And how do we know what the value of the document is?
Well, we should be able to articulate what action’s gonna be taken with that. So if somebody reads the document, what are we expecting them to be able to do as a result of reading it? Yeah. And by doing that, we can understand the value that document has, right? 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, why Yeah. We should do the same thing, right? We should say we are gonna produce this thing, um, and this thing’s gonna be used for this action during the delivery piece. Um, and so therefore, let’s do it. But let’s make sure it’s, you know, for purpose for that.
So if I go back to what you were talking about, you know, user stories have value. They are a great patent because they’re well known. Yeah. Um, so documenting some really high level user stories that map back to that strategy or roadmap or architectural blueprint or whatever the first consultancy did. Uh, that probably has value, right?
Because we kind of we’re getting a set of high level features effectively. That we can use to understand what will be done first versus second versus third. Some real research sizing maybe on how much each one would take to give us a, a timeline of how long this might take if all things go well. But if we’re down to, you know, user stories, uh, at a really low level and they’re rolling up to features and they’re rolling up to epics and we’ve got, you know, 200 user stories now in the initiation piece, we’re probably over baking it, right?
We’re, uh, yeah, we do one or two things. If we’ve time boxed it, it means somebody’s brought out their user story catalog and tick the box to generate the user stories for you without engaging with anybody. Um, or we are spending three months with 12 people creating those user stories.
Murray: Sure. So, um, I don’t create user stories at all during, um, project, uh, Initiation or this sort of planning roadmap, planning phase, I call this, um, initiative, uh, roadmaps.
By the way, that’s what my media article is called. Um, what I do with people is I get them to identify the features of the product that we are 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, their likely cost.
So we end up with a kind of prioritized product backlog with, you know, at, at a, what I would call a feature or a technical component level, much higher than a. Um, a user story and maybe we’ll have a hundred things in there. I don’t know. Uh, I, I have a way of, um, 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.
Not sure if you’re familiar with that or silent estimation. You heard of that, Shane?
Shane: Uh, it, it sounds familiar and I’ve probably done something along the lines, but I’ll probably go, need to read the actual definition to see whether I did a variation of it or something That sounded like it. Yeah.
Murray: Well look what, what, um, stakeholders want out of an, out of some sort of initiation is they want, as you said, 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, Right? So you have to answer that question. Um, and you can do that by focusing on the objective and not the detail of the, of the solution or the requirements. But, um, what I do is I’ll, I’ll brainstorm with people what the features are and components.
And then affinity mapping works like this. You put out your Fi Archie sequence on the table as just like sticky notes, you know, the old 1, 2, 3, 5, 8, 13 type thing. Mm-hmm. up to say 40 or a hundred, whatever you. Yep. And then we, we’ve got this group of people who’ve been developing these ideas about what it is we are gonna be building.
And, um, we’ve got all of the, the, these things we’re gonna build on, on individual sticky notes. And, uh, I just ask the group, what is the simplest, easiest thing for us to, to build, right? And let’s, 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, you know, 40 or a hundred. And then it usually doesn’t take long to agree on that. Cause 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, I just divide up all of the features, which are on cards.
Everybody’s got, maybe I DT 10 or 15. I just say silently, just put them down on this ruler from one to a hundred where you think they should go. Don’t 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 just to just 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, um, 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 will define what they are and what our assumptions are in more detail. And then once we’ve agreed, we’ll put it back in. So, you know, often it’s because somebody will say, uh, you said you want product search, but what is it? Like, is that out of the box or do you want some special thing or, you know, Uh, I’m assuming that we don’t need to do anything cause this product already has search in it, so I’m gonna give it a one, right?
Somebody else says, No, we need to set up the, 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 us unique three level search and blah, blah, blah. And that’s huge. So that’s just a quick agreement what it is. And then maybe we, we agree it’s the middle one and we put it in the middle.
But the point is, what I always say to people is, let’s, 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, well 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, Right.
Murray: Feature and some technical components, you know, that are not part of a effect chain, that what I would call enabling components. Okay.
Shane: So, so that goes on the assumption that the team that are doing that work have done this type of work before.
So Yeah. Using a shared language. So when we know we’re building the eCommerce store and somebody goes, We need product search, everybody knows what that is. Right? They’ve all seen
Murray: one before. That’s that’s correct. Yes. Yeah. Okay. And, and we, we do have, you know, and, and the technical people in the team, so we’re doing this towards the end.
So the technical people in the team have had, you know, a week and a half of digging into this and doing POCs and re reading stuff about things that they didn’t know. Oh,
Shane: right. So they’ve already done some research work. Right. Some hands on research work Yeah. To get to this stage. Okay. That makes sense.
Yeah. Cool. And then for that, Yeah. The, the idea of a feature, so let’s take product search, is the only artifact we produce a sticky with the, the word product search or is in the initiation piece. Is there a little bit more behind it? Is there anything else? Yeah,
Murray: no, there’s more behind it. So, you know, I write it up as, as a feature.
Yeah. Can be in a spreadsheet. It could be in Trello or Jira or something like that. Um, everybody loves Jira these days. Uh, they seem to, Yeah, do like Jira
or Trello, 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 like this time boxed initiation. Um, whatever they are, right? 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 based on the kind of planning you’ve been doing. Um, so just usually bullet points and, um, things like that. Uh, and you, you put it somewhere so people can come back to it later. And you, and I would also put on, apart from that, I would put a, a business value and a si.
So you know how he said we’re doing affinity estimation? How big is it? I also get people to then take all those, to write the, the, the size of it on the, on the sticky note. And then we take them all off again. 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?
What has the most business value? Just in business value points.
Shane: Yeah. So before we get there, so just go back, So what, what I think I heard you say around the documentation of those features Yes. Is it comes back to the point I made that you are documenting the features in a way where there is future value, right?
There’s an action you can take. And the action you were saying was when we looked at that feature called product search that we said was 13 points. Yeah. Um, we’ve got some bullet points that told us kind of what we were thinking. It was kinda what our assumptions were to create it. Um, and so that documentation has value, right?
Because it allows you to remember the conversations you had. So for me, that’s good, right? That’s a, a light piece of documentation that has value cuz there’s an action we expect to take with it later. So, So coming back to business value. Mm. So again, you are. 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 investment, 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. Right,
Murray: exactly. It’s just not valuable yet and it’s, it would take a lot of work to go down to that level, so, you know, it’s just not something that’s worth doing during initiative planning.
I don’t think if, if you’re going to do return on investment, you should be doing it on like the whole product at that point. Not, not on like
Shane: features. And the outcome, right? The, the outcome that product will have, not the features it’s got. Yeah.
Murray: Yeah, exactly. Yeah. So you, we’ve, we’ve started at the beginning in, in this scenario by saying, what’s the business problem?
Um, what’s our goal and what are the outcomes we wanna achieve? Right? And then what we’ve and those outcomes should be in things that are measurable. So, you know, new customers, uh, sales leads, customer engagements, whatever cost reductions, whatever it is.
So that’s a goal. Um, but there’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, you know, in a reasonable time? What’s the best way to achieve it? Um, so,
Shane: so, so, so when you’ve got your ruler for value, right? With low value and high value, you’re using a lens of, given the goals and outcomes we wanna achieve.
Yeah. This feature, uh, is like less likely to get us to that goal than another feature, or more likely to get us to that goal than another feature, right? Yeah. Feature first, we’re more likely to achieve that outcome, to achieve that value that we defined upfront.
Murray: That makes to, so we just do business value points, and then what we do is we do release planning by saying, um, 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. Well, that’s a five to one ratio. So I wanna do that early, but then I have a technical person who’ll saying, No, you can’t do that until you put this component in. So I’ll say, Oh, well, Right. Well, 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 a deliver from, uh, efficiency of delivery.
Murray: Yeah. So what I, what I basically do is then say, All right, or we’ll do a, like 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 one, which is just, let’s just do all the highest business value for money first, and then we’ll just 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?
Like, could you actually do it this way? Is there, is there a theme for the first, 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, 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 that then I ask the technical people to come in and just put, you know, the technical things where they need to go. Often though, technical people will wanna do like these huge technical platform pieces before. Any business values delivered Sprint
Right? Give us six months and we’ll build the best shiny platform that does everything you want. And, and I actually had one of those, so I was working with a team and um, so they had a legacy data platform and they were building a new one out. Um, and so they, yeah, they were really experienced people. So the initial behavior was, give us six months to build the platform out.
And I said, Yeah, we, we tend not to do that anymore because there’s a chance you’re gonna guess wrong. And they’re, they said, No, no, no, We know exactly, you know, what we need. And I went, Okay, well let’s, let’s shorten it a little bit. So we did it, think they did a month or, or two. Um, and that was all good. So they did a great job.
Uh, 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, that organization, which happens to be based on a relational database. So, 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. Um, and that project had descoped all of the operational reporting for that contact center. Yeah. 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, uh, of how many calls you’ve taken, how long the queue is, all those really good things that you kind of need as a call center to, uh, operate.
Well, so the data team got told right. Highest priority right now from a business value point of view is bringing that data. Unfortunately that data was based on a cloud application that 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 cool data from an api.
Mm-hmm. . Um, so, you know, first thing they do 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 yeah, again, I’m, 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, you know, those iteration zeros of a six to 12 month platform build, um, you know, we often don’t get it right. So we, we should
Murray: do that. 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 have changed around you and people could have, the business people could have lost interest cause you haven’t delivered any value to them.
That they can see and so they pull your funding, right. So yeah. Or technology
Shane: changes, right? Other technology changes. Yeah. The thing that you’ve spent a month crafting because you couldn’t find anything three months later, you know, a softwares a service thing turns up that’s good enough to do that for you without you doing all that effort.
So, yeah. Um, again, it’s that plan for a horizon that has value, um, time box it, but don’t plan for the next three years cuz really it’s a waste of time and effort.
Murray: Yeah. So, so what I say to people is, um, you know, 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, no, your, your concept of 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, right? And then let’s just do the components that we need to deliver the first piece of business value.
You know, there should be. I mean, 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 start delivering business value and then you do the rest of the technical platform stuff just before. You know, you prioritize the, the, the product features that are gonna use it.
So, and then if things change, you don’t need, you haven’t wasted all your time building it.
Shane: But that’s hard, right? So, you know, when you, when you’re working with a new team, when I’m coaching a new team, helping them understand that you can take the elephant, that you can break it down into smaller pieces and deliver them one at a time.
And they have value on their own, but yes, there’s more value in that together. But their art of decomposing something that’s complex down into smaller chunks that is. A hard thing to learn, but I was, uh, I was at a meetup last night and, um, I was talking to somebody that was, comes out of one of the large legacy data warehouse database platforms.
Um, and he 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. Um, and he said, you know, they, they went agile was the word he used, uh, 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, he said.
But over time they got better at it and they are now, you know, doing small chunks, delivering it into production in a two week cycle. Yeah, it was hard. It was hard to learn. It was hard to do, but they got there and I think that’s the key, right, is um, it takes time and effort, but it’s worth it. I
Murray: actually haven’t found it hard to get people to do this or to show them how to do it.
I mean, it. It, it’s only ever been a problem when I’ve had, I’m thinking of one occasion, we had a solution architect at, 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, basically, Like he wasn’t the expert he claimed to be.
He had no idea. So, you know, we didn’t say anything to him about it at the time. What we said is, Well, 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. Right? And then they came back and, you know, he was then comfortable to accept what these technical advisors were telling him about how to break it down.
Um, so, but, but if people have a pretty good, I, you know, if they 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. Like you’ve got all the various interfaces, they’re obvious, each one of those is obvious, relatively independent component.
And you’ve got like the, um, technical components within the, the, the product package that, that are usually, um, can be, you know, 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. You know, this I, 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, um, wanting to grab all data from all source systems and land at first. Um, and only when we’ve done that do we then go and do the, you know, 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. Um, and so yeah, I’m with you. We have to steal, 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 the next thing I do, Shane, is so we’ve done that kind of planning and experimentation and investigation, those sort of spikes. We’ve worked out what the. 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. Right. 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 this, this is right towards the end. I say, okay, well 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?
Like, just think about what you’ve worked on before. Do you feel like confident that you could do that? Does this first, given that given this team, alright, well let’s assume that apart from the people who’ve been doing this planning, we’re also gonna get in, you know, another. For developers and, you know, a quality engineer and a a UI designer.
Okay, so a typical well rounded team. Let’s just agree on a, like, like a, a good team to do this work. And then just in your experience, you reckon that this first two weeks is achievable and I’ll go, ah, move things around. Usually I get a good, they can tell you really quickly and I say, move some things into the second one.
Hey, it’s the second one. Do you think that’s reasonable? Okay, Well, now what we have is a velocity. We have a team and we have a, a, a velocity estimate, which is, I dunno, let’s say it’s 50 points of size. And I say, All right, well let’s just like re let’s just now structure, we’ve got like this big prioritized backlog of these hundred features and components.
Now we know we can do like 50 points in the first sprint. And the second one let’s just like, Just spread it all out. So now we know that it’s gonna take this team of that we agreed this team of 10 people, it’s gonna take them 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? You know, 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. You know? Okay, let’s talk about that. But basically we come to an agreement amongst the people about what’s, what’s, you know, quite comfortable.
And um, so then we say, Okay, well it looks like in six months with a team of people, we can get this far with the. The product managers there, the customers there listening to all this. Um, so don’t need to explain it again and, um, was, All right, well, that, 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, you know, 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 and
Shane: it’s guess good enough, right?
Murray: Cause it’s good enough guess.
Shane: Cause it, it’s more work, more estimation at any level of detail.
Below that is just, you know, wasted effort. Right? Um, and there’s a high chance at, 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, well this is what we guess we’re gonna do, right? We’re now putting something else in there.
So the stuff at the end’s gonna either drop off or it’s in month seven.
Murray: Yeah. It’s a forecast, not a commitment. Yeah, it’s a
Murray: Yeah, you can say it’s a guess.
Shane: A guesstimate. A guesstimate. That’s my favorite term. Right. Cause that’s what it is. That’s okay. It’s okay to guesstimate. Cause
Murray: it’s a guesstimate by a bunch of experts who should know what they’re doing.
Yeah. It’s, it’s a,
Shane: it’s a good guesstimate.
Murray: Yeah. It’s as good as any, you could spend the six months and you wouldn’t get a better guesstimate than that.
Shane: No. And you’ve lost six months. Yeah. So, you know, I think where we probably, uh, I think we probably covered a good chunk there, but I’m, I’m liking, um, that process that you use.
Um, you know, I think, uh, I think what we’ll do is, we’ll, we’ll put a link in the podcast back to the medium article you’ve written. Yeah. Um, but takeaway for me, I think is, uh, this, this idea that, you know, time box, year initiation piece of work, because doing some planning upfront has some value. Yeah. Um, but time boxing, it means you really focus on the things that are most valuable, uh, 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. Yeah. And then how you identify, um, who’s gonna do the work and where the, the gnarly gotchas are gonna be. Um, you may use a, a very, you know, differing bunch of artifacts as part of your initiation piece of work.
Um, But that’s okay. Right. And their goal is within two to four weeks we have a, a really good guess and, and have done enough groundwork that we can start running. Um, and therefore that has value. That’s kind of what I’ve taken away from this. What about you?
Murray: Yeah, uh, Shane, I, I wanna talk about, um, before you go the other altern, which you called the ad hoc scrum approach of, we don’t do no stinking panic planning around here cuz we are agile.
We’re all scrum baby. It’s like jazz. We’re a jazz quartet. We’re just improvising as we go. Right. And what’s the problem with that? Cause
Shane: there’s no problem with it. It’s perfect. Don’t have to do of setting and meetings doing. Yeah. Not, you’ll get,
Murray: That’s it. You’ll get what you want when it’s done. So shut up.
Shane: Yeah. Just gimme me code. I don’t wanna be doing this E for fluffy, sticky stuff. Give the coding window. What’s all
Murray: this about? Business cases and money. I don’t care about any of that. So, um, yeah, there are people like that. And, um, Scrum doesn’t have a, uh, sprint Zero, but on the other hand, Scrum, um, assumes that somebody has done this kind of work at, in some way.
Scrum assumes that you have a development team and you have an objective and you’ve got and a goal. And you are, you’ve got a product manager and a product owner, and you basically have a good idea of like what you’re trying to, trying to do when you start. And then the first sprint, just like developers just start, you know, exploring, I guess you’re probably doing technical spikes and things.
Shane: Um, yeah, so I’ve, I’ve done that right. And, um, Yeah. The interesting thing for me is how brutal it is to the team, to the delivery team, to the sprint team, right. Walking into that room with absolutely no background work done with a product owner sitting there telling them what they want. Um, it is just brutal for the team to be able to catch up.
Yeah. Um, and, and get up to speed and then start doing that work. So, um, yeah. I, I think, you know, a small amount of planning upfront has value. Yeah. 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. Um, but, you know, I like the idea of, uh, you know, initiation or a roadmap or, um, something that talks about, you know, initial planning, um, getting us
Yeah. I, I think that, um, the people who are paying us need to. Have some idea whether they’re gonna get good value from investing in us or not, right? They need to know that it’s gonna cost, that they’re gonna spend X dollars on achieving some outcome and it’s gonna be in some reasonable timeframe. Um, I think that’s, I mean, if you’re, you are a customer, that’s what you want and you don’t go, you don’t go and buy a car and you’ll say, How, how much is it gonna cost?
I don’t know. How long is it gonna take? I dunno. Is it gonna get me to work? Maybe . So, so I
Shane: think there’s, I think there’s. Couple of lenses on this one. It’s the difference between, uh, an internal team who have been doing it for a while versus, uh, an organization that’s having consultants or is effectively outsourcing the work versus an off the shelf product.
Um, so yeah, I’m with you. Right? You know, if I’m buying a software as a service capability, the last thing I hate is when I go to those websites and I click on the pricing BA tab and it says, Contact us. Because to me, there’s a, there’s a mix match there. I’m buying the software as a service product. I expect to be able to click a button, put my credit card in and start using it.
Um, just like if I go to a car to buy a car, I’m expecting a car to be there, you know, or, or you know, I’m buying a thing that’s already known. If I have an internal team, my view is that team is available to do the highest value work. So the executive’s job then is just to prioritize what the next highest piece of value is.
Next piece of work, that’s the highest value is and fill the pipeline. It’s that middle ground where we are getting consultants or companies to come in and do the work under a stop, a start and stop construct, you know, which I would call a project, right? They’re gonna come and do the work. Um, I’m gonna give them a bunch of money and then they’re going to deliver this thing.
Um, and I’m worried about whether I’ve got enough money to pay for it or I’m gonna get the thing I think I’m gonna get, but
Murray: even if I’ve just got an internal team, right, and that, that team doesn’t worry about money cuz they’re just there. Um, business people need to know. Whether this is gonna provide a reasonable return on investment because they have a lot of other things that they could be doing.
They could dissolve that team and put people on something else, right? Or they could, they could. Um, but that they have a lot of options. And so they need to work out, out of all the options available, what’s gonna give them the best return on investment. So they need to know not only roughly kind of what is the business value, but also roughly what is the, the size so they can decide amongst their, amongst the different options available to them.
Shane: Yeah. So, so let’s, let’s take this one, offer another podcast. Cause this comes back to business prioritization. And if I have a choice of building two products, um, but I can only build one, which 1:00 AM I gonna prioritize? And also the idea that because this one is quicker to build, therefore I should do that versus the other one, which has the same value where it takes more time.
Um, cuz I’m not sure I agree with. But then I’m not sure, I don’t agree with it. So let, let’s, you know, let’s put that one on a podcast, right? Where we talk about, uh, how organizations prioritize the work that needs to be done outside of a, a know and deliverable, right? Outside of the process, users talked about a lot, which was, we know the outcome, we know the what we need to achieve, and we’ve been given permission to kind of start it.
So let’s do an initiation to really understand the work and how we can do it and when it’s gonna get, Does that make sense?
Murray: Yeah. Yeah. I’m happy to do that on, on another, another
Shane: time. Yeah. I’m just looking. We’ve done a good hour and I think, uh, that next one will probably be a good hour as well, so, uh, All right.
Yeah. Cover that off on a, on another podcast. All
Shane: Good. Excellent. All right, well, good to catch up as always, and uh, I’ll catch you next time.
Murray: All right. Keep it real, Shane. That was the No Nonsense Agile Podcast from Murray Robinson and Shane Gibson. If you’d like help with Agile contact Murray Evolve.
That’s with zero. Thanks for listening.