Project Management Knowledge: Spikes

Project Management Knowledge: Spikes

Trying to figure out a way to capture the necessity of your team to use some of their time to learn while doing? Enter the Spike of the Scaled Agile Framework.


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, it is impossible to know it all.

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. [Shout out to my co-worker, and fellow project manager, Megan for being the rock star teacher here! PMs for the win 🙌]

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 true in my former life, it’s not the correct nomenclature to use across 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 have an expectation for development teams to be given the freedom to explore and learn while they’re doing their work. Much like being a project manager, it’s impossible for your developers to 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’re going to have to 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 end up questioning 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 not 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- Spike it!

Why use a spike in your management techniques

One of my favorite quotes I’ve 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. In any management method, leaders should be praising their teams for learning, validating, or researching a process or product. 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 spike and allow the process to work.


SAFe

Show Comments