Proto-Epics with Jocko Selberg

Hello and welcome to Small Batches with me, Adam Hawkins. I'm your guide to software delivery excellence. In each episode, I share a small batch of the theory and practices along the path. Topics include lean, continuous delivery, and conversations with industry leaders.

Now, let's begin today's episode. Aloha and Happy New Year's, everyone. I'm trying something different on the first episodes of the year. This is the first in a short series on software delivery flow, though there is a remix on the usual format.

This series features snippets from my ongoing conversations with my friend Jocko Selberg. Jocko and I met in the Flow Collective. When I learned that he was also in Hawaii, we met up for a drink to talk Flow. Since then, we've been speaking two to three times a week.

This has been going on for about a year. Jocko and I have spoken a lot about Scrum, Kanban, Flow, Agile, Planning, OKR, Sprint, Portfolios, and Complexity. Now we're to the point where we can complement each other's thinking and convey each other's thoughts in easier to understand ways. We have different backgrounds, so it's led to fun conversations and new connections.

Today, I want to channel one part of this long-running conversation. It comes from thinking about managing input streams, Kanban, and entry and exit policies. This applies to software development teams because they straddle two interconnected processes, discovery and delivery. The specifics of these processes are different in each team or organization, though the high-level structure is similar.

One group of people, typically product managers, designers, business analysts, and whoever else creates ideas, Then, through intense collaboration with the engineering team, the ideas transform into working software. The ideas generated in the discovery process feed into the delivery process. So, in a Kanban sense, there is a cue between these two processes. Ideas from discovery must be pulled into the delivery process.

This poses the question, what is the output from the discovery process and what is the input to the delivery process? The line of thinking and continued conversation eventually led to the term proto-epic. Jocko coined the term, and this is probably not new or revolutionary. The proto-prefix indicates that they are before something else.

This is what helps identify them as artifacts that sit on the bubble of discovery and delivery. These proto-epics only need to be sufficient for participants of the delivery process to transform them into the real epics. These quote real epics feel like the ones that software teams are actually developing. There will be some level of work breakdown some idea of an implementation sequence UAT plan release plan acceptance criteria and whatever else is necessary to produce working software Transforming these proto into epics is another intense act of collaboration discovery and critical thinking, typically between a group of people in the discovery and delivery process.

This is where the conversation about right-sizing, risk management, and relative cost of delay enter the conversation. This is where early thinking about desirability, feasibility, and viability are confirmed and adjusted. Then, hopefully the group can conclude on something that encompasses the idea and can become working software. All right, so now I'm going to drop you smack into the middle of my conversation with Jocko.

It might be formed for you in your mind at the point in the process that you are in, but that's not what we're talking about here. We're talking about a broader definition of two interconnected processes. I think about these proto-epics a little bit in the sense of sort of looking at them through the lens of what's happening in my team and uh identifying that a proto-epic actually does have different artifacts than the real epic by kind by in a sense not by definition but they can but they can't assume that they probably let's put it let's put it this way that one of the distinctions between one of a proto-epic and a non-proto-epic would be the shape in the way that you interact with them um what the the way that you interact with the proto epic or with the epic oh okay yes yes yes we in my team right or we're like okay we're sort of the product and the design people have sort of exited their little discovery phase and they have you know a nebulous of something to come to talk to you know the engineering team and it's like okay we have these ideas you know these options and you know engineering is like well we could you know desirable feasible and viable different options of all these different things and it's sort of this you know combinatory sort of just free-flowing thing and just all that's just like in a google doc and maybe there's some like figma designs with it or whatever but it's just sort of okay let's put some thoughts here and sort of try to nail down this or this is still open-ended or whatever i responded like his stuff looked like it was supporting documentation which is awesome it's great right so it's like okay there's this and we're all just sort of putting our little things in here and sort of identifying that like hey, this little part of this is independent from that.

This might be one story inside this thing. This is like an enabling thing or, you know, whatever, whatever. But it's just this Google Doc and maybe there's an associated like Figma with it that's like probably good enough to drive all the conversations, but not a fully specified complete requirement or whatever you want to call it. Yeah.

Okay. So you do all that. You get that point. Then the way that this proto-epic becomes an epic is that we do the triage work to say okay here's the state of our planning this is what we want to do this is how we think we can do it this is it's finger in the wind right sized we have an idea of all of the things okay tech lead go take a day or two and just validate some of these assumptions take it apart Right Attack it Right And see like what assumptions were wrong What are we missing Blah, blah, blah.

And then come back and we'll regroup and see. Yeah. And if all looks and everything looks reasonable, then it can actually be transformed into an epic, which is. Then you would still do stuff.

But you're right. It's kind of a different interaction. Right, because at that point, when you have the epic, now there's going to be a work breakdown associated with it. Then how you actually do the things in that epic is going to have sort of a sequence and the stories or the individual tickets can be like right sized or whatever.

You may decide to pull out specific things that is like, ah, this is actually an enabling thing for this that we want to release before we release the epic versus all of this. That's when all of that. That's all in my voice too. I said or a split.

Right. And all of that sort of happens at that point. but you're still not on the line of commitment. You're still in this sort of inner, this planning sort of preparatory.

Again, it's a gradient. You're moving more, it's more. It's moved one sort of increment closer, right? Because now you have, now the delivery team has a better sense of, is this fit for our process?

And can we commit to this under whatever sort of constraints or blah, blah, blah that we have? Not only when it's in the proto-epic column, as I mentioned, you can compare it against your other protoepics. So you're doing even a loose, you're not doing a hardcore one. You're not prioritizing them or anything like that, but you want to look at them in terms of value, which will be part of the conditions as to whether it moves on or not compared to those other protoepics.

And those are WIP limited very tightly, again, so that you are not flooding the system with work, but you're not interfering with any discovery process whatsoever they can only have x number of things in that protocol that's your intake no but you're you're nailing it though that's that's exactly described it better than i could and again even as i said some teams you don't need to do that on right it's more of a measure of how open-ended is the thing that's coming out of discovery because sometimes what comes through intake is like here's a story we know this like it's not an epic let's put it this way what i would do remember i always say i insert columns on a board or whatever as i would put that there but you may some teams you may find that it only spends five minutes in that queue because it's not strictly necessary but you can check it against the extra criteria and if it doesn't match it it might spend 20 minutes in that queue but it still exists it's just a virtual queue and if you need it then you do stuff there if you don't it flies through it no harm done you've got metrics it's a thing.

You know how long it's spent there. You know whether it comes back. If you're not tracking any of that, you don't have anything. There's nothing weird.

Like I said at the end, there's nothing revolutionary here You just visualizing part of it I don understand what so difficult about this well i think part of it can be too assuming people make assumptions about what the expectation is of the discovery process and what the output of those things look like i had to decompose this that's exactly what it is i had to make this sort of thing with the pm and the team it's like i don't need you to break like don't break down stuff into stories and tickets and all this shit like especially at the epic just like once we get through the proto like this sort of i didn't have the words for it i don't talk about it use that language within the team but like there's this transition point where it's like okay now we're actually going to create the epic just put all the acceptance criteria in there we in engineering will do the do the actual breakdown of the work in there and blah blah blah blah like you don't need to concern yourself with trying to answer all this shit up front before you bring it to us we just need some high level like what are you trying to achieve in the product let us sort of like work backwards from how do we do that in the engineering team yeah that's what i was saying in the proto epic column if it exists is you the team writes the exit criteria for that column and they and it's dynamic they change it all the time based on what they're discovering about what needs to be done in that process in that process and if it is literally just take five minutes and look at that okay it matches this that and that fine it moves on exactly because you know you can have a certain thing that's small enough you can just look at it you're like yep fine boop rubber it's like not quite rubber stamping but it's like yeah we don't need to do anything else this cool just send it along the line and some of them you're like holy shit we gotta do so much for this that's why i tried i tried not to confuse people, they may or may not contain stories.

They don't need to contain stories, but they're probably in most cases going to contain two or three core stories that are their risk items and they should be in there, but you're not splitting it out into all the stories yet because you haven't committed to it. But when it moves into that proto thing and you're analyzing it there, you're going to want to know what those key high risk things are so that you could determine all the other stuff that you need to. You know, I think that from the conversations that you and I Well, I hope you enjoyed this snippet from my ongoing conversation with Jocko.

Jocko also hosts his own show, The Complexity Lounge. The Lounge, as Jocko calls it, covers a broad range of topics, such as complexity science, complex adaptive systems, organizational change, and agile-slash-adaptive approaches to work in everyday life. These ideas routinely enter our conversations when it comes to finding, stabilizing, and maintaining flow. Find the Complexity Lounge on YouTube.

The next episode in this series will cover rightsizing with another snippet from my conversations with Jocko. Anyway, I hope to have you back again for the next episode. So until then, happy shipping.