Spikes

HELL YEAH… we SPIKE

the spike… why is the spike such a complex concept for a team to understand.. grasp.. embrace? Why would anyone want to work on something for a short amount of time, gather some information, answer a question and then throw your work away… just to do it again for real. spikes allow you to make better decisions and possibly determine if something is feasible at all… all without wasting a huge amount of time and/or money.

so… when do you actually perform a spike? when is it the right time to not deliver real value to the business? well, when you think of it that way… the answer should be never. although, ‘never’ is not really a viable option… when the known is not known… the spike is the way for the team… to do a little digging into the unknown and then, create a viable solution with more information in your pocket. spikes are not just confined to technical decisions… spikes should be used any time the team is unsure of what is the next step… hopefully allowing the team to answer the question with definitive assurance. Please spike… it will make the business very uncomfortable at first, but with honesty and practice, the business will see the real value of why spikes should exist.

as you might expect… spikes are a lot of things, but they are NOT:

• NOT a way to slip untested code into the production stream
• NOT a way to allow the team to make uneducated guesses at estimating stories and then cleaning up the guess with a spike
• NOT a way for improperly defined (missing definition of ready criteria) user stories to enter the groomed backlog

ok… here is where I lose most people.

spikes should be treated the same as all user stories on the card wall. spikes should be evaluated for the possible business value each will help define. They should also be estimated… estimated because each spike will reduce the capacity of the team. Many teams do not count spikes towards their velocity… I personally do not agree with this. This appears to me to be a lie to the business. (We can also compare this with defects, but that is another topic). The process of determining velocity is not an effort to collect points or apples or whatever, but a process of allowing the business to have a means to determine how much of something they can get within a certain amount of time. The concept of ‘getting credit’ should be considered something the team should not engage. velocity is not about gamification of the agile process. Report the actual velocity based on the actual work of the team… who cares whether you call them… user stories, defects, technical debt or spikes. work is work… and thus reduces the amount of capacity a team has promised the business.

In order to make spikes a little easier to digest… spikes should not be allowed to consume huge portions of the sprint. timebox them using a small estimate. you know your system… pick a reasonable estimate… it is probably not your smallest card on the wall, but definitely not the biggest either. If a spike is estimated and the team working the spike feels they have reached the end of the estimation period… then the spike is done! period… end of story. If the spike is still unable to answer the question, it is possible another spike will need to follow. this is a business decision… it is up to the business to determine if yet another spike should be played. it is not a bad thing to play more than a single spike to answer a question, but each cycle should be carefully evaluated and the business should inevitably by the deciding factor. If the spike is of a technical nature, it is the responsibility of the technical staff to sell the business value to the business, but the business will make the final decision.

spikes will not always result in additional user stories being created. many times, a spike will be initiated by the process of estimating an existing user story. the user story doesn’t have enough detail or the technical questions will not allow the user story to be estimated with certainty… a spike will be required to answer these questions. At the end of the spike, additional cards may or may not be required… simply filling in the knowledge gaps will allow the existing user story to be estimated. On the other hand, a spike may actually result in additional user stories being created.

so… just how does a spike fail… well… I actually think it is very difficult for a spike to fail. spikes are designed to answer a question, fill in the gaps, allow for more informed decision to occur. any information you gather during the spiking process will result in a better position to answer these questions… so, therefore, you are more informed and better off. the only way to truly fail would be a spike that answers nothing, gathers no information and wastes a portion of the teams capacity.

the results

what do you do with the information you have gathered during the spiking process? As far as the code you have written… learn from it and then throw it away. This is just spike code, without tests and should never be considered good enough to be considered production code. Do not allow yourself or anyone else to be swayed to using the code. it will come back to bite you… just do not do it. DELETE the code ! this also does not include putting the code in a special branch within your code repository for later retrieval… DELETE the code !!! As far as the result of the spike, document your findings, positive or negative… this will help with the decisions based on the result of the spike. A lot of times, at the end of the spike, the team will make a decision and then forget to share the findings with the team… the team playing the spike may not be the same team that plays the subsequent cards associated with the spike.

spikes are not magical. they are special in their purpose, but they do not bring magical results to the project other than they are a great way to reduce a risk and allow future cards to proceed across the wall more consistently. spikes are a great way to engage the business and allow for quicker more thorough feedback and a better understanding of upcoming complexity. complexity that will surely derail the sprint/iteration if left uncontrolled.

when to use

when should you utilize a spike… at least a couple ideas to get things started:

• the team is in a position where they do not understand something… could be the business context of the problem or a new technology unfamiliar to the team.
• a story is just too big to get a grasp on… and without breaking the problem down… you will not be able to effectively estimate.
• a new technology has been introduced and the risk of the new technology is adding significant risk to the successful estimation and probable delivery of the story.

good luck with the process of spiking.HELL YEAH… we SPIKE

the spike… why is the spike such a complex concept for a team to understand.. grasp.. embrace? Why would anyone want to work on something for a short amount of time, gather some information, answer a question and then throw your work away… just to do it again for real. spikes allow you to make better decisions and possibly determine if something is feasible at all… all without wasting a huge amount of time and/or money.

so… when do you actually perform a spike? when is it the right time to not deliver real value to the business. well, when you think of it that way… the answer should be never. although, ‘never’ is not really a viable option… when the known is not known… the spike is the way for the team… to do a little digging into the unknown and then, create a viable solution with more information in your pocket. spikes are not just confined to technical decisions… spikes should be used anytime the team is unsure of what is the next step… hopefully allowing the team to answer the question with definitive assurance. Please spike… it will make the business very uncomfortable at first, but with honesty and practice, the business will see the real value of why spikes should be exist.

as you might expect… spikes are alot of things, but they are NOT:

• NOT a way to slip untested code into the production stream
• NOT a way to allow the team to make uneducated guesses at estimating stories and then cleaning up the guess with a spike
• NOT a way for improperly defined (missing definition of ready criteria) user stories to enter the groomed backlog

ok… here is where I lose most people.

spikes should be treated the same as all user stories on the card wall. spikes should be evaluated for the possible business value each will help define. They should also be estimated… estimated because each spike will reduce the capacity of the team. Many teams do not count spikes towards their velocity… I personally do not agree with this. This appears to me to be a lie to the business. (We can also compare this to defects, but that is another topic). The process of determining velocity is not a effort to collect points or apples or whatever, but a process of allowing the business to have a means to determine how much of something they can get within a certain amount of time. The concept of ‘getting credit’ should be considered something the team should not engage. velocity is not about gamification of the agile process. Report the actually velocity based on the actual work of the team… who cares whether you call them… user stories, defects, technical debt or spikes. work is work… and thus reduces the amount of capacity a team has promised the business.

In order to make spikes a little easier to digest… spikes should not be allowed to consume huge portions of the sprint. timebox them using a small estimate. you know your system… pick a reasonable estimate… it is probably not your smallest card on the wall, but definitely not the biggest either. If a spike is estimated and the team working the spike feels they have reached the end of the estimation period… then the spike is done! period… end of story. If the spike is still unable to answer the question, it is possible another spike will need to follow. this is a business decision… it is up to the business to determine if yet another spike should be played. it is not a bad thing to play more than a single spike to answer a question, but each cycle should be carefully evaluated and the business should inevitably by the deciding factor. If the spike is of a technical nature, it is the responsibility of the technical staff to sell the business value to the business, but the business will make the final decision.

spikes will not always result in additional user stories being created. many times, a spike will be intiated by the process of estimating an existing user story. the user story doesn’t have enough detail or the technical questions will not allow the user story to be estimated with certainty… a spike will be required to answer these questions. At the end of the spike, additional cards may or may not be required… simply filling in the knowledge gaps will allow the existing user story to be estimated. On the other hand, a spike make actually result in additional user stories being created.

so… just how does a spike fail… well… I actually think it is very difficult for a spike to fail. spikes are designed to be answer a question, fill in the gaps, allow for more informed decision to occur. any information you gather during the spiking process will result in a better position to answer these questions… so therefore, you are more informed and better off. the only way to truly fail would be a spike that answers nothing, gathers no information and wastes a portion of the teams capacity.

the results

what do you do with the information you have gathered during the spiking process? As far as the code you have written… learn from it and then throw it away. This is just spike code, without tests and should never be considered good enough to be considered production code. Do not allow yourself or anyone else to be swayed to using the code. it will come back to bite you… just do not do it. DELETE the code ! this also does not include putting the code in a special branch within your code repository for later retrieval… DELETE the code !!! As far as the result of the spike, document your findings, positive or negative… this will help with the decisions based on the result of the spike. Alot of times, at the end of the spike, the team will make a decision and then forget to share the findings with the team… the team playing the spike may not be the same team that plays the subsequent cards associated with the spike.

spikes are not magical. they are special in there purpose, but they do not bring magical results to the project other than they are a great way to reduce risk and allow future cards to proceed across the wall more consistently. spikes are a great way to engage the business and allow for quicker more thorough feedback and a better understanding of upcoming complexity. complexity that will surely derail the sprint/iteration if left uncontrolled.

when to use

when should you utilize a spike… at least a couple ideas to get things started:

• the team is in a position where they do not understand something… could be the business context of the problem or a new technolgy unfamiliar to the team.
• a story is just too big to get a grasp on… and without breaking the problem down… you will not be able to effectively estimate.
• a new technology has been introduced and the risk of the new technology is adding significant risk to the successful estimation and probable delivery of the story.

good luck with the process of spiking.