Dear All , I m pursuing my PhD in Agile Software Engineering. I have a question regarding spike solution ” If we add spike in project development will it have effect on team velocity? and if yes what could be the parameters ? All the responses will be consider as a general opinion in my PhD thesis.
First let’s establish some working definitions:
“Velocity” is a proxy for productivity, in that the higher the measure of velocity, the higher the correlation to productivity (theoretically). To say it another way velocity is not a productivity measure, it’s just an indicator. Productivity can be characterized as the amount of work being produced that contributes to meeting the objective of the project. For example, fixing bugs in a green-field project (a project has not yet been deployed) is generally not considered productive, and therefore productivity will tend to decrease the more bugs there are to fix. Notice that this is inverted for a project whose objective is explicitly to fix bugs in a deployed application – fixing bugs *is* the objective, so fixing bugs is productive. Therefore, “productivity” must be understood in the context of the stated objective.
A “Spike” is a *time-boxed* technical exercise to determine two things: First, can the feature/capability be built at all; Second, if it can be built, what would be the level of effort to build it, with the assumption that level of effort can be correlated to time. The time-boxing aspect of a spike is critical, as without time-boxing it isn’t really a spike, it’s a research and development exercise. For example, a project that finds itself constantly engaging in Spikes would be wise to create a dedicated R&D track to isolate unpredictable risks and provide increased predictability in the main track. The main track would be focused on the low-timeline-risk technical features, where the R&D track would be focused on the high-timeline-risk technical features.
So now to rephrase your question:
“How does pausing to determine if a feature/capability can be built, and if so how long it would take to build, affect productivity”
As productivity is work being produced towards accomplishing a goal, the time spent on a spike is not productive. This is where people get very confused. While it is not productive, by definition it is critical, (if a spike was not critical it shouldn’t be done). From a delivery predictability perspective, few things are as scary as the development team constantly having to do spikes to figure out if/when a feature/capability can be built. The argument sometimes is made, “A spike is a productive exercise”, but it’s not by definition – but it is a critical exercise.
Think of a Spike’s relationship to productivity like changing a flat tire on a road-trip. The flat tire is unpredictable, but on a long enough road trip it is unavoidable. When it happens, it is counter-productive to the objective of getting to your destination. However, you have to do it if you want to get to your destination. However, every minute you spend changing a flat tire is a minute lost in getting to your destination. Unfortunately, changing your tire is critical *if* you are to get to your destination at all. Now, what if in changing your tire you discover that your entire axle has fallen off, or that you’re out of oil, or that you have a leak in your gas tank. These are all things that can be discovered as you pause for what you thought was a simple tire-change. There is where Spikes can easy break outside of their allotted time-box and wreck velocity.
- Spikes are counter-productive and therefore reduce velocity.
- Spikes are critical, and have to be done for the stated objective to be reached.
- The result of a spike can radically alter the velocity, depending on the determined level of effort for building a given feature/capability