Often, developers will be asked to work on a story, but nobody knows quite how to deal with it. That is why, today, we are discussing spiking feature work. We are joined by Rob O’Brien, one of the partners here at Stride, and a self-confessed “strongly opinionated product manager.” Rob was formerly one of the principal product managers involved in building out our product practice, and while he has transitioned into a partner role, he continues to do product management work. In this episode, we break down exactly what spikes are and the reasons that developers may need to spike something. We touch on the ‘known knowns’ and ‘unknown knowns’, as well as delving into the ‘known unknowns’ and the ‘unknown unknowns’ of spikes, giving examples of when these should be used and why you may need to time box an unknown unknown. To discover the best practices for the unknown unknowns and spikes in general, tune in today!
Key Points From This Episode:
Transcript for Episode 277. Spiking Feature Work — Best Practices to Figure the Unknown Unknowns
[INTRODUCTION]
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast. Living large in New York, I’m your host, Michael Nunez, and today, we’ll be talking about spiking feature work, best practices to figure out the unknown unknowns. Oftentimes, developers will be asked to work on a story and nobody knows how to deal with this and we’re afraid to speak up to product managers to say we don’t know something but I’m not alone today. A friend of the show, Rob O’Brien is here with us today.
[INTERVIEW]
[0:00:31.7] MN: How’s it going, Rob?
[0:00:32.4] RO: It’s going good, how are you doing, Bobby?
[0:00:34.4] MN: I’m all right, you know, glad to have you here. It’s great to not be the only voice in the recording and…
[0:00:39.7] RO: It’s good to be back, man.
[0:00:41.0] MN: Who better to talk about spikes than product manager like yourself. Tell us a little bit about yourself for those who may not have heard the previous episodes that we had with you?
[0:00:50.5] RO: Yeah, a strongly opinionated product manager, yeah, always good to have, yes. So yeah, this is my third time on the podcast and I’ve been back. So a little bit about me, my name is Rob O’Brien. I’m one of the partners here at Stride now. I was formerly one of the principal product managers of building out our product practice but kind of transitioned to a more of a partner role, continuing to do product management work but looking to grow our business and help kind of work with executives to be more of a strategic partner.
So I have a lot of experience with spikes and various teams.
So previous life, I worked at McKinsey and did a lot of management consulting and that looked like organizational at scale transformations. We’re talking, you know, 50 to a hundred teams, you’re trying to teach agile ways of working product mindset, design thinking. So with that you see, you know, we were doing this with marketing teams, infrastructure teams, web teams, DevOps teams, where the outcome is not always working software but the same concepts are still the same and seeing the different ways that teams use these tools like spikes has been really interesting and I’ve come to some realizations or I guess, strong opinions on how to approach these things that I’d love to share with others that just tips and tricks to help your teams out.
[0:01:56.0] MN: Yeah, awesome. Before we dive into the different types of spikes, Rob is very opinionated on those and I appreciate those opinions. I’ll try and give a definition that I found and that we teach at, or we get from, rather, qualitycoding.org/spikesolutions. They say, a spike solution is a code experiment. It’s called a spike because instead of carefully building things up layer by layer, we just brute force something, driving through the multiple layers. A spike solution is quick and dirty. Don’t spend time making it right, instead, code just enough to get the answer you need and note, this is Bobby notes here, make sure that your spike solution does not end up in production code. You want to stop what you're doing, test drive it, knowing what the information you now have. And that’s me as a developer but often times, have I spoke to a product person and I said, “Hey, we have to spike this out” I imagine a PM may have a different definition of that. Rob, do you follow the same definition, is it a little different?
[0:02:57.8] RO: No, I use a little bit broader of the definition and it’s interesting because you know, obviously, we do, do this as a training at Stride and I went through that and it was really interesting to learn because unfortunately, I never knew why we called it spikes until I think you or Travis back in the day had taught me this during onboarding. But I use it a little more broadly and I’ve seen this view and I’ll give you a little definition here in a second, be helpful because it’s not always technical coding work for teams.
So if a team isn’t doing technical coding work and you say a spike solution is a code experiment, you’re going to lose some people, right? So I like to use it a little more broadly. My definition is really, what I would say is, investigation, research or a coding prototype, which is meant to enable a team’s ability to estimate upcoming work and it explicitly does not add direct user value.
I think that definition captures a lot of what you were saying but opens it up a little bit. I think your note about saying, it doesn’t go to production is really my last note, which is like, this does not add user value, this is for us internally.
[0:03:54.6] MN: Right.
[0:03:55.2] RO: So I think those are pretty aligned, which I really like.
[0:03:57.4] MN: Yeah, because you don’t like, I imagine that the spike that one is doing will inevitably allow the direct user, will have user value but is not indirect by having it done immediately pushed up to production.
[0:04:11.4] RO: Exactly and it’s good to get into that mindset because I think saying this isn’t in production, this isn’t directly for the users, allows people to move fast, get the information they need, learn and move on and also learn that and then think about like, this isn’t something we want to show during a demo, this is for us.
Users and in stakeholders don’t care about how we do things, they care about the ultimate outcome and output. We don’t show them, “Hey, we coded the backend but the front end’s not done.” No, if it’s not done, it’s not done, right? So we’re not going to show you a spike, we did some research, that’s not relevant to them.
[0:04:43.6] MN: Right, it’s just, “Hey, we did some research, it allows us to build the upcoming functionality a little better.” So I’m sure you’ve seen it in many cases. What are some of the reasonings you have developer teams say, “Hey, we might need to spike this.”
[0:04:57.4] RO: Yes, the most, like I would say, by the books kind of like happy pathway that you would come to realizing that you might need to add some spikes to your backlog would be you’re product manager or product owner. You write a user story for some piece of functionality that you want the team to build that adds the specific user’s value for the specific purpose. As you’re walking the team through it, in this refinement session or just with someone, they say, “Hmm, cool, I get it, I couldn’t estimate it” and then the follow-up question is, “Why can’t you estimate it?”
[0:05:30.7] MN: Right.
[0:05:31.9] RO: And usually, it’s because there is some information, there’s a knowledge gap. That knowledge gap is when you say, “Let’s make a spike to capture the work to fill that knowledge gap” and we’ll know we’re done if you can then estimate the original story.
So that’s kind of the happy path of like, the obvious way to get to spikes but there’s sometimes you just know straight up, we’re going to need to spike on something ahead of time. Even if you don’t have a specific story ready, sometimes you’ll want to spike on something that you know is coming down the road that can maybe inform future stories.
That’s a pattern you don’t want to follow too much and then you spend your time doing research without any actual end user value in mind, so you have to be very careful you don’t lead to a world where all you’re doing is researching and spiking but like we said, that doesn’t add user value, so you need to limit that.
[0:06:19.1] MN: Right, you want to be able to do those spikes and research at the last responsible moment, right? When you can do that thing. Part of the reason why me and Rob were catching up on something, I want to document the spike a certain way and he came up with some terms that I want to be able to share with folks, which is like, there could be two types of spikes that can exist. There is the known unknowns and then the unknown unknowns and that reminded me of The Boondocks clip with Samuel L. Jackson where the absence of evidence is not the evidence of absence and then the two kids in the back are like, “What are you talking about?” and then of course, Samuel L. Jackson will Samuel L. Jackson and I wish I can play it but it has curses so I’m not going to.
[0:07:02.8] RO: Are we going to be able to link that in t he description of this podcast? Because people need to watch that video. It’s incredible.
[0:07:05.6] MN: I need to put it in the show notes for sure. Samuel L. Jackson doing his thing but I want to talk about those, like, we’re going to make a quadrant out of it and I want to talk about the first two that Rob has, you know, showed me when we were having this discussion. So start with the first one, there are known unknowns.
[0:07:23.6] RO: Yeah. So I think this one is actually the most common types of spikes and people, they probably realize it but they don’t change their actions based on it. So let me break this down, so known unknowns would mean, “Hey, this story came in, I get the feature but I have a few open things that I need to learn” right? The obvious ones are like, “Okay cool, the feature is about pulling a user’s profile, looking up this email address and pulling the user’s profile from Facebook.”
They might not be able to estimate that because you might say, “Well, I have a known unknown” which is, “I don’t know if Facebook has an API that can do this.” “I don’t know if that API is free, I don’t know if we can access that API through our firewalls for enterprising” but if you get those three things answered, you’re probably pretty comfortable that you could build this story, right? It’s not a crazy story but those would be known unknowns. Those three specific questions you need answered that are unknown to you, you know what you need to learn and really, that will happen quite naturally in a conversation because someone will say, “Well, I can’t estimate this because we don’t know if blank, blank, blank” write those down.
[0:08:28.4] MN: Yeah and I think that’s what I wanted to call out, right? Like, when you don’t know something but you know the questions to it, you can start the spike story or this task, rather, in a way that you know you’re done with this spike when you have those questions answered.
[0:08:46.1] RO: Exactly and that’s really critical, is that I think people get a little lose with their spikes and they just go “Okay, we got to do a spike for this story, got it, let’s move on” Like, “Woah, hold on, hold on, hold on, let’s make it more specific. Let’s make the spike the same way we would try to use the story with acceptance criteria.” Let’s make acceptance criteria for the spike but for the spike, it is the questions you need answered. You know the spike is done when all the questions have answers to them.
[0:09:11.2] MN: Right, yeah.
[0:09:11.8] RO: So whoever picks up that spike says, “Oh, I got a very clear direction, I got to get answers to these questions, then we know the spike is done.”
[0:09:19.2] MN: Right. So it’s like in your example, you have mentioned, “Hey, Facebook has an API.” We’ll find out, “Do I need an access key, is it free to figure it out?”
[0:09:27.9] RO: Exactly.
[0:09:28.6] MN: What is the end point I would have to hit and what does the data look like? Then from there, you can say, “Yes, we know that it takes XYZ to do this and we are ready to estimate” and then you can do that based on complexity essentially.
[0:09:40.9] RO: Exactly.
[0:09:42.3] MN: The other part of the spike was the unknown unknowns. You have an example on that?
[0:09:48.5] RO: Oh, I don’t have a real good solid specific example but this is the one, it is less common when it does happen. I think sometimes when there’s really vague things and sometimes this is actually a, I almost said, this is a product of product managers. This is – I will change my wording, sometimes this is an outcome of product managers not either having the time or just not doing enough research to really look into the future work but they will just say something like, “Pull financial data.”
[0:10:17.7] MN: Right.
[0:10:18.5] RO: It’s like, “Wait, wait, wait, is our financial data in one system? Is it in a 100 systems? How do we even do this?” and you just go, “We got nothing” and it’s like there’s so any questions to ask, we just need to do generic general research on like the concept of how we think about financial data in our company, where it comes from and what even financial data we need to capture and pull into the story. I know I am listing out some questions but like the amount of questions you would list out would be so large, you just do like, we just don’t even know what we don’t know. We just got to start poking around at a high level around how finances are managed at this company.
[0:10:55.3] MN: Right.
[0:10:55.9] RO: It is like listing out a few of the questions wouldn’t be enough because it would probably just lead to more spikes and more spikes and more spikes. So it’s just you don’t even know what you don’t know, so you got to just jump into it and start.
[0:11:06.4] MN: Right and you mentioned for the unknown unknowns, I think I might have an example for this as well but I want to define that the unknown unknowns, this is the time where you would try and time box something. I know that a lot of developers will go and anytime they hear the word spike that it requires a time box. But I think it is clearer for folks to guide with questions versus time because you might, you know, if you give yourself two days to research something, you’re going to use that two days but if you had three questions that you need an answer, you will finish when those three questions are answered regardless of whether it’s two days or four hours.
[0:11:40.1] RO: That’s exactly right. I think there became a pattern in product teams, development teams across all industries that we use story points for stories but we don’t use story point for spikes. We time box them and you stop to ask people why do you time box them, most people won’t have a strong answer and I think the pattern that I found was the time boxing wasn’t adding value.
[0:12:02.3] MN: Yeah.
[0:12:02.8] RO: If we have like, “Hey, we need to know if Facebook has this API, what the data is and if we can access it” why does it matter if that takes us eight hours, three days? We need those answers. Time boxing isn’t going to help us but when you get into this world of immense uncertainty, where you don’t even know what questions you want to ask that I feel like is the appropriate time to time box to make sure you don’t spin your wheels, you are not doing more research than you want and just also a sanity check to bring back some stuff you’ve seen.
So if you have known unknowns, list those questions out and make that the driving factor of when the spike is done, when the questions are answered. If you have unknown unknowns, time box it. Just do a general research on this topic, maybe we’ll give you two days. What that does is that and then incentivizes, you know, if you’re in your standup doing some other.
At the end of two days, share whatever you got back to the team and maybe you decide to add a little more time or not but that is a sanity check that you’re not like, “Oh my god, I’ve been spinning my wheels for two weeks doing research I haven’t even talked to the team. I haven’t even gotten – I am way into the weeds of like the origins of this system and it is history that is relevant I just did. I did too much research.
[0:13:12.7] MN: Right.
[0:13:13.3] RO: So time boxing is going to help there.
[0:13:14.3] MN: Yeah and I think the example that I had in mind was an internal project that I am working on where we need to fetch data to this new CRM that we’re using but we didn’t know how we were planning to do that. A previous CRM build that we did was using webhooks and this other –
[0:13:33.1] RO: Do you want to explain CRM?
[0:13:34.5] MN: CRM is the customer relationship management, where we track like the organization can track like sales and where we are in the pipeline, where are we contracted, where the money is going to be, you know, we win deals. And we want to be able to capture that for forecasting purposes.
The idea that we are now using a new CRM requires a new way of fetching and getting that information. Where in one system, we did in one way with webhooks and then we were trying to experiment as to whether it is possible for us to use webhooks again or if there are different ways to do this and it was just like a no. It is like, “Oh, we’re good. Just try diving to the docks and figure out what’s happening” and we came to the conclusion that upon further research in the CRM that we could possibly pull the CRM itself to get information that updates as opposed to a webhook and I’ll just say that it is very, very expensive just for webhooks. We’re like, “We’ll just pull the data” so right, that’s a no-no-no. We didn’t know, we just got to figure out how we can get the data.
Now, the known unknown is, “Okay, now we know we can get the data. We now need to figure out how are we going to translate that data from the CRM verbiage to what we have internally and what are the best ways that we can fetch that information without hitting our API limits.”
So that’s like the both realms of these particular spikes that we’ve been dealing with the past couple of days.
[0:14:59.3] RO: Yeah, I think that is a great example because when we were doing that new integration, if we tried to do known unknowns and we try to basically list out all the things that we learned about the first CRM we integrated with, we probably would have gone down the wrong path. We would have said, “Do they have webhooks or not? Yes, they do. Cool, so they have them, let’s go pay for them, let’s go.”
[0:15:19.8] MN: Yeah.
[0:15:20.2] RO: We would have overdone it where we because we kept – because you guys did such a good job of keeping the research more broad and just said, “Let’s time box general research” that’s an example of us opening the aperture to be like, “Let’s be creative here, let’s be thoughtful.” So I think that is a great example.
[0:15:35.2] MN: Right. Lastly, I just want to talk through, so we got known unknowns and we got unknown unknowns and in consulting, we always got to put things in quadrants. So I did this on purpose where we got the known unknowns and unknown unknowns. So I just want to go through the other two. So if you have known knowns, then that means you know everything you need to know and you go and you make the story and do the work. The other one that was kind of difficult for us to kind of clarify is the unknown knowns.
[0:16:02.7] RO: You don’t know that you know it.
[0:16:05.4] MN: Yeah, exactly and that might be, I think you had mentioned it earlier before we recorded, the idea that you yourself may not know something but like collectively as a team, you all know what to do.
[0:16:19.9] RO: Exactly because I think about anything in the backlog is really for the team. It is not for individuals, right? We don’t like to assign work. I didn’t write this story for Bobby, I didn’t write this story for Sarah, I wrote the story for the team. So I think if we think about spikes that same way where you have unknown knowns, you might come in and say, “Oh, I can estimate the story because I don’t know if Facebook has an API.” Someone on the team says, “No, actually internal. Actually, it does have an API. I’ve used it before.” Well collectively, you didn’t know this but the team know that. That was an unknown known that the team had and in that situation, that’s the beauty of a team refinement. That’s why I think you should refine work as a team not as product manager refines the work with the tech lead to get the estimate.
No, you should refine it with the full team so those unknown knowns can be shared with each other and then they become known knowns.
[0:17:11.0] MN: Right.
[0:17:11.5] RO: That’s the beauty of collaboration information spreading.
[0:17:14.7] MN: There you go. Rob, how can people reach out to you?
[0:17:17.4] RO: Yeah, if people are curious about learning more about my hot takes or strong opinions or really, any of these stuff on, I think a more broad one is just backlogs, different types of issues and backlogs, different structures and templates and ways to think about these, I would definitely just reach out to Stride. So sales@stridenyc.com.
We have a ton of really smart people. This is not my information or Rob’s opinion as much as we joke about it, this is really my learnings from working at Stride with great Striders like you Bobby and then all of our clients. So we’re always happy to help, we’re always happy to run workshops, talk to people, spread our knowledge anyway we can. So yes, sales@stridenyc.com, please shoot us an email if there is anything we can help with.
[0:17:56.7] MN: Awesome and for those out there who are trying to figure out their spikes, hopefully the absence of evidence helps you out and gives you more evidence that are maybe absent and if you haven’t, feel free to check us and check that video. It’s really cool.
[0:18:12.6] RO: Check out the video, it is very funny.
[END OF INTERVIEW]
[0:18:14.7] MN: Follow us now on Twitter @radiofreerabbit so we can keep the conversation going. Like what you hear? Give us a five star review and help developers just like you find their way into The Rabbit Hole and never miss an episode, subscribe now however you listen to your favorite podcast. On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
[END]
Links and Resources:
