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

The lifecycle of memes (and relevance to RO)

Expand Messages
  • Julian Everett
    Hi all, The meme lifecycle that Chris mentioned is an idea cycle that follows a basic on/off switching pattern: 1.) Uncertainty: resulting from an unsolved
    Message 1 of 26 , Jun 15, 2009
    View Source
    • 0 Attachment
      The lifecycle of memes (and relevance to RO)

      Hi all,

      The meme lifecycle that Chris mentioned is an idea cycle that follows a basic on/off switching pattern:

      1.)     Uncertainty: resulting from an unsolved problem or a phenomenon that does not fit within our current worldview

      2.)     (bio)diversity: a range of new ideas are then considered as possible solutions or ways of integrating the new experience into our worldview

      3.)     Dominant Meme: one particular idea is adopted as the “best” explanation/solution, and becomes embedded into the updated worldview

      4.)     Zombie Meme: social or business context changes, making the previously dominant meme no longer relevant. It is now dead and needs be laid to rest before it starts causing havoc

      5.)     Lazarus Meme: a dead idea that is brought back to life, because changes to a social or business context suddenly make it relevant again.

      Within the context of business, memes can be seen as the idea-pool DNA of an organisation that get expressed as an “extended phenotype” or sliding scale of effects: from commercial strategy to budgets, marketing, IT projects, etc. If we consider the subset of memes that constitute well-factored MMFs, then real options are the mechanism for determining what organisational memes should be expressed and when (via the optimal exercise point), and equally importantly which memes need to be culled (via negative valuation). Zombies are the things that cause the real damage: financially we are at present arguably living through the fall-out from a economic zombie meme – the efficient market hypothesis (which resulted in deregulation of capital markets, etc). Closer to home, some of the worst problems I have seen caused by technology programmes has resulted from “zombie projects”, where there has been a resistance to terminate despite clearly changed business conditions and commercials that no longer add up…

      Evolutionary theory changed the focus of biological thinking from organisms to genes. In the same way, an evolutionary perspective to software delivery emphasises the need to stop focussing on IT projects and instead think solely in terms of MMFs. Then organisations with high resource liquidity become business value hunter/gatherer cultures, where teams are continually redeployed to whichever part of the company currently has the highest value MMFs to be implemented.

      In other words, evolutionary theory suggests that the whole notion of doing IT projects is a zombie meme. And if we get rid of IT projects then out goes XP Customer as another zombie. Why is someone in marketing or sales any more of a customer than someone in IT? Customers are the people who work for other organisations, not ours. Without IT projects then colleagues from different parts of our company just become part of one cross-discipline MMF implementation team. And without IT projects then we can move towards a much healthier world of company-wide shared ownership of MMFs, which removes any political stigma of culling business cases that are no longer justifiable

      cheers

      Julian


      Picture (Device Independent Bitmap)

      Julian Everett      |     Technical Architect, Digital Media 

      BBC Worldwide
      MC2B1, Media Centre, 201 Wood Lane, London, W12 7TQ
      T: +44 (0)20 8433 2787

             

             

      This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
       
      Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this

      This e-mail has been sent by one of the following wholly-owned subsidiaries of the BBC:
       
      BBC Worldwide Limited, Registration Number: 1420028 England, Registered Address: BBC Media Centre, 201 Wood Lane, London, W12 7TQ
      BBC World News Limited, Registration Number: 04514407 England, Registered Address: BBC Media Centre, 201 Wood Lane, London, W12 7TQ
      BBC World Distribution Limited, Registration Number: 04514408, Registered Address: BBC Media Centre, 201 Wood Lane, London, W12 7TQ

       
       
    • chrismatts1968
      Julian Brilliant. When will you be posting the slides? Thank you for posting. One request. Can we use ROI Component instead of MMF? Chris
      Message 2 of 26 , Jun 15, 2009
      View Source
      • 0 Attachment
        Julian

        Brilliant. When will you be posting the slides?

        Thank you for posting. One request. Can we use "ROI Component" instead of MMF?

        Chris

        --- In real_options_discussion@yahoogroups.com, "Julian Everett" <julian.everett@...> wrote:
        >
        > Hi all,
        >
        > The meme lifecycle that Chris mentioned is an idea cycle that follows a
        > basic on/off switching pattern:
        >
        > 1.) Uncertainty: resulting from an unsolved problem or a phenomenon
        > that does not fit within our current worldview
        > 2.) (bio)diversity: a range of new ideas are then considered as
        > possible solutions or ways of integrating the new experience into our
        > worldview
        > 3.) Dominant Meme: one particular idea is adopted as the "best"
        > explanation/solution, and becomes embedded into the updated worldview
        > 4.) Zombie Meme: social or business context changes, making the
        > previously dominant meme no longer relevant. It is now "dead" and needs
        > be laid to rest before it starts causing havoc
        > 5.) Lazarus Meme: a dead idea that is brought back to life, because
        > changes to a social or business context suddenly make it relevant again.
        >
        > Within the context of business, memes can be seen as the idea-pool DNA
        > of an organisation that get expressed as an "extended phenotype" or
        > sliding scale of effects: from commercial strategy to budgets,
        > marketing, IT projects, etc. If we consider the subset of memes that
        > constitute well-factored MMFs, then real options are the mechanism for
        > determining what organisational memes should be expressed and when (via
        > the optimal exercise point), and equally importantly which memes need to
        > be culled (via negative valuation). Zombies are the things that cause
        > the real damage: financially we are at present arguably living through
        > the fall-out from a economic zombie meme - the efficient market
        > hypothesis (which resulted in deregulation of capital markets, etc).
        > Closer to home, some of the worst problems I have seen caused by
        > technology programmes has resulted from "zombie projects", where there
        > has been a resistance to terminate despite clearly changed business
        > conditions and commercials that no longer add up...
        >
        > Evolutionary theory changed the focus of biological thinking from
        > organisms to genes. In the same way, an evolutionary perspective to
        > software delivery emphasises the need to stop focussing on IT projects
        > and instead think solely in terms of MMFs. Then organisations with high
        > resource liquidity become business value hunter/gatherer cultures, where
        > teams are continually redeployed to whichever part of the company
        > currently has the highest value MMFs to be implemented.
        >
        > In other words, evolutionary theory suggests that the whole notion of
        > doing "IT projects" is a zombie meme. And if we get rid of IT projects
        > then out goes "XP Customer" as another zombie. Why is someone in
        > marketing or sales any more of a customer than someone in IT? Customers
        > are the people who work for other organisations, not ours. Without IT
        > projects then colleagues from different parts of our company just become
        > part of one cross-discipline MMF implementation team. And without IT
        > projects then we can move towards a much healthier world of company-wide
        > shared ownership of MMFs, which removes any political stigma of culling
        > business cases that are no longer justifiable...
        >
        > cheers
        >
        > Julian
        >
        >
        >
        >
        > <<Picture (Device Independent Bitmap)>>
        > Julian Everett | Technical Architect, Digital Media
        >
        > BBC Worldwide
        > MC2B1, Media Centre, 201 Wood Lane, London, W12 7TQ
        > T: +44 (0)20 8433 2787
        > This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
        >
        > Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this
        >
        > This e-mail has been sent by one of the following wholly-owned subsidiaries of the BBC:
        >
        > BBC Worldwide Limited, Registration Number: 1420028 England, Registered Address: BBC Media Centre, 201 Wood Lane, London, W12 7TQ
        > BBC World News Limited, Registration Number: 04514407 England, Registered Address: BBC Media Centre, 201 Wood Lane, London, W12 7TQ
        > BBC World Distribution Limited, Registration Number: 04514408, Registered Address: BBC Media Centre, 201 Wood Lane, London, W12 7TQ
        >
      • chrismatts1968
        Julian It might be worth explaining an extended phenotype and fitness landscape . Chris
        Message 3 of 26 , Jun 15, 2009
        View Source
        • 0 Attachment
          Julian

          It might be worth explaining an "extended phenotype" and "fitness landscape".

          Chris

          --- In real_options_discussion@yahoogroups.com, "Julian Everett" <julian.everett@...> wrote:
          >
          > Hi all,
          >
          > The meme lifecycle that Chris mentioned is an idea cycle that follows a
          > basic on/off switching pattern:
          >
          > 1.) Uncertainty: resulting from an unsolved problem or a phenomenon
          > that does not fit within our current worldview
          > 2.) (bio)diversity: a range of new ideas are then considered as
          > possible solutions or ways of integrating the new experience into our
          > worldview
          > 3.) Dominant Meme: one particular idea is adopted as the "best"
          > explanation/solution, and becomes embedded into the updated worldview
          > 4.) Zombie Meme: social or business context changes, making the
          > previously dominant meme no longer relevant. It is now "dead" and needs
          > be laid to rest before it starts causing havoc
          > 5.) Lazarus Meme: a dead idea that is brought back to life, because
          > changes to a social or business context suddenly make it relevant again.
          >
          > Within the context of business, memes can be seen as the idea-pool DNA
          > of an organisation that get expressed as an "extended phenotype" or
          > sliding scale of effects: from commercial strategy to budgets,
          > marketing, IT projects, etc. If we consider the subset of memes that
          > constitute well-factored MMFs, then real options are the mechanism for
          > determining what organisational memes should be expressed and when (via
          > the optimal exercise point), and equally importantly which memes need to
          > be culled (via negative valuation). Zombies are the things that cause
          > the real damage: financially we are at present arguably living through
          > the fall-out from a economic zombie meme - the efficient market
          > hypothesis (which resulted in deregulation of capital markets, etc).
          > Closer to home, some of the worst problems I have seen caused by
          > technology programmes has resulted from "zombie projects", where there
          > has been a resistance to terminate despite clearly changed business
          > conditions and commercials that no longer add up...
          >
          > Evolutionary theory changed the focus of biological thinking from
          > organisms to genes. In the same way, an evolutionary perspective to
          > software delivery emphasises the need to stop focussing on IT projects
          > and instead think solely in terms of MMFs. Then organisations with high
          > resource liquidity become business value hunter/gatherer cultures, where
          > teams are continually redeployed to whichever part of the company
          > currently has the highest value MMFs to be implemented.
          >
          > In other words, evolutionary theory suggests that the whole notion of
          > doing "IT projects" is a zombie meme. And if we get rid of IT projects
          > then out goes "XP Customer" as another zombie. Why is someone in
          > marketing or sales any more of a customer than someone in IT? Customers
          > are the people who work for other organisations, not ours. Without IT
          > projects then colleagues from different parts of our company just become
          > part of one cross-discipline MMF implementation team. And without IT
          > projects then we can move towards a much healthier world of company-wide
          > shared ownership of MMFs, which removes any political stigma of culling
          > business cases that are no longer justifiable...
          >
          > cheers
          >
          > Julian
          >
          >
          >
          >
          > <<Picture (Device Independent Bitmap)>>
          > Julian Everett | Technical Architect, Digital Media
          >
          > BBC Worldwide
          > MC2B1, Media Centre, 201 Wood Lane, London, W12 7TQ
          > T: +44 (0)20 8433 2787
          > This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
          >
          > Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this
          >
          > This e-mail has been sent by one of the following wholly-owned subsidiaries of the BBC:
          >
          > BBC Worldwide Limited, Registration Number: 1420028 England, Registered Address: BBC Media Centre, 201 Wood Lane, London, W12 7TQ
          > BBC World News Limited, Registration Number: 04514407 England, Registered Address: BBC Media Centre, 201 Wood Lane, London, W12 7TQ
          > BBC World Distribution Limited, Registration Number: 04514408, Registered Address: BBC Media Centre, 201 Wood Lane, London, W12 7TQ
          >
        • Kevlin Henney
          ... Hmm, this would seem a step in the wrong direction. Take a term that is used and often misunderstood with one that is not really used but would cause even
          Message 4 of 26 , Jun 15, 2009
          View Source
          • 0 Attachment
            2009/6/15 chrismatts1968 <chris.matts@...>:
            >
            > One request. Can we use "ROI Component" instead of MMF?

            Hmm, this would seem a step in the wrong direction. Take a term that
            is used and often misunderstood with one that is not really used but
            would cause even greater problems of comprehension.

            Just to be clear, as we are talking about software development, the
            term component has a number of meanings, where most of the dominant
            ones refer to an architectural component. To take a term widely used
            in one context to mean one thing and use it to mean another is perhaps
            not the best idea.

            Kevlin
          • chrismatts1968
            Kevlin You are spot on. I would like us to find a term that does not have all the baggage of software by numbers associated with it. This is particularly
            Message 5 of 26 , Jun 15, 2009
            View Source
            • 0 Attachment
              Kevlin

              You are spot on.

              I would like us to find a term that does not have all the baggage of "software by numbers" associated with it. This is particularly important on this real option group as the heuristic used in "software by numbers" is contrary to real option theory. I do not want to confuse people by discussing ideas on the group and then "recommending" a book that contains contrarian ideas.

              More than happy to accept any reasonable suggestion.

              I would like to blame my suggestion on the headache I currently have which prevented me from remember this discussion on the kanbandev group.

              Thank you Kevlin.

              Chris



              --- In real_options_discussion@yahoogroups.com, Kevlin Henney <kevlin.henney@...> wrote:
              >
              > 2009/6/15 chrismatts1968 <chris.matts@...>:
              > >
              > > One request. Can we use "ROI Component" instead of MMF?
              >
              > Hmm, this would seem a step in the wrong direction. Take a term that
              > is used and often misunderstood with one that is not really used but
              > would cause even greater problems of comprehension.
              >
              > Just to be clear, as we are talking about software development, the
              > term component has a number of meanings, where most of the dominant
              > ones refer to an architectural component. To take a term widely used
              > in one context to mean one thing and use it to mean another is perhaps
              > not the best idea.
              >
              > Kevlin
              >
            • njjreid
              Hey Chris, I ve seen you make this request this before. Can point me in the direction of your reasoning? Thanks so much, -Jason
              Message 6 of 26 , Jun 15, 2009
              View Source
              • 0 Attachment
                Hey Chris,

                I've seen you make this request this before. Can point me in the direction of your reasoning?

                Thanks so much,

                -Jason

                --- In real_options_discussion@yahoogroups.com, "chrismatts1968" <chris.matts@...> wrote:
                >
                > Julian
                >
                > Brilliant. When will you be posting the slides?
                >
                > Thank you for posting. One request. Can we use "ROI Component" instead of MMF?
                >
                > Chris
                >
                > --- In real_options_discussion@yahoogroups.com, "Julian Everett" <julian.everett@> wrote:
                > >
                > > Hi all,
                > >
                > > The meme lifecycle that Chris mentioned is an idea cycle that follows a
                > > basic on/off switching pattern:
                > >
                > > 1.) Uncertainty: resulting from an unsolved problem or a phenomenon
                > > that does not fit within our current worldview
                > > 2.) (bio)diversity: a range of new ideas are then considered as
                > > possible solutions or ways of integrating the new experience into our
                > > worldview
                > > 3.) Dominant Meme: one particular idea is adopted as the "best"
                > > explanation/solution, and becomes embedded into the updated worldview
                > > 4.) Zombie Meme: social or business context changes, making the
                > > previously dominant meme no longer relevant. It is now "dead" and needs
                > > be laid to rest before it starts causing havoc
                > > 5.) Lazarus Meme: a dead idea that is brought back to life, because
                > > changes to a social or business context suddenly make it relevant again.
                > >
                > > Within the context of business, memes can be seen as the idea-pool DNA
                > > of an organisation that get expressed as an "extended phenotype" or
                > > sliding scale of effects: from commercial strategy to budgets,
                > > marketing, IT projects, etc. If we consider the subset of memes that
                > > constitute well-factored MMFs, then real options are the mechanism for
                > > determining what organisational memes should be expressed and when (via
                > > the optimal exercise point), and equally importantly which memes need to
                > > be culled (via negative valuation). Zombies are the things that cause
                > > the real damage: financially we are at present arguably living through
                > > the fall-out from a economic zombie meme - the efficient market
                > > hypothesis (which resulted in deregulation of capital markets, etc).
                > > Closer to home, some of the worst problems I have seen caused by
                > > technology programmes has resulted from "zombie projects", where there
                > > has been a resistance to terminate despite clearly changed business
                > > conditions and commercials that no longer add up...
                > >
                > > Evolutionary theory changed the focus of biological thinking from
                > > organisms to genes. In the same way, an evolutionary perspective to
                > > software delivery emphasises the need to stop focussing on IT projects
                > > and instead think solely in terms of MMFs. Then organisations with high
                > > resource liquidity become business value hunter/gatherer cultures, where
                > > teams are continually redeployed to whichever part of the company
                > > currently has the highest value MMFs to be implemented.
                > >
                > > In other words, evolutionary theory suggests that the whole notion of
                > > doing "IT projects" is a zombie meme. And if we get rid of IT projects
                > > then out goes "XP Customer" as another zombie. Why is someone in
                > > marketing or sales any more of a customer than someone in IT? Customers
                > > are the people who work for other organisations, not ours. Without IT
                > > projects then colleagues from different parts of our company just become
                > > part of one cross-discipline MMF implementation team. And without IT
                > > projects then we can move towards a much healthier world of company-wide
                > > shared ownership of MMFs, which removes any political stigma of culling
                > > business cases that are no longer justifiable...
                > >
                > > cheers
                > >
                > > Julian
                > >
                > >
                > >
                > >
                > > <<Picture (Device Independent Bitmap)>>
                > > Julian Everett | Technical Architect, Digital Media
                > >
                > > BBC Worldwide
                > > MC2B1, Media Centre, 201 Wood Lane, London, W12 7TQ
                > > T: +44 (0)20 8433 2787
                > > This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
                > >
                > > Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this
                > >
                > > This e-mail has been sent by one of the following wholly-owned subsidiaries of the BBC:
                > >
                > > BBC Worldwide Limited, Registration Number: 1420028 England, Registered Address: BBC Media Centre, 201 Wood Lane, London, W12 7TQ
                > > BBC World News Limited, Registration Number: 04514407 England, Registered Address: BBC Media Centre, 201 Wood Lane, London, W12 7TQ
                > > BBC World Distribution Limited, Registration Number: 04514408, Registered Address: BBC Media Centre, 201 Wood Lane, London, W12 7TQ
                > >
                >
              • Kevlin Henney
                ... Let s get at this another way: what is that you are trying to characterise? Some potentially releasable increment, produced by a team and understandable by
                Message 7 of 26 , Jun 15, 2009
                View Source
                • 0 Attachment
                  2009/6/15 chrismatts1968 <chris.matts@...>:
                  >
                  > You are spot on.
                  >
                  > I would like us to find a term that does not have all the baggage of
                  > "software by numbers" associated with it. This is particularly important on
                  > this real option group as the heuristic used in "software by numbers" is
                  > contrary to real option theory. I do not want to confuse people by
                  > discussing ideas on the group and then "recommending" a book that contains
                  > contrarian ideas.
                  >
                  > More than happy to accept any reasonable suggestion.

                  Let's get at this another way: what is that you are trying to
                  characterise? Some potentially releasable increment, produced by a
                  team and understandable by customer/PO/accountant/...? When talking
                  about such things, and wishing to remain in neutral (i.e., not talking
                  FDD features, some variant of use cases, some flavour of user stories,
                  etc.), I am inclined to use just plain "increment" or "functionally
                  complete slice", but I think "releasable increment" also works in that
                  place.

                  > I would like to blame my suggestion on the headache I currently have which
                  > prevented me from remember this discussion on the kanbandev group.

                  Too much / not enough alcohol/caffeine/...? Hope it clears!

                  Kevlin
                • chrismatts1968
                  ... I like this way of approaching the issue. First off, I think you are spot on once again to say that this has to be neutral and without baggage. Longer
                  Message 8 of 26 , Jun 15, 2009
                  View Source
                  • 0 Attachment
                    --- In real_options_discussion@yahoogroups.com, Kevlin Henney <kevlin.henney@...> wrote:
                    > Let's get at this another way: what is that you are trying to
                    > characterise? Some potentially releasable increment, produced by a
                    > team and understandable by customer/PO/accountant/...? When talking
                    > about such things, and wishing to remain in neutral (i.e., not talking
                    > FDD features, some variant of use cases, some flavour of user stories,
                    > etc.), I am inclined to use just plain "increment" or "functionally
                    > complete slice", but I think "releasable increment" also works in that
                    > place.
                    >

                    I like this way of approaching the issue. First off, I think you are spot on once again to say that this has to be neutral and without baggage. Longer term, when we know what we are describing, we may appropriate a more established name.

                    What I am referring to is a "unit of business value". In order to release that business value, we may need to release minimum set of features. These features may be delivered in more than one release in order to mitigate delivery risk.

                    The key thing about it is that it is about business value rather than releases, features or developer tasks. The "unit of business value" initially says nothing about implementation as that may change by the time it comes to implement it. The "unit of business value" may be huge ( mega man year like stick a man on the moon and bring him back alive ) or teeny weeny like a single character bug fix. Realistically, somewhere in between. ;-)

                    >
                    > Too much / not enough alcohol/caffeine/...? Hope it clears!
                    >

                    On a detox. My body wasn't designed to be sober, or to get good food. :-(

                    Chris
                  • Julian Everett
                    Sure Chris. 1.) The phenotype of a meme is basically the set of material effects of an idea on our world. For example a legal statute meme (e.g. the Poll Tax)
                    Message 9 of 26 , Jun 15, 2009
                    View Source
                    • 0 Attachment
                      Sure Chris.

                      1.) The phenotype of a meme is basically the set of material effects of
                      an idea on our world. For example a legal statute meme (e.g. the Poll
                      Tax) might have a phenotype includes parliamentary special commission
                      groups, the police force, criminal justice system, protest
                      organisations, etc

                      2.) A fitness landscape is a map of the environment through which a meme
                      spreads or dies out, where the topography of the map describes the
                      factors that influence survival. A common example is company bonus
                      structures. Done right, bonuses are one way to manipulate the fitness
                      landscape of an organisation to ensure the survival of the behavioural
                      memes that are most advantageous to the interests of the organisation as
                      a whole.

                      Equally fitness landscapes are very useful tools for understanding _why_
                      a meme gained traction and spread through an environment. Let's take the
                      example of XP Customer again. I would (contentiously) suggest a
                      significant reason that meme spread through the software industry
                      environment was because the majority of people who formulated XP were
                      consultants of some sort, i.e. XP Customers were also their customers in
                      a real, financial sense. In other words, the economic reality of the
                      fitness landscape favoured a definition of customer informed by "project
                      success", but where that success was the _consultant's_ rather than the
                      client's. And as an IT consultant what's the best way of ensuring you
                      get paid? The old meme was "on-time, on-budget" used as a standard
                      charging vehicle, but that then got superceded by the even fitter notion
                      of the happy, "omniscient" XP Customer. Completely understandably,
                      because as a consultant you wouldn't want a financial dependency on a
                      client's possibly unsound wider commercial strategy (hence the
                      difficulties with agile contract definition). However from a client
                      perspective, stakeholder satisfaction is largely irrelevant in the big
                      picture - it is all about commercial strategy and delivering long term
                      ROI.




                      -----Original Message-----
                      From: real_options_discussion@yahoogroups.com
                      [mailto:real_options_discussion@yahoogroups.com] On Behalf Of
                      chrismatts1968
                      Sent: 15 June 2009 17:09
                      To: real_options_discussion@yahoogroups.com
                      Subject: [real_options_discussion] Re: The lifecycle of memes (and
                      relevance to RO)

                      Julian

                      It might be worth explaining an "extended phenotype" and "fitness
                      landscape".

                      Chris

                      --- In real_options_discussion@yahoogroups.com, "Julian Everett"
                      <julian.everett@...> wrote:
                      >
                      > Hi all,
                      >
                      > The meme lifecycle that Chris mentioned is an idea cycle that follows
                      a
                      > basic on/off switching pattern:
                      >
                      > 1.) Uncertainty: resulting from an unsolved problem or a phenomenon
                      > that does not fit within our current worldview
                      > 2.) (bio)diversity: a range of new ideas are then considered as
                      > possible solutions or ways of integrating the new experience into our
                      > worldview
                      > 3.) Dominant Meme: one particular idea is adopted as the "best"
                      > explanation/solution, and becomes embedded into the updated worldview
                      > 4.) Zombie Meme: social or business context changes, making the
                      > previously dominant meme no longer relevant. It is now "dead" and
                      needs
                      > be laid to rest before it starts causing havoc
                      > 5.) Lazarus Meme: a dead idea that is brought back to life, because
                      > changes to a social or business context suddenly make it relevant
                      again.
                      >
                      > Within the context of business, memes can be seen as the idea-pool DNA
                      > of an organisation that get expressed as an "extended phenotype" or
                      > sliding scale of effects: from commercial strategy to budgets,
                      > marketing, IT projects, etc. If we consider the subset of memes that
                      > constitute well-factored MMFs, then real options are the mechanism for
                      > determining what organisational memes should be expressed and when
                      (via
                      > the optimal exercise point), and equally importantly which memes need
                      to
                      > be culled (via negative valuation). Zombies are the things that cause
                      > the real damage: financially we are at present arguably living through
                      > the fall-out from a economic zombie meme - the efficient market
                      > hypothesis (which resulted in deregulation of capital markets, etc).
                      > Closer to home, some of the worst problems I have seen caused by
                      > technology programmes has resulted from "zombie projects", where there
                      > has been a resistance to terminate despite clearly changed business
                      > conditions and commercials that no longer add up...
                      >
                      > Evolutionary theory changed the focus of biological thinking from
                      > organisms to genes. In the same way, an evolutionary perspective to
                      > software delivery emphasises the need to stop focussing on IT projects
                      > and instead think solely in terms of MMFs. Then organisations with
                      high
                      > resource liquidity become business value hunter/gatherer cultures,
                      where
                      > teams are continually redeployed to whichever part of the company
                      > currently has the highest value MMFs to be implemented.
                      >
                      > In other words, evolutionary theory suggests that the whole notion of
                      > doing "IT projects" is a zombie meme. And if we get rid of IT projects
                      > then out goes "XP Customer" as another zombie. Why is someone in
                      > marketing or sales any more of a customer than someone in IT?
                      Customers
                      > are the people who work for other organisations, not ours. Without IT
                      > projects then colleagues from different parts of our company just
                      become
                      > part of one cross-discipline MMF implementation team. And without IT
                      > projects then we can move towards a much healthier world of
                      company-wide
                      > shared ownership of MMFs, which removes any political stigma of
                      culling
                      > business cases that are no longer justifiable...
                      >
                      > cheers
                      >
                      > Julian
                      >
                      >
                      >
                      >
                      > <<Picture (Device Independent Bitmap)>>
                      > Julian Everett | Technical Architect, Digital Media
                      >
                      > BBC Worldwide
                      > MC2B1, Media Centre, 201 Wood Lane, London, W12 7TQ
                      > T: +44 (0)20 8433 2787
                      > This e-mail (and any attachments) is confidential and may contain
                      personal views which are not the views of the BBC unless specifically
                      stated. If you have received it in error, please delete it from your
                      system. Do not use, copy or disclose the information in any way nor act
                      in reliance on it and notify the sender immediately.
                      >
                      > Please note that the BBC monitors e-mails sent or received. Further
                      communication will signify your consent to this
                      >
                      > This e-mail has been sent by one of the following wholly-owned
                      subsidiaries of the BBC:
                      >
                      > BBC Worldwide Limited, Registration Number: 1420028 England,
                      Registered Address: BBC Media Centre, 201 Wood Lane, London, W12 7TQ
                      > BBC World News Limited, Registration Number: 04514407 England,
                      Registered Address: BBC Media Centre, 201 Wood Lane, London, W12 7TQ
                      > BBC World Distribution Limited, Registration Number: 04514408,
                      Registered Address: BBC Media Centre, 201 Wood Lane, London, W12 7TQ
                      >




                      ------------------------------------

                      Yahoo! Groups Links
                    • David Peterson
                      I think what you re describing is what Tom Gilb refers to as a Design Idea . David 2009/6/15 chrismatts1968
                      Message 10 of 26 , Jun 15, 2009
                      View Source
                      • 0 Attachment
                        I think what you're describing is what Tom Gilb refers to as a "Design Idea".

                        David


                        2009/6/15 chrismatts1968 <chris.matts@...>


                        --- In real_options_discussion@yahoogroups.com, Kevlin Henney <kevlin.henney@...> wrote:
                        > Let's get at this another way: what is that you are trying to
                        > characterise? Some potentially releasable increment, produced by a
                        > team and understandable by customer/PO/accountant/...? When talking
                        > about such things, and wishing to remain in neutral (i.e., not talking
                        > FDD features, some variant of use cases, some flavour of user stories,
                        > etc.), I am inclined to use just plain "increment" or "functionally
                        > complete slice", but I think "releasable increment" also works in that
                        > place.
                        >

                        I like this way of approaching the issue. First off, I think you are spot on once again to say that this has to be neutral and without baggage. Longer term, when we know what we are describing, we may appropriate a more established name.

                        What I am referring to is a "unit of business value". In order to release that business value, we may need to release minimum set of features. These features may be delivered in more than one release in order to mitigate delivery risk.

                        The key thing about it is that it is about business value rather than releases, features or developer tasks. The "unit of business value" initially says nothing about implementation as that may change by the time it comes to implement it. The "unit of business value" may be huge ( mega man year like stick a man on the moon and bring him back alive ) or teeny weeny like a single character bug fix. Realistically, somewhere in between. ;-)


                        >
                        > Too much / not enough alcohol/caffeine/...? Hope it clears!
                        >

                        On a detox. My body wasn't designed to be sober, or to get good food. :-(

                        Chris


                      • chrismatts1968
                        David Good point. Although it probably means the same thing, I do not think the name reflects the intend, but rather the process. Although we may use our own
                        Message 11 of 26 , Jun 16, 2009
                        View Source
                        • 0 Attachment
                          David

                          Good point. Although it probably means the same thing, I do not think the name reflects the intend, but rather the process.

                          Although we may use our own term ( for now ). It would be useful if we also identified all the synonyms.

                          Chris

                          --- In real_options_discussion@yahoogroups.com, David Peterson <david@...> wrote:
                          >
                          > I think what you're describing is what Tom Gilb refers to as a "Design
                          > Idea".
                          > David
                          >
                          >
                          > 2009/6/15 chrismatts1968 <chris.matts@...>
                          >
                          > >
                          > >
                          > > --- In real_options_discussion@yahoogroups.com<real_options_discussion%40yahoogroups.com>,
                          > > Kevlin Henney <kevlin.henney@> wrote:
                          > > > Let's get at this another way: what is that you are trying to
                          > > > characterise? Some potentially releasable increment, produced by a
                          > > > team and understandable by customer/PO/accountant/...? When talking
                          > > > about such things, and wishing to remain in neutral (i.e., not talking
                          > > > FDD features, some variant of use cases, some flavour of user stories,
                          > > > etc.), I am inclined to use just plain "increment" or "functionally
                          > > > complete slice", but I think "releasable increment" also works in that
                          > > > place.
                          > > >
                          > >
                          > > I like this way of approaching the issue. First off, I think you are spot
                          > > on once again to say that this has to be neutral and without baggage. Longer
                          > > term, when we know what we are describing, we may appropriate a more
                          > > established name.
                          > >
                          > > What I am referring to is a "unit of business value". In order to release
                          > > that business value, we may need to release minimum set of features. These
                          > > features may be delivered in more than one release in order to mitigate
                          > > delivery risk.
                          > >
                          > > The key thing about it is that it is about business value rather than
                          > > releases, features or developer tasks. The "unit of business value"
                          > > initially says nothing about implementation as that may change by the time
                          > > it comes to implement it. The "unit of business value" may be huge ( mega
                          > > man year like stick a man on the moon and bring him back alive ) or teeny
                          > > weeny like a single character bug fix. Realistically, somewhere in between.
                          > > ;-)
                          > >
                          > > >
                          > > > Too much / not enough alcohol/caffeine/...? Hope it clears!
                          > > >
                          > >
                          > > On a detox. My body wasn't designed to be sober, or to get good food. :-(
                          > >
                          > > Chris
                          > >
                          > >
                          > >
                          >
                        • Kevlin Henney
                          ... OK, so is there any danger in using the word unit to describe something that is divisible like? In the sense that sometimes unit is seen to be something
                          Message 12 of 26 , Jun 16, 2009
                          View Source
                          • 0 Attachment
                            2009/6/15 chrismatts1968 <chris.matts@...>:
                            >
                            > What I am referring to is a "unit of business value". In order to release
                            > that business value, we may need to release minimum set of features. These
                            > features may be delivered in more than one release in order to mitigate
                            > delivery risk.

                            OK, so is there any danger in using the word "unit" to describe
                            something that is divisible like? In the sense that sometimes unit is
                            seen to be something definitive and discrete, but not divisible. I
                            would say that "increment" and "slice" may be more neutral as they do
                            not come with the association of defining a system of units (sic).

                            >> Too much / not enough alcohol/caffeine/...? Hope it clears!
                            >
                            > On a detox. My body wasn't designed to be sober, or to get good food. :-(

                            If the initial design isn't working out, consider refactoring ;-)

                            Kevlin
                          • Karl Scotland
                            2009/6/15 chrismatts1968 ... Joshua Kerievsky suggested calling it an improvement on the kanbandev list. I like that. Karl -- Karl
                            Message 13 of 26 , Jun 16, 2009
                            View Source
                            • 0 Attachment
                              2009/6/15 chrismatts1968 <chris.matts@...>

                              What I am referring to is a "unit of business value". In order to release that business value, we may need to release minimum set of features. These features may be delivered in more than one release in order to mitigate delivery risk.

                              The key thing about it is that it is about business value rather than releases, features or developer tasks. The "unit of business value" initially says nothing about implementation as that may change by the time it comes to implement it. The "unit of business value" may be huge ( mega man year like stick a man on the moon and bring him back alive ) or teeny weeny like a single character bug fix. Realistically, somewhere in between. ;-)

                              Joshua Kerievsky suggested calling it an "improvement" on the kanbandev list. I like that.

                              Karl
                               
                              --
                              Karl Scotland
                              Agile Coach
                              http://availagility.wordpress.com/
                            • Julian Everett
                              If you take a product backlog, prioritise it using real options rather than MoSCoW/HML/etc then what you should end up with is a componentised ROI model where
                              Message 14 of 26 , Jun 16, 2009
                              View Source
                              • 0 Attachment
                                If you take a product backlog, prioritise it using real options rather
                                than MoSCoW/HML/etc then what you should end up with is a componentised
                                ROI model where each epic constitutes a line item in the business case:
                                hence the term "ROI component". Fair comment about the connotations of
                                the term component however!

                                How about "Optimal Marketable Featureset" as another possibility?
                                Generally, optimal implies minimal because of the overwhelming driver to
                                reduce risk, however it recognises there might be occasions where it's
                                worth taking on higher levels of risk if the potential payback is worth
                                it...

                                Julian





                                -----Original Message-----
                                From: real_options_discussion@yahoogroups.com
                                [mailto:real_options_discussion@yahoogroups.com] On Behalf Of
                                chrismatts1968
                                Sent: 15 June 2009 17:56
                                To: real_options_discussion@yahoogroups.com
                                Subject: [real_options_discussion] Re: The lifecycle of memes (and
                                relevance to RO)

                                --- In real_options_discussion@yahoogroups.com, Kevlin Henney
                                <kevlin.henney@...> wrote:
                                > Let's get at this another way: what is that you are trying to
                                > characterise? Some potentially releasable increment, produced by a
                                > team and understandable by customer/PO/accountant/...? When talking
                                > about such things, and wishing to remain in neutral (i.e., not talking
                                > FDD features, some variant of use cases, some flavour of user stories,
                                > etc.), I am inclined to use just plain "increment" or "functionally
                                > complete slice", but I think "releasable increment" also works in that
                                > place.
                                >

                                I like this way of approaching the issue. First off, I think you are
                                spot on once again to say that this has to be neutral and without
                                baggage. Longer term, when we know what we are describing, we may
                                appropriate a more established name.

                                What I am referring to is a "unit of business value". In order to
                                release that business value, we may need to release minimum set of
                                features. These features may be delivered in more than one release in
                                order to mitigate delivery risk.

                                The key thing about it is that it is about business value rather than
                                releases, features or developer tasks. The "unit of business value"
                                initially says nothing about implementation as that may change by the
                                time it comes to implement it. The "unit of business value" may be huge
                                ( mega man year like stick a man on the moon and bring him back alive )
                                or teeny weeny like a single character bug fix. Realistically, somewhere
                                in between. ;-)

                                >
                                > Too much / not enough alcohol/caffeine/...? Hope it clears!
                                >

                                On a detox. My body wasn't designed to be sober, or to get good food.
                                :-(

                                Chris



                                ------------------------------------

                                Yahoo! Groups Links




                                Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this

                                This e-mail has been sent by one of the following wholly-owned subsidiaries of the BBC:

                                BBC Worldwide Limited, Registration Number: 1420028 England, Registered Address: BBC Media Centre, 201 Wood Lane, London, W12 7TQ
                                BBC World News Limited, Registration Number: 04514407 England, Registered Address: BBC Media Centre, 201 Wood Lane, London, W12 7TQ
                                BBC World Distribution Limited, Registration Number: 04514408, Registered Address: BBC Media Centre, 201 Wood Lane, London, W12 7TQ
                              • chrismatts1968
                                ... I m not sure if it would work. Names are either abstract ( Black-Scholes, User Story ) or they are descriptive and distinctive ( Test-Driven-Development ).
                                Message 15 of 26 , Jun 16, 2009
                                View Source
                                • 0 Attachment
                                  --- In real_options_discussion@yahoogroups.com, Karl Scotland <kjscotland@...> wrote:
                                  >
                                  > 2009/6/15 chrismatts1968 <chris.matts@...>
                                  >
                                  > >
                                  > > What I am referring to is a "unit of business value". In order to release
                                  > > that business value, we may need to release minimum set of features. These
                                  > > features may be delivered in more than one release in order to mitigate
                                  > > delivery risk.
                                  > >
                                  > > The key thing about it is that it is about business value rather than
                                  > > releases, features or developer tasks. The "unit of business value"
                                  > > initially says nothing about implementation as that may change by the time
                                  > > it comes to implement it. The "unit of business value" may be huge ( mega
                                  > > man year like stick a man on the moon and bring him back alive ) or teeny
                                  > > weeny like a single character bug fix. Realistically, somewhere in between.
                                  > > ;-)

                                  > Joshua Kerievsky suggested calling it an "improvement" on the kanbandev
                                  > list. I like that.

                                  I'm not sure if it would work. Names are either abstract ( Black-Scholes, User Story ) or they are descriptive and distinctive ( Test-Driven-Development ). My concern with "improvement" is that it might be confusing to someone joining the group. They would read a comment like "The latest improvement is based on our workshop" and not realise that "improvement" had a special and particular meaning. Names are often awkward which make them stand out.

                                  How about "Quantum of value"?

                                  This is not a fixed thing but really a place holder until we find a name that works.
                                • Matt Wynne
                                  ... What s wrong with potentially shippable product increment, eh? ;) Seriously, Scenario works for us. We use BDD to specify automated tests for each change
                                  Message 16 of 26 , Jun 16, 2009
                                  View Source
                                  • 0 Attachment
                                    On 16 Jun 2009, at 13:40, chrismatts1968 wrote:
                                    > How about "Quantum of value"?
                                    >
                                    What's wrong with potentially shippable product increment, eh? ;)

                                    Seriously, 'Scenario' works for us. We use BDD to specify automated
                                    tests for each change we make to the product, so as part of our
                                    analysis we basically identify the fantasy scenarios that the product
                                    doesn't yet satisfy, prioritise them, then incrementally make them
                                    real. I really like this model for thinking about and planning our work.

                                    I think the word probably lacks something in conveying the potential
                                    that is locked inside a to-be-satisfied scenario. Also, like
                                    'improvement', it probably doesn't work too well out of context.

                                    Matt Wynne
                                    http://blog.mattwynne.net
                                    http://www.songkick.com
                                  • Brandon Carlson
                                    How about Defect it seems the world can t get enough of those.
                                    Message 17 of 26 , Jun 16, 2009
                                    View Source
                                    • 0 Attachment
                                      How about "Defect" it seems the world can't get enough of those.

                                      On Tue, Jun 16, 2009 at 1:51 PM, Matt Wynne<matt@...> wrote:
                                      >
                                      >
                                      >
                                      > On 16 Jun 2009, at 13:40, chrismatts1968 wrote:
                                      >> How about "Quantum of value"?
                                      >>
                                      > What's wrong with potentially shippable product increment, eh? ;)
                                      >
                                      > Seriously, 'Scenario' works for us. We use BDD to specify automated
                                      > tests for each change we make to the product, so as part of our
                                      > analysis we basically identify the fantasy scenarios that the product
                                      > doesn't yet satisfy, prioritise them, then incrementally make them
                                      > real. I really like this model for thinking about and planning our work.
                                      >
                                      > I think the word probably lacks something in conveying the potential
                                      > that is locked inside a to-be-satisfied scenario. Also, like
                                      > 'improvement', it probably doesn't work too well out of context.
                                      >
                                      > Matt Wynne
                                      > http://blog.mattwynne.net
                                      > http://www.songkick.com
                                      >
                                      >
                                    • Brad Appleton
                                      ... Didnt we have this same discussion on the Kanban list where the above seemed to meet with favorable sentiment? (I was the one that used the word quantum ,
                                      Message 18 of 26 , Jun 17, 2009
                                      View Source
                                      • 0 Attachment
                                        chrismatts1968 wrote:

                                        > How about "Quantum of value"?
                                        >
                                        > This is not a fixed thing but really a place holder until we find a name
                                        > that works.

                                        Didnt we have this same discussion on the Kanban list where the above
                                        seemed to meet with favorable sentiment? (I was the one that used the
                                        word "quantum", and Kevlin liked it and suggest "QoV" above)

                                        When I look at the thesaurus on dictionary.com I get the following ...

                                        atom, bit, bite, branch, chip, chunk, component, constituent, cut,
                                        dollup, dram, element, entity, extract, fixture, fragment, grain,
                                        granule, iota, increment, installment, item, jot, lot, lump, modicum,
                                        module, moiety, molecule, morsel, mote, nodule, nugget, ounce, parcel,
                                        particle, partition, patch, piece, portion, quantum, ration, remnant,
                                        scrap, section, sector, segment, serving, share, shot, shred, slab,
                                        slice, sliver, slug, smithereen, span, speck, splice, splinter, spot,
                                        string, subdivision, token, unit



                                        --
                                        Brad Appleton <brad {AT} bradapp.net>
                                        Agile CM Environments (http://blog.bradapp.net/)
                                        & Software CM Patterns (www.scmpatterns.com)
                                        "And miles to go before I sleep" -- Robert Frost
                                      • Kevlin Henney
                                        2009/6/17 Brad Appleton ... Something like that, although I specifically suggested Quantum of Flow (for the various possible
                                        Message 19 of 26 , Jun 17, 2009
                                        View Source
                                        • 0 Attachment
                                          2009/6/17 Brad Appleton <Brad.Appleton@...>
                                          >
                                          > chrismatts1968 wrote:
                                          >
                                          > > How about "Quantum of value"?
                                          > >
                                          > > This is not a fixed thing but really a place holder until we find a name
                                          > > that works.
                                          >
                                          > Didnt we have this same discussion on the Kanban list where the above
                                          > seemed to meet with favorable sentiment? (I was the one that used the
                                          > word "quantum", and Kevlin liked it and suggest "QoV" above)

                                          Something like that, although I specifically suggested Quantum of Flow
                                          (for the various possible pronunciations of QoF).

                                          Quantum of value and QoV (probably just spelt out rather than
                                          pronounced) works well because it is short, memorable and doesn't
                                          raise (too many) unnecessary questions. It suggests something
                                          incremental that has some value, but doesn't get caught up in the
                                          discussion or distraction of whether or not something is marketable (a
                                          slippery term, especially in internal IT organisations) or whether we
                                          are actually recouping ROI at that point (again, not relevant to all
                                          kinds of software development).

                                          Kevlin
                                        • David Peterson
                                          What about Quantum of Solace ? :-) I use work item for the same reasons Kevlin mentioned and I don t like jargon. David 2009/6/17 Kevlin Henney
                                          Message 20 of 26 , Jun 17, 2009
                                          View Source
                                          • 0 Attachment
                                            What about "Quantum of Solace"? :-)

                                            I use "work item" for the same reasons Kevlin mentioned and I don't like jargon.

                                            David



                                            2009/6/17 Kevlin Henney <kevlin.henney@...>


                                            2009/6/17 Brad Appleton <Brad.Appleton@...>


                                            >
                                            > chrismatts1968 wrote:
                                            >
                                            > > How about "Quantum of value"?
                                            > >
                                            > > This is not a fixed thing but really a place holder until we find a name
                                            > > that works.
                                            >
                                            > Didnt we have this same discussion on the Kanban list where the above
                                            > seemed to meet with favorable sentiment? (I was the one that used the
                                            > word "quantum", and Kevlin liked it and suggest "QoV" above)

                                            Something like that, although I specifically suggested Quantum of Flow
                                            (for the various possible pronunciations of QoF).

                                            Quantum of value and QoV (probably just spelt out rather than
                                            pronounced) works well because it is short, memorable and doesn't
                                            raise (too many) unnecessary questions. It suggests something
                                            incremental that has some value, but doesn't get caught up in the
                                            discussion or distraction of whether or not something is marketable (a
                                            slippery term, especially in internal IT organisations) or whether we
                                            are actually recouping ROI at that point (again, not relevant to all
                                            kinds of software development).

                                            Kevlin


                                          • chrismatts1968
                                            ... I like QoV, QoF or QoS as the name for the value related item..... which breaks down into a number of work items ( rather than user story which ties us
                                            Message 21 of 26 , Jun 17, 2009
                                            View Source
                                            • 0 Attachment
                                              --- In real_options_discussion@yahoogroups.com, David Peterson <david@...> wrote:
                                              >
                                              > What about "Quantum of Solace"? :-)
                                              > I use "work item" for the same reasons Kevlin mentioned and I don't like

                                              I like QoV, QoF or QoS as the name for the value related item..... which breaks down into a number of "work items" ( rather than user story which ties us too much to XP ). Glad I did not invent any of the names.... I'm lousy at it, although I am good at the nicking the credit from other people. ;-)

                                              I suggest QoV ( Quantum of Value ) pronounced Quoff ( to spot the outsiders who misppronounce it ;-) ) and "work item".

                                              Any objections?
                                            • Julian Everett
                                              I was thinking about this some more last night. One of the key learnings that has come out my recent experiences of using real options to inform product
                                              Message 22 of 26 , Jun 17, 2009
                                              View Source
                                              • 0 Attachment
                                                I was thinking about this some more last night. One of the key learnings
                                                that has come out my recent experiences of using real options to inform
                                                product delivery is the importance of getting the right set of stories.
                                                To that end, iterative backlog refactoring has been key to assessing
                                                all the different ways the functionality can be chopped up into
                                                shippable work items.

                                                What constitutes the "right" set of stories is essentially the set which
                                                together result in the maximum cumulative risked-adjusted RO valuation
                                                of the backlog.

                                                For that reason, "Optimally Factored Featureset" as a better version of
                                                "MMF" seemed the best choice to me - as it best expresses what we are
                                                trying to achieve?..

                                                cheers

                                                Julian




                                                -----Original Message-----
                                                From: real_options_discussion@yahoogroups.com
                                                [mailto:real_options_discussion@yahoogroups.com] On Behalf Of
                                                chrismatts1968
                                                Sent: 17 June 2009 14:25
                                                To: real_options_discussion@yahoogroups.com
                                                Subject: [real_options_discussion] Re: The lifecycle of memes (and
                                                relevance to RO)

                                                --- In real_options_discussion@yahoogroups.com, David Peterson
                                                <david@...> wrote:
                                                >
                                                > What about "Quantum of Solace"? :-)
                                                > I use "work item" for the same reasons Kevlin mentioned and I don't
                                                like

                                                I like QoV, QoF or QoS as the name for the value related item..... which
                                                breaks down into a number of "work items" ( rather than user story which
                                                ties us too much to XP ). Glad I did not invent any of the names.... I'm
                                                lousy at it, although I am good at the nicking the credit from other
                                                people. ;-)

                                                I suggest QoV ( Quantum of Value ) pronounced Quoff ( to spot the
                                                outsiders who misppronounce it ;-) ) and "work item".

                                                Any objections?





                                                ------------------------------------

                                                Yahoo! Groups Links




                                                Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this

                                                This e-mail has been sent by one of the following wholly-owned subsidiaries of the BBC:

                                                BBC Worldwide Limited, Registration Number: 1420028 England, Registered Address: BBC Media Centre, 201 Wood Lane, London, W12 7TQ
                                                BBC World News Limited, Registration Number: 04514407 England, Registered Address: BBC Media Centre, 201 Wood Lane, London, W12 7TQ
                                                BBC World Distribution Limited, Registration Number: 04514408, Registered Address: BBC Media Centre, 201 Wood Lane, London, W12 7TQ
                                              • Brad Appleton
                                                ... I like it, But to play devils-advocate for just a moment ... what is it that makes QoV more preferable than Unit-of-Value (UoV) or Value-Item? Certainly
                                                Message 23 of 26 , Jun 17, 2009
                                                View Source
                                                • 0 Attachment
                                                  chrismatts1968 wrote:
                                                  > I suggest QoV ( Quantum of Value ) pronounced Quoff ( to spot the
                                                  > outsiders who misppronounce it ;-) ) and "work item".
                                                  >
                                                  > Any objections?

                                                  I like it, But to play devils-advocate for just a moment ... what is it
                                                  that makes QoV more preferable than Unit-of-Value (UoV) or Value-Item?

                                                  Certainly "quantum" comes across more like jargon then "unit" or "item".
                                                  And there is a certain symmetry and conciseness to seeing "value item"
                                                  and "work item" together.

                                                  I acknowledge "item" fails to indicate something of minimal size (while
                                                  still having value). Yet perhaps there is usefulness in being able to
                                                  express the difference between a "value item" and a "canonical value
                                                  item" or "basic value item" or "atomic value item (or even "quantum
                                                  value item" ;-)

                                                  Again, if the desire is to minimize jargon, then it would seem that the
                                                  following seem the "most" plain & simple:
                                                  * value-item
                                                  * basic value-item (or canonical value-item)
                                                  * work-item


                                                  --
                                                  Brad Appleton <brad {AT} bradapp.net>
                                                  Agile CM Environments (http://blog.bradapp.net/)
                                                  & Software CM Patterns (www.scmpatterns.com)
                                                  "And miles to go before I sleep" -- Robert Frost
                                                • Eric Willeke
                                                  Get OFF! I like it. *On Wed, Jun 17, 2009 at 3:01 PM, Julian Everett wrote: * For that reason, Optimally Factored Featureset as a
                                                  Message 24 of 26 , Jun 17, 2009
                                                  View Source
                                                  • 0 Attachment
                                                    Get OFF!
                                                     
                                                    I like it.
                                                    On Wed, Jun 17, 2009 at 3:01 PM, Julian Everett <julian.everett@...> wrote:
                                                    For that reason, "Optimally Factored Featureset" as a better version of
                                                    "MMF" seemed the best choice to me - as it best expresses what we are
                                                    trying to achieve?..
                                                  • njjreid
                                                    I agree with that QoV sound a big jargony to me. Value Element? Technically composed of smaller parts, but greater than their sum and unsplittable w/o losing
                                                    Message 25 of 26 , Jun 17, 2009
                                                    View Source
                                                    • 0 Attachment
                                                      I agree with that QoV sound a big jargony to me.

                                                      Value Element? Technically composed of smaller parts, but greater than their sum and unsplittable w/o losing some unique properties.

                                                      --- In real_options_discussion@yahoogroups.com, Brad Appleton <Brad.Appleton@...> wrote:
                                                      >
                                                      > chrismatts1968 wrote:
                                                      > > I suggest QoV ( Quantum of Value ) pronounced Quoff ( to spot the
                                                      > > outsiders who misppronounce it ;-) ) and "work item".
                                                      > >
                                                      > > Any objections?
                                                      >
                                                      > I like it, But to play devils-advocate for just a moment ... what is it
                                                      > that makes QoV more preferable than Unit-of-Value (UoV) or Value-Item?
                                                      >
                                                      > Certainly "quantum" comes across more like jargon then "unit" or "item".
                                                      > And there is a certain symmetry and conciseness to seeing "value item"
                                                      > and "work item" together.
                                                      >
                                                      > I acknowledge "item" fails to indicate something of minimal size (while
                                                      > still having value). Yet perhaps there is usefulness in being able to
                                                      > express the difference between a "value item" and a "canonical value
                                                      > item" or "basic value item" or "atomic value item (or even "quantum
                                                      > value item" ;-)
                                                      >
                                                      > Again, if the desire is to minimize jargon, then it would seem that the
                                                      > following seem the "most" plain & simple:
                                                      > * value-item
                                                      > * basic value-item (or canonical value-item)
                                                      > * work-item
                                                      >
                                                      >
                                                      > --
                                                      > Brad Appleton <brad {AT} bradapp.net>
                                                      > Agile CM Environments (http://blog.bradapp.net/)
                                                      > & Software CM Patterns (www.scmpatterns.com)
                                                      > "And miles to go before I sleep" -- Robert Frost
                                                      >
                                                    • Brad Appleton
                                                      Indeed - I sort of like the meaning of OFF as described below. I have often felt (and argued) strongly that refactoring should apply every bit as much to
                                                      Message 26 of 26 , Jun 18, 2009
                                                      View Source
                                                      • 0 Attachment
                                                        Indeed - I sort of like the meaning of OFF as described below. I have often felt (and argued) strongly that refactoring should apply every bit as much to stories as to code.

                                                        So I definitely like OFF (Optimally Factored Featureset) as a better verison of minimal marketable feature-*SET*.

                                                        But I don't feel it conveys the notion of a minimal yet marketable *feature* (as opposed to a feature-SET). This would correspond to the individual value-item, rather than the set of well-factored ones.

                                                        I was looking at the description for a new book today:

                                                        * The Options Trading Body of Knowledge: The Definitive Source for Information About the Options Industry; By Michael C. Thomsett (see http://www.informit.com/title/0137142935 and also the article at http://www.ftpress.com/articles/article.aspx?p=1352546)

                                                        After reading that, I get the impression that "value proposition" or "value element" might be the better term to use. (VP or VE)

                                                        "Value proposition" by itself may not convey the idea of minimal granularity tho, so a qualifier/prefix like "minimal" and/or "sufficient" might be needed (leaving us with one of: MVP, MSP, or MSVP).

                                                        I sort of like the acronym MVP or MSVP (minimally sufficient value proposal). [But I suppose Value-Element works too]


                                                        --- In real_options_discussion@yahoogroups.com, Eric Willeke <eric.willeke@...> wrote:
                                                        >
                                                        > Get OFF!
                                                        >
                                                        > I like it.
                                                        > *On Wed, Jun 17, 2009 at 3:01 PM, Julian Everett <julian.everett@...>wrote:
                                                        > *
                                                        > For that reason, "Optimally Factored Featureset" as a better version of
                                                        > "MMF" seemed the best choice to me - as it best expresses what we are
                                                        > trying to achieve?..
                                                        >
                                                      Your message has been successfully submitted and would be delivered to recipients shortly.