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

Fitting stuff into a 30 day sprint

Expand Messages
  • jcloughley@performancesoft.com
    Naturally, not everything fits into a 30 day sprint. I have a fairly large change planned where we are augmenting our transport layer. Doing this one feature
    Message 1 of 12 , Aug 2, 2005
    • 0 Attachment
      Naturally, not everything fits into a 30 day sprint. I have a fairly
      large change planned where we are augmenting our transport layer. Doing
      this one feature within a 30 day timebox won't work.

      We could split it such that the architecture review is done in sprint 1,
      with the design following in sprint 2. The resulting coding and testing
      would then occur in the third sprint with the new feature completed at the
      end of the third sprint. However, life doesn't always work thay way.

      Specifically, what if the resulting coding effort will take longer than 30
      days? Do code check-ins occur across sprints such that most of the
      feature is in and tested in sprint 3 with the remaining work completed in
      sprint 4 and available at the end of sprint 4? If so, how do you keep QA
      happy that there are code changes in sprint 3 that aside from unit tests
      by developers, has not been tested by QA?

      Essentially I'm looking for some concrete examples of what others are
      doing/have done for this scenario.

      Of course, bug fixes for unrelated issues are included in all of the
      sprints described above where we may choose to ship at the end of any or
      all sprints.

      Thanks...

      Jim
    • Mitch Lacey
      Jim, The scenario you describe below sounds an awful lot like a traditional, prescribed approach to me :-) Is the work that you have laid out able to be
      Message 2 of 12 , Aug 2, 2005
      • 0 Attachment

        Jim,

         

        The scenario you describe below sounds an awful lot like a traditional, prescribed approach “to me”  J 

         

        Is the work that you have laid out able to be split up into small chunks such that you can spend 3-5 days doing the architecture review, spend 3-5 days doing some lightweight design, spend the last two weeks doing coding, testing and integration?  If not, maybe it should be.

         

        Here is an example.  It works better as a diagram, but this should work.

         

        Think of your augmentation of the transport layer as “the feature”.  When the feature is complete, you’ll be at “100” – this is just a number that does not represent much other than a value of 100.

         

        In sprint 1, think on how you can accomplish doing arch, design, code, test and integration into a 30 day period, incrementing your feature from a value of “0” (after all, you’re staring out in day 1 of sprint 1) to a value of, say, “20”

         

        In sprint 2, think of how you can build on that value of 20 to take it to 30 or 40 or 50.  You’ll do the same exercises through the different disciplines growing the functionality.

         

        Sprint 3-n, repeat.

         

         

         

        Now, for the personal experiences:

        What if the resulting coding effort will take longer than 30 days? 

        ML: Break it down into small work items until it fits in a 30 day window.  Yes, this is a short answer, but I do not want to write a novel right now. J  I’d be happy to spend some time on the phone with you if you’re interested.

         

        Do code check-ins occur across sprints such that most of the feature is in and tested in sprint 3 with the remaining work completed in sprint 4 and available at the end of sprint 4?

        ML: We do check ins and builds daily at a minimum.  We do integration testing nightly on the teams off hours through automation (after all, you have 16 hours available to you when you’re not at work – make that fancy hardware do something!).  We finish all our work in each sprint and call ourselves done (long meaning on what this is, but you should define what it means to be done for your team, with your team, up front).

         

        If so, how do you keep QA happy that there are code changes in sprint 3 that aside from unit tests by developers, has not been tested by QA?

        ML: Test continually as part of the sprint.  Bring QA into the world of the developer, the architect and have them contribute to the designs.  Nothing at the end of any sprint should be untested.  You are delivering an incremental piece of functionality that delivers business value to your customers and your company every sprint.  Everyone is involved in contributing to this – everyone.

         

        Of course, bug fixes for unrelated issues are included in all of the sprints described above where we may choose to ship at the end of any or all sprints.

        ML: but of course!  J

         

        That help?

         

        -Mitch

         

         

        -----Original Message-----
        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of jcloughley@...
        Sent: Tuesday, August 02, 2005 5:39 PM
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] Fitting stuff into a 30 day sprint

         

        Naturally, not everything fits into a 30 day sprint.  I have a fairly large change planned where we are augmenting our transport layer.  Doing this one feature within a 30 day timebox won't work.

         

        We could split it such that the architecture review is done in sprint 1, with the design following in sprint 2.  The resulting coding and testing would then occur in the third sprint with the new feature completed at the end of the third sprint.  However, life doesn't always work thay way.

         

        Specifically, what if the resulting coding effort will take longer than 30 days?  Do code check-ins occur across sprints such that most of the feature is in and tested in sprint 3 with the remaining work completed in sprint 4 and available at the end of sprint 4?  If so, how do you keep QA happy that there are code changes in sprint 3 that aside from unit tests by developers, has not been tested by QA?

         

        Essentially I'm looking for some concrete examples of what others are doing/have done for this scenario.

         

        Of course, bug fixes for unrelated issues are included in all of the sprints described above where we may choose to ship at the end of any or all sprints.

         

        Thanks...

         

        Jim

         

         

         

         

        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/

         

         

         

         

      • Ron Jeffries
        Hi Jim, I m going to take a perhaps surprising position here ... ... Actually I disagree. Everything can be done in 30 day sprints. In fact, I think everything
        Message 3 of 12 , Aug 2, 2005
        • 0 Attachment
          Hi Jim,

          I'm going to take a perhaps surprising position here ...

          On Tuesday, August 2, 2005, at 8:39:23 PM, jcloughley@... wrote:

          > Naturally, not everything fits into a 30 day sprint. I have a fairly
          > large change planned where we are augmenting our transport layer. Doing
          > this one feature within a 30 day timebox won't work.

          Actually I disagree. Everything can be done in 30 day sprints. In
          fact, I think everything can be done in one week iterations.

          In fact, I think everything can be done in one /day/ chunks.

          > We could split it such that the architecture review is done in sprint 1,
          > with the design following in sprint 2. The resulting coding and testing
          > would then occur in the third sprint with the new feature completed at the
          > end of the third sprint. However, life doesn't always work thay way.

          > Specifically, what if the resulting coding effort will take longer than 30
          > days? Do code check-ins occur across sprints such that most of the
          > feature is in and tested in sprint 3 with the remaining work completed in
          > sprint 4 and available at the end of sprint 4? If so, how do you keep QA
          > happy that there are code changes in sprint 3 that aside from unit tests
          > by developers, has not been tested by QA?

          Too many questions. Anyway, the concern is valid. There is no reason
          whatsoever to imagine that the three-sprint split, as described,
          will work. (There is also no reason to imagine that 30 days of
          coding is properly prefixed with 30 real days of architectural
          review, followed by 30 real days of design, and if that's true, then
          three sprints is too long.

          > Essentially I'm looking for some concrete examples of what others are
          > doing/have done for this scenario.

          Split the story, do "vertical" slices in each sprint. Ideally, I'd
          do each slice in a week.

          It's always possible, as far as I can tell. After all ... if the
          work is going to be done in 90 days, something must be done every
          one of those 90 days. The issue isn't whether the work is capable of
          being segmented. It's whether we can come up with a way to account
          for it.

          Ron Jeffries
          www.XProgramming.com
          In programming, do, or undo. There is always try. --Yoda
        • mike.dwyer1@comcast.net
          Ron: The time needed to develop stuff is out of the control of the developer. The requestor s ability to provide clarity as to the functions needed and the
          Message 4 of 12 , Aug 3, 2005
          • 0 Attachment
            Ron:
            The time needed to develop stuff is out of the control of the developer.  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.
             
            Ah, but what defines quickly?  It is definitely not the clock, or a calendar.  Perhaps it is the time needed to construct the right sized chunks to work on.
             
            If you agree with some of this, then let's ask another question.  Describe the key skills needed to accomplish this.
             
            Just a thought.
             
            --
            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 --------------

            > Hi Jim,
            >
            > I'm going to take a perhaps surprising position here ...
            >
            > On Tuesday, August 2, 2005, at 8:39:23 PM, jcloughley@... wrote:
            >
            > > Naturally, not everything fits into a 30 day sprint. I have a fairly
            > > large change planned where we are augmenting our transport layer. Doing
            > > this one feature within a 30 day timebox won't work.
            >
            > Actually I disagree. Everything can be done in 30 day sprints. In
            > fact, I think everything can be done in one week iterations.
            >
            > In fact, I think everything can be done in one /day/ chunks.
            >
            > > We could split it such that the architecture review is done in sprint 1,
            > > with the design following in sprint 2. The resulting coding and testing
            > > would then occur in the third sprint with the new feature completed at the
            > > end of the third sprint. However, life doesn't always work thay way.
            >
            > > Specifically, what if the resulting coding effort will take longer than 30
            > > days? Do code check-ins occur across sprints such that most of the
            > > feature is in and tested in sprint 3 with the remaining work completed in
            > > sprint 4 and available at the end of sprint 4? If so, how do you keep QA
            > > happy that there are code changes in sprint 3 that aside from unit tests
            > > by developers, has not been tested by QA?
            >
            > Too many questions. Anyway, the concern is valid. There is no reason
            > whatsoever to imagine that the three-sprint split, as described,
            > will work. (There is also no reason to imagine that 30 days of
            > coding is properly prefixed with 30 real days of architectural
            > review, followed by 30 real days of design, and if that's true, then
            > three sprints is too long.
            >
            > > Essentially I'm looking for some concrete examples of what others are
            > > doing/have done for this scenario.
            >
            > Split the story, do "vertical" slices in each sprint. Ideally, I'd
            > do each slice in a week.
            >
            > It's always possible, as far as I can tell. After all ... if the
            > work is going to be done in 90 days, something must be done every
            > one of those 90 days. The issue isn't whether the work is capable of
            > being segmented. It's whether we can come up with a way to account
            > for it.
            >
            > Ron Jeffries
            > www.XProgramming.com
            > In programming, do, or undo. There is always try. --Yoda
            >
            >
            >
            > 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/
            >
            >
            >
          • Ron Jeffries
            ... 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. ...
            Message 5 of 12 , Aug 3, 2005
            • 0 Attachment
              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.
            • Jim Cloughley
              I guess I should have filled in more of the blanks. I ve been here about 2 months and my team is well experienced but is not used to scrum. I came from an
              Message 6 of 12 , Aug 3, 2005
              • 0 Attachment

                I guess I should have filled in more of the blanks.  I’ve been here about 2 months and my team is well experienced but is not used to scrum.  I came from an environment where we had a 30-day iteration, a nightly build, automated unit and system testing and the developers and QA saw the value of all 4.  I know the value but I’m not having much success just telling others about it.  I think developers and QA need to experience it in order to really *see* the value.

                 

                One thing that came up with my new team was a feature that someone here had been working on for the last couple of months.  Essentially we were experimenting with wrapping our communication layer in http in order to get through firewalls, etc.  The question came up on how that feature would have worked in scrum.  They stated that it wouldn’t have fit into 30 days.

                 

                I agree that the feature could have been split into chewable chunks and those chunks could have been integrated daily and been in early sprints BUT not without feedback from unit tests, not without feedback from system tests, not without early QA involvement, etc.  I think the missing piece of the puzzle was that it’s ok to have code checked in that is “done” (in the scrum sense of “done”) where every agrees it’s “done” – including QA.  However, the feature itself may not yet be done because you’re only part way through the entire feature.

                 

                Jim

                 

                 


                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.


              • 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 7 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 8 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 9 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 10 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 11 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 12 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.