Loading ...
Sorry, an error occurred while loading the content.

Re: Re-planning after a spike

Expand Messages
  • Kiel Hodges
    ... server. The ... currently have ... even story ... will take! As Ron said, timebox it. ... the required ... iteration? ... iteration? I personally like to
    Message 1 of 16 , May 1, 2003
    • 0 Attachment
      --- In extremeprogramming@yahoogroups.com, Mike Williams
      <mwilliams@a...> wrote:
      > I need some advice.
      >
      > We have a J2EE app that we wish to port to a new application
      server. The
      > trouble is, while the Customer wants this ASAP, we don't
      currently have
      > enough info or experience to provide any kind of estimate, or
      even story
      > breakdown, for this work.
      >
      > Obviously, we need to run a spike in order to
      > - work out how to install the new server
      > - determine the feasibility of porting
      > - generate and estimate one or more stories for doing the port
      >
      > Of course, it's also difficult to estimate how long the spike
      will take!

      As Ron said, timebox it.
      >
      > How should we handle this? If we do the spike, and identify
      the required
      > stories, is it worth re-planning to include them in the current
      iteration?
      > Or would that be too disruptive; should we wait for the next
      iteration?

      I personally like to minimize re-planning during an iteration. It
      will happen enough from time to time anyway due to unforseen
      issues. Don't add to that. If you are concerned that too much
      time will pass before that next iteration, perhaps you should
      consider shorter iterations.

      Kiel Hodges
      SelfSo Software

      > --
      > cheers, Mike
    • Kiel Hodges
      ... server. The ... currently have ... even story ... Actually, you don t neccesarily need a spike to work out how to install the new server (except to the
      Message 2 of 16 , May 1, 2003
      • 0 Attachment
        --- In extremeprogramming@yahoogroups.com, Mike Williams
        <mwilliams@a...> wrote:
        > I need some advice.
        >
        > We have a J2EE app that we wish to port to a new application
        server. The
        > trouble is, while the Customer wants this ASAP, we don't
        currently have
        > enough info or experience to provide any kind of estimate, or
        even story
        > breakdown, for this work.
        >
        > Obviously, we need to run a spike in order to
        > - work out how to install the new server
        > - determine the feasibility of porting
        > - generate and estimate one or more stories for doing the port

        Actually, you don't neccesarily need a spike to work out how to
        install the new server (except to the degree that it serves the
        other two goals of the spike). You don't need to know everything
        to estimate and plan a story. You just need to know enough to be
        reasonably confident in the plan.

        Of course, you may realize this and feel that you need more
        information to be confident. I don't object to your inclusion of
        that spike goal, I just question how "obvious" the need for the
        spike is.

        Just some idle thoughts! ;->
        Kiel Hodges
        SelfSo Software

        > Of course, it's also difficult to estimate how long the spike
        will take!
        >
        > How should we handle this? If we do the spike, and identify
        the required
        > stories, is it worth re-planning to include them in the current
        iteration?
        > Or would that be too disruptive; should we wait for the next
        iteration?
        >
        > --
        > cheers, Mike
      • jeffgrigg63132
        ... Guess. OK, you ll be wrong. The numbers will be off, and you ll get more or fewer stories done this week than you planned. It s not the end of the world.
        Message 3 of 16 , May 1, 2003
        • 0 Attachment
          --- Mike Williams <mwilliams@a...> wrote:
          > I need some advice.
          >
          > [...] we don't currently have enough info or experience to
          > provide any kind of estimate, or even story breakdown, for
          > this work.
          >
          > Obviously, we need to run a spike in order to
          > - work out how to install the new server
          > - determine the feasibility of porting
          > - generate and estimate one or more stories for doing the port


          Guess.

          OK, you'll be wrong. The numbers will be off, and you'll get more or
          fewer stories done this week than you planned. It's not the end of
          the world. You'll know why the numbers were off, and it's not every
          week that you'll be installing a server for the first time.

          I think it would help to have some kind of priority order in mind for
          the stories you sign up for in such an uncertain week, as you'll
          probably have to add or drop a few.

          After a week or two (maybe by the end of the first week) you'll have
          something on which to base your estimates. Things can only get
          better. ;->
        • Mike Williams
          ... Ron Why not time-box the spike? Take a week. Okay. ... Ron I m not understanding this question. Must be missing Ron something. Maybe someone else won t,
          Message 4 of 16 , May 1, 2003
          • 0 Attachment
            >>> On Thu, 1 May 2003 04:55:33 -0400,
            >>> "Ron" == Ron Jeffries <ronjeffries@...> wrote:

            Ron> Why not time-box the spike? Take a week.

            Okay.

            >> If we do the spike, and identify the required stories, is it worth
            >> re-planning to include them in the current iteration? Or would that
            >> be too disruptive; should we wait for the next iteration?

            Ron> I'm not understanding this question. Must be missing
            Ron> something. Maybe someone else won't, and I'll pick it up.

            Sorry Ron, I didn't explain it very well. I'll try again:

            The functionality we're after is *automatic* deployment to a new type of
            J2EE application-server. The "spike" would involve doing the deployment
            *manually*, to determine how tricky automation would be. This initial
            server installation and manual deployment might only take a day or so, or
            we might be struggling with it for a couple of weeks (due to app-server
            limitations, bugs, etc). It's hard to know.

            We've added the "spike" task to the iteration-plan, but lacking any
            estimates for the automation work, we've left that off. (Perhaps that's
            where I'm going wrong?)

            If the spike only takes a day or two, then we're going to be under pressure
            to get cracking on the automation work ASAP. My question is, should I now
            allow the "deployment automation" story to be wedged into the current
            iteration? Or, force the customer to wait until next iteration?

            --
            cheers, Mike
          • Mike Williams
            ... Kiel I personally like to minimize re-planning during an iteration. Kiel If you are concerned that too much time will pass before that next Kiel
            Message 5 of 16 , May 1, 2003
            • 0 Attachment
              >>> On Thu, 01 May 2003 11:16:16 -0000,
              >>> "Kiel" == "Kiel Hodges" <kielhodges@...> wrote:

              Kiel> I personally like to minimize re-planning during an iteration.

              Kiel> If you are concerned that too much time will pass before that next
              Kiel> iteration, perhaps you should consider shorter iterations.

              Thanks Kiel, good point.

              --
              cheers, Mike
            • Ron Jeffries
              ... There is no force in XP. If your iterations are short, what difference will it make to the customer whether you start now or in a week? OTOH, if you want
              Message 6 of 16 , May 1, 2003
              • 0 Attachment
                On Thursday, May 1, 2003, at 6:59:41 PM, Mike Williams wrote:

                > We've added the "spike" task to the iteration-plan, but lacking any
                > estimates for the automation work, we've left that off. (Perhaps that's
                > where I'm going wrong?)

                > If the spike only takes a day or two, then we're going to be under pressure
                > to get cracking on the automation work ASAP. My question is, should I now
                > allow the "deployment automation" story to be wedged into the current
                > iteration? Or, force the customer to wait until next iteration?

                There is no "force" in XP.

                If your iterations are short, what difference will it make to the customer
                whether you start now or in a week?

                OTOH, if you want to spike and then start immediately, block out as much
                time as you think necessary. What's the worst that could happen?

                Ron Jeffries
                www.XProgramming.com
                Hope is not a strategy. -- Michael Henos
              • William Pietri
                ... Another option is to go one level deeper. Normally, they buy stories. When we can t estimate a story, we let them buy a spike, which is essentially them
                Message 7 of 16 , May 4, 2003
                • 0 Attachment
                  On Thu, 2003-05-01 at 04:26, Kiel Hodges wrote:
                  >
                  > Of course, you may realize this and feel that you need more
                  > information to be confident. I don't object to your inclusion of
                  > that spike goal, I just question how "obvious" the need for the
                  > spike is.

                  Another option is to go one level deeper.

                  Normally, they buy stories. When we can't estimate a story, we let them
                  buy a spike, which is essentially them buying the estimate on the story.
                  But if we can't estimate the spike easily, then we can always offer them
                  the option of buying an estimate of the spike.

                  So one might say, "Well, the spike could be from 1-6 points depending on
                  how well-behaved the app server is. By spending a half-point on
                  research, I can narrow that down for you."

                  William

                  --
                  brains for sale: http://scissor.com/
                • Ron Jeffries
                  ... I m having trouble imagining a spike that I couldn t estimate. I m thinking that I can spike most anything in a half day. Examples, please, of some of
                  Message 8 of 16 , May 4, 2003
                  • 0 Attachment
                    On Sunday, May 4, 2003, at 10:55:54 AM, William Pietri wrote:

                    > On Thu, 2003-05-01 at 04:26, Kiel Hodges wrote:
                    >>
                    >> Of course, you may realize this and feel that you need more
                    >> information to be confident. I don't object to your inclusion of
                    >> that spike goal, I just question how "obvious" the need for the
                    >> spike is.

                    > Another option is to go one level deeper.

                    > Normally, they buy stories. When we can't estimate a story, we let them
                    > buy a spike, which is essentially them buying the estimate on the story.
                    > But if we can't estimate the spike easily, then we can always offer them
                    > the option of buying an estimate of the spike.

                    > So one might say, "Well, the spike could be from 1-6 points depending on
                    > how well-behaved the app server is. By spending a half-point on
                    > research, I can narrow that down for you."

                    I'm having trouble imagining a spike that I couldn't estimate. I'm thinking
                    that I can spike most anything in a half day. Examples, please, of some of
                    these hard-to-estimate-squared things?

                    Thanks,

                    Ron Jeffries
                    www.XProgramming.com
                    You don't want to sell me waterfall.
                    You want to go home and rethink your life.
                  • William Pietri
                    ... I think the OP s question is a good example. ... deployment doodad with a new app server. They were thinking of the spike as doing the deployment manually
                    Message 9 of 16 , May 4, 2003
                    • 0 Attachment
                      On Sun, 2003-05-04 at 08:48, Ron Jeffries wrote:
                      >
                      > > So one might say, "Well, the spike could be from 1-6 points depending on
                      > > how well-behaved the app server is. By spending a half-point on
                      > > research, I can narrow that down for you."
                      >
                      > I'm having trouble imagining a spike that I couldn't estimate. I'm thinking
                      > that I can spike most anything in a half day. Examples, please, of some of
                      > these hard-to-estimate-squared things?

                      I think the OP's question is a good example.


                      >From what I understand, the end goal is some sort of automatic
                      deployment doodad with a new app server. They were thinking of the spike
                      as doing the deployment manually until they got a handle on what it
                      would take to write the automated deployment doodad.

                      But in my experience, these sorts of thing vary widely. If a vendor has
                      really nailed the autodeploy stuff and has good docs, then it might take
                      me an hour to figure it out and do enough deploys to be sure that I
                      could automate it easily. With other app servers, I've had that take a
                      week (e.g., Tomcat and JRun just after they introduced autodeploy).

                      So if they customer wants an estimate on the spike, the answer
                      "somewhere between an hour and a week" might not be precise enough for
                      them. In which case, I'd offer to spend, say, a half-day reading docs,
                      poking at the thing, rummaging on the net, and calling pals to see what
                      experiences they'd had.


                      Do you think that fits the bill? Or would you tackle it in a different
                      way?


                      William


                      --
                      brains for sale: http://scissor.com/
                    • Ron Jeffries
                      ... I think I understand what you are saying now, yes. Thanks! Ron Jeffries www.XProgramming.com Sorry about your cow ... I didn t know she was sacred.
                      Message 10 of 16 , May 4, 2003
                      • 0 Attachment
                        On Sunday, May 4, 2003, at 1:57:51 PM, William Pietri wrote:

                        > But in my experience, these sorts of thing vary widely. If a vendor has
                        > really nailed the autodeploy stuff and has good docs, then it might take
                        > me an hour to figure it out and do enough deploys to be sure that I
                        > could automate it easily. With other app servers, I've had that take a
                        > week (e.g., Tomcat and JRun just after they introduced autodeploy).

                        > So if they customer wants an estimate on the spike, the answer
                        > "somewhere between an hour and a week" might not be precise enough for
                        > them. In which case, I'd offer to spend, say, a half-day reading docs,
                        > poking at the thing, rummaging on the net, and calling pals to see what
                        > experiences they'd had.


                        > Do you think that fits the bill? Or would you tackle it in a different
                        > way?

                        I think I understand what you are saying now, yes. Thanks!

                        Ron Jeffries
                        www.XProgramming.com
                        Sorry about your cow ... I didn't know she was sacred.
                      • Dossy
                        ... Customer: We need you to write an integration bridge from your e-commerce solution to our new fulfillment system. Programmer: Great. Where s the spec.
                        Message 11 of 16 , May 4, 2003
                        • 0 Attachment
                          On 2003.05.04, Ron Jeffries <ronjeffries@...> wrote:
                          > > So one might say, "Well, the spike could be from 1-6 points depending on
                          > > how well-behaved the app server is. By spending a half-point on
                          > > research, I can narrow that down for you."
                          >
                          > I'm having trouble imagining a spike that I couldn't estimate. I'm thinking
                          > that I can spike most anything in a half day. Examples, please, of some of
                          > these hard-to-estimate-squared things?

                          Customer: "We need you to write an integration bridge from your
                          e-commerce solution to our new fulfillment system."

                          Programmer: "Great. Where's the spec. for the integration? What's
                          the data interchange format?"

                          Customer: "It's not well documented, and whatever documentation is
                          available may likely be outdated since it was all written during the
                          design phase and doesn't seem to be updated after the first
                          delivered release, yet."


                          Giving a reasonably safe estimate as to when you'll have a working
                          integration bridge (even to demonstrate just proof-of-concept with the
                          simplest of functionality implemented) might take a long time.

                          You might find out that the data interchange format which initially
                          /looks/ like XML (and was probably supposed to be) really isn't, so
                          parsing responses from the system with a off-the-shelf XML parser isn't
                          possible, so you have to spend time writing a minimal parser for
                          responses ... you might find that supposedly valid input messages
                          haven't been implemented yet, so instead of using the request messages
                          you want, you need to hack a similar effect by composing multiple
                          request messages that ARE implemented which achieve ALMOST the same end
                          result.

                          The way I personally handled this situation was to suggest that given
                          half a day, I would know a lot more about what state all the various
                          unknown variables were in and then could give some better estimates. I
                          didn't set out to produce something that "worked" from the spike. It
                          was just an exploratory one.

                          I think it's important to realizer and/or remember that a spike doesn't
                          necessarily have to produce something that works. It's just to enhance
                          our (gapped) understanding of things, so that we CAN make more informed
                          decisions -- or in the least, know where we might need to spike next.
                          This is, of course, why I treat almost all CODE that's produced during a
                          spike as throw-away, but NEVER the knowledge gained.

                          Like Ron, I'd be curious to hear of a scenario where it'd take more than
                          half a day to glean enough useful knowledge about a problem ... I'm sure
                          there's some out there (Glen's usually good at coming up with examples,
                          I wonder where he's at today). I think examples that involve
                          question-and-answer waiting on third-party answers are disqualified
                          here, because that's always a problem that we have to deal with. I'm
                          interested in problems that regardless of idling wait time from others,
                          where a spike could reasonably take more than half a day. I wonder if
                          hardware development is also disqualified -- if it takes you 30 minutes
                          to build the spike, but 3 days to implement the hardware to test it ...
                          does this spike qualify as taking 30 minutes, or 3 days? I'd say 3
                          days, because only after the 3 days would you actually have learned what
                          you were trying to learn ...

                          -- Dossy

                          --
                          Dossy Shiobara mail: dossy@...
                          Panoptic Computer Network web: http://www.panoptic.com/
                          "He realized the fastest way to change is to laugh at your own
                          folly -- then you can let go and quickly move on." (p. 70)
                        • Mike Williams
                          Ron I m having trouble imagining a spike that I couldn t estimate. I m Ron thinking that I can spike most anything in a half day. Examples, Ron please, of
                          Message 12 of 16 , May 4, 2003
                          • 0 Attachment
                            Ron> I'm having trouble imagining a spike that I couldn't estimate. I'm
                            Ron> thinking that I can spike most anything in a half day. Examples,
                            Ron> please, of some of these hard-to-estimate-squared things?

                            William> From what I understand, the end goal is some sort of automatic
                            William> deployment doodad with a new app server. They were thinking of
                            William> the spike as doing the deployment manually until they got a
                            William> handle on what it would take to write the automated deployment
                            William> doodad.

                            William> But in my experience, these sorts of thing vary widely. If a
                            William> vendor has really nailed the autodeploy stuff and has good docs,
                            William> then it might take me an hour to figure it out and do enough
                            William> deploys to be sure that I could automate it easily. With other
                            William> app servers, I've had that take a week (e.g., Tomcat and JRun
                            William> just after they introduced autodeploy).

                            Exactly. Thanks William.

                            For some app-servers we've encountered, it's taken quite some effort (days,
                            even weeks) just to get the thing installed, and work out how to configure
                            it! So, there's potentially quite a bit of work to do before we can even
                            attempt manual deployment.

                            --
                            cheers, Mike
                          • Ron Jeffries
                            ... Yes, and it can take weeks for the compiler to arrive. But are these examples of spikes that are hard to estimate? I m hoping to have something more to say
                            Message 13 of 16 , May 5, 2003
                            • 0 Attachment
                              On Monday, May 5, 2003, at 12:01:21 AM, Mike Williams wrote:

                              > Ron> I'm having trouble imagining a spike that I couldn't estimate. I'm
                              > Ron> thinking that I can spike most anything in a half day. Examples,
                              > Ron> please, of some of these hard-to-estimate-squared things?

                              > William> From what I understand, the end goal is some sort of automatic
                              > William> deployment doodad with a new app server. They were thinking of
                              > William> the spike as doing the deployment manually until they got a
                              > William> handle on what it would take to write the automated deployment
                              > William> doodad.

                              > William> But in my experience, these sorts of thing vary widely. If a
                              > William> vendor has really nailed the autodeploy stuff and has good docs,
                              > William> then it might take me an hour to figure it out and do enough
                              > William> deploys to be sure that I could automate it easily. With other
                              > William> app servers, I've had that take a week (e.g., Tomcat and JRun
                              > William> just after they introduced autodeploy).

                              > Exactly. Thanks William.

                              > For some app-servers we've encountered, it's taken quite some effort (days,
                              > even weeks) just to get the thing installed, and work out how to configure
                              > it! So, there's potentially quite a bit of work to do before we can even
                              > attempt manual deployment.

                              Yes, and it can take weeks for the compiler to arrive. But are these
                              examples of spikes that are hard to estimate? I'm hoping to have something
                              more to say on this shortly ...

                              Ron Jeffries
                              www.XProgramming.com
                              You are closing your eyes to a situation you do not wish to acknowledge.
                              --Professor Harold Hill
                            • Ron Jeffries
                              On Sunday, May 4, 2003, at 5:56:13 PM, Georg Tuparev sent me this offline (I think). I trust that it won t offend him if I offer it back to the group. ...
                              Message 14 of 16 , May 5, 2003
                              • 0 Attachment
                                On Sunday, May 4, 2003, at 5:56:13 PM, Georg Tuparev sent me this offline
                                (I think). I trust that it won't offend him if I offer it back to the
                                group.

                                >> Examples, please, of some of
                                >> these hard-to-estimate-squared things?

                                > How about 3D structure comparison between macromolecules (e.g.
                                > proteins) or trajectory elements of asteroid?

                                This, along with a few other examples offered, has shaken loose what was
                                behind my wondering how it could be hard to estimate a spike. Thanks for
                                that. I hope the following will be interesting, if not sought after, and
                                I'm sure that people's replies will be useful.

                                As always, what follows is my opinion.

                                First of all, this 3D thing, like some of the other examples, is not a
                                story. Therefore it does not need an estimate. These aren't the ideas
                                you're looking for -- move on.

                                When we do a spike (other than an Architectural Spike, which should surely
                                be a team-wide enterprise time-boxed to about a week), we are trying to
                                find out enough to estimate a story. Since a story should be about a week's
                                work, we need to get way down below "3D structure comparison between
                                macromolecules" before we're in range of either a story or a spike.

                                Second, there are things that can't be estimated that are preconditions for
                                a spike: we don't know how long it will take to get the server software
                                installed or the compiler here from the vendor. We need to be careful in
                                these cases with elapsed time vs programmer time. We might like to say "I'm
                                busy waiting for the compiler to show up, can't take on any more work," but
                                I suspect it won't stick. For an install, I'd use my best guess and say
                                that I'd report back if it turns out to be a problem.

                                Things can go wrong in setting up. There's this odd thing that happens if
                                you install Visual Studio before installing IIS, and it can take forever
                                before you find out that there is a fix for it. And so on. These don't stop
                                me from estimating -- they make my estimate wrong sometimes. That's OK.

                                Ron Jeffries
                                www.XProgramming.com
                                Knowledge must come through action;
                                you can have no test which is not fanciful, save by trial. -- Sophocles
                              Your message has been successfully submitted and would be delivered to recipients shortly.