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

Re: [scrumdevelopment] Re: Organizational Patterns of Agile Softw are Development

Expand Messages
  • Brad Appleton
    ... [...] ... I think you re running into a problem I ran into when coming up with the above names. For example, take Minimal Deployable Release . It really
    Message 1 of 18 , Oct 27, 2004
    • 0 Attachment
      On Wed, Oct 27, 2004 at 10:31:02AM -0500, Mike Beedle wrote:
      >
      > Brad wrote:
      > > * Minimal Deployable Releases
      > > * Minimal Manageable Iterations
      > > * Minimal Meaningful Models
      > > * Minimal Marketable Features
      > > * Minimal Malleable Designs
      > > * Minimal Mergeable Change-Tasks
      > > * Minimal Testable Modifications
      > > * Minimal Perpetual Peer-Review

      [...]
      > > * Minimal Deployable Releases
      >
      > Maximal Deployable Releases.

      I think you're running into a problem I ran into when
      coming up with the above names. For example, take "Minimal
      Deployable Release". It really would be clearer to say
      "deployable minimal release". Then it's clear that
      "minimal" refers to the release, not its deployability
      (which would be "minimally deployable" rather than "minimal
      yet deployable" :-). But by putting the "minimal" at the
      beginning it emphasizes the lean aspect and takes poetic
      license with the aliteration (at the possible expense of
      clarity :-)

      So I think you want your releases to be Maximally Deployable,
      but the releases themselves are probably not maximal in
      their size (you probably want to maximize the value in the
      release while minimizing the size to what can be deployed
      successfully and swiftly.


      > > * Minimal Manageable Iterations
      >
      > Balanced Manageable Iterations
      >
      > We want to balance not minimize manage iterations.

      So, just to clarify, the intent was to read that
      as "minimal yet manageable" and not as "minimally
      manageable". I think SCRUM feels that one month is about as
      minimal as it wants while still being manageable both from
      the perspective of the team and the customer. I think
      SCRUM tends toward the belief that one week iterations
      are harder to manage. So the "making them manageable"
      part is what forces a balance to be struck regarding.

      That was at least my philosophy when coming up with each of
      those names (tho I took my lead from "Software by Numbers"
      with its "Minimal Marketable Features"). The trick is finding
      a balance between how small is possible, versus how small
      is still feasible and at what point does getting smaller
      start to create an imbalance among shared sets of concerns.

      Hence, my feeling that release "smallness" needs to be
      constrained by what can successfully deployed. Anything
      that is so small as to not be deployable would be
      too small. I guess if you look at it from a time-frame
      where the time-frame is constant, then you want to maximize
      the deployability within that time-frame. That's another
      way to look at it.

      I was coming more from a perspective of someone having
      to write patterns/stories for how they should Size the
      Release, the Iteration, the Modeling, the Tasks, etc. so
      I had to come up with what I felt was a word that best
      characterized the criteria for knowing how to
      determine "how small is too small" is to small.
      Hence,
      * For releases, I felt it was deployability

      * For iterations, I felt it was the ability to manage the
      scope, the team, the tasks, and the customer relationship.

      * For features, I liked Denne's and Huang's criteria of
      "marketability". The feature has to be large enough
      to be perceived as a marketable "chunk" of customer
      value that is worth the effort to do reporting and
      status-accounting for. It can certainly be broken down
      into smaller and smaller chunks for the purpose of
      coding, but once you get to the point where the customer
      says "that's smaller than what I'm interested in seeing
      tracking and status-accounting reports and charts for"
      - then that is the smallest "chunk" form the customer's
      view, and any further breakdown still needs to be able
      to roll-up progress (e.g. burndown charts and task-cards)
      against the granularity of customer visibility and
      reporting.

      * For model, I felt it was "meaningfulness". Pictures
      are drawn to the extent that they help facilitate
      communicate more conveniently than code, and beyond
      that - code is used. (so the purpose of modeling
      in agile projects is not for code-generation or
      translation/specification, but for things like
      metaphor, and shared-vocabulary, and the foundations
      of domain-driven design)

      * For design, I felt it was basically similar to Kent's
      criteria for "simple design" of the code

      * For coding, I think TDD emphasizes working in the
      smallest possible increments at a time that are still testable.

      * For change-tasks, I think continuous/frequent integration
      suggests working in the smallest feasible chunks that
      can be successfully merged (integrated) without "breaking
      the build" for anyone else on the team

      > Part of our: PROJECT MANAGEMENT/RELREASE MANGEMENT
      >
      > > * Minimal Meaningful Models
      >
      > Minimal for us is ... the code.
      >
      > But occasionally we do models upon client request.
      > Part of our: CUSTOMER SATISFACTION

      Thats sounds different from what I've heard from a lot of
      other SCRUMers. My understanding is that SCRUM will still
      often to some very basic, rudimentary pictures/diagrams
      to convey the essence of "metaphor" or the subject domain
      (even if only on a napkin). XP does this too.


      > > * Minimal Marketable Features
      >
      > Maximal Marketable Features

      Here again I think you really mean "Maximally Marketable",
      but you want the features themselves to still be as
      minimal (in size) as feasible while still maximizing
      their marketability.

      > > * Minimal Malleable Designs
      >
      > Minimal for us is ... the code

      As it is in my write-up as well. Did you get a chance to
      read my descriptions of each of those things or did you
      just try to understand it solely from the dual-word names?

      > > * Minimal Mergeable Change-Tasks
      >
      > Maximal Mergeable Change-Tasks
      >
      > We want to maximize the Mergeable Change-Tasks.

      Again, I believe you mean Maximally, not Maximal (because
      it modifies the mergeability, not the change-task). When you
      are sizing a change-task in SCRUM you are not maximizing
      it. You aren't necessarily even trying to maximize the
      number of change tasks. You are trying to maximize
      the frequency of integration, which means making the
      merges as frequent as feasible. So how frequent is too
      frequent? How small is too small to merge? I claim
      mergeability is the criteria: small enough to merge/integrate
      without breaking the build.

      > > * Minimal Testable Modifications

      Again, the minimal (or maximal, in your case) modifies
      the noun, rather than the adjective that follows it.
      The modification is both minimal yet still testable

      > We want to maximize the testing of all the system
      > Including any new modifications.

      I think "deploy comprehensive testing" (as Poppendieck
      describes it) is what you mean here. That is very
      different from saying maximize the testable system, or
      even maximize the testing. (You don't want to maximize
      the amount of testing for the sake of having more tests
      do you? Do you want to write enough tests to have 100%
      coverage of all paths, conditions, statements, etc., are
      is there some subset of that which you feel is the most
      "bang for the buck" regarding the number of type of tests
      that are actually used versus what is possible?

      > Part of our: FREQUENT INTEGRATION/RELREASE MANGEMENT
      >
      > > * Minimal Perpetual Peer-Review
      >
      > Minimal for us is ... NO Peer Reviews

      Again that sounds very different from what I've heard you
      and other SCRUMers describe. Recall that Pair programming
      is a form of continuous-two-person peer review. I think
      you are referring to the formality of the peer-review when
      you say "NO Peer Reviews". You really mean "NO Formal Peer
      Reviews". Those two are very different things.

      From what I see in the books and read on the lists and
      hear from other agilists (including yourself :-), both XP
      and SCRUM do peer-reviews all the time, but they make them
      as informal as feasible (and part of that being effective
      is making the amount of stuff being reviewed be as small
      as feasible).

      --
      Brad Appleton <brad@...> www.bradapp.net
      Software CM Patterns (www.scmpatterns.com)
      Effective Teamwork, Practical Integration
      "And miles to go before I sleep." -- Robert Frost
    • Mike Beedle
      ... Brad, I will write what we strive in different words to clarify: We want to deploy *as much as we can* in terms of features. That sounds like maximal in
      Message 2 of 18 , Oct 27, 2004
      • 0 Attachment
        Mike Beedle wrote:
        > Brad Appleton wrote:
        > > * Minimal Deployable Releases
        >
        >       Maximal Deployable Releases.

        Brad Appleton wrote:
        >So I think you want your releases to be Maximally Deployable,
        >but the releases themselves are probably not maximal in
        >their size (you probably want to maximize the value in the
        >release while minimizing the size to what can be deployed
        >successfully and swiftly.

        Brad,

        I will write what we strive in different words to clarify:

        We want to deploy *as much as we can* in terms of features.

        That sounds like "maximal in size" to me but what do you mean by size?

        Megabytes? Number of files? We only count features for size.

        Mike Beedle wrote:
        > Brad Appleton wrote:
        > > * Minimal Manageable Iterations
        >
        >       Balanced Manageable Iterations
        >
        >       We want to balance not minimize manage iterations.

        Brad Appleton wrote:
        >The trick is finding a balance between how small is possible,
        >versus how small is still feasible and at what point does
        >getting smaller start to create an imbalance among shared
        >sets of concerns.

        ... This is why I felt "balanced" was a better description.

        Not too small that you can't do something meaningful, but not too large that
        you don't make a release for a long time.


        Mike Beedle wrote:
        > Brad Appleton wrote:
        >       Part of our: PROJECT MANAGEMENT/RELREASE MANGEMENT
        >
        > > * Minimal Meaningful Models
        >
        >       Minimal for us is ... the code.
        >
        >       But occasionally we do models upon client request.
        >       Part of our: CUSTOMER SATISFACTION

        Brad Appleton wrote:
        >Thats sounds different from what I've heard from a lot of
        >other SCRUMers.  My understanding is that SCRUM will still
        >often to some very basic, rudimentary pictures/diagrams
        >to convey the essence of "metaphor" or the subject domain
        >(even if only on a napkin). XP does this too.


        Well, there is not such a thing as "Generic Scrum" implemented in practice.


        Every Scrummer does something different in practice by definition:

        All Scrummer must plan, track, manage, develop, integrate, test
        and release but *every* Scrummer does so in a different way.

        Scrum means: adapt to your needs -- self-organize. So everything goes in
        terms of engineering tasks -- as long as it gets the job done. Scrummers do
        *what they need to do to satisfy their customers*.

        In our case we don’t do pictures unless the client wants them and pays for
        them.

        Mike Beedle wrote:
        > Brad Appleton wrote:
        > > * Minimal Marketable Features
        >
        >       Maximal Marketable Features

        Brad Appleton wrote:
        >Here again I think you really mean "Maximally Marketable",
        >but you want the features themselves to still be as
        >minimal (in size) as feasible while still maximizing
        >their marketability.

        I think we do want the most *features* - a maximal numbers of features to go
        on our web sites, brochures and demonstrations, with the "maximum
        marketable" potential.

        Now, understood, the "maximal number of features" does not always mean the
        "maximum marketable" potential, of course, but in most cases it does.

        Mike Beedle wrote:
        > Brad Appleton wrote:
        > > * Minimal Malleable Designs
        >
        >       Minimal for us is ... the code

        Brad Appleton wrote:
        >As it is in my write-up as well. Did you get a chance to
        >read my descriptions of each of those things or did you
        >just try to understand it solely from the dual-word names?

        Just from the dual-word names.

        Mike Beedle wrote:
        > Brad Appleton wrote:
        > > * Minimal Mergeable Change-Tasks
        >
        >       Maximal Mergeable Change-Tasks
        >
        >       We want to maximize the Mergeable Change-Tasks.

        Brad Appleton wrote:
        > small enough to merge/integrate without breaking the build.

        Oh, I see, I missed that part. What I was trying to convey is:

        We want a maximum number of change-tasks to be mergeable.
        Because otherwise, we have to do it manually.

        For example, picture a CVS synchronization process I want Eclipse to tell
        me:
        Out of these change-tasks I can merge the maximum number,
        hopefully all of the change-tasks.

        But now I see you were going after something else.

        Mike Beelde wrote
        > Brad Appleton wrote:
        > > * Minimal Testable Modifications
        > * Maximize the Testable System

        Brad Appleton wrote:
        >Again, the minimal (or maximal, in your case) modifies
        >the noun, rather than the adjective that follows it.
        >The modification is both minimal yet still testable

        Mike Beedle wrote:
        > We want to maximize the testing of all the system
        > Including any new modifications.

        Brad Appleton wrote:
        >I think "deploy comprehensive testing" (as Poppendieck
        >describes it) is what you mean here. That is very
        >different from saying maximize the testable system, or
        >even maximize the testing. (You don't want to maximize
        >the amount of testing for the sake of having more tests
        >do you? Do you want to write enough tests to have 100%
        >coverage of all paths, conditions, statements, etc., are
        >is there some subset of that which you feel is the most
        >"bang for the buck" regarding the number of type of tests
        >that are actually used versus what is possible?


        I think you meant for "Minimal Testable Modifications"

        "small modifications that can be tested".

        Is that correct? If so, I am ok with that.

        There is also a minimum acceptable or doable testing, so I can buy:

        "Minimal testing" or even "Minimal Tests"

        But in this case:

        "Balanced Testing" sounds more appropriate to me, as in
        "choose your battles", or "get the most bang for your buck".

        I was going after:

        "Maximize your testing with the goal to reach 100% coverage."

        when I wrote the first response.


        Mike Beedle wrote:
        > Brad Appleton wrote:
        > Part of our: FREQUENT INTEGRATION/RELREASE MANGEMENT
        >
        > > * Minimal Perpetual Peer-Review
        >
        >       Minimal for us is ... NO Peer Reviews

        Brad Appleton wrote:
        > Again that sounds very different from what I've heard you
        > and other SCRUMers describe. Recall that Pair programming
        > is a form of continuous-two-person peer review. I think
        > you are referring to the formality of the peer-review when
        > you say "NO Peer Reviews". You really mean "NO Formal Peer
        > Reviews". Those two are very different things.
        >
        > From what I see in the books and read on the lists and
        > hear from other agilists (including yourself :-), both XP
        > and SCRUM do peer-reviews all the time, but they make them
        > as informal as feasible (and part of that being effective
        > is making the amount of stuff being reviewed be as small
        > as feasible).

        We don't do formal reviews and we don't do pairing. In our shop, everyone
        tests, sees, and modifies if needed everyone else's code anytime.
        I guess that can be seen as a form of Peer Review,

        - Mike
      • Ron Jeffries
        ... I suspect that most people already think their release frequency is balanced. Our customers don t really want more than one release a year. I believe
        Message 3 of 18 , Oct 27, 2004
        • 0 Attachment
          On Wednesday, October 27, 2004, at 4:53:47 PM, Mike Beedle wrote:

          > Brad Appleton wrote:
          >>The trick is finding a balance between how small is possible,
          >>versus how small is still feasible and at what point does
          >>getting smaller start to create an imbalance among shared
          >>sets of concerns.

          > ... This is why I felt "balanced" was a better description.

          > Not too small that you can't do something meaningful, but not too large that
          > you don't make a release for a long time.

          I suspect that most people already think their release frequency is
          balanced. "Our customers don't really want more than one release a year."

          I believe Brad is suggesting that more frequent releases is the constant
          pressure one should feel. I would agree, and would guess that he would,
          that we would also like to have as much in each release as possible. It's a
          bit hard to imagine anyone not wanting that, but it's easy to imagine (or
          find) people who don't know they should want to release more often.

          Ron Jeffries
          www.XProgramming.com
          My advice is to do it by the book, get good at the practices, then do as
          you will. Many people want to skip to step three. How do they know?
        • Brad Appleton
          ... What about time? I think you only want as many features as possible if you are assuming a specific time-duration between now and the end of the release.
          Message 4 of 18 , Oct 27, 2004
          • 0 Attachment
            On Wed, Oct 27, 2004 at 03:53:47PM -0500, Mike Beedle wrote:
            > I will write what we strive in different words to clarify:
            >
            > We want to deploy *as much as we can* in terms of features.
            >
            > That sounds like "maximal in size" to me but what do you mean by size?

            What about time? I think you only want "as many features
            as possible" if you are assuming a specific time-duration
            between now and the end of the release.

            Remember, the practices I characterized at:
            http://www.cmcrossroads.com/article/34375

            are referring to different levels of scale of feedback
            cycles. And there is a Saturn-like diagram that
            tries to illustrate that.

            So "size" is about keeping the duration as small
            as possible for the purpose of rapid-feedback &
            learning/adjustment, which means minimizing the scope
            as much as feasible to make the time-duration smaller
            and smaller.

            > In our case we dont do pictures unless the client wants
            > them and pays for them.

            You want to deliver WORKING CODE, and not any documents
            or pictures that the customer didn't explicitly ask for.

            And you want to communicate program/design information
            in the most effective and efficient means possible.
            And you do indeed use pictures as part of that
            programmer-to-programmer communication. You just don't do
            it for the sake of making models or for generating code
            or detailed specs. You do it ONLY to the extent that it
            facilitates face-to-face communication about higher-level
            concepts and abstractions more easily than text/code
            does. And after that, you use code rather than drawing.

            If you're telling me SCRUMers don't draw any pictures
            on whiteboards (or paper or napkins) as a commonplace
            occurrence between programmer-programmer communication,
            than that contradicts everything else I've ever heard and
            seen w.r.t. SCRUM.

            > I think we do want the most *features* - a maximal numbers
            > of features to go on our web sites, brochures and
            > demonstrations, with the "maximum marketable" potential.

            I think where agility comes into play is in making
            the relevant feed-back loops as short as possible
            while still balancing this desire. And I think
            it is the short-feedback-loop that is characteristic
            of agility rather than the desire for maximal # features.
            I don't think maximal # features is a particularly agile
            characteristic

            > Brad Appleton wrote:
            > >As it is in my write-up as well. Did you get a chance to
            > >read my descriptions of each of those things or did you
            > >just try to understand it solely from the dual-word names?
            >
            > Just from the dual-word names.

            Okay - that explains a lot. I suggest reading the
            descriptions before trying to comment further on what
            those dual-word names mean (there was an earlier post that
            had the 2-3 line descriptions as well). URL is above

            > Brad Appleton wrote:
            > > small enough to merge/integrate without breaking the build.
            >
            > Oh, I see, I missed that part.

            Yeah. I think reading the actual descriptions would clear
            up a lot of the misunderstanding that seem to be taking
            place here.

            > I think you meant for "Minimal Testable Modifications"
            >
            > "small modifications that can be tested".
            >
            > Is that correct? If so, I am ok with that.

            Yes. Again, I think reading the actual descriptions would
            clear up a lot of the misunderstanding that seem to be
            taking place here.

            > We don't do formal reviews and we don't do pairing.
            > In our shop, everyone tests, sees, and modifies
            > if needed everyone else's code anytime. I guess
            > that can be seen as a form of Peer Review,

            Yup. And you are doing it all the time, usually in pretty
            small chunks.

            --
            Brad Appleton <brad@...> www.bradapp.net
            Software CM Patterns (www.scmpatterns.com)
            Effective Teamwork, Practical Integration
            "And miles to go before I sleep." -- Robert Frost
          • Mike Beedle
            ... Brad: Ok, I read the article. I think you need better names for the minimal list . I agree with most concepts -- not with all of them, however, more on
            Message 5 of 18 , Oct 27, 2004
            • 0 Attachment
              On Wed, Oct 27, 2004 at 03:53:47PM -0500, Mike Beedle wrote:
              > I will write what we strive in different words to clarify:
              >
              >       We want to deploy *as much as we can* in terms of features.
              >
              > That sounds like "maximal in size" to me but what do you mean by size?

              Brad wrote:
              > What about time? I think you only want "as many features
              > as possible" if you are assuming a specific time-duration
              > between now and the end of the release.
              >
              > Remember, the practices I characterized at:
              >   http://www.cmcrossroads.com/article/34375

              Brad:

              Ok, I read the article. I think you need better names for the "minimal
              list". I agree with most concepts -- not with all of them, however, more on
              this below.

              On the other hand, I like the idea to categorize them in terms of minimums',
              balances', or maximums'.

              Here are a couple of comments.

              (On "Minimal Deployable Releases")
              The article says:

              "Release content is minimized to balance the impact of deployment
              and installation/upgrade against the amount of business value
              delivered."

              However, the article doesn't say anything about time as you indicated above
              -- the "minimizing time" makes sense but the article says "release content
              is minimized...". So perhaps a better name is:

              Minimize the Time but Maximize the Context between Releases

              That leaves much less to be interpreted as to what should be "minimal".

              (on " Minimal Manageable Iterations")
              The article says:
              "Iterations are kept short in order to minimize the opportunity for changes
              to their scope, and rapidly enable customer-feedback on tangible working
              results in the shortest time-span"

              But very short iterations are also a problem -- for once the time of the
              Product Owner, the Customer (or its equivalent) is not as accessible.

              People that ask for shorter iterations seem to ignore these facts:

              Availability and schedules of Customers, Executives and/or other
              resources.

              To say:

              "the VP of Marketing should be here with us in the trenches every
              day
              for the Sprint Planning Meeting on Monday, through the week for
              questions, and with us on Friday for the Sprint Review Meeting"

              is simply not possible for many companies.

              So I am not sure "smaller iterations than 30 days" (or Sprints) are really
              desirable -- from a business perspective, in most business scenarios.

              You are also supposed to do something "meaningful" business-wise, and in
              most shops less than 30 days does not allow you to do that: another little
              fact people that ask for shorter interactions ignore.

              So, I am still with "Balanced Manageable Iteration" -- not minimal.


              (on the "Minimal Meaningful Models" and "Minimal Malleable Design", etc.)
              Mike Beedle wrote:
              > In our case we dont do pictures unless the client wants
              > them and pays for them.

              Brad Appleton wrote:
              >And you want to communicate program/design information
              >in the most effective and efficient means possible.
              >And you do indeed use pictures as part of that
              >programmer-to-programmer communication.

              We don't draw.... seriously. We just code. And we talk about "technical
              things" all the time. Our face-to-face communication is in front of
              computer monitors that display the code -- no need to draw the code.

              Brad Appleton wrote:
              >If you're telling me SCRUMers don't draw any pictures
              >on whiteboards (or paper or napkins) as a commonplace
              >occurrence between programmer-programmer communication,
              >than that contradicts everything else I've ever heard and
              >seen w.r.t. SCRUM.

              I am talking for the rest of the Scrumers -- other Scrumers can and should
              do whatever they feel it is *necessary* to satisfy their customers,
              including "drawing pictures", if necessary.


              (on " Minimal Marketable Features")
              Mike Beedle wrote:
              > I think we do want the most *features* - a maximal numbers
              > of features to go on our web sites, brochures and
              > demonstrations, with the "maximum marketable" potential.

              Brad wrote:
              > I think where agility comes into play is in making
              > the relevant feed-back loops as short as possible
              > while still balancing this desire. And I think
              > it is the short-feedback-loop that is characteristic
              > of agility rather than the desire for maximal # features.
              > I don't think maximal # features is a particularly agile
              > characteristic

              Again the interpretation of the language is ambiguous.

              Now, after reading the article I see what you meant:

              Minimal Marketable Features
              Features are decomposed into the smallest marketable units of useful

              deliverable business value, in order to fit within short iterations
              and ensure critical functionality is implemented first.

              So each of the features is minimal not the bag of "Marketable Features" as
              in:

              Minimal "Marketable Features"

              which frankly doesn't make any sense. So perhaps a better name is:

              Minimal (or the Smallest Possible) Features that
              are still Deployable and Marketable

              Brad Appleton wrote:
              >Okay - that explains a lot. I suggest reading the
              >descriptions before trying to comment further on what
              >those dual-word names mean (there was an earlier post that
              >had the 2-3 line descriptions as well). URL is above

              The names should be good enough to describe what these things are.

              I suggest using less ambiguous language.

              (on "Minimal Mergeable Change")
              The article says:
              "Minimal Mergeable Change-Tasks Changes are checked-in and committed to the
              codeline as atomic transactions representing the smallest-feasible unit of
              working/tested functionality that won’t break the build."

              Ok, now that I get the meaning, I have the same question as below:

              Wouldn't you like to code the largest possible feature that won't
              break the build?

              (on "Minimal Testable Modifications")
              Mike Beedle wrote:
              > I think you meant for "Minimal Testable Modifications"
              >
              >       "small modifications that can be tested".
              >
              > Is that correct?  If so, I am ok with that.

              Brad Appleton wrote:
              > Yes. Again, I think reading the actual descriptions would
              > clear up a lot of the misunderstanding that seem to be
              > taking place here.

              Ok, I get the "meaning" now, but now I have other questions on this.

              Wouldn't you like to code the largest possible feature that is still
              testable and deployable in a short time?

              "Balance" between size and time comes to mind, as well as the atomicity of
              the feature.

              Is it important that the features are small and testable only? or does it
              also make sense that they are deployable? Atomic? Or can they be "maximal
              in size, but deployable and atomic in a minimum window of time"?

              To rephrase:

              maximal features in size, that are deployable and atomic in a
              minimum window of time


              (on "Minimal Perpetual Peer-Review")
              The article says:
              Code is reviewed in very-small increments as soon as feasible after it is
              written (possibly even as it is being written) to minimize error detection
              and rework, and enforce coding standards."

              Ok, I buy into that given that "availability and the ability to modify is
              there" by the group.

              I hope the comments are useful -- you(we) are onto something *very big*,
              that's why I am taking the time to respond:

              The *true* rules of Agile Software Development

              These are the "simple rules" that, through simple interactions, give rise to
              the emergence of "Agile Teams" and their hyperproductivity,

              - Mike
            • Mike Beedle
              I wrote: Minimize the Time but Maximize the Context between Releases But I meant: Minimize the Time but Maximize the Content between Releases mb
              Message 6 of 18 , Oct 27, 2004
              • 0 Attachment

                I wrote:

                      Minimize the Time but Maximize the Context between Releases

                But I meant:

                      Minimize the Time but Maximize the Content between Releases

                 

                mb



                 

              • Brad Appleton
                ... Yes. Thanks Ron! That is pretty close to what I was trying to convey. If one of the biggest differences about agile is having fast+short feedback cycles,
                Message 7 of 18 , Oct 28, 2004
                • 0 Attachment
                  On Wed, Oct 27, 2004 at 05:00:39PM -0400, Ron Jeffries wrote:
                  > I suspect that most people already think their release frequency is
                  > balanced. "Our customers don't really want more than one release a year."
                  >
                  > I believe Brad is suggesting that more frequent releases is the constant
                  > pressure one should feel. I would agree, and would guess that he would,
                  > that we would also like to have as much in each release as possible. It's a
                  > bit hard to imagine anyone not wanting that, but it's easy to imagine (or
                  > find) people who don't know they should want to release more often.

                  Yes. Thanks Ron! That is pretty close to what I was trying to convey.

                  If one of the biggest differences about "agile" is having fast+short
                  feedback cycles, and if faster+shorter is increasingly better, then
                  the question becomes how short can we make it? If agile motivates
                  us to make changes and plans be as small as possible, then how
                  small is too small? What is the lower limit?

                  I suggested the lowerbounds are dictated by things like:
                  deployability, manageability, marketability, meaningfulness,
                  consistency (mergeable/buildable), correctness (testable), etc.
                  --
                  Brad Appleton <brad@...> www.bradapp.net
                  Software CM Patterns (www.scmpatterns.com)
                  Effective Teamwork, Practical Integration
                  "And miles to go before I sleep." -- Robert Frost
                • Marco Abis
                  Brad, ... My lowerbound is customer value. Maybe we write 1000 lines of code but they don t bring value to the customer so the current cycle isn t closed.
                  Message 8 of 18 , Oct 28, 2004
                  • 0 Attachment
                    Brad,

                    >I suggested the lowerbounds are dictated by things like:
                    >deployability, manageability, marketability, meaningfulness,
                    >consistency (mergeable/buildable), correctness (testable), etc.

                    My lowerbound is customer value. Maybe we write 1000 lines of code but they don't bring value to the customer so the current cycle isn't closed. Maybe we write 1 important, valuable line of code and then we can close a cycle and ship it.


                    Marco Abis
                    http://www.agilemovement.it - Italian Agile Movement
                    http://www.agilityspi.com - Agility SPI :: Software Process Improvement
                  • Brad Appleton
                    ... For which of those items? Releases? Iterations? Features? Change-Tasks? ... That would suggest Releases is your answer to my question above. In that case
                    Message 9 of 18 , Oct 28, 2004
                    • 0 Attachment
                      On Thu, Oct 28, 2004 at 05:23:59PM +0200, Marco Abis wrote:
                      > Brad,
                      >
                      > >I suggested the lowerbounds are dictated by things like:
                      > >deployability, manageability, marketability, meaningfulness,
                      > >consistency (mergeable/buildable), correctness (testable), etc.
                      >
                      > My lowerbound is customer value.

                      For which of those items? Releases? Iterations? Features?
                      Change-Tasks?

                      > Maybe we write 1000 lines of code but they don't bring
                      > value to the customer so the current cycle isn't closed.
                      > Maybe we write 1 important, valuable line of code and
                      > then we can close a cycle and ship it.

                      That would suggest "Releases" is your answer to my
                      question above. In that case I'm going to claim that
                      "deployability" trumps your lowerbound:
                      - I think something can still bring-value to the customer
                      and could be shippable, but that if the customer feels
                      its not deployable because of other stuff (that may
                      or may not be related to that feature) then, even tho
                      we might want to ship at that time, if the customer
                      won't accept it, then it can't be the end of a release
                      cycle. (But it could still be the end of an iteration,
                      or a future)

                      - I also think something can bring value to the customer,
                      but that something smaller might still be deployable,
                      and that we should try to cajole the customer into
                      accept the smaller thing first if at all feasible.

                      --
                      Brad Appleton <brad@...> www.bradapp.net
                      Software CM Patterns (www.scmpatterns.com)
                      Effective Teamwork, Practical Integration
                      "And miles to go before I sleep." -- Robert Frost
                    • Michael Spayd
                      I believe my experience is similar, but not exactly the same, as what has been voiced on this topic. I worked with a large number of teams struggling to figure
                      Message 10 of 18 , Oct 28, 2004
                      • 0 Attachment
                        I believe my experience is similar, but not exactly the same, as what
                        has been voiced on this topic.

                        I worked with a large number of teams struggling to figure out how
                        frequent releases could make sense in their world. They were coming
                        from normal waterfall releases, once a year or so.

                        What we collectively discovered was that *deployable* was very
                        different from *deployed*. In other words, a release (ideally this
                        would have be an iteration, but hey, they didn't actually believe in
                        agile) should be deployable, but the customer might decide it maybe
                        was not worth deploying.....because the cost of deployment was
                        relatively high (what with all the end environment testing, costs of
                        training users, etc). This didn't mean the software was not valuable
                        at that point, only that it wasn't valuable ENOUGH to bear the costs
                        of deployment.

                        As far as customer value, that means so many different things as to be
                        semi-worthless in the worlds I have been in. Value for the onsite
                        customer (to borrow an XP-ism is FAR different from the customer Big
                        Boss, especially if that is a VP level person.

                        Hope that is of some use to someone other than me :-)

                        Michael

                        --
                        Michael K. Spayd
                        COGILITY, llc
                        "Business Mind, Social Heart"
                        michael.spayd@...
                        720.300.5286


                        On Thu, 28 Oct 2004 11:21:04 -0500, Brad Appleton <brad@...> wrote:
                        > On Thu, Oct 28, 2004 at 05:23:59PM +0200, Marco Abis wrote:
                        > > Brad,
                        > >
                        > > >I suggested the lowerbounds are dictated by things like:
                        > > >deployability, manageability, marketability, meaningfulness,
                        > > >consistency (mergeable/buildable), correctness (testable), etc.
                        > >
                        > > My lowerbound is customer value.
                        >
                        > For which of those items? Releases? Iterations? Features?
                        > Change-Tasks?
                        >
                        > > Maybe we write 1000 lines of code but they don't bring
                        > > value to the customer so the current cycle isn't closed.
                        > > Maybe we write 1 important, valuable line of code and
                        > > then we can close a cycle and ship it.
                        >
                        > That would suggest "Releases" is your answer to my
                        > question above. In that case I'm going to claim that
                        > "deployability" trumps your lowerbound:
                        > - I think something can still bring-value to the customer
                        > and could be shippable, but that if the customer feels
                        > its not deployable because of other stuff (that may
                        > or may not be related to that feature) then, even tho
                        > we might want to ship at that time, if the customer
                        > won't accept it, then it can't be the end of a release
                        > cycle. (But it could still be the end of an iteration,
                        > or a future)
                        >
                        > - I also think something can bring value to the customer,
                        > but that something smaller might still be deployable,
                        > and that we should try to cajole the customer into
                        > accept the smaller thing first if at all feasible.
                        >
                        > --
                        > Brad Appleton <brad@...> www.bradapp.net
                        > Software CM Patterns (www.scmpatterns.com)
                        > Effective Teamwork, Practical Integration
                        > "And miles to go before I sleep." -- Robert Frost
                        >
                        >
                        >
                        >
                        > To Post a message, send it to: scrumdevelopment@...
                        > To Unsubscribe, send a blank message to:
                        > scrumdevelopment-unsubscribe@...
                        >
                        >
                        >
                        > Yahoo! Groups Sponsor
                        >
                        >
                        > Get unlimited calls to
                        >
                        > U.S./Canada
                        >
                        > ________________________________
                        > 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 the Yahoo! Terms of Service.
                      • Brad Appleton
                        ... Thanks for the lesson learned Michael! My experience has been similar. I think you touch on what I view as the key difference between an iteration and a
                        Message 11 of 18 , Oct 28, 2004
                        • 0 Attachment
                          On Thu, Oct 28, 2004 at 09:32:50PM -0600, Michael Spayd wrote:
                          > What we collectively discovered was that *deployable* was very
                          > different from *deployed*. In other words, a release (ideally this
                          > would have be an iteration, but hey, they didn't actually believe in
                          > agile) should be deployable, but the customer might decide it maybe
                          > was not worth deploying.....because the cost of deployment was
                          > relatively high (what with all the end environment testing, costs of
                          > training users, etc). This didn't mean the software was not valuable
                          > at that point, only that it wasn't valuable ENOUGH to bear the costs
                          > of deployment.

                          Thanks for the lesson learned Michael!

                          My experience has been similar. I think you touch on what
                          I view as the key difference between an iteration and a
                          release. The customer may likely not deploy/install/upgrade
                          the software after each iteration (even tho they will
                          agree to do acceptance testing/evaluation).

                          Otherwise, in the ideal agile view, the customer would
                          deploy each iteration. But since that quite frequently
                          does not happen, we still have to have these things
                          called releases that are distinct from iterations.
                          And the releases are the things the customers say
                          they are inclined to deploy (and even then, they still
                          might not deploy it)

                          For a lot of the stuff I do, we have a sandbox environment
                          where we mimic the configuration of the production environment,
                          but all the data and results are non-production. And the users
                          can "play" in the sandbox to test out new functionality. We
                          update the sandbox at the end of each iteration (at the very least,
                          often more frequently than that).

                          But the customer is NOT willing to have upgrades happen
                          that often because each deployment is not only possible
                          down-time for their systems, but even when it isn't, its
                          still a change in their business process and training. They
                          can't easily be talked into more frequent releases.

                          They were initially wary of taking even two of them a year.
                          Weve managed to talk them into every 2-3 months. Our
                          iterations (when I was on the project anyway) were about 3
                          weeks. Then the next iteration would start while there was
                          a week-long customer-eval period for the previous iteration
                          (so we had some overlap in iterations)

                          Another reason for wanting to decrease the time-interval
                          between releases is that of legacy support. We find that
                          the longer the time period between releases, the more
                          likely the customer is to demand maintenance of the
                          previous release while the current release is in
                          development. And the more likely it is we'll have to
                          do that with a "branch" (yuck) rather than by simply
                          giving them the latest working stuff that has both the
                          fixes, and whatever features were implemented since then.

                          Smaller releases decreases the size and likelihood of our
                          multiple maintenance burden for legacy releases.
                          --
                          Brad Appleton <brad@...> www.bradapp.net
                          Software CM Patterns (www.scmpatterns.com)
                          Effective Teamwork, Practical Integration
                          "And miles to go before I sleep." -- Robert Frost
                        • Ron Jeffries
                          We ve been talking a bit about frequent releases, the notion of deployed vs deployable , the cost of deploying, and so on. I d like to bring out just two
                          Message 12 of 18 , Oct 29, 2004
                          • 0 Attachment
                            We've been talking a bit about frequent releases, the notion of "deployed"
                            vs "deployable", the "cost" of deploying, and so on. I'd like to bring out
                            just two points.

                            The most common reasons given and used for infrequent deployment are
                            evidence of poor software development practice.

                            Infrequent shipment is evidence of poor business practice.

                            Reasons Given for Infrequent Deployment

                            In my experience, and there's been a lot of it, the most common stated
                            reason for deploying infrequently is "the customers don't want it." In my
                            experience, the /real/ reason for deploying infrequently is that when we
                            deployed last time, we nuked the customers with so many defects that they
                            and we are scared to do it again.

                            When we face people with this truth, their most common come-back is "But if
                            we change features, the customers would have to retrain everyone, and we
                            would have to retrain all our support people. There's more to it than just
                            bugs." When we look at the truth of this we find that we can readily change
                            features by adding new items to the menu that people don't have to use, we
                            can build features that walk you through doing whatever the new thing is,
                            and that in fact we don't need to build software that requires retraining
                            every time we release a version.

                            "Yes, but we have to rewrite the manual and reprint it." I answer: "If your
                            developers can refactor and develop real running tested code between now
                            and when the feature is ready, a tech writer can certainly update the
                            documents in the same amount of time." And I can point to teams that do it
                            just that way. No one rewrites the manual every time out: they update it.

                            I can't think of a case I've seen where all the reasons didn't come down to
                            just one: we're afraid that it won't work.

                            Fear of Defects is Evidence of Poor Development Practice

                            If we're afraid of there being defects in the code, that means we don't
                            know whether there are defects or not. Otherwise we would have said "There
                            are exactly 11 defects in the code, and we couldn't possibly ship until
                            they are fixed."

                            Therefore, our development process is producing code of unknown quality.
                            That would be bad. Our code is untested, and uninspected. Otherwise we'd
                            know. But we know, as Agilistas, what to do about that. XP calls the
                            relevant practices Test-Driven Development, Acceptance Tests, Pair
                            Programming. Whatever you call them, they are about knowing rather than
                            fearing what the situation is. They're about rapid feedback.

                            And we know that the best thing to do after discovering a defect right away
                            is to fix it right away rather than build on it.

                            If an organization fears release, it's evidence that they aren't doing the
                            right things, or that the word has not been communicated. If they don't
                            know the defect situation, they should fix their practices so that they do
                            know.

                            Business Impact of Infrequent Deployment

                            Undeployed software is inventory. Inventory is now understood to be waste.
                            When the software is deployed, it starts to bring in value. It might bring
                            in dollars, it might bring in customer satisfaction. Either way, we
                            wouldn't be writing it if it wasn't supposed to bring us value. We don't
                            get the value until we ship it.

                            Bottom Line

                            If we're not shipping our software when it's ready, it's poor business
                            practice.

                            If we're not sure whether our software is ready, it's poor software
                            practice.

                            Ron Jeffries
                            www.XProgramming.com
                            Comments lie. Code doesn't.
                          • mike.dwyer1@comcast.net
                            This is getting to be irritating Ron, but I have to agree with you - yet again! Worse yet, you may have sparked another simple metric for the WIKI. That being
                            Message 13 of 18 , Oct 29, 2004
                            • 0 Attachment
                              This is getting to be irritating Ron, but I have to agree with you - yet again!
                              Worse yet, you may have sparked another simple metric for the WIKI.
                              That being an "Accepted Releases" factor.  as defined by the number of releases deployed in a year times the average customer satisfaction rating of the team over the same period of time. 
                               
                              So if you did 4 releases in a year and they had  customer sat levels of -1, 0, 3, 1 for an average of .75 then your "Accepted Release Factor" is 3.
                               
                              If you did 12 releases in a year with the same sat levels it would be an 8.
                               
                              Correspondingly if your raised your customer sat level average to a 1 then things get better.
                               
                              However if you stay at a zero customer sat level you get a goose egg which represents an average score.
                               
                              The higher the number the better you are doing.
                              (refer to previous post on SCRUM METRICS) 
                              --
                              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 --------------

                              >
                              > We've been talking a bit about frequent releases, the notion of "deployed"
                              > vs "deployable", the "cost" of deploying, and so on. I'd like to bring out
                              > just two points.
                              >
                              > The most common reasons given and used for infrequent deployment are
                              > evidence of poor software development practice.
                              >
                              > Infrequent shipment is evidence of poor business practice.
                              >
                              > Reasons Given for Infrequent Deployment
                              >
                              > In my experience, and there's been a lot of it, the most common stated
                              > reason for deploying infrequently is "the customers don't want it." In my
                              > experience, the /real/ reason for deploying infrequently is that when we
                              > deployed last time, we nuked the customers with so many defects that they
                              > and we are scared to do it again.
                              >
                              > When we face people with this truth, their most common come-back is "But if
                              > we change features, the customers would have to retrain everyone, and we
                              > would have to retrain all our support people. There's more to it than just
                              > bugs." When we look at the truth of this we find that we can readily change
                              > features by adding new items to the menu that people don't have to use, we
                              > can build features that walk you through doing whatever the new thing is,
                              > and that in fact we don't need to build software that requires retraining
                              > every time we release a version.
                              >
                              > "Yes, but we have to rewrite the manual and reprint it." I answer: "If your
                              > developers can refactor and develop real running tested code between now
                              > and when the feature is ready, a tech writer can certainly update the
                              > documents in the same amount of time." And I can point to teams that do it
                              > just that way. No one rewrites the manual every time out: they update it.
                              >
                              > I can't think of a case I've seen where all the reasons didn't come down to
                              > just one: we're afraid that it won't work.
                              >
                              > Fear of Defects is Evidence of Poor Development Practice
                              >
                              > If we're afraid of there being defects in the code, that means we don't
                              > know whether there are defects or not. Otherwise we would have said "There
                              > are exactly 11 defects in the code, and we couldn't possibly ship until
                              > they are fixed."
                              >
                              > Therefore, our development process is producing code of unknown quality.
                              > That would be bad. Our code is untested, and uninspected. Otherwise we'd
                              > know. But we know, as Agilistas, what to do about that. XP calls the
                              > relevant practices Test-Driven Development, Acceptance Tests, Pair
                              > Programming. Whatever you call them, they are about knowing rather than
                              > fearing what the situation is. They're about rapid feedback.
                              >
                              > And we know that the best thing to do after discovering a defect right away
                              > is to fix it right away rather than build on it.
                              >
                              > If an organization fears release, it's evidence that they aren't doing the
                              > right things, or that the word has not been communicated. If they don't
                              > know the defect situation, they should fix their practices so that they do
                              > know.
                              >
                              > Business Impact of Infrequent Deployment
                              >
                              > Undeployed software is inventory. Inventory is now understood to be waste.
                              > When the software is deployed, it starts to bring in value. It might bring
                              > in dollars, it might bring in customer satisfaction. Either way, we
                              > wouldn't be writing it if it wasn't supposed to bring us value. We don't
                              > get the value until we ship it.
                              >
                              > Bottom Line
                              >
                              > If we're not shipping our software when it's ready, it's poor business
                              > practice.
                              >
                              > If we're not sure whether our software is ready, it's poor software
                              > practice.
                              >
                              > Ron Jeffries
                              > www.XProgramming.com
                              > Comments lie. Code doesn't.
                              >
                              >
                              >
                              >
                              > ------------------------ Yahoo! Groups Sponsor --------------------~-->
                              > $9.95 domain names from Yahoo!. Register anything.
                              > http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/9EfwlB/TM
                              > --------------------------------------------------------------------~->
                              >
                              > 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/
                              >
                              >
                              >
                              >
                            • Shimmings, Ian
                              Oops! This was meant for internal consumption so you won t know who James is, but check out his blog anyway: http://jimblogdog.blogspot.com
                              Message 14 of 18 , Oct 29, 2004
                              • 0 Attachment

                                Oops!  This was meant for internal consumption so you won’t know who “James” is, but check out his blog anyway: http://jimblogdog.blogspot.com

                                 

                                Ian

                                 

                                 

                                 


                                From: Shimmings, Ian [mailto:ian.shimmings@...]
                                Sent: 29 October 2004 17:06
                                To: scrumdevelopment@yahoogroups.com
                                Subject: FW: [scrumdevelopment] Frequent Releases

                                 

                                Works well with James’ latest homily – “every line of code has an ROI”.  You don’t start realising that ROI until it is in production.

                                 

                                Ian

                                 


                                From: Shimmings, Ian
                                Sent: 29 October 2004 17:04
                                To: ' scrumdevelopment@yahoogroups.com '
                                Subject: FW: [scrumdevelopment] Frequent Releases

                                 

                                My current hobby-horse!  Release as soon as it is possible.

                                 

                                Ian

                                 


                                From: Ron Jeffries [mailto:ronjeffries@...]
                                Sent: 29 October 2004 12:07
                                To: scrumdevelopment@yahoogroups.com
                                Subject: [scrumdevelopment] Frequent Releases

                                 

                                We've been talking a bit about frequent releases, the notion of "deployed"
                                vs "deployable", the "cost" of deploying, and so on. I'd like to bring out
                                just two points.

                                     The most common reasons given and used for infrequent deployment are
                                     evidence of poor software development practice.

                                     Infrequent shipment is evidence of poor business practice.

                                Reasons Given for Infrequent Deployment

                                In my experience, and there's been a lot of it, the most common stated
                                reason for deploying infrequently is "the customers don't want it." In my
                                experience, the /real/ reason for deploying infrequently is that when we
                                deployed last time, we nuked the customers with so many defects that they
                                and we are scared to do it again.

                                When we face people with this truth, their most common come-back is "But if
                                we change features, the customers would have to retrain everyone, and we
                                would have to retrain all our support people. There's more to it than just
                                bugs." When we look at the truth of this we find that we can readily change
                                features by adding new items to the menu that people don't have to use, we
                                can build features that walk you through doing whatever the new thing is,
                                and that in fact we don't need to build software that requires retraining
                                every time we release a version.

                                "Yes, but we have to rewrite the manual and reprint it." I answer: "If your
                                developers can refactor and develop real running tested code between now
                                and when the feature is ready, a tech writer can certainly update the
                                documents in the same amount of time." And I can point to teams that do it
                                just that way. No one rewrites the manual every time out: they update it.

                                I can't think of a case I've seen where all the reasons didn't come down to
                                just one: we're afraid that it won't work.

                                Fear of Defects is Evidence of Poor Development Practice

                                If we're afraid of there being defects in the code, that means we don't
                                know whether there are defects or not. Otherwise we would have said "There
                                are exactly 11 defects in the code, and we couldn't possibly ship until
                                they are fixed."

                                Therefore, our development process is producing code of unknown quality.
                                That would be bad. Our code is untested, and uninspected. Otherwise we'd
                                know. But we know, as Agilistas, what to do about that. XP calls the
                                relevant practices Test-Driven Development, Acceptance Tests, Pair
                                Programming. Whatever you call them, they are about knowing rather than
                                fearing what the situation is. They're about rapid feedback.

                                And we know that the best thing to do after discovering a defect right away
                                is to fix it right away rather than build on it.

                                If an organization fears release, it's evidence that they aren't doing the
                                right things, or that the word has not been communicated. If they don't
                                know the defect situation, they should fix their practices so that they do
                                know.

                                Business Impact of Infrequent Deployment

                                Undeployed software is inventory. Inventory is now understood to be waste.
                                When the software is deployed, it starts to bring in value. It might bring
                                in dollars, it might bring in customer satisfaction. Either way, we
                                wouldn't be writing it if it wasn't supposed to bring us value. We don't
                                get the value until we ship it.

                                Bottom Line

                                If we're not shipping our software when it's ready, it's poor business
                                practice.

                                If we're not sure whether our software is ready, it's poor software
                                practice.

                                Ron Jeffries
                                www.XProgramming.com
                                Comments lie. Code doesn't.




                                To Post a message, send it to:   scrumdevelopment@...
                                To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...



                                _____________________________________________________________________
                                This e-mail has been scanned for viruses by MessageLabs. The information contained in this message is confidential and is intended for the addressee only. If you have received this message in error, please notify Conchango plc as soon as possible. The unauthorised use, disclosure, copying or alteration of this message is prohibited and may be unlawful. The internet cannot guarantee the integrity of this message and therefore Conchango plc will not be liable for the message if modified.

                                Reg. Heritage House, Church Road , Egham, Surrey , TW20 9QD T 44 (0) 1784 222 222 F 44 (0) 1784 222 200 E talktous@... No. 2598884


                                To Post a message, send it to:   scrumdevelopment@...
                                To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...




                                 

                                Yahoo! Groups Links

                                 


                                _____________________________________________________________________
                                This e-mail has been scanned for viruses by MessageLabs. The information contained in this message is confidential and is intended for the addressee only. If you have received this message in error, please notify Conchango plc as soon as possible. The unauthorised use, disclosure, copying or alteration of this message is prohibited and may be unlawful. The internet cannot guarantee the integrity of this message and therefore Conchango plc will not be liable for the message if modified.

                                Reg. Heritage House, Church Road, Egham, Surrey, TW20 9QD T 44 (0) 1784 222 222 F 44 (0) 1784 222 200 E talktous@... No. 2598884
                              • Ron Jeffries
                                ... What s odd is that many people find a way to be irritated without agreeing. ... Ron Jeffries www.XProgramming.com If you re not throwing some gravel once
                                Message 15 of 18 , Oct 29, 2004
                                • 0 Attachment
                                  On Friday, October 29, 2004, at 11:25:33 AM, mike.dwyer1@... wrote:

                                  > This is getting to be irritating Ron, but I have to agree with you - yet again!

                                  What's odd is that many people find a way to be irritated without agreeing.
                                  :)

                                  Ron Jeffries
                                  www.XProgramming.com
                                  If you're not throwing some gravel once in a while,
                                  you're not using the whole road.
                                • Michael Spayd
                                  I d say what is irritating is people who find a way to be disagreeable without at least being interesting (let alone useful). :-) Michael On Fri, 29 Oct 2004
                                  Message 16 of 18 , Oct 29, 2004
                                  • 0 Attachment
                                    I'd say what is irritating is people who find a way to be disagreeable
                                    without at least being interesting (let alone useful). :-)

                                    Michael


                                    On Fri, 29 Oct 2004 14:53:17 -0400, Ron Jeffries
                                    <ronjeffries@...> wrote:
                                    > On Friday, October 29, 2004, at 11:25:33 AM, mike.dwyer1@... wrote:
                                    >
                                    > > This is getting to be irritating Ron, but I have to agree with you - yet
                                    > again!
                                    >
                                    > What's odd is that many people find a way to be irritated without agreeing.
                                    > :)
                                    >
                                    > Ron Jeffries
                                    > www.XProgramming.com
                                    > If you're not throwing some gravel once in a while,
                                    > you're not using the whole road.
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    > To Post a message, send it to: scrumdevelopment@...
                                    > To Unsubscribe, send a blank message to:
                                    > scrumdevelopment-unsubscribe@...
                                    >
                                    >
                                    >
                                    > Yahoo! Groups Sponsor
                                    >
                                    > ADVERTISEMENT
                                    >
                                    >
                                    > ________________________________
                                    > 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 the Yahoo! Terms of Service.


                                    --
                                    Michael K. Spayd
                                    COGILITY, llc
                                    "Business Mind, Social Heart"
                                    michael.spayd@...
                                    720.300.5286
                                  • Boris Gloger
                                    ... On Fri, 29 Oct 2004 20:51:35 -0600, Michael Spayd ... Questions is: What makes them not agreeing? - maybe agreeing needs an emotinal basis?
                                    Message 17 of 18 , Oct 30, 2004
                                    • 0 Attachment
                                      > On Fri, 29 Oct 2004 14:53:17 -0400, Ron Jeffries
                                      > <ronjeffries@...> wrote:
                                      > > On Friday, October 29, 2004, at 11:25:33 AM, mike.dwyer1@... wrote:
                                      > >
                                      > > > This is getting to be irritating Ron, but I have to agree with you - yet
                                      > > again!
                                      > >
                                      > > What's odd is that many people find a way to be irritated without agreeing.
                                      > > :)

                                      On Fri, 29 Oct 2004 20:51:35 -0600, Michael Spayd
                                      <michael.spayd@...> wrote:
                                      >
                                      > I'd say what is irritating is people who find a way to be disagreeable
                                      > without at least being interesting (let alone useful). :-)
                                      >

                                      Questions is: "What makes them not agreeing?" - maybe agreeing needs
                                      an emotinal basis?
                                    • Brad Appleton
                                      ... I think we might subdivide that into (1) fear of our stuff (the software/product) and also (2) fear of themselves (their own organizational dysfunctions
                                      Message 18 of 18 , Nov 1, 2004
                                      • 0 Attachment
                                        On Fri, Oct 29, 2004 at 07:07:01AM -0400, Ron Jeffries wrote:
                                        > Reasons Given for Infrequent Deployment
                                        >
                                        > In my experience, and there's been a lot of it, the most common stated
                                        > reason for deploying infrequently is "the customers don't want it." In my
                                        > experience, the /real/ reason for deploying infrequently is that when we
                                        > deployed last time, we nuked the customers with so many defects that they
                                        > and we are scared to do it again.

                                        I think we might subdivide that into
                                        (1) fear of our stuff (the software/product)
                                        and also
                                        (2) fear of themselves (their own organizational dysfunctions regarding
                                        any stuff they are responsible for doing on their side (e.g, training, communication, coordination) before the deploy the upgrade within their organization)

                                        Also ... everywhere you wrote "fear" or "scared" in your
                                        post, I wonder if I replace the word with "distrust" if
                                        it is still a valid statement. If so, it makes me think
                                        of the "Customer collaboration over contract negotiation"
                                        part of the agile manifesto ...

                                        So maybe it should be less about "negotiating" more frequent
                                        releases with the customer, but should instead be more about
                                        collaborating with them?

                                        --
                                        Brad Appleton <brad@...> www.bradapp.net
                                        Software CM Patterns (www.scmpatterns.com)
                                        Effective Teamwork, Practical Integration
                                        "And miles to go before I sleep." -- Robert Frost
                                      Your message has been successfully submitted and would be delivered to recipients shortly.