Tips for using spikes effectively

[Stan Stevenson]

I'm hoping the community might be able to help.  I'm trying to improve how my teams make use of spikes.

Each team uses spikes quite differently from one another, and although I'm not suggesting they are using them incorrectly, I simply feel there is an opportunity for review and improvement.  We've been looking at different aspects of our practices and I would like to do a workshop around spikes.

What I'm looking for are tips, principles or practices to help guide teams in using spikes effectively.

Any guidance would be appreciated.

Stan

[Chet Hendrickson]

Hi,

I would strongly recommend that spikes be rigidly time boxed.  I find half a day to be appropriate.

chet

	Chet Hendrickson ch...@hendricksonxp.com	Tel 248.345.7258 http://www.hendricksonxp.com

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.
Visit this group at https://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.

[Nirmaljeet Malhotra]

I second Chet on the time box. Additionally, I also suggest that teams be clear on the acceptance criteria for a spike. Since the intent of a spike is to arrive at a approach/decision or validate a hypothesis, clarity on what data will conclude the spike is very important.

An anti pattern for a spike is when teams start using spikes to do some design work up front. This is not acceptable. Spikes should be used sparingly.

Nirmal

On Wed, Sep 20, 2017 at 8:44 AM, Chet Hendrickson <ch...@hendricksonxp.com> wrote:

Hi,

I would strongly recommend that spikes be rigidly time boxed.  I find half a day to be appropriate.

chet

	Chet Hendrickson ch...@hendricksonxp.com	Tel 248.345.7258 http://www.hendricksonxp.com

On Sep 20, 2017, at 9:16 AM, Stan Stevenson <daniel.s...@gmail.com> wrote:

I'm hoping the community might be able to help.  I'm trying to improve how my teams make use of spikes.

Each team uses spikes quite differently from one another, and although I'm not suggesting they are using them incorrectly, I simply feel there is an opportunity for review and improvement.  We've been looking at different aspects of our practices and I would like to do a workshop around spikes.

What I'm looking for are tips, principles or practices to help guide teams in using spikes effectively.

Any guidance would be appreciated.

Stan

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.

To unsubscribe from this group and stop receiving emails from it, send an email to scrumalliance+unsubscribe@googlegroups.com.

To post to this group, send email to scruma...@googlegroups.com.
Visit this group at https://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.

To unsubscribe from this group and stop receiving emails from it, send an email to scrumalliance+unsubscribe@googlegroups.com.

[Ron Jeffries]

Hi Nirmaljeet,

On Sep 20, 2017, at 10:36 AM, Nirmaljeet Malhotra <mnirm...@gmail.com> wrote:

An anti pattern for a spike is when teams start using spikes to do some design work up front. This is not acceptable. Spikes should be used sparingly.

I’m not understanding quite what you’re saying here. The point of a spike is exactly to figure out something we need to know, and often we need to know how to design a thing. So I’d think using them for that would be good. This makes me think that you and I have a different idea about what a design spike would be.

What is it that troubles you? What goes wrong when design spikes don’t go well?

Ron Jeffries

ronjeffries.com

There's no word for accountability in Finnish. 

Accountability is something that is left when responsibility has been subtracted. 

--Pasi Sahlberg

[Nirmaljeet Malhotra]

Hi Ron,

I have no problems with teams using spikes to validate design decisions or any other decisions for that matter, but I do discourage them from using spikes all the time as an excuse to do the design work in sprint N for the story to be developed in sprint N+1. Pretty soon teams treat this a process and limit their creativity and crawl back into the phase approach mindset.

Design spikes not going well is not an issue till the outcome helps teams take a step towards the right decision.

 

[Tom Mellor]

Spikes are not used just for design, Nirmal.  There are lots of different types of experiments done by teams that fall under the umbrella of the term, "spike."  Spikes help a team reach decisions and conclusions, the "rightness" of such decisions can often be validated later. 

[Nirmaljeet Malhotra]

Tom,

You are right. Spikes are not just for design and I never said they are. Design was just one example that I used. 

On Fri, Sep 22, 2017 at 11:49 AM, 'Tom Mellor' via Scrum Alliance - transforming the world of work. <scruma...@googlegroups.com> wrote:

Spikes are not used just for design, Nirmal.  There are lots of different types of experiments done by teams that fall under the umbrella of the term, "spike."  Spikes help a team reach decisions and conclusions, the "rightness" of such decisions can often be validated later. 

[George Dinwiddie]

It seems there's violent agreement going on that might have obscured the
advice given to Stan on "tips, principles or practices to help guide

teams in using spikes effectively."

The two most important principles, in my mind, are
1. Know what question you want the spike to answer, and
2. Know how much you're willing to spend to learn the answer.

If you are explicit on both of these before you start, you're way ahead
of the game. You might decide later that you've got a different
question, or given what you've learned, you're willing to spend more
time, but make these explicit decisions rather than sliding down a
slippery slope. These principles help you avoid "The Spike that Ate the
Project."

- George

On 9/22/17 2:42 PM, Nirmaljeet Malhotra wrote:
> Tom,
>
> You are right. Spikes are not just for design and I never said they are.
> Design was just one example that I used.
>
> On Fri, Sep 22, 2017 at 11:49 AM, 'Tom Mellor' via Scrum Alliance -
> transforming the world of work. <scruma...@googlegroups.com

> <mailto:scruma...@googlegroups.com>> wrote:
>
> Spikes are not used just for design, Nirmal.  There are lots of
> different types of experiments done by teams that fall under the
> umbrella of the term, "spike."  Spikes help a team reach decisions
> and conclusions, the "rightness" of such decisions can often be
> validated later.
>

--

----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Ron Jeffries]

Hi Nirmaljeet,

On Sep 21, 2017, at 11:31 PM, Nirmaljeet Malhotra <mnirm...@gmail.com> wrote:

I have no problems with teams using spikes to validate design decisions or any other decisions for that matter, but I do discourage them from using spikes all the time as an excuse to do the design work in sprint N for the story to be developed in sprint N+1. Pretty soon teams treat this a process and limit their creativity and crawl back into the phase approach mindset.

Yes, that would trouble me, if stories start taking two Sprints all the time. That said, if I were a reasonable person — which assumes facts not in evidence — I might be OK with all my stories getting done in two Sprints. :)

Ron Jeffries

ronjeffries.com

 Speed is ppoor subsittute fo accurancy -- Fortune Cookie

[Ron Jeffries]

Hi George!

On Sep 22, 2017, at 3:13 PM, George Dinwiddie <li...@iDIAcomputing.com> wrote:

The two most important principles, in my mind, are
 1. Know what question you want the spike to answer, and
 2. Know how much you're willing to spend to learn the answer.

If you are explicit on both of these before you start, you're way ahead of the game. You might decide later that you've got a different question, or given what you've learned, you're willing to spend more time, but make these explicit decisions rather than sliding down a slippery slope. These principles help you avoid "The Spike that Ate the Project."

Yes, oddly enough I mostly agree. :) I’d add that the amount I’m willing to spend is rarely more than a couple of people for a day.

Ron Jeffries

ronjeffries.com

If another does not intend offense, it is wrong for me to seek it;

if another does indeed intend offense, it is foolish for me to permit it.

  -- Kelly Easterley

[Stan Stevenson]

Thanks George, I like this, very simple and elegant.

[Stan Stevenson]

I would agree with Ron,  I've rarely seen a team commit more than a couple of times to a spike. If they try, then I would normally have a closer look to see if the spike couldn't be refined a little.