Spikes: the sneaky Value assassin
Recently I see the term “spike” pop up more and more.
And the funny thing is, it looks like it is sometimes used to close the gaps (or hide them) without giving proper thoughts on adding value or purpose.
To start of, let’s see what SAFe has to say about spikes (I cut it down a bit here and there):
Spikes are a type of exploration Story. Their purpose is to gain the knowledge necessary to reduce the risk of a technical approach, better understand a requirement, or increase the reliability of a story estimate.
Agile and Lean value facts over speculation. When faced with a question, risk, or uncertainty, Agile Teams conduct small experiments before moving to implementation, rather than speculate about the outcome or jump to a Solution.
- Teams may use spikes in a variety of situations: Estimate new Features and Capabilities to analyze the implied behavior, providing insight about the approach for splitting them into smaller, quantifiable pieces
- Perform feasibility analysis and other activities that help determine the viability of epics
- Conduct basic research to familiarize them with a new technology or domain Gain confidence in a technical or functional approach, reducing risk and uncertainty
So, looking at this, we can almost roughly call this “Refinement” in Scrum.
And that’s where I see things go wrong. Because I see a trend here that the actual refinement is replaced by a number of Spikes.
In my work environment, the PO has some Business Analysts as stakeholder, which provide the content of the PBI’s. Those PBI’s are further refined by the team, into “work”.
Now, the BA’s noticed that if they are unable to provide sufficient content, a Spike can be called for it to investigate this PBI further. A slippery slope can be found here, because unnoticeably, the modus operandi is becoming: the work which should have been done by BA’s, can also be done by the team in the form of a Spike. Resulting in business whishes becoming less and less explored and written down from the BA side, and more and more Spiked by the team side.
The reason I wrote this, is because I think a SM has a good, challenging and maybe new role to play. As a SM, I think nowadays it is important to help the team and organization to teach them the difference between Spikes and Refinement. And to make transparent what value can be delivered with both of them. One step further, what value the team can NOT provide, when they are spending time on a Spike, which should have been done by BA in the first place.
I am pushing back Spikes a lot these days, and it may be something all SM’s can encounter.
It can be hard, but in the end, I think we have a healthy balance between an occasional Spike and prober BA work being done. What really works well for me: I let the team decide if they think they need a Spike for some theme to be delivered. If they don’t; the request is returned made to BA side.
More people encountering this on the work floor?
What you're describing seems to be a symptom of something that needs to be made transparent and dealt with. When you start to see a team spike more backlog items than not it's definitely worth investigating. I've seen teams spike everything because they barely ever refined, others were a new team that didn't have the contextual knowledge, some just wanted 'more time', and the list could go on.
I believe spikes could be addressed in a more detailed collaborative refinement session. I've found some teams don't always understand the outcomes of refinement and don't view it as a working session for the Scrum Team.
I worked with a team once who actually refined better when I was not present as the Scrum Master. I believe because I had scheduled the session they viewed it as 'my meeting' and were not as accountable and didn't deep dive into the details required. After a few unproductive sessions I helped them understand and articulate the outcomes of refinement and let them self organize and handle it themselves with better results.
If you're familiar with the Cynefin framework I would say I'm more of an advocate for spikes when work falls into the complex realm. Timebox it, do research, run experiments or proof of concepts with a goal in mind (think SMART goals). These could come as a outcome of a quality refinement session.
I've seen something similar. I'm rather torn on it, though.
For some perspective, I work in an environment where we use extreme levels of traceability from the initial high level concepts through relevant tests, deployments, and operations. This is extremely beneficial since our customers operate in a regulated space. When engaging with clients, we had to give them confidence that our product and the processes used to build and maintain it were sufficient to meet their demands and the expectations of the regulatory agencies that audit them.
Because of the environment that we work in, having "Spikes" as work items in our tracking tool made sense. We can link the Spikes to the objectives and initiatives and to the other work that is being refined or understood through the Spikes, including what new work was uncovered because of the Spike. It also gives a place to write notes, upload file attachments, link to wiki pages, and more - again, all part of the high traceability.
Personally, I consider a Spike to be a way to define and allocate time and effort for specific refinement objectives. In the Scrum Guide, refinement is pretty vague as to how it's actually done. A team may find it helpful to define the refinement to be done in the terms of specific work items (Spikes) and plan for them, make them visible on a Sprint Backlog or board of some kind, and track them to completion.
I think the kind of extreme traceability that I need to work with may be overhead or wasteful for many organizations, but I do think that there's value in making refinement visible, having well-defined objectives for what is refined, and being able to track and coordinate it is immensely valuable.