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

Resistance

Expand Messages
  • mpkirby@frontiernet.net
    I m interested in what other people have found to be the big resistance items are for scrum. Here s my current list: Senior developers feel that there is
    Message 1 of 30 , Dec 11, 2005
    • 0 Attachment
      I'm interested in what other people have found to be the big resistance items are for scrum.
      Here's my current list:

      Senior developers feel that there is "nothing in it for them". They don't need help
      from others, and generally don't feel like providing help to others

      Senior management's comment to me was "I don't like a management process that
      requires a daily meeting. It feels very inflexible. Some of your team members may
      require daily guidance, but others will not and will resent that you are putting them in
      that category. You should manage the ones that need daily guidance differently
      from those that are independendent."

      Developer's comment "This is nothing more than an attempt by management to
      delegate their responsibilities to people in the group so they can do whatever they
      feel like"

      Daily Standup: "What's the point. I know where the experts are. If I get in trouble,
      I'll go ask for help directly. I don't need a daily meeting to do that."

      Any other choice comments or quotes? And of course, there's the follow up question on
      how you deal with that resistance.

      Mike

      ---
      mpkirby@...
    • news.gmane.org
      Hi Mike Its all about that phrase whats in it for me? . ... We all get into software development for a reason. For many of us, it was because software
      Message 2 of 30 , Dec 11, 2005
      • 0 Attachment
        Hi Mike

        Its all about that phrase "whats in it for me?".

        mpkirby@... wrote:
        > I'm interested in what other people have found to be the big resistance items are for scrum.
        > Here's my current list:
        >
        > Senior developers feel that there is "nothing in it for them". They don't need help
        > from others, and generally don't feel like providing help to others

        We all get into software development for a reason. For many of us, it
        was because software development was a mental challenge, like doing
        cross word puzzles or sudoka. And what we got from it was the mental
        satisfaction of solving a difficult problem. With that frame of
        reference, introducing techniques and practices that improve my ability
        to do crossword puzzels will not help me enjoy doing crossword puzzles
        more. You have to change the frame of reference. If you can win money
        from completing crossword puzzles faster than anyone else, then suddenly
        I have another way of getting a different reward out of doing crossword
        puzzles, and productivity becomes important to me.

        > Senior management's comment to me was "I don't like a management process that
        > requires a daily meeting. It feels very inflexible. Some of your team members may
        > require daily guidance, but others will not and will resent that you are putting them in
        > that category. You should manage the ones that need daily guidance differently
        > from those that are independendent."

        I don't understand what motivates senior managers, so I can't comment here
        >
        > Developer's comment "This is nothing more than an attempt by management to
        > delegate their responsibilities to people in the group so they can do whatever they
        > feel like"
        >
        > Daily Standup: "What's the point. I know where the experts are. If I get in trouble,
        > I'll go ask for help directly. I don't need a daily meeting to do that."
        >
        > Any other choice comments or quotes? And of course, there's the follow up question on
        > how you deal with that resistance.
        > Mike

        Not so much solutions, but I hope you get what you want

        Daniel
      • Lasse Durucz
        ... resistance items are for scrum. ... They don t need help ... process that ... your team members may ... you are putting them in ... guidance differently
        Message 3 of 30 , Dec 11, 2005
        • 0 Attachment
          --- In scrumdevelopment@yahoogroups.com, mpkirby@f... wrote:
          >
          > I'm interested in what other people have found to be the big
          resistance items are for scrum.
          > Here's my current list:
          >
          > Senior developers feel that there is "nothing in it for them".
          They don't need help
          > from others, and generally don't feel like providing help to others
          >
          > Senior management's comment to me was "I don't like a management
          process that
          > requires a daily meeting. It feels very inflexible. Some of
          your team members may
          > require daily guidance, but others will not and will resent that
          you are putting them in
          > that category. You should manage the ones that need daily
          guidance differently
          > from those that are independendent."
          >
          > Developer's comment "This is nothing more than an attempt by
          management to
          > delegate their responsibilities to people in the group so they
          can do whatever they
          > feel like"
          >
          > Daily Standup: "What's the point. I know where the experts are.
          If I get in trouble,
          > I'll go ask for help directly. I don't need a daily meeting to
          do that."
          >
          > Any other choice comments or quotes? And of course, there's the
          follow up question on
          > how you deal with that resistance.
          >
          > Mike
          >
          > ---
          > mpkirby@f...
          >

          Here is another one (from the project managers now converging into
          Product owners / Customer proxy):

          "So the only thing you take responsibility for now (as scrum master)is
          to solve as many problems (stories) as possible within a fix timeframe
          ? What we want is someone who can turn our specs into flawless
          software, and someone we can nail to the wall otherwise".

          and another one ..

          "We need our old specs. Without them we loose track and the details
          disappear into blurry stories that we don't want to take
          responsibility for"
        • Platty
          __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
          Message 4 of 30 , Dec 11, 2005
          • 0 Attachment
            __________________________________________________
            Do You Yahoo!?
            Tired of spam? Yahoo! Mail has the best spam protection around
            http://mail.yahoo.com
          • mpkirby@frontiernet.net
            ... Hmm. While the desire for the old specs I can see as a form of resistance, their fear over loss of detail and blurry stories is probabaly a reasonable
            Message 5 of 30 , Dec 11, 2005
            • 0 Attachment
              On 11 Dec 2005 at 19:45, Lasse Durucz wrote:

              > "We need our old specs. Without them we loose track and the details
              > disappear into blurry stories that we don't want to take
              > responsibility for"

              Hmm. While the desire for the "old specs" I can see as a form of resistance, their fear over
              loss of detail and "blurry stories" is probabaly a reasonable fear.

              Perhaps that's another theme. What is everyone afraid of? What's the basic fear? Is there
              fear of responsibility? Of loosing control? Of trusing someone? OF someone else trusting
              you? Or perhaps just plain old change?


              Mike

              ---
              mpkirby@...
            • Paul Webb
              ... don t need help ... I think to a great extent agile processes are often resisted by people who have got by ok using the old-ways. The why change?
              Message 6 of 30 , Dec 11, 2005
              • 0 Attachment
                >> Senior developers feel that there is "nothing in it for them".  They
                don't need help
                >> from others, and generally don't feel like providing help to others

                I think to a great extent agile processes are often resisted by people who
                have got by ok using the old-ways. The "why change?" mentality creeps in.
                It's also an unfortunate fact that many, (but not all), developers have
                limited social skills, and don't want to ask for or provide help. While this
                is a pretty dumb attitude, (that should not generally be associated with
                anyone who calls themselves 'senior'), it is one of those realities the
                process is just going to have to battle through and try to change. Maybe
                this developer should be involved much more closely with the process itself?
                Tickle their egos! :)

                In regards to the second and last paragraphs (on daily Scrums), Scrums are
                not about daily guidance nor are they the appropriate time to be asking
                experts for help (imho). They are about providing daily visibility, feedback
                and communication of issues which can then be addressed in more appropriate
                forums if needed. The three questions for the scrum are pretty clear in
                intent. What did you do yesterday? What are you doing today? Is there
                anything blocking you? It sounds like the intent of the daily Scrum meeting
                has not been effectively communicated or has been lost along the way.
                Perhaps these managers are not asking the right questions? I always find it
                amusing when managers completely ignore the simple rules of daily scrums and
                then wonder why they achieve very little. :) (this happens alot)


                >> "This is nothing more than an attempt by management to
                >> delegate their responsibilities to people in the group so they can do
                whatever they feel like"

                I don't think this is the case at all. Like most agile PM practices, Scrum
                aligns the team and management roles as they should be. Teams should
                appreciate that Scrum gives them the freedom to self-organise. It is not a
                case of management pushing their work onto the team (although I am sure
                there will be some PM's who will do this). A flip-side of self organisation
                is accountability - the team is held accountable for the work they deliver -
                so they can't just do whatever they feel like. This is a concept bounded
                largely in trust and common sense professional values, and I don't think the
                statement above sounds 'trusting'. To me it sounds again like a
                miscommunication or misunderstanding of the process :)


                The number one reason why I find there is resistance, is because the process
                is poorly communicated such that people just "Don't get it". It might be
                that the process is only socialised within the 'PM' community and not to the
                dev team or to the other business stakeholders such as product managers etc.
                Agile is a cultural change as much as a process change and needs to be
                socialised into whole organisations (or at least to all people with any
                vague connection to the delivery of software). I really think that poor
                communication of Agile, (and the resistance it inevitably brings), is in a
                large part due to the fact that there seems to be many people out there
                'practicing Agile' without actually taking the time to understand or follow
                it properly. (An unfortunate by-product of this is that there are now so
                many people who now think that agile is about no design or documentation and
                cowboy development. You only need to work around such an environment to
                overhear people saying 'We're agile - we don't do documentation', to
                understand where some of the resistance and fear comes from.)

                I think it is important in the context of this discussion topic that we
                understand that half the battle is ensuring that everyone in the
                organisation understands the processes and practices, why they work, and the
                benefits that agile delivers over waterfall. Otherwise the only option
                people have is to resist (which is a natural urge). We also need to address
                the fact that people's egos often get bruised in a change to agile, so they
                will naturally react in a defensive, resistant manner. I myself was very
                resistant to Agile when I first started using it. I had most of the same
                questions as were in the email below. Fortunately, the people who were
                advocating it did so in such a way whereby the benefits became very clear.
                We also followed the processes as stated; only making changes where the
                fundamental rules and ideas would not be affected. When I found out how
                much better things were with Agile, I dropped all my defences and adopted it
                100%.

                Sorry for the huge post. Hope it helps :)


                Paul Webb
                Senior .NET Developer / Consultant
                BBIS MCAD
                Agile Alliance Member, Certified Scrum Master
                +61 (0)414 598 809

                ________________________________________
                From: scrumdevelopment@yahoogroups.com
                [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of
                mpkirby@...
                Sent: Monday, 12 December 2005 2:58 AM
                To: scrumdevelopment@yahoogroups.com
                Subject: [scrumdevelopment] Resistance

                I'm interested in what other people have found to be the big resistance
                items are for scrum. 
                Here's my current list:

                    Senior developers feel that there is "nothing in it for them".  They
                don't need help
                    from others, and generally don't feel like providing help to others

                    Senior management's comment to me was "I don't like a management process
                that
                    requires a daily meeting.  It feels very inflexible.  Some of your team
                members may
                    require daily guidance, but others will not and will resent that you are
                putting them in
                    that category.  You should manage the ones that need daily guidance
                differently
                    from those that are independendent."

                    Developer's comment "This is nothing more than an attempt by management
                to
                    delegate their responsibilities to people in the group so they can do
                whatever they
                    feel like"

                    Daily Standup: "What's the point.  I know where the experts are.  If  I
                get in trouble,
                    I'll go ask for help directly.  I don't need a daily meeting to do
                that."

                Any other choice comments or quotes?  And of course, there's the follow up
                question on
                how you deal with that resistance.

                Mike

                ---
                mpkirby@...



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


                ________________________________________
                YAHOO! GROUPS LINKS

                •  Visit your group "scrumdevelopment" on the web.
                 
                •  To unsubscribe from this group, send an email to:
                 scrumdevelopment-unsubscribe@yahoogroups.com
                 
                •  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

                ________________________________________
              • Ron Jeffries
                ... I d like to hear from people who actually personally know someone who thinks that s what Agile is. Ron Jeffries www.XProgramming.com The lyf so short, the
                Message 7 of 30 , Dec 12, 2005
                • 0 Attachment
                  On Monday, December 12, 2005, at 12:20:20 AM, Paul Webb wrote:

                  > (An unfortunate by-product of this is that there are now so
                  > many people who now think that agile is about no design or documentation and
                  > cowboy development. You only need to work around such an environment to
                  > overhear people saying 'We're agile - we don't do documentation', to
                  > understand where some of the resistance and fear comes from.)

                  I'd like to hear from people who actually personally know someone
                  who thinks that's what Agile is.

                  Ron Jeffries
                  www.XProgramming.com
                  The lyf so short, the craft so long to lerne. -- Geoffrey Chaucer
                • Mike Dwyer
                  Ron: Last week I was at dinner with a COO who is intrigued by Agile and Scrum not just as development method but beyond that. One of his key concerns was the
                  Message 8 of 30 , Dec 12, 2005
                  • 0 Attachment
                    Ron:
                    Last week I was at dinner with a COO who is intrigued by Agile and Scrum not
                    just as development method but beyond that. One of his key concerns was the
                    documentation. He knew little about the innards of development, nor the
                    complexities the Boolean world we live in. What he did know is the that 6
                    months after finishing the 'frombaz' module and the "watchmacallit" layer he
                    needed to approve a 5 man month project to investigate the interface layer
                    and the documentation wasn't up to date.

                    So the honest answer is that traditional documentation traces the genealogy
                    of the logic of something. It does everything to catalog the journey in
                    developing something and serves as a great artifact. It is useless because
                    it does not detail HOW it works when it went out the door.

                    This makes a strong argument for TDD and the accompanying information as to
                    what a thing does, what it needs to do the job, what it produces and how it
                    communicates when something is wrong.

                    Now he is intrigued by TDD.

                    Michael F. Dwyer

                    "Planning constantly peers into the future for indications as to where a
                    solution may emerge."
                    "A Plan is a complex situation, adapting to an emerging solution."

                    -----Original Message-----
                    From: scrumdevelopment@yahoogroups.com
                    [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ron Jeffries
                    Sent: Monday, December 12, 2005 5:24 AM
                    To: scrumdevelopment@yahoogroups.com
                    Subject: [scrumdevelopment] Agile = No Documentation?

                    On Monday, December 12, 2005, at 12:20:20 AM, Paul Webb wrote:

                    > (An unfortunate by-product of this is that there are now so
                    > many people who now think that agile is about no design or documentation
                    and
                    > cowboy development. You only need to work around such an environment to
                    > overhear people saying 'We're agile - we don't do documentation', to
                    > understand where some of the resistance and fear comes from.)

                    I'd like to hear from people who actually personally know someone
                    who thinks that's what Agile is.

                    Ron Jeffries
                    www.XProgramming.com
                    The lyf so short, the craft so long to lerne. -- Geoffrey Chaucer



                    To Post a message, send it to: scrumdevelopment@...
                    To Unsubscribe, send a blank message to:
                    scrumdevelopment-unsubscribe@...
                    Yahoo! Groups Links
                  • Paul Webb
                    Ron, Amazing as it is, I hear people saying things like that quite often! It gets me really riled up and I find myself having to get very irate and noisy
                    Message 9 of 30 , Dec 12, 2005
                    • 0 Attachment

                      Ron,

                       

                      Amazing as it is, I hear people saying things like that quite often!   It gets me really riled up and I find myself having to get very irate and noisy when I hear it!

                       

                      I find it’s usually young developers who have heard it from someone who is equally out of touch with what Agile really is. Unfortunately this trash can get communicated back to stakeholders who can’t be bothered checking for themselves or to other developers who pass it on ….. Until they find someone who will slap them back into reality, or end up making a complete and utter mess of things.

                       

                      Typically I find with these people that ideas such as “the simplest thing that could possibly work” gets interpreted as “quick and dirty”, and simple design gets interpreted as “no design” ( just a couple of examples). It’s typically lazy or misinformed developers trying to find excuses to do less work  and/or get involved in ‘trendy’ agile development (without spending the time or energy to understand it) J  (and by the way I have heard “several” IT recruiters refer to agile as ‘trendy’)

                       

                      I may have made the issue sound more widespread than it is, but I think it has impacted me because it is rather annoying to hear someone misrepresent something that you spend a lot of time trying to understand and get right, and it is definitely a factor in some of the resistance to agile that I have personally experienced.

                       

                      Cheers,

                      Paul

                       

                      Paul Webb

                      Senior .NET Developer / Consultant

                      BBIS MCAD

                      Agile Alliance Member, Certified Scrum Master

                      +61 (0)414 598 809

                       


                      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ron Jeffries
                      Sent: Monday, 12 December 2005 9:24 PM
                      To: scrumdevelopment@yahoogroups.com
                      Subject: [scrumdevelopment] Agile = No Documentation?

                       

                      On Monday, December 12, 2005, at 12:20:20 AM, Paul Webb wrote:

                      > (An unfortunate by-product of this is that there are now so
                      > many people who now think that agile is about no design or documentation and
                      > cowboy development. You only need to work around such an environment to
                      > overhear people saying 'We're agile - we don't do documentation', to
                      > understand where some of the resistance and fear comes from.)

                      I'd like to hear from people who actually personally know someone
                      who thinks that's what Agile is.

                      Ron Jeffries
                      www.XProgramming.com
                      The lyf so short, the craft so long to lerne.  -- Geoffrey Chaucer

                    • Ron Jeffries
                      ... Did he also do a five day project to investigate why the product owner didn t ask for documentation? ... Well, actually, if it were kept up to date like it
                      Message 10 of 30 , Dec 12, 2005
                      • 0 Attachment
                        On Monday, December 12, 2005, at 8:16:25 AM, Mike Dwyer wrote:

                        > Last week I was at dinner with a COO who is intrigued by Agile and Scrum not
                        > just as development method but beyond that. One of his key concerns was the
                        > documentation. He knew little about the innards of development, nor the
                        > complexities the Boolean world we live in. What he did know is the that 6
                        > months after finishing the 'frombaz' module and the "watchmacallit" layer he
                        > needed to approve a 5 man month project to investigate the interface layer
                        > and the documentation wasn't up to date.

                        Did he also do a five day project to investigate why the product
                        owner didn't ask for documentation?

                        > So the honest answer is that traditional documentation traces the genealogy
                        > of the logic of something. It does everything to catalog the journey in
                        > developing something and serves as a great artifact. It is useless because
                        > it does not detail HOW it works when it went out the door.

                        Well, actually, if it were kept up to date like it is clearly
                        supposed to be, traditional documentation /would/ detail how it
                        works when it goes out the door. I think in the trades this is
                        called "as built" documentation.

                        It is probably faster to get to market with a low level of
                        documentation done at the beginning of the project and with the
                        documentation the product actually needs done toward the end.

                        But if the product needs a feature, the product owner asks for it,
                        and the team does it. Documentation is a feature.

                        > This makes a strong argument for TDD and the accompanying information as to
                        > what a thing does, what it needs to do the job, what it produces and how it
                        > communicates when something is wrong.

                        At some detail level, this is true. At the level of "how does this
                        system work anyway", I'm not convinced that TDD is sufficient.

                        > Now he is intrigued by TDD.

                        That's nice. The product probably has bugs, too.

                        Ron Jeffries
                        www.XProgramming.com
                        Only the hand that erases can write the true thing. -- Meister Eckhart
                      • Ron Jeffries
                        ... Yes. It might be best to take them out of the gene pool. ... It s hard to know what to do about people who say things that are unfounded and untrue. ...
                        Message 11 of 30 , Dec 12, 2005
                        • 0 Attachment
                          On Monday, December 12, 2005, at 8:18:52 AM, Paul Webb wrote:

                          > Amazing as it is, I hear people saying things like that quite often! It
                          > gets me really riled up and I find myself having to get very irate and noisy
                          > when I hear it!

                          Yes. It might be best to take them out of the gene pool.

                          > I find it's usually young developers who have heard it from someone who is
                          > equally out of touch with what Agile really is. Unfortunately this trash can
                          > get communicated back to stakeholders who can't be bothered checking for
                          > themselves or to other developers who pass it on ... Until they find someone
                          > who will slap them back into reality, or end up making a complete and utter
                          > mess of things.

                          It's hard to know what to do about people who say things that are
                          unfounded and untrue.

                          > Typically I find with these people that ideas such as "the simplest thing
                          > that could possibly work" gets interpreted as "quick and dirty", and simple
                          > design gets interpreted as "no design" ( just a couple of examples). It's
                          > typically lazy or misinformed developers trying to find excuses to do less
                          > work and/or get involved in 'trendy' agile development (without spending
                          > the time or energy to understand it) :-) (and by the way I have heard
                          > "several" IT recruiters refer to agile as 'trendy')

                          Very distressing ...

                          > I may have made the issue sound more widespread than it is, but I think it
                          > has impacted me because it is rather annoying to hear someone misrepresent
                          > something that you spend a lot of time trying to understand and get right,
                          > and it is definitely a factor in some of the resistance to agile that I have
                          > personally experienced.

                          Yes ... that's why I'm interested in concrete stories about these
                          things when the occur.

                          Ron Jeffries
                          www.XProgramming.com
                          2 + 2 = 5, for sufficiently large values of 2.
                        • jerrad anderson
                          When I first was learning about agile, my boss informed me that we couldn t use XP cause it meant no documentation I ofcourse didn t know any better at the
                          Message 12 of 30 , Dec 12, 2005
                          • 0 Attachment
                            When I first was learning about agile, my boss informed me that we couldn't use XP cause it meant "no documentation" I ofcourse didn't know any better at the time and dropped it. It's an easy misnomer. My current scrum team turns out reams of usefull documentation.
                             
                            Jerrad

                             
                            On 12/12/05, Ron Jeffries <ronjeffries@...> wrote:
                            On Monday, December 12, 2005, at 12:20:20 AM, Paul Webb wrote:

                            > (An unfortunate by-product of this is that there are now so
                            > many people who now think that agile is about no design or documentation and
                            > cowboy development. You only need to work around such an environment to
                            > overhear people saying 'We're agile - we don't do documentation', to
                            > understand where some of the resistance and fear comes from.)

                            I'd like to hear from people who actually personally know someone
                            who thinks that's what Agile is.

                            Ron Jeffries
                            www.XProgramming.com
                            The lyf so short, the craft so long to lerne.  -- Geoffrey Chaucer


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




                            YAHOO! GROUPS LINKS




                          • Mike Dwyer
                            The cost effective argument is yes all product have bugs, many of whom (ideally)we don t know about. How can I resolve issues customers have that does not
                            Message 13 of 30 , Dec 12, 2005
                            • 0 Attachment
                              The cost effective argument is yes all product have bugs, many of whom
                              (ideally)we don't know about.

                              How can I resolve issues customers have that does not require going back and
                              doing the same stuff we did a short time ago.

                              What can I tell product owners is a Must Have from a CxO level?


                              Maintenance programming, unlike development, is the art of getting it to
                              work the way it is expected to, as opposed to how it was envisioned to
                              operate.

                              Step 1. in the dark art of maintenance programming is to determine if in
                              fact it is a problem that was overlooked in development or if it is a
                              problem perceived by the user that was not considered in development.

                              Source for step 1. Documentation. Given the choice between really great
                              mulit-volume genealogical treatises, and a complete test document, I choose
                              the test document as it shows me what was tested and approved to go out the
                              door.
                              Triage tree.
                              Is there a test to validate or check what the customer asked for?
                              Does the code work as tested?
                              Does the user have the corresponding version of the code?

                              Next Steps
                              Now I can determine where to begin, stop and how much work I have to do.

                              Rant
                              As to the idea of a perfect product, I am happy to send all another copy of
                              "the Last Bug", And once again launch into a soapbox derby as to the value
                              of it. But that is a waste of bits.

                              comment
                              I state for all, that I too agree with Ron on the need for bug free
                              products.

                              and asides
                              In fact if you read between the lines you will note that one of the triage
                              questions asks if there is a test for this problem.

                              Hmm. If there is, and this is the right version of the code then who let
                              this out?
                              If there is not, and the product owner thinks this is important, create a
                              test that defines the boundaries (and the error handling), make an
                              enhancement that fits inside the space and validate it works.

                              If you the product owner need time to figure it out, OK. Take the issue off
                              my plate, put it on yours and report out on it so I know what my backlog
                              looks like.

                              Michael F. Dwyer

                              "Planning constantly peers into the future for indications as to where a
                              solution may emerge."
                              "A Plan is a complex situation, adapting to an emerging solution."

                              -----Original Message-----
                              From: scrumdevelopment@yahoogroups.com
                              [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ron Jeffries
                              Sent: Monday, December 12, 2005 8:49 AM
                              To: scrumdevelopment@yahoogroups.com
                              Subject: Re: [scrumdevelopment] Agile = No Documentation?

                              On Monday, December 12, 2005, at 8:16:25 AM, Mike Dwyer wrote:

                              > Last week I was at dinner with a COO who is intrigued by Agile and Scrum
                              not
                              > just as development method but beyond that. One of his key concerns was
                              the
                              > documentation. He knew little about the innards of development, nor the
                              > complexities the Boolean world we live in. What he did know is the that
                              6
                              > months after finishing the 'frombaz' module and the "watchmacallit" layer
                              he
                              > needed to approve a 5 man month project to investigate the interface layer
                              > and the documentation wasn't up to date.

                              Did he also do a five day project to investigate why the product
                              owner didn't ask for documentation?

                              > So the honest answer is that traditional documentation traces the
                              genealogy
                              > of the logic of something. It does everything to catalog the journey in
                              > developing something and serves as a great artifact. It is useless
                              because
                              > it does not detail HOW it works when it went out the door.

                              Well, actually, if it were kept up to date like it is clearly
                              supposed to be, traditional documentation /would/ detail how it
                              works when it goes out the door. I think in the trades this is
                              called "as built" documentation.

                              It is probably faster to get to market with a low level of
                              documentation done at the beginning of the project and with the
                              documentation the product actually needs done toward the end.

                              But if the product needs a feature, the product owner asks for it,
                              and the team does it. Documentation is a feature.

                              > This makes a strong argument for TDD and the accompanying information as
                              to
                              > what a thing does, what it needs to do the job, what it produces and how
                              it
                              > communicates when something is wrong.

                              At some detail level, this is true. At the level of "how does this
                              system work anyway", I'm not convinced that TDD is sufficient.

                              > Now he is intrigued by TDD.

                              That's nice. The product probably has bugs, too.

                              Ron Jeffries
                              www.XProgramming.com
                              Only the hand that erases can write the true thing. -- Meister Eckhart



                              To Post a message, send it to: scrumdevelopment@...
                              To Unsubscribe, send a blank message to:
                              scrumdevelopment-unsubscribe@...
                              Yahoo! Groups Links
                            • Jim Hyslop
                              ... Hash: SHA1 ... I must be missing something, because it seems to me you just contradicted yourself: in the first paragraph you seem to suggest that as-built
                              Message 14 of 30 , Dec 12, 2005
                              • 0 Attachment
                                -----BEGIN PGP SIGNED MESSAGE-----
                                Hash: SHA1

                                Ron Jeffries wrote:
                                > Well, actually, if it were kept up to date like it is clearly
                                > supposed to be, traditional documentation /would/ detail how it
                                > works when it goes out the door. I think in the trades this is
                                > called "as built" documentation.
                                >
                                > It is probably faster to get to market with a low level of
                                > documentation done at the beginning of the project and with the
                                > documentation the product actually needs done toward the end.
                                >
                                > But if the product needs a feature, the product owner asks for it,
                                > and the team does it. Documentation is a feature.

                                I must be missing something, because it seems to me you just
                                contradicted yourself: in the first paragraph you seem to suggest that
                                as-built documentation should be automatically kept up to date, but in
                                the third you seem to suggest it should only be maintained if
                                specifically requested by the product owner. What am I missing?

                                > At the level of "how does this
                                > system work anyway", I'm not convinced that TDD is sufficient.

                                That I'd agree with: TDD documents each part of the elephant that the
                                individual programmer touches, not the elephant as a whole.

                                - --
                                Jim Hyslop
                                Dreampossible: Better software. Simply. http://www.dreampossible.ca
                                Consulting * Mentoring * Training in
                                C/C++ * OOD * SW Development & Practices * Version Management
                                -----BEGIN PGP SIGNATURE-----
                                Version: GnuPG v1.4.2 (MingW32)
                                Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

                                iD8DBQFDnZLoLdDyDwyJw+MRApkQAJ9sIrJ2S8J3W/upKXWP6ODMghnVFACZAXNY
                                vFX+Qu+AIHAjSUfud3txfJU=
                                =04bd
                                -----END PGP SIGNATURE-----
                              • todd
                                ... And that s the information I as a new comer to a code base need the most. After I sync a tree from the repository what s my next step? I need something
                                Message 15 of 30 , Dec 12, 2005
                                • 0 Attachment
                                  Jim Hyslop wrote:

                                  >
                                  > That I'd agree with: TDD documents each part of the elephant that the
                                  > individual programmer touches, not the elephant as a whole.

                                  And that's the information I as a new comer to a code base need the
                                  most. After I sync
                                  a tree from the repository what's my next step? I need something that
                                  gives me an
                                  overview and how all the parts fit together. I've spent too much of my
                                  life CSI'ing
                                  code to figure out what to do.

                                  BTW, I think anyone reading this thread
                                  http://groups.yahoo.com/group/scrumdevelopment/message/9565 could
                                  reasonably conclude that Agile says don't write documentation that many
                                  a reasonable programmer would fine useful.

                                  I think this page is a good entry point the conversation
                                  http://c2.com/cgi/wiki?CommentTheWhy. One could reasonably conclude that
                                  agile says don't document what many reasonable people would say to document.

                                  You can argue 20 ways to sunday that agile doesn't say don't document,
                                  but on a incident by incident basis, when has the answer ever been to
                                  document?
                                • Mike Dwyer
                                  Barely sufficient would be the theme of my mantra on this, but then again, Jim has stated it far better than I could. So tell me, outside of fixing the bug
                                  Message 16 of 30 , Dec 12, 2005
                                  • 0 Attachment
                                    "Barely sufficient" would be the theme of my mantra on this, but then again,
                                    Jim has stated it far better than I could.

                                    So tell me, outside of fixing the bug or understanding what went out, what
                                    else have you REALLY used all the dead trees for?

                                    Wall Decorations?
                                    Something to fill up your bookshelf with?
                                    A barrier?

                                    Seriously what mission critical role does what part of the documentation
                                    play in making what you do better the next time?

                                    Michael F. Dwyer

                                    "Planning constantly peers into the future for indications as to where a
                                    solution may emerge."
                                    "A Plan is a complex situation, adapting to an emerging solution."

                                    -----Original Message-----
                                    From: scrumdevelopment@yahoogroups.com
                                    [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of todd
                                    Sent: Monday, December 12, 2005 11:58 AM
                                    To: scrumdevelopment@yahoogroups.com
                                    Subject: Re: [scrumdevelopment] Agile = No Documentation?

                                    Jim Hyslop wrote:

                                    >
                                    > That I'd agree with: TDD documents each part of the elephant that the
                                    > individual programmer touches, not the elephant as a whole.

                                    And that's the information I as a new comer to a code base need the
                                    most. After I sync
                                    a tree from the repository what's my next step? I need something that
                                    gives me an
                                    overview and how all the parts fit together. I've spent too much of my
                                    life CSI'ing
                                    code to figure out what to do.

                                    BTW, I think anyone reading this thread
                                    http://groups.yahoo.com/group/scrumdevelopment/message/9565 could
                                    reasonably conclude that Agile says don't write documentation that many
                                    a reasonable programmer would fine useful.

                                    I think this page is a good entry point the conversation
                                    http://c2.com/cgi/wiki?CommentTheWhy. One could reasonably conclude that
                                    agile says don't document what many reasonable people would say to document.

                                    You can argue 20 ways to sunday that agile doesn't say don't document,
                                    but on a incident by incident basis, when has the answer ever been to
                                    document?




                                    To Post a message, send it to: scrumdevelopment@...
                                    To Unsubscribe, send a blank message to:
                                    scrumdevelopment-unsubscribe@...
                                    Yahoo! Groups Links
                                  • Dave Churchville
                                    ... I think there are a few parts to this conversation. 1. In much of the literature and discussion of Agile, there is a clear, unambiguous distaste for
                                    Message 17 of 30 , Dec 12, 2005
                                    • 0 Attachment
                                      --- In scrumdevelopment@yahoogroups.com, todd <todd@p...> wrote:
                                      >
                                      > Jim Hyslop wrote:
                                      >
                                      > BTW, I think anyone reading this thread
                                      > http://groups.yahoo.com/group/scrumdevelopment/message/9565 could
                                      > reasonably conclude that Agile says don't write documentation that many
                                      > a reasonable programmer would fine useful.
                                      >
                                      > I think this page is a good entry point the conversation
                                      > http://c2.com/cgi/wiki?CommentTheWhy. One could reasonably conclude that
                                      > agile says don't document what many reasonable people would say to document.
                                      >
                                      > You can argue 20 ways to sunday that agile doesn't say don't document,
                                      > but on a incident by incident basis, when has the answer ever been to
                                      > document?

                                      I think there are a few parts to this conversation.

                                      1. In much of the literature and discussion of Agile, there is a clear, unambiguous distaste for *development* documentation, i.e. design documents that explain how the *code* works. This is obviosuly where newcomers get the idea that Agile = No Documentation. It's because that's what they read. As it relates to documenting code.

                                      2. Many developers aren't involved with creating functional specs, user documentation, etc. So as far as they're concerned, they don't have to do code documentation, and they never had to do the other kind anyway. Once again, from a developer perspective, this leads logically to Agile = No Documentation.

                                      3. Most of the documentation that's supported or acknowledged in Agile discussion is pawned off on the Customer. As in, "if you feel you need documentation that's a Customer Responsibility". Suggesting that a real agile developer never writes documentation unless ordered by the customer as a story.

                                      There are also very few public examples of documentation from real-world Agile projects. Doesn't mean it doesn't exist, but let's face it - most people learn by example.

                                      From my usability readings, this sounds a lot like "User Errors = Design Errors". If a large number of people keep thinking that Agile = No Documentation, maybe there's a problem with the current literature. Instead of yelling at them, how about giving them some examples of Agile Documentation from real projects. Anyone got any to share? (I can probably come up with some from my previous work situations if I scrub them a bit).

                                      --Dave

                                      -----------------------------------
                                      Dave Churchville
                                      ExtremePlanner Software
                                      http://www.extremeplanner.com
                                      Agile Project Management Made Easy
                                    • Ron Jeffries
                                      ... /Traditional/ documents start at the beginning and are kept update. I m suggesting that writing them just in time instead, as an Agile project would,
                                      Message 18 of 30 , Dec 12, 2005
                                      • 0 Attachment
                                        On Monday, December 12, 2005, at 10:10:32 AM, Jim Hyslop wrote:

                                        >> Well, actually, if it were kept up to date like it is clearly
                                        >> supposed to be, traditional documentation /would/ detail how it
                                        >> works when it goes out the door. I think in the trades this is
                                        >> called "as built" documentation.
                                        >>
                                        >> It is probably faster to get to market with a low level of
                                        >> documentation done at the beginning of the project and with the
                                        >> documentation the product actually needs done toward the end.
                                        >>
                                        >> But if the product needs a feature, the product owner asks for it,
                                        >> and the team does it. Documentation is a feature.

                                        > I must be missing something, because it seems to me you just
                                        > contradicted yourself: in the first paragraph you seem to suggest that
                                        > as-built documentation should be automatically kept up to date, but in
                                        > the third you seem to suggest it should only be maintained if
                                        > specifically requested by the product owner. What am I missing?

                                        /Traditional/ documents start at the beginning and are kept update.
                                        I'm suggesting that writing them "just in time" instead, as an Agile
                                        project would, would be more efficient and effective.

                                        Ron Jeffries
                                        www.XProgramming.com
                                        2 + 2 = 5, for sufficiently large values of 2.
                                      • Steven Gordon
                                        ... Not writing the ones whose purposes would be better served by direct person-to-person communication would be even more efficient and effective. Not writing
                                        Message 19 of 30 , Dec 12, 2005
                                        • 0 Attachment
                                          On 12/12/05, Ron Jeffries <ronjeffries@...> wrote:
                                          On Monday, December 12, 2005, at 10:10:32 AM, Jim Hyslop wrote:

                                          >> Well, actually, if it were kept up to date like it is clearly
                                          >> supposed to be, traditional documentation /would/ detail how it
                                          >> works when it goes out the door. I think in the trades this is
                                          >> called "as built" documentation.
                                          >>
                                          >> It is probably faster to get to market with a low level of
                                          >> documentation done at the beginning of the project and with the
                                          >> documentation the product actually needs done toward the end.
                                          >>
                                          >> But if the product needs a feature, the product owner asks for it,
                                          >> and the team does it. Documentation is a feature.

                                          > I must be missing something, because it seems to me you just
                                          > contradicted yourself: in the first paragraph you seem to suggest that
                                          > as-built documentation should be automatically kept up to date, but in
                                          > the third you seem to suggest it should only be maintained if
                                          > specifically requested by the product owner. What am I missing?

                                          /Traditional/ documents start at the beginning and are kept update.
                                          I'm suggesting that writing them "just in time" instead, as an Agile
                                          project would, would be more efficient and effective.

                                          Ron Jeffries
                                          www.XProgramming.com
                                          2 + 2 = 5, for sufficiently large values of 2.
                                           
                                          Not writing the ones whose purposes would be better served by direct person-to-person communication would be even more efficient and effective.  Not writing the ones whose purpose would be better served by writing a reusable program (such as automated specifications/tests) would be also be even more efficient and effective.
                                           
                                          Is this how things start to get too close to recommending that no traditional, formal documentation be written?
                                           
                                          Steven Gordon

                                           

                                        • Ron Jeffries
                                          ... Sure, especially when we see people -- and there are some among us -- who think more highly of formal communications than reality (that is, MY reality)
                                          Message 20 of 30 , Dec 12, 2005
                                          • 0 Attachment
                                            On Monday, December 12, 2005, at 2:14:22 PM, Steven Gordon wrote:

                                            > Not writing the ones whose purposes would be better served by direct
                                            > person-to-person communication would be even more efficient and effective.
                                            > Not writing the ones whose purpose would be better served by writing a
                                            > reusable program (such as automated specifications/tests) would be also be
                                            > even more efficient and effective.

                                            > Is this how things start to get too close to recommending that no
                                            > traditional, formal documentation be written?

                                            Sure, especially when we see people -- and there are some among us
                                            -- who think more highly of formal communications than reality (that
                                            is, MY reality) would suggest. ;->

                                            Ron Jeffries
                                            www.XProgramming.com
                                            Speculation or experimentation - which is more likely to give the correct answer?
                                          • Joe Szodfridt
                                            In our agile process, we get slammed by those outside of our project for having what they like to call unreliable documentation . We develop documentation
                                            Message 21 of 30 , Dec 12, 2005
                                            • 0 Attachment
                                              In our agile process, we get slammed by those outside of our project
                                              for having what they like to call "unreliable documentation". We
                                              develop documentation the same way we develop code - incrementally.
                                              Each sprint adds more information to the documentation. Consequently
                                              our documentation even though it is ever changing tends to be a more
                                              accurate reflection of the actual code than most other forms of
                                              documentation within the organization.

                                              IMHO, it is important for a team or organization to define and agree
                                              upon what level of documentation is required to be maintained for each
                                              sprint. The required documentation is part of the definition of what
                                              "done" means for each sprint. Once that is in place a sprint cannot
                                              be considered "done" until the documentation is also "done" to the
                                              agreed upon level.

                                              Joe Szodfridt
                                              --- In scrumdevelopment@yahoogroups.com, jerrad anderson
                                              <jayrod84@g...> wrote:
                                              >
                                              > When I first was learning about agile, my boss informed me that we
                                              couldn't
                                              > use XP cause it meant "no documentation" I ofcourse didn't know any
                                              better
                                              > at the time and dropped it. It's an easy misnomer. My current scrum team
                                              > turns out reams of usefull documentation.
                                              >
                                              > Jerrad
                                              >
                                              >
                                              > On 12/12/05, Ron Jeffries <ronjeffries@x...> wrote:
                                              > >
                                              > > On Monday, December 12, 2005, at 12:20:20 AM, Paul Webb wrote:
                                              > >
                                              > > > (An unfortunate by-product of this is that there are now so
                                              > > > many people who now think that agile is about no design or
                                              documentation
                                              > > and
                                              > > > cowboy development. You only need to work around such an
                                              environment to
                                              > > > overhear people saying 'We're agile - we don't do documentation', to
                                              > > > understand where some of the resistance and fear comes from.)
                                              > >
                                              > > I'd like to hear from people who actually personally know someone
                                              > > who thinks that's what Agile is.
                                              > >
                                              > > Ron Jeffries
                                              > > www.XProgramming.com <http://www.xprogramming.com/>
                                              > > The lyf so short, the craft so long to lerne. -- Geoffrey Chaucer
                                              > >
                                              > >
                                              > > To Post a message, send it to: scrumdevelopment@e...
                                              > > To Unsubscribe, send a blank message to:
                                              > > scrumdevelopment-unsubscribe@e...
                                              > >
                                              > >
                                              > > ------------------------------
                                              > > YAHOO! GROUPS LINKS
                                              > >
                                              > >
                                              > > - Visit your group
                                              "scrumdevelopment<http://groups.yahoo.com/group/scrumdevelopment>"
                                              > > on the web.
                                              > >
                                              > > - To unsubscribe from this group, send an email to:
                                              > >
                                              scrumdevelopment-unsubscribe@yahoogroups.com<scrumdevelopment-unsubscribe@yahoogroups.com?subject=Unsubscribe>
                                              > >
                                              > > - Your use of Yahoo! Groups is subject to the Yahoo! Terms of
                                              > > Service <http://docs.yahoo.com/info/terms/>.
                                              > >
                                              > >
                                              > > ------------------------------
                                              > >
                                              >
                                            • Eduardo Miranda
                                              Actually I have to agree with Jim. I am newbie in Agile, gathering information to maybe become a practioner. And despite all I ve read about Agile
                                              Message 22 of 30 , Dec 12, 2005
                                              • 0 Attachment
                                                Actually I have to agree with Jim. I am newbie in Agile, gathering information to maybe become a practioner. And despite all I've read about Agile documentation I'm still looking forward to get my hands on a sample of a requirement documentation.
                                                 
                                                Where do we begin? I'm sure isn't just coding, but I don't know how.
                                                 
                                                Eduardo Miranda
                                                 
                                                 
                                                >
                                                > --- In scrumdevelopment@yahoogroups.com, todd wrote:
                                                > >
                                                > > Jim Hyslop wrote:
                                                > >
                                                > > BTW, I think anyone reading this thread
                                                > > http://groups.yahoo.com/group/scrumdevelopment/message/9565 could
                                                > > reasonably conclude that Agile says don't write documentation that many
                                                > > a reasonable programmer would fine useful.
                                                > >
                                                > > I think this page is a good entry point the conversation
                                                > > http://c2.com/cgi/wiki?CommentTheWhy. One could reasonably conclude that
                                                > > agile says don't document what many reasonable people would say to document.
                                                > >
                                                > > You can argue 20 ways to sunday that agile doesn't say don't document,
                                                > > but on a incident by incident basis, when has the answer ever been to
                                                > > document?
                                                >
                                                > I think there are a few parts to this conversation.
                                                >
                                                > 1. In much of the literature and discussion of Agile, there is a clear,
                                                > unambiguous distaste for *development* documentation, i.e. design documents
                                                > that explain how the *code* works. This is obviosuly where newcomers get the
                                                > idea that Agile = No Documentation. It's because that's what they read. As it
                                                > relates to documenting code.
                                                >
                                                > 2. Many developers aren't involved with creating functional specs, user
                                                > documentation, etc. So as far as they're concerned, they don't have to do code
                                                > documentation, and they never had to do the other kind anyway. Once again,
                                                > from a developer perspective, this leads logically to Agile = No Documentation.
                                                >
                                                > 3. Most of the documentation that's supported or acknowledged in Agile
                                                > discussion is pawned off on the Customer. As in, "if you feel you need
                                                > documentation that's a Customer Responsibility". Suggesting that a real agile
                                                > developer never writes documentation unless ordered by the customer as a story.
                                                >
                                                > There are also very few public examples of documentation from real-world Agile
                                                > projects. Doesn't mean it doesn't exist, but let's face it - most people learn
                                                > by example.
                                                >
                                                > From my usability readings, this sounds a lot like "User Errors = Design
                                                > Errors". If a large number of people keep thinking that Agile = No
                                                > Documentation, maybe there's a problem with the current literature. Instead of
                                                > yelling at them, how about giving them some examples of Agile Documentation
                                                > from real projects. Anyone got any to share? (I can probably come up with
                                                > some from my previous work situations if I scrub them a bit).
                                                >
                                                > --Dave
                                                >
                                                > -----------------------------------
                                                > Dave Churchville
                                                > ExtremePlanner Software
                                                > http://www.extremeplanner.com
                                                > Agile Project Management Made Easy
                                                >
                                                >
                                                >
                                                >
                                                >
                                                >
                                                >
                                                >
                                                > To Post a message, send it to: scrumdevelopment@...
                                                > To Unsubscribe, send a blank message to: scrumdevelopment-
                                                > unsubscribe@...
                                                >
                                                >
                                                >
                                                > SPONSORED LINKS
                                                > Scrum
                                                >
                                                > ===============================================================================
                                                > YAHOO! GROUPS LINKS
                                                >
                                                > * Visit your group "scrumdevelopment" on the web.
                                                >
                                                >
                                                > To unsubscribe from this group, send an email to:
                                                > scrumdevelopment-unsubscribe@yahoogroups.com
                                                >
                                                >
                                                > Your use of Yahoo! Groups is subject to the Yahoo!_Terms_of_Service.
                                                >
                                                > ===============================================================================
                                                >
                                                >
                                              • Ron Jeffries
                                                ... Well, there is no standard requirement documentation in Agile. ... What books have you read on Scrum? With that information, we can better suggest the
                                                Message 23 of 30 , Dec 12, 2005
                                                • 0 Attachment
                                                  On Monday, December 12, 2005, at 4:07:18 PM, Eduardo Miranda wrote:

                                                  > Actually I have to agree with Jim. I am newbie in Agile, gathering
                                                  > information to maybe become a practioner. And despite all I've
                                                  > read about Agile documentation I'm still looking forward to get my
                                                  > hands on a sample of a requirement documentation.

                                                  Well, there is no standard "requirement documentation" in Agile.

                                                  > Where do we begin? I'm sure isn't just coding, but I don't know how.

                                                  What books have you read on Scrum? With that information, we can
                                                  better suggest the next thing to look at ...

                                                  Ron Jeffries
                                                  www.XProgramming.com
                                                  The greatest mistake we make is living in constant fear that we will make one.
                                                  -- John Maxwell
                                                • Tiran Dagan
                                                  Dear Eduardo, Those who are new to scrum describe agile methods as having many short iterations and low ceremony (amount of method weight in terms of
                                                  Message 24 of 30 , Dec 12, 2005
                                                  • 0 Attachment

                                                    Dear Eduardo,

                                                     

                                                    Those who are new to scrum describe agile methods as having many short iterations and “low ceremony” (amount of method weight in terms of documentation, formal steps, review,etc). However this is not true: scrum is silent on the question of ceremony and leaves the question to the discretion of the team.

                                                     

                                                    I enjoyed reading Craig Larman’s “Agile & Iterative Development” which provides a nice overview of scrum, XP, UP and Evo.

                                                     

                                                    Tiran.

                                                     

                                                     

                                                     

                                                    Tiran Dagan

                                                    6FootMedia.Com
                                                    Transforming business pathways with technology

                                                    169 W 73rd St #6 New York NY 10023
                                                    Toll Free Phone:  (866) 636-6888 Fax: (800) 230-1587 Mobile : (917) 346-9004

                                                     


                                                     

                                                     


                                                    From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Ron Jeffries
                                                    Sent: Monday, December 12, 2005 5:12 PM
                                                    To: scrumdevelopment@yahoogroups.com
                                                    Subject: Re: [scrumdevelopment] Re: Agile = No Documentation?

                                                     

                                                    On Monday, December 12, 2005, at 4:07:18 PM, Eduardo Miranda wrote:

                                                    > Actually I have to agree with Jim. I am newbie in Agile, gathering
                                                    > information to maybe become a practioner. And despite all I've
                                                    > read about Agile documentation I'm still looking forward to get my
                                                    > hands on a sample of a requirement documentation.

                                                    Well, there is no standard "requirement documentation" in Agile.

                                                    > Where do we begin? I'm sure isn't just coding, but I don't know how.

                                                    What books have you read on Scrum? With that information, we can
                                                    better suggest the next thing to look at ...

                                                    Ron Jeffries
                                                    www.XProgramming.com
                                                    The greatest mistake we make is living in constant fear that we will make one.
                                                      --  John Maxwell

                                                  • Mike Cohn
                                                    First: Eduardo welcome to our group. I m a big fan of yours--from your Running the Successful High-Tech Project Office book to your IEEE articles (planning
                                                    Message 25 of 30 , Dec 12, 2005
                                                    • 0 Attachment
                                                      First: Eduardo welcome to our group. I'm a big fan of yours--from your "Running the Successful High-Tech Project Office" book to your IEEE articles (planning and executing time-bound projects; and Improving Subjective Estimates, which I've referenced in my newest book).

                                                      Second: I think the reason why it's hard to find a "sample agile requirements document" is that such documents are never static very long. Most of my clients are using 3x5 note cards for their "documents."  A handful use tools such as VerisonOne or Rally. The requirements documents start out with intentionally incomplete descriptions of very high level requirements but that are refined through the process. One client recently finished adding support to their web-based product for employers to enter payroll data for their employees. This started out as one sentence on one note card. That card was later torn up and written as about 20 cards. As those were worked on some of those 20 cards were replaced by more cards. When done, they probably worked on 30-40 cards, each of which represented a "user story" or single requirement. The problem in producing a "sample agile requirements document" is that the 40 cards never really existed at the same time. By the time the 40th was written there were perhaps 23 that had been developed and ripped up.

                                                      Mike Cohn
                                                      Author:
                                                        Agile Estimating and Planning
                                                        User Stories Applied
                                                      www.mountaingoatsoftware.com


                                                      On Dec 12, 2005, at 2:07 PM, Eduardo Miranda wrote:

                                                      Actually I have to agree with Jim. I am newbie in Agile, gathering information to maybe become a practioner. And despite all I've read about Agile documentation I'm still looking forward to get my hands on a sample of a requirement documentation.
                                                       
                                                      Where do we begin? I'm sure isn't just coding, but I don't know how.
                                                       
                                                      Eduardo Miranda
                                                       
                                                       
                                                      >
                                                      > --- In scrumdevelopment@yahoogroups.com, todd wrote:
                                                      > >
                                                      > > Jim Hyslop wrote:
                                                      > >
                                                      > > BTW, I think anyone reading this thread
                                                      > > reasonably conclude that Agile says don't write documentation that many
                                                      > > a reasonable programmer would fine useful.
                                                      > >
                                                      > > I think this page is a good entry point the conversation
                                                      > > http://c2.com/cgi/wiki?CommentTheWhy. One could reasonably conclude that
                                                      > > agile says don't document what many reasonable people would say to document.
                                                      > >
                                                      > > You can argue 20 ways to sunday that agile doesn't say don't document,
                                                      > > but on a incident by incident basis, when has the answer ever been to
                                                      > > document?
                                                      >
                                                      > I think there are a few parts to this conversation.
                                                      >
                                                      > 1. In much of the literature and discussion of Agile, there is a clear,
                                                      > unambiguous distaste for *development* documentation, i.e. design documents
                                                      > that explain how the *code* works. This is obviosuly where newcomers get the
                                                      > idea that Agile = No Documentation. It's because that's what they read. As it
                                                      > relates to documenting code.
                                                      >
                                                      > 2. Many developers aren't involved with creating functional specs, user
                                                      > documentation, etc. So as far as they're concerned, they don't have to do code
                                                      > documentation, and they never had to do the other kind anyway. Once again,
                                                      > from a developer perspective, this leads logically to Agile = No Documentation.
                                                      >
                                                      > 3. Most of the documentation that's supported or acknowledged in Agile
                                                      > discussion is pawned off on the Customer. As in, "if you feel you need
                                                      > documentation that's a Customer Responsibility". Suggesting that a real agile
                                                      > developer never writes documentation unless ordered by the customer as a story.
                                                      >
                                                      > There are also very few public examples of documentation from real-world Agile
                                                      > projects. Doesn't mean it doesn't exist, but let's face it - most people learn
                                                      > by example.
                                                      >
                                                      > From my usability readings, this sounds a lot like "User Errors = Design
                                                      > Errors". If a large number of people keep thinking that Agile = No
                                                      > Documentation, maybe there's a problem with the current literature. Instead of
                                                      > yelling at them, how about giving them some examples of Agile Documentation
                                                      > from real projects. Anyone got any to share? (I can probably come up with
                                                      > some from my previous work situations if I scrub them a bit).
                                                      >
                                                      > --Dave
                                                      >
                                                      > -----------------------------------
                                                      > Dave Churchville
                                                      > ExtremePlanner Software
                                                      > Agile Project Management Made Easy
                                                      >
                                                      >
                                                      >
                                                      >
                                                      >
                                                      >
                                                      >
                                                      >
                                                      > To Post a message, send it to: scrumdevelopment@...
                                                      > To Unsubscribe, send a blank message to: scrumdevelopment-
                                                      >
                                                      >
                                                      >
                                                      > SPONSORED LINKS
                                                      > Scrum
                                                      >
                                                      > ===============================================================================
                                                      > YAHOO! GROUPS LINKS
                                                      >
                                                      > * Visit your group "scrumdevelopment" on the web.
                                                      >
                                                      >
                                                      > To unsubscribe from this group, send an email to:
                                                      >
                                                      >
                                                      > Your use of Yahoo! Groups is subject to the Yahoo!_Terms_of_Service.
                                                      >
                                                      > ===============================================================================
                                                      >
                                                      >


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




                                                      YAHOO! GROUPS LINKS





                                                    • Brad Appleton
                                                      ... What I ve done before and have seen others do, is the User Docs serving double-duty Requirements Doc. Where we started off being mandated to have some
                                                      Message 26 of 30 , Dec 13, 2005
                                                      • 0 Attachment
                                                        Ron Jeffries wrote:
                                                        > /Traditional/ documents start at the beginning and are kept update.
                                                        > I'm suggesting that writing them "just in time" instead, as an Agile
                                                        > project would, would be more efficient and effective.

                                                        What I've done before and have seen others do, is the "User Docs"
                                                        serving double-duty "Requirements Doc." Where we started off being
                                                        mandated to have some kind of early version of "Requirements" to show
                                                        our prospective customer, and we did it with the intent of evolving it
                                                        into the Reference docs and User-Guide.

                                                        Come to think of it, we had most of the "examples" in the docs as
                                                        end-user test-cases too: The User docs were done in a text-markup
                                                        language (which is probably the main drawback of how we did it at the
                                                        time), and it was easy to have "special tags" around command-line
                                                        invocation examples and their expected output which a script could parse
                                                        into a set of test-cases and expected-results as part of a regression test.

                                                        So our "User Stories" were both our "User Docs" and our "Acceptance
                                                        Tests". And we had hyperlink "tags" the sections in the docs from the
                                                        class/method that implemented|tested a particular behavior -- we werent
                                                        doing it for the sake of traceability, just to make our own lives easier
                                                        when navigating the code (In fact, I suppose we could have had a
                                                        separate markup-file for each user-story and then the traceability would
                                                        have been even more transparent)

                                                        I suppose that wouldnt work so well for GUI stuff these days (but might
                                                        work well for a lot of XML/SOAP & Web-Services stuff??)

                                                        We did the same sort of thing for the APIs for our code-base, albeit in
                                                        much more of a literate programming style (a bit like a cross between
                                                        Java-Doc and Perl's PODs combined with some extraction and collation). I
                                                        guess since our APIs were documented, those ended up being "Design
                                                        Stories" rather than "User Stories" (hmmnn - I'll have to ponder that
                                                        some more)

                                                        I don't see why this sort of thing couldnt be done today with FitNesse!
                                                        Does anyone have any experience using FitNesse to additionally generate
                                                        UserDocs and/or use hyperlinks in their code/tests to FitNesse or Fit
                                                        wiki-pages?
                                                        --
                                                        Brad Appleton <brad@...> www.bradapp.net
                                                        Software CM Patterns (www.scmpatterns.com)
                                                        Effective Teamwork, Practical Integration
                                                        "And miles to go before I sleep" --Robert Frost
                                                      • Pascal Roy
                                                        The Naked Objects (NO) framework has an interesting approach where the user doc is generated from the acceptance tests (based on an extension of JUnit test
                                                        Message 27 of 30 , Dec 13, 2005
                                                        • 0 Attachment

                                                          The Naked Objects (NO) framework has an interesting approach where the user doc is generated from the acceptance tests (based on an extension of JUnit test case). They can do that because user interactions in Naked objects take a standard form, users can specify the implementation of any story (or use case) in terms of direct operations upon business objects.

                                                           

                                                          Here’s an example of a generated user document : “http://www.nakedobjects.org/book/methodology/auto-documentation-example.png”.

                                                          The text is automatically from the test case code. For example, if I remember well because it’s been a while since I’ve looked at this, the “phrase Retrieve the booking object” was generated because a standard method of the Naked Object framework is used to retrieve a Booking object. The second phrase is generated because the booking object requested was the “#2, confirmed” (probably passed in as an argument to the previous method). The third phrase is a call to a documentation method part of the NO Acceptance Test framework that simply prints out text. The bullets are also controlled by another method of the acceptance framework.

                                                           

                                                          It’s really an interesting implementation and worth a look if you are interested at all in such concepts.

                                                           

                                                          Pascal Roy, ing./P.Eng., PMP

                                                          Vice-président/Vice President

                                                          Elapse Technologies Inc.

                                                           

                                                          [url]   http://www.elapsetech.com

                                                          [email] pascal.roy@...

                                                          [cell]  514-862-6836

                                                           


                                                          De : scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] De la part de Brad Appleton
                                                          Envoyé : 13 décembre 2005 03:26
                                                          À : scrumdevelopment@yahoogroups.com; XP list; Agile Modeling list
                                                          Objet : [scrumdevelopment] Requirements and Tests and User-Docs all-in-one? (was Re: Agile = No Documentation?)

                                                           

                                                          Ron Jeffries wrote:
                                                          > /Traditional/ documents start at the beginning and are kept update.
                                                          > I'm suggesting that writing them "just in time" instead, as an Agile
                                                          > project would, would be more efficient and effective.

                                                          What I've done before and have seen others do, is the "User Docs"
                                                          serving double-duty "Requirements Doc." Where we started off being
                                                          mandated to have some kind of early version of "Requirements" to show
                                                          our prospective customer, and we did it with the intent of evolving it
                                                          into the Reference docs and User-Guide.

                                                          Come to think of it, we had most of the "examples" in the docs as
                                                          end-user test-cases too: The User docs were done in a text-markup
                                                          language (which is probably the main drawback of how we did it at the
                                                          time), and it was easy to have "special tags" around command-line
                                                          invocation examples and their expected output which a script could parse
                                                          into a set of test-cases and expected-results as part of a regression test.

                                                          So our "User Stories" were both our "User Docs" and our "Acceptance
                                                          Tests". And we had hyperlink "tags" the sections in the docs from the
                                                          class/method that implemented|tested a particular behavior -- we werent
                                                          doing it for the sake of traceability, just to make our own lives easier
                                                          when navigating the code (In fact, I suppose we could have had a
                                                          separate markup-file for each user-story and then the traceability would
                                                          have been even more transparent)

                                                          I suppose that wouldnt work so well for GUI stuff these days (but might
                                                          work well for a lot of XML/SOAP & Web-Services stuff??)

                                                          We did the same sort of thing for the APIs for our code-base, albeit in
                                                          much more of a literate programming style (a bit like a cross between
                                                          Java-Doc and Perl's PODs combined with some extraction and collation). I
                                                          guess since our APIs were documented, those ended up being "Design
                                                          Stories" rather than "User Stories" (hmmnn - I'll have to ponder that
                                                          some more)

                                                          I don't see why this sort of thing couldnt be done today with FitNesse!
                                                          Does anyone have any experience using FitNesse to additionally generate
                                                          UserDocs and/or use hyperlinks in their code/tests to FitNesse or Fit
                                                          wiki-pages?
                                                          --
                                                          Brad Appleton <brad@...> www.bradapp.net
                                                              Software CM Patterns (www.scmpatterns.com)
                                                              Effective Teamwork, Practical Integration
                                                          "And miles to go before I sleep" --Robert Frost

                                                        • Jim Hyslop
                                                          ... Hash: SHA1 ... Well, that s _one_ way to promote good naming conventions, isn t it? - -- Jim Hyslop Dreampossible: Better software. Simply.
                                                          Message 28 of 30 , Dec 13, 2005
                                                          • 0 Attachment
                                                            -----BEGIN PGP SIGNED MESSAGE-----
                                                            Hash: SHA1

                                                            Pascal Roy wrote:
                                                            > The text is automatically from the test case code. For example, if I
                                                            > remember well because it?s been a while since I?ve looked at this, the
                                                            > ?phrase Retrieve the booking object? was generated because a standard method
                                                            > of the Naked Object framework is used to retrieve a Booking object.

                                                            Well, that's _one_ way to promote good naming conventions, isn't it?

                                                            - --
                                                            Jim Hyslop
                                                            Dreampossible: Better software. Simply. http://www.dreampossible.ca
                                                            Consulting * Mentoring * Training in
                                                            C/C++ * OOD * SW Development & Practices * Version Management
                                                            -----BEGIN PGP SIGNATURE-----
                                                            Version: GnuPG v1.4.2 (MingW32)
                                                            Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

                                                            iD8DBQFDnw/PLdDyDwyJw+MRAtHJAJ9USMpmst1uGx418Xbd8rZQ+dS+NgCfXiLs
                                                            LsZR3I6J1t6dVtMso39Ag7s=
                                                            =fYdt
                                                            -----END PGP SIGNATURE-----
                                                          • Jim Hyslop
                                                            ... Hash: SHA1 ... I must give credit where credit is due. I did not write that, I think Todd did. If I read the attributions correctly, Todd responded to a
                                                            Message 29 of 30 , Dec 13, 2005
                                                            • 0 Attachment
                                                              -----BEGIN PGP SIGNED MESSAGE-----
                                                              Hash: SHA1

                                                              Eduardo Miranda wrote:
                                                              > Actually I have to agree with Jim.

                                                              I must give credit where credit is due. I did not write that, I think
                                                              Todd did. If I read the attributions correctly, Todd responded to a
                                                              message of mine, then added the quoted part below, and a subsequent
                                                              reply snipped my comments (I'm not entirely sure, since can't find the
                                                              original message):

                                                              >>--- In scrumdevelopment@yahoogroups.com, todd wrote:
                                                              >>
                                                              >>>Jim Hyslop wrote:
                                                              >>>
                                                              >>>BTW, I think anyone reading this thread
                                                              >>>http://groups.yahoo.com/group/scrumdevelopment/message/9565 could
                                                              >>>reasonably conclude that Agile says don't write documentation that many
                                                              >>>a reasonable programmer would fine useful.
                                                              >>>
                                                              >>>I think this page is a good entry point the conversation
                                                              >>>http://c2.com/cgi/wiki?CommentTheWhy. One could reasonably conclude that
                                                              >>>agile says don't document what many reasonable people would say to document.
                                                              >>>
                                                              >>>You can argue 20 ways to sunday that agile doesn't say don't document,
                                                              >>>but on a incident by incident basis, when has the answer ever been to
                                                              >>>document?

                                                              - --
                                                              Jim Hyslop
                                                              Dreampossible: Better software. Simply. http://www.dreampossible.ca
                                                              Consulting * Mentoring * Training in
                                                              C/C++ * OOD * SW Development & Practices * Version Management
                                                              -----BEGIN PGP SIGNATURE-----
                                                              Version: GnuPG v1.4.2 (MingW32)
                                                              Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

                                                              iD8DBQFDnxKoLdDyDwyJw+MRAunQAJ9h3E7iuwr30e9T7gpc2UEH/D3jUQCdGHV0
                                                              tE7cJMHWnyLuywIzurviJl8=
                                                              =YRFR
                                                              -----END PGP SIGNATURE-----
                                                            • Daren Desjardins
                                                              Robert Martin recently made a post on his blog about people interpreting Agile to mean no documentation.
                                                              Message 30 of 30 , Jan 3, 2006
                                                              • 0 Attachment
                                                                Robert Martin recently made a post on his blog about people interpreting Agile to mean no documentation.

                                                                http://www.butunclebob.com/ArticleS.UncleBob.OnDocumentation

                                                                In my book: Agile Software Development: Principles, Patterns, and Practices, I describe "Martin's first law of documentation" as: Produce no document unless it's need is immediate and significant. Some folks have taken this to mean that Agile Development is development without documentation. This is not the case.

                                                                Documentation is a necessary part of all software development projects. Rejecting documentation in the name of "Agility" is a flawed religious behavior. It is just as flawed as uncritically accepting the production of dozens of different documents in the name of some Ruminated Ultimate Process. Documentation, like any other activity, needs to be created on a prioritized, return-on-investment basis. We create documents only if those documents are needed, and will more than pay back the effort required to produce them.

                                                                Agile Methods require two kinds of documentation: Requirements and Design Documents. All other kinds of documents are optional within Agile Methods; but optional does not mean absent.



                                                                On 12/12/05, Ron Jeffries <ronjeffries@...> wrote:
                                                                On Monday, December 12, 2005, at 4:07:18 PM, Eduardo Miranda wrote:

                                                                > Actually I have to agree with Jim. I am newbie in Agile, gathering
                                                                > information to maybe become a practioner. And despite all I've
                                                                > read about Agile documentation I'm still looking forward to get my
                                                                > hands on a sample of a requirement documentation.

                                                                Well, there is no standard "requirement documentation" in Agile.

                                                                > Where do we begin? I'm sure isn't just coding, but I don't know how.

                                                                What books have you read on Scrum? With that information, we can
                                                                better suggest the next thing to look at ...

                                                                Ron Jeffries
                                                                www.XProgramming.com
                                                                The greatest mistake we make is living in constant fear that we will make one.
                                                                  --  John Maxwell


                                                              Your message has been successfully submitted and would be delivered to recipients shortly.