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

Fitting a squirrel burger into a 30 day sprint

Expand Messages
  • Mike Dwyer
    Ron: Forgive me but I will have to respond to your cogent and well order response tomorrow. I made the mistake of reading the posts in a LIFO order and this
    Message 1 of 12 , Aug 3, 2005
    • 0 Attachment
      Ron:
      Forgive me but I will have to respond to your cogent and well order response
      tomorrow. I made the mistake of reading the posts in a LIFO order and this
      is what is left of my brain.

      "The customer walks in and tells you of a new thing they saw on TV where
      somebody said Squirrel Burger and Ken showed up made it and left, leaving
      the fried squirrel in a half eaten bun.

      I want one, they said, and I want it in a week then they left

      Where do you begin?


      Michael F. Dwyer

      "I loved a woman who drove me to drink - I must find her and thank her
      someday" W.C Fields

      -----Original Message-----
      From: scrumdevelopment@yahoogroups.com
      [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ron Jeffries
      Sent: Wednesday, August 03, 2005 6:32 AM
      To: scrumdevelopment@yahoogroups.com
      Subject: Re: [scrumdevelopment] Fitting stuff into a 30 day sprint

      On Wednesday, August 3, 2005, at 5:15:36 AM, mike.dwyer1@... wrote:

      > The time needed to develop stuff is out of the control of the developer.

      Well, the time needed to develop /all/ the stuff is somewhat out of
      the control of the developer. The time needed to take one step ...
      perhaps is not.

      > The requestor's ability to provide clarity as to the functions
      > needed and the team's capability to reach agreement on the common
      > perception, wold seem to be the critical issue. Once clarity and
      > agreement are reached anything can be built quickly.

      Well, I think that just maybe, Agile software development is about
      building the software while reaching clarity, not after reaching
      clarity.

      Jim, for some reason, dropped into waterfall mode when faced with an
      apparently big problem. He quickly noted, however, that, as always,
      it wasn't likely to work.

      > Ah, but what defines quickly? It is definitely not the clock, or a
      > calendar.

      Actually, as far as I can tell from what I've seen in Agile projects
      all over, quickly is in fact defined by the clock and calendar.

      All the work we ever do will be done in one-day chunks, at least as
      long as they let us go home and sleep. So the first step in
      answering Jim's question is to assume that there is an answer.

      I agree that doesn't make the answer easy to find, but it makes it
      possible. Doing a three-sprint feature is a choice, but it is one
      that drops the essence of Scrum. Let's not do that quite yet.

      > Perhaps it is the time needed to construct the right
      > sized chunks to work on.

      Well ... I guess it might be. An XP team will often ask to be given
      a story to experiment with something. This is a valid story if it
      provides business value, and the business value such a story
      provides is generally information. This information includes how
      long it will take to do the feature, and some clarity on how it will
      be done.

      Wise teams treat these experiments not as design sessions, but as
      design and construction sessions: they build the software they care
      about.

      > If you agree with some of this, then let's ask another question.
      > Describe the key skills needed to accomplish this.

      The key skills to accomplish this are present in everyone, usually
      to a sufficient degree to enable a team to do it just fine.

      It often happens, when I'm on a gig somewhere, that a story turns up
      that is "too big". Sometimes I make a suggestion or two that breaks
      the log jam: though it's not what I'm necessarily there to do, it
      seems like an interesting line of work. I'm not sure how to market
      it.

      But what happens is that I work with the team. I maintain my
      confidence that there's a way to do everything incrementally,
      primarily based on the fact that everything actually /is/ done
      incrementally, we just don't parse it that way. I ask questions like
      - how do we see it working
      - how could we find out whether that's a good idea
      - would something like this work
      - couldn't we experiment on that right now
      and after a while the team knows something to do.

      I'd like to attribute those successful results to my 1337 hax0r
      sk1llz, and I admit that I am good at it. But the real knowledge and
      figuring out comes from the team.

      What do they need? Things they already have: knowledge of the system
      and programming techniques; ability to generate alternatives and
      ideas; creativity; things like that.

      And they have to try.

      > Just a thought.

      And an interesting one. I haven't answered it quite in the form you
      may have expected. What are you thinking now?

      Ron Jeffries
      www.XProgramming.com
      If there's only one answer, then this must not be a very interesting topic.



      To Post a message, send it to: scrumdevelopment@...
      To Unsubscribe, send a blank message to:
      scrumdevelopment-unsubscribe@...
      Yahoo! Groups Links
    • Ron Jeffries
      ... I guess I don t understand the question. Ron Jeffries www.XProgramming.com How do I know what I think until I hear what I say? -- E M Forster
      Message 2 of 12 , Aug 3, 2005
      • 0 Attachment
        On Wednesday, August 3, 2005, at 10:38:02 PM, Mike Dwyer wrote:

        > Forgive me but I will have to respond to your cogent and well order response
        > tomorrow. I made the mistake of reading the posts in a LIFO order and this
        > is what is left of my brain.

        > "The customer walks in and tells you of a new thing they saw on TV where
        > somebody said Squirrel Burger and Ken showed up made it and left, leaving
        > the fried squirrel in a half eaten bun.

        > I want one, they said, and I want it in a week then they left

        > Where do you begin?

        I guess I don't understand the question.

        Ron Jeffries
        www.XProgramming.com
        How do I know what I think until I hear what I say? -- E M Forster
      • aacockburn
        ... leaving the fried squirrel in a half eaten bun. ... I d begin by asking them to come back. How come they left and didn t come back? ... Definitely what
        Message 3 of 12 , Aug 3, 2005
        • 0 Attachment
          > somebody said Squirrel Burger and Ken showed up made it and left,
          leaving > the fried squirrel in a half eaten bun.
          >
          > I want one, they said, and I want it in a week then they left
          >
          > Where do you begin?

          I'd begin by asking them to come back. How come they left and didn't
          come back?

          > > The requestor's ability to provide clarity as to the functions
          > > needed and the team's capability to reach agreement on the common
          > > perception, wold seem to be the critical issue. Once clarity and
          > > agreement are reached anything can be built quickly.
          >
          > Well, I think that just maybe, Agile software development is about
          > building the software while reaching clarity, not after reaching
          > clarity.

          Definitely what Ron said. At the same time, software creation is all
          about growth and transfer of "understandings" (in quotes due to its
          subjective and unreliable nature). The people gain clarity/
          understanding of the problem over time, and gain clarity/
          understanding of their proposed solution over time. Usually they have
          to ship their encoded muddled understanding just as they are starting
          to achieve clarity. It is possible, and occasionally happens, that
          they get the software working and the users happy, and then instead
          of shipping the system, they declare that they are close to clarity
          and then study their encoded solution and gain more clarity and then
          rewrite the program much smaller and simpler.

          In this last case, they do indeed build the last version quickly,
          having achieved clarity.

          (An example: back in 1978-80, a not-very-social colleague of mine was
          assigned to write a real-time operating system for a mammoth 3D real-
          time computer graphics flight simulator. He pissed everyone off by
          rewriting the operating system from scratch every 4 months ... except
          that by the end of the project, he had written it in FORTRAN! By that
          time, his clarity was great, and the operating system was simpler and
          faster and easier to maintain than any of his previous versions. I
          don't think he ever received appropriate kudos for this
          accomplishment)
        • Ron Jeffries
          ... I ve noticed that if you piss people off sufficiently, it no longer matters that you were right ... Ron Jeffries www.XProgramming.com Comments lie. Code
          Message 4 of 12 , Aug 4, 2005
          • 0 Attachment
            On Thursday, August 4, 2005, at 2:14:17 AM, aacockburn wrote:

            > (An example: back in 1978-80, a not-very-social colleague of mine was
            > assigned to write a real-time operating system for a mammoth 3D real-
            > time computer graphics flight simulator. He pissed everyone off by
            > rewriting the operating system from scratch every 4 months ... except
            > that by the end of the project, he had written it in FORTRAN! By that
            > time, his clarity was great, and the operating system was simpler and
            > faster and easier to maintain than any of his previous versions. I
            > don't think he ever received appropriate kudos for this
            > accomplishment)

            I've noticed that if you piss people off sufficiently, it no longer
            matters that you were right ...

            Ron Jeffries
            www.XProgramming.com
            Comments lie. Code doesn't.
          • aacockburn
            ... was ... real- ... except ... that ... and ... Right --- the magic is to piss them off just barely not enough to rebel. In this case, history proved him
            Message 5 of 12 , Aug 4, 2005
            • 0 Attachment
              --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
              <ronjeffries@X...> wrote:
              > On Thursday, August 4, 2005, at 2:14:17 AM, aacockburn wrote:
              >
              > > (An example: back in 1978-80, a not-very-social colleague of mine
              was
              > > assigned to write a real-time operating system for a mammoth 3D
              real-
              > > time computer graphics flight simulator. He pissed everyone off by
              > > rewriting the operating system from scratch every 4 months ...
              except
              > > that by the end of the project, he had written it in FORTRAN! By
              that
              > > time, his clarity was great, and the operating system was simpler
              and
              > > faster and easier to maintain than any of his previous versions. I
              > > don't think he ever received appropriate kudos for this
              > > accomplishment)
              >
              > I've noticed that if you piss people off sufficiently, it no longer
              > matters that you were right ...
              >

              Right --- the magic is to piss them off just barely not enough to
              rebel.
              In this case, history proved him right in that the system shipped and
              was maintained over 5+ years, and the OS had an unusually long life.
              The discomfort was mostly around the fact that he would rewrite it
              over the weekend and obviously there would be bugs in it on Monday
              morning.
              It is easy to conflate being non-talkative with having a faulty
              strategy... Someone else with a good bedside manner could have pulled
              it off perhaps with less tearing of the social fabric, and still
              ended up with the same code.
            • mike.dwyer1@comcast.net
              When we look at the CAS model Clarity and Agreement should be considered continuum. As clarity and agreement converge, the simpler the solution becomes. The
              Message 6 of 12 , Aug 4, 2005
              • 0 Attachment
                When we look at the CAS model Clarity and Agreement should be considered continuum.   As clarity and agreement converge, the simpler the solution becomes.  The question i am wandering toward is not so much the refinement of clarity and agreement that Agile provides but rather what defines the boundary between insufficient and sufficient clarity and agreement to start with.To put it another way how far do we venture into the realms of Complexity, Ambiguity and Chaos.
                 
                Alistair says for them to come back.  I am asking for some indicators that tell us not to go forward as opposed to only those that tell us we can do it.
                 
                I appreciate both of your assistance in refining the question.  Please continue.
                --
                Mike Dwyer

                "I Keep six faithful serving-men
                Who serve me well and true:
                Their names are What and Where and When
                And How and Why and Who." - Kipling
                 
                -------------- Original message --------------

                > > somebody said Squirrel Burger and Ken showed up made it and left,
                > leaving > the fried squirrel in a half eaten bun.
                > >
                > > I want one, they said, and I want it in a week then they left
                > >
                > > Where do you begin?
                >
                > I'd begin by asking them to come back. How come they left and didn't
                > come back?
                >
                > > > The requestor's ability to provide clarity as to the functions
                > > > needed and the team's capability to reach agreement on the common
                > > > perception, wold seem to be the critical issue. Once clarity and
                > > > agreement are reached anything can be built quickly.
                > >
                > > Well, I think that just maybe, Agile software development is about
                > > building the software while reaching clarity, not after reaching
                > > clarity.
                >
                > Definitely what Ron said. At the same time, software creation is all
                > about growth and transfer of "understandings" (in quotes due to its
                > subjective and unreliable nature). The people gain clarity/
                > understanding of the problem over time, and gain clarity/
                > understanding of their proposed solution over time. Usually they have
                > to ship their encoded muddled understanding just as they are starting
                > to achieve clarity. It is possible, and occasionally happens, that
                > they get the software working and the users happy, and then instead
                > of shipping the system, they declare that they are close to clarity
                > and then study their encoded solution and gain more clarity and then
                > rewrite the program much smaller and simpler.
                >
                > In this last case, they do indeed build the last version quickly,
                > having achieved clarity.
                >
                > (An example: back in 1978-80, a not-very-social colleague of mine was
                > assigned to write a real-time operating system for a mammoth 3D real-
                > time computer graphics flight simulator. He pissed everyone off by
                > rewriting the operating system from scratch every 4 months ... except
                > that by the end of the project, he had written it in FORTRAN! By that
                > time, his clarity was great, and the operating system was simpler and
                > faster and easier to maintain than any of his previous versions. I
                > don't think he ever received appropriate kudos for this
                > accomplishment)
                >
                >
                >
                >
                >
                >
                >
                >
                > To Post a message, send it to: scrumdevelopment@...
                > To Unsubscribe, send a blank message to:
                > scrumdevelopment-unsubscribe@...
                > Yahoo! Groups Links
                >
                > <*> To visit your group on the web, go to:
                > http://groups.yahoo.com/group/scrumdevelopment/
                >
                > <*> To unsubscribe from this group, send an email to:
                > scrumdevelopment-unsubscribe@yahoogroups.com
                >
                > <*> Your use of Yahoo! Groups is subject to:
                > http://docs.yahoo.com/info/terms/
                >
                >
                >
              Your message has been successfully submitted and would be delivered to recipients shortly.