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

For an article: What do you wish your CIO understood about requirements?

Expand Messages
  • estherschindler
    Howdy, folks. I m senior online editor at CIO.com (and more invisibly at CSOonline.com). Among the things that CIOs most desperately want to know -- really,
    Message 1 of 22 , Dec 18, 2006
      Howdy, folks. I'm senior online editor at CIO.com (and more invisibly
      at CSOonline.com). Among the things that CIOs most desperately want to
      know -- really, they say this -- is what their development staff
      thinks, but doesn't SAY. At least, the DBA or developer won't say it
      directly to the CIO or other top management. So I'm starting a series
      of articles about "what CIOs really need to know about..." which will
      cover various topics. The first one is about software requirements.

      My question to you is a very simple one: ***If you could get your CIO
      to understand one thing, just ONE THING about software requirements,
      what would it be?***

      And then, the obvious follow-up: why did you pick *that*? War stories
      to illustrate your point would be great.

      You can touch on anything to do with the software requirements
      process; I'm game for whatever you give me.

      Ideally I would quote you by name and company and location ("Esther
      Schindler is a senior developer at the Groovy Corporation in
      Scottsdale Arizona") but as long as you give me some kind of context
      I'm willing to work without one. That is, I do need some identifying
      characteristics to give the article credibility ("Esther works at a
      large finance company in the Southwest") but I don't want you to lose
      your job when the CIO realizes that the developer quoted works for
      *her*! <grin> So please be sure to let me know how to refer to you in
      the article.

      I'll be sure to stop by here (as I expect others want to participate
      in the conversation), but it'd be great if you could send me a private
      message. I don't want to miss any responses. Reply privately if that's
      easier, too.

      I plan to work on this during the holiday and to collect responses
      over the next week or so. I'm hoping to publish the article on CIO.com
      by mid-January at the latest.

      So: what clue would you like your CIO to get? about software
      requirements, that is?

      Esther Schindler
      senior online editor
      CXO Media
    • David H
      ... Dear Esther. I might be a little bit different from the answers you might expect, but here is my take on it. What you described I do not need my CIO to
      Message 2 of 22 , Dec 18, 2006
        estherschindler wrote:

        > Howdy, folks. I'm senior online editor at CIO.com (and more invisibly
        > at CSOonline.com). Among the things that CIOs most desperately want to
        > know -- really, they say this -- is what their development staff
        > thinks, but doesn't SAY. At least, the DBA or developer won't say it
        > directly to the CIO or other top management. So I'm starting a series
        > of articles about "what CIOs really need to know about..." which will
        > cover various topics. The first one is about software requirements.
        >

        Dear Esther.

        I might be a little bit different from the answers you might expect, but
        here is my take on it.
        What you described I do not need my CIO to understand. What I need my
        CIO to understand, above all else, is that he/she hired experts. People
        which are very talented and devoted in the area of expertise that they
        have.

        Requirements, created by the business, by marketing, marketing analysts
        and every other business unit which is necessary to create and ship a
        product will happily take care of the requirements process.

        What I expect my CIO to know in this particular process are strategical
        decisions. This of course includes working the product backlog in
        accordance with the strategical needs of the company.

        But to me, that is all. The nitty gritty detail should be left to the
        experts.

        -d
      • dnicolet99
        I d like to second David H s answer. What he s talking about is trust , a basic agile principle. So many companies boast about the effort they make to hire
        Message 3 of 22 , Dec 19, 2006
          I'd like to second David H's answer. What he's talking about is
          "trust", a basic agile principle. So many companies boast about the
          effort they make to hire smart and capable people, only to treat their
          employees like mindless automatons once they're on the payroll.

          If I had to think of just one thing for CIOs to know about
          requirements, it would be that change is the norm rather than the
          exception. We need to turn away from the traditional approach of
          trying to nail down all the detailed requirements up front, and then
          imposing so-called "change control" processes designed not to control
          change, but to discourage it. Instead, CIOs should actively and firmly
          support methods that embrace change and deal with it gracefully, as
          agile and lean methods are meant to do.

          If it's okay to mention a second thing (even though you asked for just
          one, in all caps and emphasized with editorial asterisks), it would be
          for CIOs to understand the best value-add role for Business Analysts,
          and structure the IT organization accordingly.

          Circa 1970, when business people were ignorant of (and uninterested
          in) information technology and programmers were ignorant of (and
          uninterested in) business issues, the need arose for "translators" who
          could understand both groups and speak both languages. The Business
          Analyst role as we know it was born. The translator role has long
          since become entrenched and is simply assumed to be a natural and
          necessary part of the development process, despite the fact business
          people are very comfortable with computers and technical people are
          quite cognizant of business issues. The results are unintelligible
          requirements documents, process formalities that add no value, a
          needless layer of abstraction between customers and developers, and a
          rather amusing sub-industry that specializes in crafting
          impressive-sounding job titles like Requirements Engineer and
          Requirements Architect.

          CIOs should use Business Analysts in a role more in keeping with the
          job title: To analyze business processes and identify opportunities
          for improvement. That would be a value-add role. On software
          development projects, Business Analysts should not get between the
          customers and the developers. When they do, they only cause confusion
          and slow things down. Business people and technical people can (or can
          learn to) communicate perfectly well without a translator. CIOs who
          recognize this fact will be able to structure their organizations in a
          leaner and more effective way than those who do not.


          --- In extremeprogramming@yahoogroups.com, "estherschindler"
          <esther@...> wrote:
          >
          > Howdy, folks. I'm senior online editor at CIO.com (and more invisibly
          > at CSOonline.com). Among the things that CIOs most desperately want to
          > know -- really, they say this -- is what their development staff
          > thinks, but doesn't SAY. At least, the DBA or developer won't say it
          > directly to the CIO or other top management. So I'm starting a series
          > of articles about "what CIOs really need to know about..." which will
          > cover various topics. The first one is about software requirements.
          >
          > My question to you is a very simple one: ***If you could get your CIO
          > to understand one thing, just ONE THING about software requirements,
          > what would it be?***
          >
          > And then, the obvious follow-up: why did you pick *that*? War stories
          > to illustrate your point would be great.
          >
          > You can touch on anything to do with the software requirements
          > process; I'm game for whatever you give me.
          >
          > Ideally I would quote you by name and company and location ("Esther
          > Schindler is a senior developer at the Groovy Corporation in
          > Scottsdale Arizona") but as long as you give me some kind of context
          > I'm willing to work without one. That is, I do need some identifying
          > characteristics to give the article credibility ("Esther works at a
          > large finance company in the Southwest") but I don't want you to lose
          > your job when the CIO realizes that the developer quoted works for
          > *her*! <grin> So please be sure to let me know how to refer to you in
          > the article.
          >
          > I'll be sure to stop by here (as I expect others want to participate
          > in the conversation), but it'd be great if you could send me a private
          > message. I don't want to miss any responses. Reply privately if that's
          > easier, too.
          >
          > I plan to work on this during the holiday and to collect responses
          > over the next week or so. I'm hoping to publish the article on CIO.com
          > by mid-January at the latest.
          >
          > So: what clue would you like your CIO to get? about software
          > requirements, that is?
          >
          > Esther Schindler
          > senior online editor
          > CXO Media
          >
        • Scott Ambler
          ... wrote: I wrote a detailed article on this sort of topic a few years ago for Cutter entitled Doomed from the Start: What Everyone But Senior
          Message 4 of 22 , Dec 19, 2006
            --- In extremeprogramming@yahoogroups.com, "estherschindler"
            <esther@...> wrote:

            I wrote a detailed article on this sort of topic a few years ago for
            Cutter entitled "Doomed from the Start: What Everyone But Senior
            Management Seems to Know". See
            http://www.cutter.com/content/itjournal/fulltext/2004/03/itj0403f.html

            If I was to pick one issue, it would be the naive desire of getting
            a "solid" estimate up front early in the project. That one decision
            motivates a whole bunch of really bad practices, such as big
            requirements up front (BRUF), big design up front (BDUF), judging the
            project team on whether they meet the budget INSTEAD of whether they
            acheived great ROI, ...

            - Scott
          • Willem Bogaerts
            ... If a project was sold for a fixed price, not meeting the budget equals by definition not achieving sufficient ROI . The problem is that the blame is
            Message 5 of 22 , Dec 19, 2006
              > ..., judging the
              > project team on whether they meet the budget INSTEAD of whether they
              > acheived great ROI, ...

              If a project was sold for a fixed price, "not meeting the budget" equals
              by definition "not achieving sufficient ROI". The problem is that the
              blame is always put on the people who have to meet the unknown (in
              scope) and impossible (in time, as the scope is only known at the very
              last moment) schedule. It is never the people who made the schedule.

              Best regards,
              Willem Bogaerts
            • Victor
              I tend to agree with most of what has been said on this subject by all participants, and I would like to add a few thoughts. The fact that requirements tend to
              Message 6 of 22 , Dec 19, 2006
                I tend to agree with most of what has been said on this subject by all participants, and I would like to add a few thoughts.

                The fact that requirements tend to be fluid has implications. One of the implications is on the concept of organizational hierarchy. The purpose of many of the modern organizations is to produce intellectual property. The best intellectual productivity is achieved in environments that promote creativity through respect and good communication. Mechanistic Hierarchies based on the concepts developed during the first industrial revolution are not conducive to creativity. One of the central concepts of these decrepit hierarchies is control. Management positions tend to be filled by micro-controllers with narrow horizons, whose inertia slows down the enterprise's productivity. In today's environments, where the probability that yesterday's requirements will not be relevant tomorrow is very high, control freaks should be replaced by collaborators and enablers. One of the best techniques to implement this approach is MBWA, Management by Walking Around. CIOs should be there, engaging people in conversations and listening to the various inputs. The Agile approach has more practical advice. Communication, cooperation, respect should be implemented at all levels of the organization, This is not just for the CIO, but she has the responsibility to create and maintain such an environment.

                Victor Goldberg, Ph.D.

                ================================================

                ----- Original Message -----
                From: dnicolet99
                To: extremeprogramming@yahoogroups.com
                Sent: Tuesday, December 19, 2006 5:24 AM
                Subject: [XP] Re: For an article: What do you wish your CIO understood about requirements?


                I'd like to second David H's answer. What he's talking about is
                "trust", a basic agile principle. So many companies boast about the
                effort they make to hire smart and capable people, only to treat their
                employees like mindless automatons once they're on the payroll.

                If I had to think of just one thing for CIOs to know about
                requirements, it would be that change is the norm rather than the
                exception. We need to turn away from the traditional approach of
                trying to nail down all the detailed requirements up front, and then
                imposing so-called "change control" processes designed not to control
                change, but to discourage it. Instead, CIOs should actively and firmly
                support methods that embrace change and deal with it gracefully, as
                agile and lean methods are meant to do.

                If it's okay to mention a second thing (even though you asked for just
                one, in all caps and emphasized with editorial asterisks), it would be
                for CIOs to understand the best value-add role for Business Analysts,
                and structure the IT organization accordingly.

                Circa 1970, when business people were ignorant of (and uninterested
                in) information technology and programmers were ignorant of (and
                uninterested in) business issues, the need arose for "translators" who
                could understand both groups and speak both languages. The Business
                Analyst role as we know it was born. The translator role has long
                since become entrenched and is simply assumed to be a natural and
                necessary part of the development process, despite the fact business
                people are very comfortable with computers and technical people are
                quite cognizant of business issues. The results are unintelligible
                requirements documents, process formalities that add no value, a
                needless layer of abstraction between customers and developers, and a
                rather amusing sub-industry that specializes in crafting
                impressive-sounding job titles like Requirements Engineer and
                Requirements Architect.

                CIOs should use Business Analysts in a role more in keeping with the
                job title: To analyze business processes and identify opportunities
                for improvement. That would be a value-add role. On software
                development projects, Business Analysts should not get between the
                customers and the developers. When they do, they only cause confusion
                and slow things down. Business people and technical people can (or can
                learn to) communicate perfectly well without a translator. CIOs who
                recognize this fact will be able to structure their organizations in a
                leaner and more effective way than those who do not.

                --- In extremeprogramming@yahoogroups.com, "estherschindler"
                <esther@...> wrote:
                >
                > Howdy, folks. I'm senior online editor at CIO.com (and more invisibly
                > at CSOonline.com). Among the things that CIOs most desperately want to
                > know -- really, they say this -- is what their development staff
                > thinks, but doesn't SAY. At least, the DBA or developer won't say it
                > directly to the CIO or other top management. So I'm starting a series
                > of articles about "what CIOs really need to know about..." which will
                > cover various topics. The first one is about software requirements.
                >
                > My question to you is a very simple one: ***If you could get your CIO
                > to understand one thing, just ONE THING about software requirements,
                > what would it be?***
                >
                > And then, the obvious follow-up: why did you pick *that*? War stories
                > to illustrate your point would be great.
                >
                > You can touch on anything to do with the software requirements
                > process; I'm game for whatever you give me.
                >
                > Ideally I would quote you by name and company and location ("Esther
                > Schindler is a senior developer at the Groovy Corporation in
                > Scottsdale Arizona") but as long as you give me some kind of context
                > I'm willing to work without one. That is, I do need some identifying
                > characteristics to give the article credibility ("Esther works at a
                > large finance company in the Southwest") but I don't want you to lose
                > your job when the CIO realizes that the developer quoted works for
                > *her*! <grin> So please be sure to let me know how to refer to you in
                > the article.
                >
                > I'll be sure to stop by here (as I expect others want to participate
                > in the conversation), but it'd be great if you could send me a private
                > message. I don't want to miss any responses. Reply privately if that's
                > easier, too.
                >
                > I plan to work on this during the holiday and to collect responses
                > over the next week or so. I'm hoping to publish the article on CIO.com
                > by mid-January at the latest.
                >
                > So: what clue would you like your CIO to get? about software
                > requirements, that is?
                >
                > Esther Schindler
                > senior online editor
                > CXO Media
                >





                [Non-text portions of this message have been removed]
              • Brad Smith
                Hi Esther - I work for a federal agency where CIOs tend to (a) come from other than technical backgrounds and (b) are often consumed with the need to respond
                Message 7 of 22 , Dec 19, 2006
                  Hi Esther -

                  I work for a federal agency where CIOs tend to (a) come from other than
                  technical backgrounds and (b) are often consumed with the need to
                  respond to oversight requests from the Administration and Congress and
                  therefore have little time to focus on details like software
                  requirements.

                  My one item would be that in order to make sure that requirements are
                  effective and properly implemented it is imperative to support the
                  user's representative on the team. All too often, as Scott Ambler might
                  say, the team does the big up front design, including requirements
                  gathering, and then goes off to do the work in isolation delivering a
                  product that may meet requirements at one level but fail completely to
                  meet them in a way the user needs and expects.

                  By the way, I just found a copy of Extended Attributes on a bookshelf in
                  my office, May 1999 issue. :)

                  Brad


                  On Mon, 2006-12-18 at 21:45 +0000, estherschindler wrote:

                  > My question to you is a very simple one: ***If you could get your CIO
                  > to understand one thing, just ONE THING about software requirements,
                  > what would it be?***
                  >
                  >


                  [Non-text portions of this message have been removed]
                • banshee858
                  ... I would agree with the sentiment expressed earlier - if the CIO wants to know the details of the requirements, then we got bigger fish to fry. That said,
                  Message 8 of 22 , Dec 19, 2006
                    >
                    > So: what clue would you like your CIO to get? about software
                    > requirements, that is?
                    >
                    I would agree with the sentiment expressed earlier - if the CIO wants
                    to know the details of the requirements, then we got bigger fish to
                    fry. That said, suppose my CIO was merely curious on what I did each
                    day and wanted to learn a little about what people are doing I might
                    respond with this (borrowed from Mike Cohn) - meeting a series of
                    requirements is not the same thing as meeting our customer's goals.
                    Tell me what are customer's goals are (even better bring the customer
                    in and he/she can tell me in person) and we can then figure out what
                    types of requirements are needed. Then, when we are ready to execute,
                    let us plan around our customer's goals, not around the requirements.

                    Carlton
                  • Victor
                    Mah Pleshah, Joseph, (My Pleasure, in some kind of USA accent :-) I am taking this from the University of Life in the Province of Enlightement, part of
                    Message 9 of 22 , Dec 19, 2006
                      Mah Pleshah, Joseph, (My Pleasure, in some kind of USA accent :-)

                      I am taking this from the University of Life in the Province of Enlightement, part of the State of Movement. :-)

                      I am glad you found it valuable.
                      Victor

                      ===============================

                      ----- Original Message -----
                      From: Josef Scherer
                      To: extremeprogramming@yahoogroups.com
                      Sent: Tuesday, December 19, 2006 5:12 PM
                      Subject: AW: [XP] Re: For an article: What do you wish your CIO understood about requirements?


                      Hello Victor,

                      Thanks for sharing this thoughts.
                      I don't know from what province you take this way of putting it, but I can understand this whithout thinking agile/XP/Scrum/Lean. And this makes it valuable when talking to others not familiar with agile approaches.

                      Josef

                      ----- Ursprüngliche Mail ----
                      Von: Victor <vmgoldberg@...>
                      An: extremeprogramming@yahoogroups.com
                      Gesendet: Dienstag, den 19. Dezember 2006, 15:21:24 Uhr
                      Betreff: Re: [XP] Re: For an article: What do you wish your CIO understood about requirements?

                      I tend to agree with most of what has been said on this subject by all participants, and I would like to add a few thoughts.

                      The fact that requirements tend to be fluid has implications. One of the implications is on the concept of organizational hierarchy. The purpose of many of the modern organizations is to produce intellectual property. The best intellectual productivity is achieved in environments that promote creativity through respect and good communication. Mechanistic Hierarchies based on the concepts developed during the first industrial revolution are not conducive to creativity. One of the central concepts of these decrepit hierarchies is control. Management positions tend to be filled by micro-controllers with narrow horizons, whose inertia slows down the enterprise's productivity. In today's environments, where the probability that yesterday's requirements will not be relevant tomorrow is very high, control freaks should be replaced by collaborators and enablers. One of the best techniques to implement this approach is MBWA, Management by Walking Around. CIOs should be there,
                      engaging people in conversations and listening to the various inputs. The Agile approach has more practical advice. Communication, cooperation, respect should be implemented at all levels of the organization, This is not just for the CIO, but she has the responsibility to create and maintain such an environment.

                      Victor Goldberg, Ph.D.

                      ============ ========= ========= ========= =========

                      ----- Original Message -----
                      From: dnicolet99
                      To: extremeprogramming@ yahoogroups. com
                      Sent: Tuesday, December 19, 2006 5:24 AM
                      Subject: [XP] Re: For an article: What do you wish your CIO understood about requirements?

                      I'd like to second David H's answer. What he's talking about is
                      "trust", a basic agile principle. So many companies boast about the
                      effort they make to hire smart and capable people, only to treat their
                      employees like mindless automatons once they're on the payroll.

                      If I had to think of just one thing for CIOs to know about
                      requirements, it would be that change is the norm rather than the
                      exception. We need to turn away from the traditional approach of
                      trying to nail down all the detailed requirements up front, and then
                      imposing so-called "change control" processes designed not to control
                      change, but to discourage it. Instead, CIOs should actively and firmly
                      support methods that embrace change and deal with it gracefully, as
                      agile and lean methods are meant to do.

                      If it's okay to mention a second thing (even though you asked for just
                      one, in all caps and emphasized with editorial asterisks), it would be
                      for CIOs to understand the best value-add role for Business Analysts,
                      and structure the IT organization accordingly.

                      Circa 1970, when business people were ignorant of (and uninterested
                      in) information technology and programmers were ignorant of (and
                      uninterested in) business issues, the need arose for "translators" who
                      could understand both groups and speak both languages. The Business
                      Analyst role as we know it was born. The translator role has long
                      since become entrenched and is simply assumed to be a natural and
                      necessary part of the development process, despite the fact business
                      people are very comfortable with computers and technical people are
                      quite cognizant of business issues. The results are unintelligible
                      requirements documents, process formalities that add no value, a
                      needless layer of abstraction between customers and developers, and a
                      rather amusing sub-industry that specializes in crafting
                      impressive-sounding job titles like Requirements Engineer and
                      Requirements Architect.

                      CIOs should use Business Analysts in a role more in keeping with the
                      job title: To analyze business processes and identify opportunities
                      for improvement. That would be a value-add role. On software
                      development projects, Business Analysts should not get between the
                      customers and the developers. When they do, they only cause confusion
                      and slow things down. Business people and technical people can (or can
                      learn to) communicate perfectly well without a translator. CIOs who
                      recognize this fact will be able to structure their organizations in a
                      leaner and more effective way than those who do not.

                      --- In extremeprogramming@ yahoogroups. com, "estherschindler"
                      <esther@...> wrote:
                      >
                      > Howdy, folks. I'm senior online editor at CIO.com (and more invisibly
                      > at CSOonline.com) . Among the things that CIOs most desperately want to
                      > know -- really, they say this -- is what their development staff
                      > thinks, but doesn't SAY. At least, the DBA or developer won't say it
                      > directly to the CIO or other top management. So I'm starting a series
                      > of articles about "what CIOs really need to know about..." which will
                      > cover various topics. The first one is about software requirements.
                      >
                      > My question to you is a very simple one: ***If you could get your CIO
                      > to understand one thing, just ONE THING about software requirements,
                      > what would it be?***
                      >
                      > And then, the obvious follow-up: why did you pick *that*? War stories
                      > to illustrate your point would be great.
                      >
                      > You can touch on anything to do with the software requirements
                      > process; I'm game for whatever you give me.
                      >
                      > Ideally I would quote you by name and company and location ("Esther
                      > Schindler is a senior developer at the Groovy Corporation in
                      > Scottsdale Arizona") but as long as you give me some kind of context
                      > I'm willing to work without one. That is, I do need some identifying
                      > characteristics to give the article credibility ("Esther works at a
                      > large finance company in the Southwest") but I don't want you to lose
                      > your job when the CIO realizes that the developer quoted works for
                      > *her*! <grin> So please be sure to let me know how to refer to you in
                      > the article.
                      >
                      > I'll be sure to stop by here (as I expect others want to participate
                      > in the conversation) , but it'd be great if you could send me a private
                      > message. I don't want to miss any responses. Reply privately if that's
                      > easier, too.
                      >
                      > I plan to work on this during the holiday and to collect responses
                      > over the next week or so. I'm hoping to publish the article on CIO.com
                      > by mid-January at the latest.
                      >
                      > So: what clue would you like your CIO to get? about software
                      > requirements, that is?
                      >
                      > Esther Schindler
                      > senior online editor
                      > CXO Media
                      >

                      [Non-text portions of this message have been removed]





                      __________________________________________________________
                      Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de

                      [Non-text portions of this message have been removed]





                      [Non-text portions of this message have been removed]
                    • Phlip
                      ... Ebonics, actually, via the Southern Gullah Dialect. Heppi tu oblyj. ... Express them as tests. Period. Just get that thru the thick skull, and everything
                      Message 10 of 22 , Dec 19, 2006
                        Victor wrote:

                        > Mah Pleshah, Joseph, (My Pleasure, in some kind of USA accent :-)

                        Ebonics, actually, via the Southern Gullah Dialect. Heppi tu'oblyj.

                        > > What do you wish your CIO understood about requirements?

                        Express them as tests. Period. Just get that thru the thick skull, and
                        everything else sho' goes easy.

                        --
                        Phlip
                        http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
                      • estherschindler
                        ... I haven t read the essay at your link, yet, but I shall. I don t want to tell the CIO to Don t Do This unless I counter it with Instead, do THIS. What
                        Message 11 of 22 , Dec 20, 2006
                          --- In extremeprogramming@yahoogroups.com, "Scott Ambler"
                          <scottwambler@...> wrote:
                          > If I was to pick one issue, it would be the naive desire of getting
                          > a "solid" estimate up front early in the project. That one decision
                          > motivates a whole bunch of really bad practices, such as big
                          > requirements up front (BRUF), big design up front (BDUF), judging the
                          > project team on whether they meet the budget INSTEAD of whether they
                          > acheived great ROI, ...

                          I haven't read the essay at your link, yet, but I shall.

                          I don't want to tell the CIO to "Don't Do This" unless I counter it
                          with "Instead, do THIS." What would you tell a CIO whom you believed
                          was sincerely listening?
                        • estherschindler
                          ... Can you give me a specific instance? Examples will make this point come alive. ... Oh, cool! We did an awfully nice job on that, didn t we? I m still quite
                          Message 12 of 22 , Dec 20, 2006
                            --- In extremeprogramming@yahoogroups.com, Brad Smith <bgsmith@...> wrote:
                            > My one item would be that in order to make sure that requirements are
                            > effective and properly implemented it is imperative to support the
                            > user's representative on the team. All too often, as Scott Ambler might
                            > say, the team does the big up front design, including requirements
                            > gathering, and then goes off to do the work in isolation delivering a
                            > product that may meet requirements at one level but fail completely to
                            > meet them in a way the user needs and expects.

                            Can you give me a specific instance? Examples will make this point
                            come alive.

                            > By the way, I just found a copy of Extended Attributes on a bookshelf in
                            > my office, May 1999 issue. :)

                            Oh, cool! We did an awfully nice job on that, didn't we? I'm still
                            quite proud of it.

                            How shall I refer to you in the article? (Asked of Brad, but please
                            folks, take pity on me and tell me...)

                            Esther
                          • estherschindler
                            ... That is beautifully said. Er, how shall I refer to you in the article? (I m sure I m beginning to sound plaintive on this point.) ... Oooh, that s a
                            Message 13 of 22 , Dec 20, 2006
                              --- In extremeprogramming@yahoogroups.com, "dnicolet99" <dnicolet@...>
                              wrote:
                              > If I had to think of just one thing for CIOs to know about
                              > requirements, it would be that change is the norm rather than the
                              > exception. We need to turn away from the traditional approach of
                              > trying to nail down all the detailed requirements up front, and then
                              > imposing so-called "change control" processes designed not to control
                              > change, but to discourage it. Instead, CIOs should actively and firmly
                              > support methods that embrace change and deal with it gracefully, as
                              > agile and lean methods are meant to do.

                              That is beautifully said.

                              Er, how shall I refer to you in the article? (I'm sure I'm beginning
                              to sound plaintive on this point.)

                              > If it's okay to mention a second thing (even though you asked for just
                              > one, in all caps and emphasized with editorial asterisks), it would be
                              > for CIOs to understand the best value-add role for Business Analysts,
                              > and structure the IT organization accordingly.

                              Oooh, that's a fascinating idea. Wouldn't THAT send off sparks in some
                              quarters!

                              Esther
                            • dnicolet99
                              ... Thanks. ... My name is Dave Nicolette. ... To say the least!
                              Message 14 of 22 , Dec 20, 2006
                                --- In extremeprogramming@yahoogroups.com, "estherschindler"
                                <esther@...> wrote:
                                >
                                >
                                > That is beautifully said.

                                Thanks.
                                >
                                > Er, how shall I refer to you in the article? (I'm sure I'm beginning
                                > to sound plaintive on this point.)
                                >
                                My name is Dave Nicolette.

                                > > If it's okay to mention a second thing (even though you asked for just
                                > > one, in all caps and emphasized with editorial asterisks), it would be
                                > > for CIOs to understand the best value-add role for Business Analysts,
                                > > and structure the IT organization accordingly.
                                >
                                > Oooh, that's a fascinating idea. Wouldn't THAT send off sparks in some
                                > quarters!

                                To say the least!
                              • Jeff Grigg
                                ... To emphasize this point: I ve encountered a number of situations recently where the programmers knew more about the business policies than the business
                                Message 15 of 22 , Dec 26, 2006
                                  --- "dnicolet99" <dnicolet@...> wrote:
                                  > Circa 1970, when business people were ignorant of (and
                                  > uninterested in) information technology and programmers
                                  > were ignorant of (and uninterested in) business issues [...].
                                  > [Now,] business people are very comfortable with computers and
                                  > technical people are quite cognizant of business issues. [...]

                                  To emphasize this point:
                                  I've encountered a number of situations recently where the programmers
                                  knew more about the business policies than the business people! This
                                  might seem odd, except that when business policies are automated, one
                                  can quickly get to the point where the current system is the expert on
                                  the business policies, as it implements them, and the business
                                  managers forget or are subject to turnover.
                                • Jeff Grigg
                                  ... OK; I think you need a good sound bite. I d be glad to give you this one: There s no such thing as requirements. For example, if the system itself is
                                  Message 16 of 22 , Dec 26, 2006
                                    --- "estherschindler" <esther@...> wrote:
                                    > ***If you could get your CIO to understand one thing, just
                                    > ONE THING about software requirements, what would it be?***

                                    OK; I think you need a good sound bite.
                                    I'd be glad to give you this one:
                                    "There's no such thing as requirements.
                                    For example, if the system itself is optional, than all
                                    of its 'requirements' must be optional too, right?"

                                    Back in the day, when computers couldn't do much, then the concept of
                                    system requirements made a lot of sense: Unless new the system could
                                    track inventory and pay employees, then there was no point in building
                                    it. But today, most software projects I see are trying to improve or
                                    optimize existing process. Usually, the sponsoring corporation won't
                                    go out of business, in the short term, if we don't build this system,
                                    to help optimize the supply chain.

                                    So most software development projects I see are a question of
                                    opportunity: If we do this, then we can improve our operations this much.

                                    Therefore, we need to get our minds off of the idea that there is some
                                    list of hundreds or thousands of "requirements" that we can go out to
                                    the business and "gather." Instead, we have lots of ideas and
                                    opportunities. And as we *incrementally* take advantage of these
                                    opportunities, we can improve the business.

                                    So we have opportunities, not "requirements." We can gain a lot by
                                    doing some of them now, and delaying others.

                                    -- Jeff Grigg, Consultant, Saint Louis, MO
                                  • Victor
                                    ... can quickly get to the point where the current system is the expert on the business policies, as it implements them, and the business managers forget or
                                    Message 17 of 22 , Dec 26, 2006
                                      > ... when business policies are automated, one
                                      can quickly get to the point where the current system is the expert on
                                      the business policies, as it implements them, and the business
                                      managers forget or are subject to turnover.

                                      Tough as it sounds, it's really scary when this happens in critical environments, like medicine, banking, and security.

                                      Therefore, it is incumbent to those organizations to keep a well organized and easily accessible independent source of knowledge (people and documentation) for those times when there is a need to review policies and protocols. Currently, it doesn't always happen.

                                      Also, for the automated processes it's important to have the capability of not just spit decisions but also the justifications for such decisions.

                                      Victor

                                      =============================

                                      ----- Original Message -----
                                      From: Jeff Grigg
                                      To: extremeprogramming@yahoogroups.com
                                      Sent: Tuesday, December 26, 2006 4:24 PM
                                      Subject: [XP] Re: For an article: What do you wish your CIO understood about requirements?


                                      --- "dnicolet99" <dnicolet@...> wrote:
                                      > Circa 1970, when business people were ignorant of (and
                                      > uninterested in) information technology and programmers
                                      > were ignorant of (and uninterested in) business issues [...].
                                      > [Now,] business people are very comfortable with computers and
                                      > technical people are quite cognizant of business issues. [...]

                                      To emphasize this point:
                                      I've encountered a number of situations recently where the programmers
                                      knew more about the business policies than the business people! This
                                      might seem odd, except that when business policies are automated, one
                                      can quickly get to the point where the current system is the expert on
                                      the business policies, as it implements them, and the business
                                      managers forget or are subject to turnover.





                                      [Non-text portions of this message have been removed]
                                    • estherschindler
                                      ... It s not so much that I want sound bytes, per se. It s that to organize the responses from dozens of developers and testers (I ve asked this question on a
                                      Message 18 of 22 , Dec 28, 2006
                                        --- In extremeprogramming@yahoogroups.com, "Jeff Grigg"
                                        <jeffgrigg@...> wrote:
                                        >
                                        > --- "estherschindler" <esther@> wrote:
                                        > > ***If you could get your CIO to understand one thing, just
                                        > > ONE THING about software requirements, what would it be?***
                                        >
                                        > OK; I think you need a good sound bite.
                                        > I'd be glad to give you this one:
                                        > "There's no such thing as requirements.
                                        > For example, if the system itself is optional, than all
                                        > of its 'requirements' must be optional too, right?"

                                        It's not so much that I want sound bytes, per se. It's that to
                                        organize the responses from dozens of developers and testers (I've
                                        asked this question on a few discussion lists), it helps to be able to
                                        summarize the responses. And then to back up the "this is one thing
                                        developers feel you should know" with pithy examples and opinions from
                                        real people.

                                        For example, one of the interesting results of this process is to
                                        learn how much developers' opinions diverge on the granularity of
                                        requirements. I'm not very surprised that agile/XP developers feel
                                        that the process should evolve, and that the requirements should get
                                        more focused with every iteration. But curiously (or, now that I think
                                        of it, not so curiously), some programmers want the specs in
                                        excruciating detail (system MUST do this, MAY do that), and others
                                        want a general set of the app's goals and want to be left alone to
                                        figure out how it should work.

                                        Since what I'm trying to do is give the best-intentioned CIO some
                                        pragmatic "here's what you can do to improve the process" suggestions,
                                        I find that I have to back up and say, "Establish or learn what level
                                        of granularity the developers are most comfortable working with."

                                        Esther
                                      • Larry Brunelle
                                        ... Hmmmmmm. You know, I have had it given me both ways. I suspect the preference may be somewhat situational. I think that if you re in a situation where
                                        Message 19 of 22 , Dec 28, 2006
                                          estherschindler wrote:
                                          > --- In extremeprogramming@yahoogroups.com, "Jeff Grigg"
                                          > <jeffgrigg@...> wrote:
                                          >
                                          >>--- "estherschindler" <esther@> wrote:
                                          >>
                                          >>>***If you could get your CIO to understand one thing, just
                                          >>>ONE THING about software requirements, what would it be?***
                                          >>
                                          >>OK; I think you need a good sound bite.
                                          >>I'd be glad to give you this one:
                                          >> "There's no such thing as requirements.
                                          >> For example, if the system itself is optional, than all
                                          >> of its 'requirements' must be optional too, right?"
                                          >
                                          >
                                          > It's not so much that I want sound bytes, per se. It's that to
                                          > organize the responses from dozens of developers and testers (I've
                                          > asked this question on a few discussion lists), it helps to be able to
                                          > summarize the responses. And then to back up the "this is one thing
                                          > developers feel you should know" with pithy examples and opinions from
                                          > real people.
                                          >
                                          > For example, one of the interesting results of this process is to
                                          > learn how much developers' opinions diverge on the granularity of
                                          > requirements. I'm not very surprised that agile/XP developers feel
                                          > that the process should evolve, and that the requirements should get
                                          > more focused with every iteration. But curiously (or, now that I think
                                          > of it, not so curiously), some programmers want the specs in
                                          > excruciating detail (system MUST do this, MAY do that), and others
                                          > want a general set of the app's goals and want to be left alone to
                                          > figure out how it should work.

                                          Hmmmmmm. You know, I have had it given me both ways. I suspect the
                                          preference may be somewhat situational. I think that if you're in a
                                          situation where there is a high level of trust, a loose expression of
                                          requirements allows the team (including the customer or nearest
                                          surrogate) to zero in on the REAL requirements through some amount of
                                          iteration. I think the need for "excruciating detail" is more
                                          characteristic of an environment (or developers who came from one)
                                          where someone was always going to carp and the best CYA was to show
                                          that the code did what the requirements said - even if the best
                                          commercial value would have been otherwise. To do that, the
                                          requirements must be explicitly definitive.

                                          I suggest (just as I would to legislators if I was asked - don't hold
                                          your breath for THAT) that requirements often (and laws as well) should
                                          begin with some kind of preamble giving intention. Sometimes, two
                                          different implementations might completely satisfy the raw requirements,
                                          but one might be ever so much more idiomatic to the underlying business
                                          motivation and thus more maintainable and extensible.

                                          > Since what I'm trying to do is give the best-intentioned CIO some
                                          > pragmatic "here's what you can do to improve the process" suggestions,
                                          > I find that I have to back up and say, "Establish or learn what level
                                          > of granularity the developers are most comfortable working with."
                                          >
                                          > Esther
                                        • Brad Appleton
                                          ... Yes - I run into this a lot too. However, even when they get what they think they want, I ve never seen it solve the problem they were hoping it would
                                          Message 20 of 22 , Dec 29, 2006
                                            estherschindler wrote:
                                            > of it, not so curiously), some programmers want the specs in
                                            > excruciating detail (system MUST do this, MAY do that),

                                            Yes - I run into this a lot too. However, even when they get what they
                                            think they want, I've never seen it solve the problem they were hoping
                                            it would solve (namely that requirements change).

                                            Often, the more their "estimates" are going to be regarded as
                                            "promises", the more detail they want in the requirements. (But that
                                            doesnt solve the problem. In fact it often makes matters worse)

                                            > and others want a general set of the app's goals and want to be left alone to
                                            > figure out how it should work.

                                            This often has to do with a feeling of freedom/empowerment. Some want
                                            details to be given to them so they wont/cant be blamed for the
                                            decisions that led to those details. Others want to know merely the few
                                            true/hard and binding constraints - everything else is freedom within
                                            those constraints, and is often more interesting/challenging.

                                            Im curious as to whether those wanting more freedom to be "left alone to
                                            figure out how it should work" are under less pressure to make
                                            initial/early estimates be accurate, or if they are the ones who get to
                                            flesh out the details first before they give any estimate?

                                            > Since what I'm trying to do is give the best-intentioned CIO some
                                            > pragmatic "here's what you can do to improve the process" suggestions,
                                            > I find that I have to back up and say, "Establish or learn what level
                                            > of granularity the developers are most comfortable working with."

                                            Before I made that "leap", I'd want to know how many of those folks have
                                            ever experienced the thing they are asking for, and if it ended up
                                            solving the problem they had thought it would solve. Im particularly
                                            interested in the answer to this from those that wanted more detailed
                                            requirements, and if it did "solve" the problem, did it result in a
                                            successfully delivered system, or did it merely allow them to shift "the
                                            blame" elsewhere.

                                            --
                                            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
                                          • estherschindler
                                            ... left alone to ... Oh, sure -- on both counts. Judging from the nature of the replies, my personal observation is that the developers who want fewer
                                            Message 21 of 22 , Jan 3, 2007
                                              --- In extremeprogramming@yahoogroups.com, Brad Appleton
                                              <Brad.Appleton@...> wrote:
                                              > > and others want a general set of the app's goals and want to be
                                              left alone to
                                              > > figure out how it should work.
                                              >
                                              > This often has to do with a feeling of freedom/empowerment. Some want
                                              > details to be given to them so they wont/cant be blamed for the
                                              > decisions that led to those details. Others want to know merely the few
                                              > true/hard and binding constraints - everything else is freedom within
                                              > those constraints, and is often more interesting/challenging.

                                              Oh, sure -- on both counts.

                                              Judging from the nature of the replies, my personal observation is
                                              that the developers who want fewer requirements typically work on
                                              smaller projects where the definition is not complex, and/or the
                                              development team is small (very possibly a solo consultant). Or it's a
                                              creative endeavor, such as web site design... the squishier UI side of
                                              things more than cranking out database connectivity code.

                                              I understand the "I want everything documented" side, too. I know one
                                              programmer locally who works for a big financial firm; he's been a
                                              contractor on that position for six months or so. George is livid
                                              because the management never did send out any form of software
                                              requirements, and the result is that everybody is making it up as they
                                              go along. You _know_ that it's being designed for the programmer's
                                              easy path rather than the user's need, because they have no idea what
                                              the user needs. And, rather than adopt a CYA attitude, the developers
                                              are really upset about it... just feeling helpless.

                                              > Im curious as to whether those wanting more freedom to be "left
                                              alone to
                                              > figure out how it should work" are under less pressure to make
                                              > initial/early estimates be accurate, or if they are the ones who get to
                                              > flesh out the details first before they give any estimate?

                                              I've no idea. I'm asking in public forums just like this one, and they
                                              tell me only what they tell me. <chuckle>

                                              Esther
                                            • Victor
                                              Hi Esther, One thing that seems to be left out of your comments is the concept of communication between developers and customers. Remember, this is an XP
                                              Message 22 of 22 , Jan 3, 2007
                                                Hi Esther,

                                                One thing that seems to be left out of your comments is the concept of communication between developers and customers. Remember, this is an XP group and it's useful to read and understand the corresponding literature.

                                                Within the XP environment, customers and developers are co-located, The customer or her representative is always available to answer questions from the developers, or bring their own insight. The issue is not so much to be lax on the requirements, but let the requirements develop in their exacting detail as part of the development process, rather than totally upfront, before any development has occurred and any new insight about the real needs had had the opportunity to evolve.

                                                This is important because of the reality that in most cases it's impossible to envision the totality of the application's requirements upfront. It could be argued that how come that bridges and huge, complex buildings can be designed upfront and software can't. If you observe at many of these bridges and buildings, you may see design problems. However, because it's so expensive to redesign once the construction is finished, people just live with those imperfections and many times gloss over them. They are not mentioned unless something collapses.

                                                This is one of the advantages of the software being soft, that by maintaining its malleability throughout the development process, improvements and corrections can be done on the fly at very low cost. The responsibility of maintaining the software malleability falls on the shoulders of the XP team.

                                                If you have more questions, please keep shooting.

                                                Victor Goldberg, Ph.D.

                                                ==============================================

                                                ----- Original Message -----
                                                From: estherschindler
                                                To: extremeprogramming@yahoogroups.com
                                                Sent: Wednesday, January 03, 2007 7:40 PM
                                                Subject: [XP] Re: For an article: What do you wish your CIO understood about requirements


                                                --- In extremeprogramming@yahoogroups.com, Brad Appleton
                                                <Brad.Appleton@...> wrote:
                                                > > and others want a general set of the app's goals and want to be
                                                left alone to
                                                > > figure out how it should work.
                                                >
                                                > This often has to do with a feeling of freedom/empowerment. Some want
                                                > details to be given to them so they wont/cant be blamed for the
                                                > decisions that led to those details. Others want to know merely the few
                                                > true/hard and binding constraints - everything else is freedom within
                                                > those constraints, and is often more interesting/challenging.

                                                Oh, sure -- on both counts.

                                                Judging from the nature of the replies, my personal observation is
                                                that the developers who want fewer requirements typically work on
                                                smaller projects where the definition is not complex, and/or the
                                                development team is small (very possibly a solo consultant). Or it's a
                                                creative endeavor, such as web site design... the squishier UI side of
                                                things more than cranking out database connectivity code.

                                                I understand the "I want everything documented" side, too. I know one
                                                programmer locally who works for a big financial firm; he's been a
                                                contractor on that position for six months or so. George is livid
                                                because the management never did send out any form of software
                                                requirements, and the result is that everybody is making it up as they
                                                go along. You _know_ that it's being designed for the programmer's
                                                easy path rather than the user's need, because they have no idea what
                                                the user needs. And, rather than adopt a CYA attitude, the developers
                                                are really upset about it... just feeling helpless.

                                                > Im curious as to whether those wanting more freedom to be "left
                                                alone to
                                                > figure out how it should work" are under less pressure to make
                                                > initial/early estimates be accurate, or if they are the ones who get to
                                                > flesh out the details first before they give any estimate?

                                                I've no idea. I'm asking in public forums just like this one, and they
                                                tell me only what they tell me. <chuckle>

                                                Esther





                                                [Non-text portions of this message have been removed]
                                              Your message has been successfully submitted and would be delivered to recipients shortly.