‘I Love Spikes’ by Manny the Grouch

“I love spikes!  Anything dirty or dingy or dusty!

“Welcome to my trash can!  I am Manny the Grouch.  Many of you know my brother as the negative, pseudo-mean, and sarcastic hoarder of Sesame Street.  I, on the other hand, am a team member on a scrum team at a local development company.  Recently, my company decided to go Agile.   While it has been going well, we are struggling with getting work ready to start the next sprint.  Occasionally too, my bosses still ask what I am doing on the team; you see, I am not a developer.  But that is OK because someone told us about this new kind of backlog item called a ‘spike.’  And let me tell you, I love spikes!  They let me prove my worth to the the organization!  And my team loves them too since it makes our velocity seem higher.  How, you ask?  Because it is a user story and we add story points.  Ever since we have introduced spikes, our velocity has gone up by 150%.  And now, when someone asks ‘what is the B.A. doing on the scrum team?’ I can point to this trusty user story.”

Ok, so this is a bit silly.  There is no such a person as “Manny the Grouch” and there is definitely no such thing as these so-called “spikes”. . .  Well, the first part is accurate.

Just a warning, I get a bit wordy below!

What is a Spike?

If you were like me, I had heard of a spike but didn’t exactly know what it was, truly.  I had started seeing this more and more over the past year or so, especially in organizations early in their agile adoption or those looking to scale right off the bat.  Spikes go by many different names depending on the flavor of agile or the organization, with one specific called a “tracer bullets” – or an architecture/technology research item.  In the past, many teams just called spikes “research only” user stories.  But let’s jump into where I believe this comes from.  And again, this is mostly just me digging, so if I need to write a retraction, I can and will! 🙂

The first time spike appeared was in eXtreme Programming (XP).  With XP being an engineering practice-focused agile framework, the developer (and development team, by extension) drives the framework.  This means that, in context, spikes affect the developer more than the rest of the team.  XP’s website states that a “spike solution” is:

[a way] to figure out answers to tough technical or design problems. A spike solution is a very simple program to explore potential solutions. Build the spike to only addresses the problem under examination and ignore all other concerns.

In this model, the story is more-than-likely already pointed and acceptance criteria has been completed (what the product owner “expects” the user story to do or not do).  This means the spike is an interactive research item that might consist of a prototype, new way of working, or even a foray into a proof of concept.  But, a spike absolutely was something that took time away from the development team’s coding “work” in order to do something that was not releasable.  This was an exception and was not meant become the norm.  We wanted development teams creating viable increments!  And because of this, we wanted the product owner to say, “yes, please work on a spike instead of a functional story.”

The Evolution of the Spike

The next time [I think] we see the spike is in a “scaled methodology.”  Why can’t I give you the name of this?  Because, according to the fine print on their website, I cannot use any of it without permission and their name is copyrighted, so I would rather just stay away from it all together.  This means I will not write out the definition they give for a spike.  This means I will also not copy and paste from the website (like I did from XP’s website above) that is admittedly “open source”, mainly because I can’t – copy and paste has been disabled.  I will also not be screen capturing – it has been disabled too.  Free to use is so awesome!  Good thing they haven’t figured out a way to block my phone from taking a picture!  Oh wait, that too would be violating U.S. and international copyright law according to their website’s “fine print” seen here:

 

So, a few points here.  Spikes, in “copyrighted scaled methodology”, seem to have become predecessors [to some extent] to estimation.  According to what I cannot copy, spikes can be used for estimating upcoming “stuff” or for analysis, feasibility, or researching anything new.  They can also be used when things are too big in order to solution them for estimating (I hope I didn’t use any copyrighted words in there).  So, they have become a tool of the entire project management model’s team members to produce an “estimable” user story, epic, etc.  And if the product owner is responsible for driving out the content of the backlog, this means that he/she and his/her staff should have spikes that show their work.

Where This Can Go Awry

Unfortunately, I have seen some anti-patterns come out of “copyrighted scaled methodology” that I do not believe are healthy for teams.  The problem is that, instead of exposing the issue and solutioning, many have used “copyrighted scaled methodology” to justify their actions and their complicated organizational model.  And I have heard it around spikes.  Teams have used spikes to band-aid some serious anti-agile disorders instead of being honest and coming up with a plan to create a better way of working.

The Prognosis and the Medicine

Because of this, many teams have come down with anti-agile disorders.  Here are a few:

Teams that need to “justify” their teammembers actions or bandwidth are suffering from Managementitis.  They are still under the thumb of the leadership in their department/organization/company.   They have not yet established a trust factor OR the organization does not understand Agile.  The solution is not to show how much work the individual is doing through spikes, but rather to focus on the “done increment”; focus on the outcome, not the hours spent working.

Teams that have to show their story points complete as a PKI are suffering from another disorder called Irritable Velocity Syndrome.  They have stopped using velocity as a planning point and started using it as a performance indicator.  I would rather them use “done” or “not done” as a performance indicator and use velocity to understand what the team is capable of and how long it will be until we reach certain product vision milestones!

Product Owners (and analysts by extension – whether I like it or not) who cannot refine the backlog without a spike can be cured from Otherdayjobetriosis through proper education of their leadership to say, ” this is my day job – to focus on making the backlog good and reflective of a value-driven, ROI-focused product vision.”  Sometimes someone from outside the organization needs to be brought in to help with this; sometimes it can be a visionary from within.  Either way, ignoring the problem will cause certain side effects including: long and tedious planning sessions, lack of release, sudden urge to find a new job, dry mouth (maybe), irritability of the team with the Product Owner, slow performance, even project cancellation.

Next

Like all of my blogs, this is just an aspect to get one thinking.  Are all of those spikes helpful or hurtful?  Do they cover up an underlying issue?  If they do not promote transparency, inspection, and adaption, then I believe they are actually slowing your agile adoption and improvement.  Just pull the band-aid off and focus on the solution to the problem, not the temporary fix that fits into the business model.  Remember, agile isn’t just an IT process, it is an organizational way of life.