Project Management Knowledge: Spikes

Project Management Knowledge: Spikes

Are you trying to figure out a way to capture the necessity of your team to use some of their time to learn while doing so? Enter the Spike of the Scaled Agile Framework (SAFe).

It’s been noted that you should try to learn something new every day. It’s a point I take literally in my everyday life, both by necessity (to keep up with my kids) and my choice of profession. While I take pride in knowing everything I can about being a professional project manager, knowing everything is impossible.

However, I’ve found this profession is ripe with talent. There’s also an abundant willingness to share and teach; it seems seared into the very nature of most project managers. Case in point: I was just schooled on spikes.

Originally part of the Extreme Programming (XP) family of Agile, the Spike was created to “represent activities such as research, design, investigation, exploration, and prototyping.” (SAFe)

At one point in my career, I learned that a spike in a project was another way to define a sudden need, that is, a sudden “spike of need or results.” And while that term may have been valid in my former life, it’s not the correct nomenclature for business and project management land.

To use or not to use

There are two schools of thought on using the term: “use it” and “don’t use it.” I should point out that when I state “use it,” I’m referring to literally writing it/calling it out on project boards.

First, as I’ve stated before, I expect development teams to be free to explore and learn while doing their work. Much like being a project manager, your developers can’t know everything. Think about the last time you tried coding something off the top of your head. Unless you’re an avid coder or prodigy hacker, you must look up some code attributes to get the thingamajig to communicate with the thingamabob.

That noted, should you or should you not note a Spike within your tasks (perhaps on your backlog, stories, etc.)? Here’s my take on it. Your team may know there’s an expectation to read/watch/learn whenever they need to for a new API or process. However, the Product Owner or Stakeholders may not know the team needs to do this and may question why they’re “just reading.” Writing out “Spike” as part of the task will ensure everyone knows the task may require some educational component (and thus, may take a day or so longer, and you’ll no doubt have to explain what a Spike is to the Stakeholders).

On the flip side, it may not be necessary to spell it out if your task board is for internal use only. But, if you work in an open environment where anyone can see what’s going on with the project, I’d err on the side of caution and tell the world your team is learning while doing it- Spike it!

Why use a spike in your management techniques

One of my favorite quotes I heard from an instructor a few years ago seems to have come directly from the Scaled Agile Framework website (I’ll credit them since he didn’t),

Agile and Lean value facts over speculation.

This isn’t just about Agile or Lean either. Leaders should praise their teams for learning, validating, or researching a process or product in any management method. Half-assery isn’t needed. Speculation only leads to rework, and rework isn’t just wasteful; it’s also expensive.

So next time you’re trying to figure out how to explain why the team needs to brush up on some code-foo before they start smashing their keyboard, remember to bust out the SpikeSpike and allow the process to work.