March 15, 2021
We see it more often than we’d like. The program or team is humming along, when a key stakeholder walks in with a New, Shiny Object (NSO) that needs to be done ASAP. This idea may be totally worth it. Or maybe not. How do you help your stakeholder decide if this NSO is the next big thing while protecting your team(s) from being disrupted? The key is to make sure the stakeholder knows what the NSO entails and what must be given up to get it. Allow me to present my playbook for dealing with a stakeholder’s Shiny Object Syndrome and their NSO.
Move 1: Get Crisp on the Idea
Often, a stakeholder comes up with their next great idea in the shower and just has to get it out of their head. Nothing wrong with having a great idea, but we need to know what it looks like. I’m a fan of hypotheses. Get this person to come up with a hypothesis for their NSO. Sometimes this activity alone stops the person in their tracks. If nothing else, it helps them get crisp on the idea. If you’re not sure how to form the hypothesis, try this hypothesis-driven development template.
Move 2: Put it in Context
You will need to check the NSO against the strategy, which your stakeholder quite possibly set. It’s your first filter on whether you should take up the work. If it’s not in your strategy, then you will need a strong justification to do it, especially if it’s a big-ticket item.
If the NSO aligns with the strategy or if there is a strong justification for it, then it’s time to check the roadmap. Why? Your roadmap should give the stakeholder context for where this NSO would fit in versus the other work. Sometimes this context is enough to shift their idea right or even drop it altogether. Funny story: I had one stakeholder who discovered their NSO was already in the roadmap in the right spot. For more information on how to create an effective roadmap, I recommend Product Roadmaps Relaunched: How to Set Direction while Embracing Uncertainty by C. Todd Lombardo.
Move 3: Reveal the Sacrifice
You have a hypothesis, the NSO is in context on the roadmap, and the NSO still has to be done ASAP! Next, show them what outcomes are currently being worked on. Ask: “Are you willing to sacrifice today’s outcomes for this new thing?” Notice that I said “outcomes” and not “features”. You should be driving for value and outcomes, not just cranking out features. Where do you find your outcomes? PI Objectives and/or Sprint Goals are a good place to start. If you don’t have those, then you will have to do a little interpretation (and create an improvement backlog item to become more outcome-driven!)
Move 4: Talk about the Cost of Change
So now they’re willing to make that sacrifice? I admire that level of dedication. Maybe this NSO is a thing, but there’s still work to do. So far, your stakeholder is willing to sacrifice some current and future work items. Time for a wallet check—are you willing to sacrifice the cost to wrap up the current work?
They may ask “What cost?” Let them know that there’s an Interrupt Tax. Unless your team(s) are practicing technical excellence, it’s going to take some time to unravel all the code and stuff they’ve been working on. My experience is it can take a week or two, but it may take longer.
Time is money and a little financial literacy certainly helps. You need to know the cost of your team’s (or teams’) time for a week; if you don’t know, then their manager should. If you want to ballpark it, here’s a reasonable formula: Assume a developer salary is $70k/year (no benefits) and that a team is 7 people. Assume the whole team will be involved in backing out of the current work. The cost per week is about $9,500, but you can round it up to $10k. And that’s just the cost of getting ready. So is your stakeholder willing to pay $10k+ to get ready to start the NSO? The team(s) SHOULD be creating a POTENTIALLY Shippable Increment of the product every Sprint, so closing the current work up neatly shouldn’t be a huge problem at a Sprint or PI Boundary. Can it wait until then? After all, we should do more than just a quick hypothesis. The rest of the stakeholders need to be consulted and okay with these changes.
Wrap-Up
So what happens if your stakeholder has a great idea, has put it into context, knows what they’ll have to give up, and understands the Interrupt Tax and is willing to pay it? Go back to the Agile Manifesto Principles: “Welcome changing requirements, even late in development. Agile Processes harness change for the customer’s competitive advantage.” While making such a big change may seem overwhelming, you have already proved to yourselves that the NSO is worthwhile and valuable. So go for it!
Looking for guidance in your Agile Transformation? For nearly 3 decades, our experienced coaches have mentored clients in their digital transformations.
Written by Randy Smith , SPCT
Randy is a Consultant, Trainer, Agile Transformation Coach, and SPCT. He believes that a transformation is about more than adopting a framework—it’s also about meeting people where they’re at to help them create an optimal human system that can happily and effectively deliver value to customers. Randy has more than 2 decades of experience in the industry and has worked in several sectors, including tech, manufacturing, shipping, financial, and medical firms, and he has served many roles like developer, test management, release management, support, etc. He started using Agile principles and values with a team in 1999, got his SPC in 2014, and completed his SPCT in May 2019.
