When Do You Start Work?

In this episode of Definitely Maybe Agile, Peter Maddison and David Sharrock explore the critical question: "How do we know when work is ready to start developing?" They discuss the challenges of translating business requirements into technical implementation, the importance of having the right people in collaborative discussions, and practical approaches to defining "ready" work. Peter shares recent experiences with organizations struggling with this exact problem, while Dave highlights how trust between business and technology teams impacts the handoff process. They explore visual collaboration techniques, the concept of "full kit," and practical ways to determine if work is truly ready to begin.

This week´s takeaways:

1. Revisit and reinforce your work definition process regularly, as changing roles and organizational shifts can erode even the most robust systems over time.
2. Use the "full kit" concept as part of your definition of ready, and be willing to say no to work that doesn't meet these criteria.
3. Work is ready to start when it's the team's top priority, has a clearly defined problem to solve, and the team can confidently estimate it within their typical delivery range.

Chapters

• 0:00 Introduction and Topic Overview
• 0:54 Business vs Technology Perspectives
• 2:43 Professional Confidence in Teams
• 4:59 Psychological Safety in Planning
• 6:49 When to Start Work: The Full Kit Concept
• 8:20 Breaking Down Work into Smaller Increments
• 12:30 Visual Tools for Defining Work
• 15:30 Key Takeaways and Wrap-up

Transcript

Peter: 0:04

Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and David Sharrock discuss the complexities of adopting new ways of working at scale. Hello, Dave.

Dave: 0:13

How are you today, Peter? Great to catch up with you and doing very well. I'm in Vancouver. The sun's been shining for like three days. Everybody in Vancouver is walking around with a smile on their face.

Peter: 0:24

I like it. I like it. It's actually sunny here today too, which is nice, although it's also around zero.

Dave: 0:32

Now it just means the Vancouverites are smiling more. Yes, indeed.

Peter: 0:37

So what's the topic?

Dave: 0:38

today. Today I've been doing a workshop and one of the questions that came up just as one of those really interesting questions that drills into everything that we really talk about, and the question is how do we know when work is ready to start developing?

Peter: 0:54

yeah, and this is quite a timely one. I've been working with an organization recently on doing exactly this. It's it's the funnel from. Hey, we've got this idea and when we really, really want to do this piece, it's sort of this big hairy verbal stuff. How do we get that to the point where we've got a piece of it that we could actually undertake and work on, and they're breaking it through that funnel?

Dave: 1:20

And I think it's a really interesting problem as well because it sits right at that boundary between business trying to define their requirements in business language and their expectations and their understanding of what a system can do. Combining that, crossing over to the technology team that has a very different vocabulary and understanding of what's often very similar terms being used, so the language gets really difficult. And then, if we don't have a lot of trust in that handover, if we get this wrong, fingers start pointing the other way and saying see, we should have started sooner or we shouldn't have started this, you haven't defined it and you don't know the problem.

Dave: 2:00

So it's that sort of friction point between business and technology as well.

Peter: 2:04

Yes, and we especially see this with problems where it's like well, from a business perspective, all we're going to do is add these two fields. But then from a technology perspective, well, those two fields mean I've got to update all the database, I've got to update the back end systems, it's got to show up in these reports. I've got to rebuild the reports, I've got to add all these interdependencies.

Dave: 2:24

So you're adding two fields is actually a lot of work, yeah, and I think another thing that I think is quite valuable for us to consider here is if I take the perspective of the technology teams as their defining work.

Dave: 2:46

Very often a technology team may not be as comfortable discussing something in a sort of a discussion and they need time to go away and evaluate what's really changing.

Dave: 2:50

And that comes down to both experience on the team, on the technology, of course, and knowledge of where you're working, but also it comes down to the piece of work is too large, like those two fields sounds really simple, but the consequences of that can be quite extreme, quite extended, and so one of the things that is an ideal that we're aiming for is that sort of professional confidence that when we work with a professional say you get a plumber coming around to your place because there's something that needs you know, you've got some questions around the plumbing, or a mechanic on your car or whatever there's a huge difference to that person who's kind of green, and you can almost see in their eyes that they're not sure what the problem is and so they're going to kind of go well, I need some time, and there's a little bit of buffering, they push back and they go.

Dave: 3:37

You're going to have to give me I can only do an assessment or something like this. You can tell they're not sure of where to go. And then there's the plumber, the mechanic or the team that you work with, where they've got that world weariness about them. They've seen everything, and when you ask them for something, they go yep, I know exactly what we need to do. We're going to do X, y and Z, and then they can sort of take it off and run. And I think there's a huge difference there, because in that second situation they're not pushing back on the work that needs to be done or trying to get clarification or anything, because they know where they're going and they really do understand their systems and they're able to isolate that problem and really address it.

Peter: 4:21

That's an interesting piece in that it's having the right people in the room to have the right conversation around. What's it going to take to get this done? One problem that we often see organizations run into is that they don't have enough of those people who can have that conversation, and so those people often need to be in lots of conversations and, depending on how you've divided up your delivery and or how your systems interact, you may find that you have a bottleneck just simply in the fact that that one person needs to be in every conversation and do the work.

Dave: 4:56

Well, and I think there's also a psychological safety element there, because if you're a little bit unsure and you're in an environment where if I say something and it turns out to have not been quite correct, that comes back and sort of erodes that confidence in the relationship or the trust in the relationship, then I'm better off not saying anything. So in those situations, say in an estimation conversation, I actually have to take things away, I need a spike, I need another round of estimation.

Dave: 5:27

I can't have that conversation with my colleagues who may be able to give me the information I need in the open with my product owner in the room or my stakeholders in the room seeing us navigate something if it's not a safe space for us to be able to do that?

Peter: 5:43

And I think there's a piece here where organizations don't come back and reinforce these concepts. So you might start off on the right track and say, oh, we've got this, we figured it out, we've got this process. We're going to meet every month and we're going to have a conversation about what the work is. We're going to figure out how to prioritize it, break it down, what we're going to do, got all the right people in the room, but then as time goes on, you start to forget about the rigor of this and there's other distractions, or new accountabilities get assigned to different members so they don't always turn up to the meeting and so you don't have the right people to have that conversation and you end up with all this running around.

Dave: 6:20

You've just described how waste gets into the conversation, into the process, right? So we start not holding one another accountable to this sort of clear, focused decision making. And now we're adding in buffer. We're basically saying, well, let's use a spike to do the exploration instead of having the discussion in the room. Yeah, I feel in some ways I've dragged things off topic. But how about if we go back to that original question when do you start work?

Peter: 6:49

So when do you start work? You start work and I always like the concept of a full kit, which I think comes out of either theory of constraints, space, or out of lean. Maybe where this idea that I don't start work, that I don't have all the right pieces for, maybe where this idea that I don't start work, that I don't have all the right pieces for. So if I know that for me to finish the work, I need to understand at basic level what the risks are and I need to understand what dependencies I have, I need to understand who's going to need to do the work, so I'm not going to start any work where I haven't identified these elements of it.

Dave: 7:22

I find this one an interesting one because I agree 100% for the piece of work that's in front of me. I worry a little bit that if it's a bigger piece of work. It's a little bit like waiting for all the traffic lights to be green on my journey to wherever I'm going before I start work.

Peter: 7:39

Yes, and so this when we look at the funnel we want to start from, I've got a whole bunch of different things we want to start from. I've got a whole bunch of different things. There's always more ideas of things that I could probably take on than I possibly have the capacity to execute against. So from there I figure out which ones of these can I align to my strategy, which ones of these are potentially the ones I want to tackle first, because they're probably the most relevant, they might add the most value to the organization. First, because they're probably the most relevant, they might add the most value to the organization. Or they're the most critical, because we've got upcoming compliance needs or we've got other things that require that we do this work. So these need to be higher up the stack. And from there I can start to think about well, how do I break those down into smaller increments of value?

Peter: 8:23

And that's that rock crushing piece, because when we have these massive pieces of work, it's very hard to compare them Because we don't know enough and, to your point, we're never going to be able to understand everything about them and any estimations we make are likely to be wrong anyway, because we tend to be very bad at that as humans, and we've talked about that in prior podcasts as well. So from there it's that I need it down into something I can understand a little bit better. So I need to make it small enough that we can comprehend and think okay, can I compare this? How critical is this piece? Can I think of a part of this that I can carve off and say will this thing deliver a piece of value that I can start to say, okay, it's worth starting on this piece, because then I'll have this at least, and then I can decide what I'm going to do at the end.

Dave: 9:14

I think I agree with everything that you just said and I think in my head, if I was working with a team, I'd probably say it in the following ways. I'd say number one have you got a piece of work that's a priority? It's the top of the list. We need to work on it. So let's put all our attention behind that number one. Number two do I know what problem I'm solving? Have I kind of defined it in a way that I've got something that I can't report progress on? I can actually report delivery of, and I think that's a critical thing. And number three when we discuss it with the team, can they estimate it? And does that estimate come in a range that the team has a history of delivering? And if I've got that, then you can start work Now.

Dave: 9:51

It might not get you to your final destination in one fell swoop, but it's high priority. So you need to be working at high value, high priority. It's urgent. However, we're going to define it needs to be done. It's a problem, not a technical task. So there's some value that we can put in front of the business and we can negotiate, talk, get feedback on whatever it is, and the team understands enough of it to agree on a relative sizing.

Peter: 10:21

And we know exactly that.

Dave: 10:22

May or may not be great, but it's enough to get moving and we can learn from it.

Peter: 10:26

Yeah, and one of the things that I like about that full kit concept is you can start from this is what we need to start work, and you can start to look at, as you take work on, what sort of things seem to make the work go smoother or better and start to add them in and say, ok, well, we started with these three things, but we're going to add this fourth one that says we need to have a metric that we can measure within a month's worth of delivery so we can decide whether to continue or not. And we're not going to start work until we define that. I'm just picking something that you might put into the kit to say, okay, so now for work to start, these four things need to be true and we have agreement and you have the people in the room to say, okay, this work here isn't ready to go because we don't have this piece of information.

Dave: 11:22

And wouldn't it be a fantastic idea, once you've got those four ideas, that you write them down somewhere that you call your definition of ready? And now I've got a very, very simple hurdle or gate to go through any piece of work that we're going to pick up on the team. We can do that quick check. Does it hit these four things? Yeah, let's get moving.

Peter: 11:38

Yeah, the other piece, that there's a couple of other pieces where we look at tying this into where do we do the work as well, and other pieces where we look at tying this into where do we do the work as well. And so for when you're doing that initial like what sort of thing is this that's? I find that's best done in visual tools, like on either a virtual whiteboard or a real whiteboard, where we can like it's a bit more tangible and we can move things around more easily. Uh, whereas one mistake I see people people do is like oh okay, so we've got this piece of work, I'm gonna create this initiative in Jira and I'm going to then break it down into 57 stories and it and it suddenly becomes permanent, which is and harder to manipulate.

Dave: 12:17

I I couldn't agree more, as you're describing that. I'm sort of maybe it's a realization, it's a. I was this old when I realized how powerful a whiteboard is as a collaboration tool and I feel I mean we use collaboration, online collaboration tools all the time. I also don't think we use a whiteboard, an online whiteboard, as a collaboration tool nearly enough.

Dave: 12:44

Because, I think that conversation and documentation is only one dimension in terms of communication and understanding, and the whiteboard really fills in that gap between the two kind of you know, complete visual representation in wherever versus a discussion in a or a jira ticket or something, and the whiteboard really helps us capture what we're talking about and have a decent discussion.

Peter: 13:10

Yeah, it's increasing the bandwidth of communication. We're going from that single lane road to the highway by just making everything visual and being able to communicate in that fashion. So I think that's a critical piece when we're starting to define the work. I think the other piece there is that making it incremental, so that we're taking pieces and then moving down. So the first thing that we're going to capture is like what is this? And compressing each other.

Peter: 13:37

The next bits we're going to start to capture are more details about, well, how might we break this down or what sort of thing could we work on.

Peter: 13:45

And then, working in that incremental fashion, uh, one way of doing that is building out, um, have some sort of canvas where you build it out and you just add information into it as you go along. Uh, one piece, uh, in recent uh work that I've been doing that came as a conversation is especially for those initial, where you're comparing things from a visual perspective. As fascinating as all the numbers and details are, they're nowhere near as important as the text that describes what the thing is and what's it going to do and what's the benefit going to be, and if you have those three boxes big and clear so that people can compare them and you can read them. I think that's a very valuable piece. I think, if we go back to the conversation that we were having with was it Marcelo, on the PR FAQ, it's a similar concept like having the detail, and in that detail that really helps you start to understand what is it we're trying to do here.

Dave: 14:44

Yeah, that's a great point. That's a great point. I'm just kind of like labeling. We can have a whole conversation around this one as well, but terminology, labeling, vocabulary and so on For so many contexts can start that you actually have to understand what is that team going to be delivering? How does it fit within the product strategy and the value stream? And then you find out that they're not thinking in terms of value stream. They have a different terminology for it. So that clause is almost like a glossary of just sitting there and saying when we say X, this is what we mean in this organization.

Peter: 15:30

Yes, yeah, that's a very good point too. I've run into that in organizations, especially any organizations related to manufacturing, where value stream is already a term but not applied in the same way as we're using it within the knowledge world. I mean, it's effectively the same thing, but that's not how we're thinking of it. We're using it a little bit differently.

Dave: 15:50

We've jumped around quite a bit there, so I'm going to challenge you to come up with three things to take away, because the question was quite broad, or at least it led to many different threads in our conversation. So what are the three takeaways?

Peter: 16:06

For me, I think the understanding that, even if you've in the past had a very robust way of defining a big network, that revisiting that and making sure people are engaged in it is a very critical part of the process because we lose focus over time because people changing roles, so you need to reinforce the concepts back into the system.

Peter: 16:30

I will always draw upon the full kit concept and the idea that what we need in that definition of ready in that kit to say everything's ready to go, that changes with time as we learn more about the work that we're delivering and that's a part of the evolution of that system, and using that as a way of saying no to work is a critical part of this too.

Peter: 16:53

So we could say this work is not ready to go because we don't have this piece and we've said we will not start work that doesn't have that and we need to hold ourselves to that, and that's often a part that the organizations struggle with. Another one that I thought you brought up at the start that I thought was rather good, although it did take us off on a bit of a tangent was around trust between the different parts of the organization to make this happen and how we can reinforce that trust by ensuring that we have the right people in the room to have the conversation, and that's another critical part of the system. So I think I'd go with those three and yourself.

Dave: 17:33

I'm going to try and keep it to just two. Okay, one of those is one thing I'm taking away from our conversation I always love this because I get something to remind me to focus on in the next few weeks is actually using some form of digital whiteboarding. I think we do a lot of communication, which is just not in that space, that broad bandwidth as you described, which a whiteboard steps in, and I think it's really critical. That was one.

Dave: 18:02

And then the second one is to go straight back to that original question when should you start development? The team's top of the backlog, so it has priority. The team's able to estimate it, so they have confidence that they kind of know where they're going. Then get going.

Peter: 18:17

Yeah, that's good. Well, with that, we'll wrap up for today. As always, you can send us messages at feedback at definitelymaybeagilecom, and we'd love to hear from you and thank you all. Thank you, Dave, until next time. Thanks again, peter. You've been listening to Definitely Maybe Agile, the podcast where your hosts, Peter Maddison and David Sharrock, focus on the art and science of digital agile and DevOps at scale.