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

How do you explain one of the agile principles "Simplicity" to a group

Expand Messages
  • avienaash@ymail.com
    How do you explain one of the agile principles Simplicity--the art of maximizing the amount of work not done--is essential to a group. What different
    Message 1 of 28 , Sep 25, 2012
    • 0 Attachment
      How do you explain one of the agile principles "Simplicity--the art of maximizing the amount of work not done--is essential" to a group.

      What different examples you all share and how do you make people understand this principle.

      Thanks,

      Avienaash
      www.agilebuddha.com 
    • Charles Bradley - Scrum Coach CSP CSM PSM
      Avienaash, I asked Ron Jeffries and Chet Hendrickson (fellow list members and two of the AM authors) the exact same question at Agile2012.  I blogged about
      Message 2 of 28 , Sep 26, 2012
      • 0 Attachment
        Avienaash,

        I asked Ron Jeffries and Chet Hendrickson (fellow list members and two of the AM authors) the exact same question at Agile2012.  I blogged about their answers here:

        http://www.scrumcrazy.com/Agile2012+Q%26A+-+Ron+Jeffries+and+Chet+Hendrickson+on+Simplicity

        HTH,
         
        -------
        Charles Bradley
        http://www.ScrumCrazy.com




        From: "avienaash@..." <avienaash@...>
        To: scrumdevelopment@yahoogroups.com
        Sent: Tuesday, September 25, 2012 11:00 PM
        Subject: [scrumdevelopment] How do you explain one of the agile principles "Simplicity" to a group



        How do you explain one of the agile principles "Simplicity--the art of maximizing the amount of work not done--is essential" to a group.

        What different examples you all share and how do you make people understand this principle.

        Thanks,

        Avienaash
        www.agilebuddha.com 



      • Adam Sroka
        Great answer! I also think it is important to understand the idea of YAGNI (Ya aint gonna need it.) Folks in this business are way, way too quick to accept
        Message 3 of 28 , Sep 26, 2012
        • 0 Attachment
          Great answer! 

          I also think it is important to understand the idea of YAGNI (Ya aint gonna need it.) Folks in this business are way, way too quick to accept gobs of complexity because they believe that it will save them work later. I'm thinking specifically about frameworks and tools that seem to be just about right for what you want to do, except that you don't actually know how you will use them yet. 

          The problem with that idea is that you have to carry that complexity around everywhere you go. It's like buying the heaviest thing right at the start of your mall trip and then carrying it to all the other stores. 

          If you watch the way Ron and Chet and some of the rest of us work, we tend to prefer to start the first story with nothing but a general purpose language and the minimum set of tools needed to write and run unit tests for it. 

          On Wed, Sep 26, 2012 at 1:10 PM, Charles Bradley - Scrum Coach CSP CSM PSM I <chuck-lists2@...> wrote:
           

          Avienaash,

          I asked Ron Jeffries and Chet Hendrickson (fellow list members and two of the AM authors) the exact same question at Agile2012.  I blogged about their answers here:

          http://www.scrumcrazy.com/Agile2012+Q%26A+-+Ron+Jeffries+and+Chet+Hendrickson+on+Simplicity

          HTH,
           
          -------
          Charles Bradley
          http://www.ScrumCrazy.com




          From: "avienaash@..." <avienaash@...>
          To: scrumdevelopment@yahoogroups.com
          Sent: Tuesday, September 25, 2012 11:00 PM
          Subject: [scrumdevelopment] How do you explain one of the agile principles "Simplicity" to a group



          How do you explain one of the agile principles "Simplicity--the art of maximizing the amount of work not done--is essential" to a group.

          What different examples you all share and how do you make people understand this principle.

          Thanks,

          Avienaash
          www.agilebuddha.com 




        • RonJeffries
          We thought it was pretty good for improv. :) R ... Ron Jeffries www.XProgramming.com I m really pissed off by what people are passing off as agile these
          Message 4 of 28 , Sep 26, 2012
          • 0 Attachment
            We thought it was pretty good for improv. :)
            R
            On Sep 26, 2012, at 4:19 PM, Adam Sroka <adam.sroka@...> wrote:

            Great answer! 


            Ron Jeffries
            I'm really pissed off by what people are passing off as "agile" these days.
            You may have a red car, but that does not make it a Ferrari.
              -- Steve Hayes

          • Adam Sroka
            I think Kent s rules are usually the best place to go to start talking about what simplicity means for software. A related tactic that I have used is to invert
            Message 5 of 28 , Sep 26, 2012
            • 0 Attachment
              I think Kent's rules are usually the best place to go to start talking about what simplicity means for software. 

              A related tactic that I have used is to invert the rules. In other words, if we had software that lacked tests, had duplication, etc. what would that mean? I assert that each of those things makes maintenance harder, thus making mistakes more likely, thus making the software unsafe to work with. Therefore when we are talking about simple design we are really talking about safety, something that everyone can relate to. 

              On Wed, Sep 26, 2012 at 1:20 PM, RonJeffries <ronjeffries@...> wrote:
               

              We thought it was pretty good for improv. :)

              R
              On Sep 26, 2012, at 4:19 PM, Adam Sroka <adam.sroka@...> wrote:

              Great answer! 


              Ron Jeffries
              I'm really pissed off by what people are passing off as "agile" these days.
              You may have a red car, but that does not make it a Ferrari.
                -- Steve Hayes


            • Charles Bradley - Scrum Coach CSP CSM PSM
              Hmmm. code safety... How safe do you feel extending/modifying this code?  Do you feel safer with automated tests, or less safe? Kind of reminds me of the
              Message 6 of 28 , Sep 26, 2012
              • 0 Attachment
                Hmmm. code safety...

                How safe do you feel extending/modifying this code?  Do you feel safer with automated tests, or less safe?

                Kind of reminds me of the happiness metric...

                How happy are you that you have to modify this code? (1-5 scale)

                That sounds like a cool way to judge how bad the tech debt is in some specific code.

                -------
                Charles Bradley
                http://www.ScrumCrazy.com




                From: Adam Sroka <adam.sroka@...>
                To: scrumdevelopment@yahoogroups.com
                Sent: Wednesday, September 26, 2012 2:52 PM
                Subject: Re: [scrumdevelopment] How do you explain one of the agile principles "Simplicity" to a group



                I think Kent's rules are usually the best place to go to start talking about what simplicity means for software. 

                A related tactic that I have used is to invert the rules. In other words, if we had software that lacked tests, had duplication, etc. what would that mean? I assert that each of those things makes maintenance harder, thus making mistakes more likely, thus making the software unsafe to work with. Therefore when we are talking about simple design we are really talking about safety, something that everyone can relate to. 

                On Wed, Sep 26, 2012 at 1:20 PM, RonJeffries <ronjeffries@...> wrote:
                 
                We thought it was pretty good for improv. :)
                R
                On Sep 26, 2012, at 4:19 PM, Adam Sroka <adam.sroka@...> wrote:

                Great answer! 


                Ron Jeffries
                I'm really pissed off by what people are passing off as "agile" these days.
                You may have a red car, but that does not make it a Ferrari.
                  -- Steve Hayes






              • Adam Sroka
                On Wed, Sep 26, 2012 at 2:22 PM, Charles Bradley - Scrum Coach CSP CSM ... Not how safe do you feel. That is important, but not the point. How safe are you?
                Message 7 of 28 , Sep 26, 2012
                • 0 Attachment
                  On Wed, Sep 26, 2012 at 2:22 PM, Charles Bradley - Scrum Coach CSP CSM
                  PSM I <chuck-lists2@...> wrote:
                  >
                  >
                  >
                  > Hmmm. code safety...
                  >
                  > How safe do you feel extending/modifying this code? Do you feel safer
                  > with automated tests, or less safe?
                  >

                  Not how safe do you feel. That is important, but not the point.

                  How safe are you?

                  Any code that isn't tested can break and you won't know. Any code that
                  is duplicated can need to change and you won't remember all the places
                  where. Any code that is obfuscated you won't understand and will
                  change for the wrong reasons. Any superfluous details in the code will
                  cause you to read them and waste your time (and potentially get
                  distracted and miss something.)

                  If you have code with these qualities you are not safe.
                • Alan Dayley
                  Great answers. I usually tell the story of a multi-week effort I participated in to create an interface layer for *possible* varying hardware connections. We
                  Message 8 of 28 , Sep 26, 2012
                  • 0 Attachment
                    Great answers.

                    I usually tell the story of a multi-week effort I participated in to create an interface layer for *possible* varying hardware connections.  We never connected but one type of hardware on that system, weeks wasted and code not used.  This jogs the memory of people when they remember a similar design, coding or some other effort for "we are going to need it eventually" purposes that never came to be.

                    Talking about focus and producing high quality of the essence of each story also usually gets nods.

                    Alan

                    On Tue, Sep 25, 2012 at 10:00 PM, avienaash@... <avienaash@...> wrote:
                     

                    How do you explain one of the agile principles "Simplicity--the art of maximizing the amount of work not done--is essential" to a group.

                    What different examples you all share and how do you make people understand this principle.

                    Thanks,

                    Avienaash
                    www.agilebuddha.com 


                  • avienaash@ymail.com
                    Thanks Charles for sharing that link. It was very useful. This is what comes to mind when I think about simplicity. Simplicity is simplifying work.
                    Message 9 of 28 , Sep 26, 2012
                    • 0 Attachment
                      Thanks Charles for sharing that link. It was very useful.

                      This is what comes to mind when I think about simplicity.  Simplicity is simplifying work. De-cluttering your mind. De-cluttering your product. Test driven development follows simplicity. You right just enough code to pass your tests.

                      Just barely good enough thinking is followed across Agile. You write just enough code, just enough features/design, just enough effort to deliver working software, just enough documentation etc.

                      Simplifying,De-cluttering your workspace. Working in open space.

                      Simplifying mind. Not being manipulative, being honest and open. Scrum philosophy of working in small teams, working in small sprints, working on small stories etc all imbibe simplicity thinking.

                      I read some where "The simplest way to achieve simplicity is through thoughtful reduction"

                      Product Owner has to do a lot of De-cluttering of backlog to identify features that will make his product successful. Simplicity facilitates creating product with minimum functionality that is easy to use, simple user interfaces -- Minimum viable product or Minimum marketable feature set.

                      Having only 3 roles on a team is simplicity....thoughtful reduction of hierarchy within the organization is a step towards simplicity to me.

                      I still have a question, how do you comprehend the sentence "the art of maximizing the amount of work not done--is essential"?

                      Avie
                      www.agilebuddha.com

                      --- In scrumdevelopment@yahoogroups.com, Alan Dayley <alandd@...> wrote:
                      >
                      > Great answers.
                      >
                      > I usually tell the story of a multi-week effort I participated in to create
                      > an interface layer for *possible* varying hardware connections. We never
                      > connected but one type of hardware on that system, weeks wasted and code
                      > not used. This jogs the memory of people when they remember a similar
                      > design, coding or some other effort for "we are going to need it
                      > eventually" purposes that never came to be.
                      >
                      > Talking about focus and producing high quality of the essence of each story
                      > also usually gets nods.
                      >
                      > Alan
                      >
                      > On Tue, Sep 25, 2012 at 10:00 PM, avienaash@...
                      > avienaash@...wrote:
                      >
                      > > **
                      > >
                      > >
                      > > How do you explain one of the agile principles "Simplicity--the art of
                      > > maximizing the amount of work not done--is essential" to a group.
                      > >
                      > > What different examples you all share and how do you make people
                      > > understand this principle.
                      > >
                      > > Thanks,
                      > >
                      > > Avienaash
                      > > www.agilebuddha.com
                      > >
                      > >
                      >
                    • Michael James
                      I think we ve all fallen for this at least once. As a younger man with the coveted software architect job title I was asked to provide a general purpose
                      Message 10 of 28 , Sep 26, 2012
                      • 0 Attachment
                        I think we've all fallen for this at least once.  As a younger man with the coveted "software architect" job title I was asked to provide a general purpose services layer for location based applications on mobile devices.  So I threw in everything and the kitchen sink.  It turned out they only needed a few specific services, which the speculative stuff I built wasn't optimized for. 

                        Ya Ain't Gonna Need It. Strive for simplicity.  Scrum's short timebox and clear Sprint Goals can be used to reduce the inventory of bloated designs.  And please eliminate job titles such as "software architect."

                        --mj

                        On Sep 26, 2012, at 7:01 PM, Alan Dayley <alandd@...> wrote:

                         

                        Great answers.


                        I usually tell the story of a multi-week effort I participated in to create an interface layer for *possible* varying hardware connections.  We never connected but one type of hardware on that system, weeks wasted and code not used.  This jogs the memory of people when they remember a similar design, coding or some other effort for "we are going to need it eventually" purposes that never came to be.

                        Talking about focus and producing high quality of the essence of each story also usually gets nods.

                        Alan

                        On Tue, Sep 25, 2012 at 10:00 PM, avienaash@... <avienaash@...> wrote:
                         

                        How do you explain one of the agile principles "Simplicity--the art of maximizing the amount of work not done--is essential" to a group.

                        What different examples you all share and how do you make people understand this principle.

                        Thanks,

                        Avienaash
                        www.agilebuddha.com 


                      • RonJeffries
                        MJ, Right on! The real skill in these days is to build up that layer bit by bit as we need it. R ... Ron Jeffries www.XProgramming.com Everything that needs to
                        Message 11 of 28 , Sep 27, 2012
                        • 0 Attachment
                          MJ,

                          Right on! The real skill in these days is to build up that layer bit by bit as we need it.

                          R
                          On Sep 27, 2012, at 1:51 AM, Michael James <mj4scrum@...> wrote:

                          I think we've all fallen for this at least once.  As a younger man with the coveted "software architect" job title I was asked to provide a general purpose services layer for location based applications on mobile devices.  So I threw in everything and the kitchen sink.  It turned out they only needed a few specific services, which the speculative stuff I built wasn't optimized for. 

                          Ya Ain't Gonna Need It. Strive for simplicity.  Scrum's short timebox and clear Sprint Goals can be used to reduce the inventory of bloated designs.  And please eliminate job titles such as "software architect."


                          Ron Jeffries
                          www.XProgramming.com
                          Everything that needs to be said has already been said.
                          But since no one was listening, everything must be said again. -- Andre Gide

                        • Cass Dalton
                          And the key word there is inventory. The large designs batches up as one complex unit are equivalent to the inter process inventory that Toyota did away with
                          Message 12 of 28 , Sep 27, 2012
                          • 0 Attachment

                            And the key word there is inventory.  The large designs batches up as one complex unit are equivalent to the inter process inventory that Toyota did away with when developing the Toyota Production System, which is the root of lean production, which is very similar to agile.

                            On Sep 27, 2012 8:41 AM, "RonJeffries" <ronjeffries@...> wrote:
                             

                            MJ,


                            Right on! The real skill in these days is to build up that layer bit by bit as we need it.

                            R
                            On Sep 27, 2012, at 1:51 AM, Michael James <mj4scrum@...> wrote:

                            I think we've all fallen for this at least once.  As a younger man with the coveted "software architect" job title I was asked to provide a general purpose services layer for location based applications on mobile devices.  So I threw in everything and the kitchen sink.  It turned out they only needed a few specific services, which the speculative stuff I built wasn't optimized for. 

                            Ya Ain't Gonna Need It. Strive for simplicity.  Scrum's short timebox and clear Sprint Goals can be used to reduce the inventory of bloated designs.  And please eliminate job titles such as "software architect."


                            Ron Jeffries
                            www.XProgramming.com
                            Everything that needs to be said has already been said.
                            But since no one was listening, everything must be said again. -- Andre Gide

                          • avienaash@ymail.com
                            Thanks everyone for chiming in. This is what comes to mind when I think about simplicity. Simplicity is simplifying work, de-cluttering your mind,
                            Message 13 of 28 , Sep 28, 2012
                            • 0 Attachment
                              Thanks everyone for chiming in.

                              This is what comes to mind when I think about simplicity. Simplicity is simplifying work, de-cluttering your mind, De-cluttering your product. Test driven development follows simplicity. You right just enough code to pass your tests.

                              Just barely good enough(JBGE) thinking is followed across Agile. You write just enough code, just enough features/design, just enough effort to deliver working software, just enough documentation etc.

                              Simplifying is-  de-cluttering your workspace,working in open space.

                              Simplifying mind. Not being manipulative, being honest and open. Scrum thinking of working in small teams, working in small sprints, working on small stories etc all imbibe simplicity thinking.

                              I read some where "The simplest way to achieve simplicity is through thoughtful reduction"

                              Product Owner has to do a lot of De-cluttering of backlog to identify features that will make his product successful. Simplicity facilitates creating product that is easy to use, simple user interfaces -- Minimum viable product or Minimum marketable feature set.

                              Having only 3 roles on a team is simplicity....thoughtful reduction of hierarchy within the organization is step towards simplicity.


                              I see TDD, daily stand-up etc are all processes which implements Simplicity principle.

                              I still have a question, how do you comprehend the sentence "the art of maximizing the amount of work not done--is essential"?

                              Avienaash Shiralige

                              --- In scrumdevelopment@yahoogroups.com, RonJeffries <ronjeffries@...> wrote:
                              >
                              > MJ,
                              >
                              > Right on! The real skill in these days is to build up that layer bit by bit as we need it.
                              >
                              > R
                              > On Sep 27, 2012, at 1:51 AM, Michael James mj4scrum@... wrote:
                              >
                              > > I think we've all fallen for this at least once. As a younger man with the coveted "software architect" job title I was asked to provide a general purpose services layer for location based applications on mobile devices. So I threw in everything and the kitchen sink. It turned out they only needed a few specific services, which the speculative stuff I built wasn't optimized for.
                              > >
                              > > Ya Ain't Gonna Need It. Strive for simplicity. Scrum's short timebox and clear Sprint Goals can be used to reduce the inventory of bloated designs. And please eliminate job titles such as "software architect."
                              >
                              >
                              > Ron Jeffries
                              > www.XProgramming.com
                              > Everything that needs to be said has already been said.
                              > But since no one was listening, everything must be said again. -- Andre Gide
                              >
                            • George Dinwiddie
                              Avienaash, ... When organizations set out to build software, they do many things that they think are a necessary part of the process of building software, but
                              Message 14 of 28 , Sep 28, 2012
                              • 0 Attachment
                                Avienaash,

                                On 9/28/12 6:00 AM, avienaash@... wrote:
                                > I still have a question, how do you comprehend the sentence "the art of
                                > maximizing the amount of work not done--is essential"?

                                When organizations set out to build software, they do many things that
                                they think are a necessary part of the process of building software, but
                                do not, in themselves, contribute to the final product. Consider, for
                                example, the following:
                                - Design documents are not necessary to design software.
                                - Requirements documents are not necessary to understanding the
                                requirements.
                                - Handing off from programmer to tester is not necessary.
                                - Estimating is not necessary for producing software.

                                You may find that these things server a purpose in your organization,
                                even though they do not directly lead to working software. If so, you
                                might consider their purpose, and consider other ways to achieving the
                                same purpose with less time and effort. This would be an example of
                                increasing the amount of work not done.

                                Does that help?

                                - George

                                --
                                ----------------------------------------------------------------------
                                * George Dinwiddie * http://blog.gdinwiddie.com
                                Software Development http://www.idiacomputing.com
                                Consultant and Coach http://www.agilemaryland.org
                                ----------------------------------------------------------------------
                              • Charles Bradley - Scrum Coach CSP CSM PSM
                                Good answer from George. Avienaash, I have always just interpreted that phrase to mean inspecting closely to remove waste in the process.  People often think
                                Message 15 of 28 , Sep 28, 2012
                                • 0 Attachment
                                  Good answer from George.

                                  Avienaash,

                                  I have always just interpreted that phrase to mean inspecting closely to remove waste in the process.  People often think very hard about what they think is needed to accomplish a task.  They usually don't think about what *isn't* needed.  The optimum line between what is really needed, and what isn't really needed, is one that needs to be inspected often, especially with multiple pairs of eyes.
                                   
                                  -------
                                  Charles Bradley
                                  http://www.ScrumCrazy.com




                                  From: George Dinwiddie <lists@...>
                                  To: scrumdevelopment@yahoogroups.com
                                  Sent: Friday, September 28, 2012 11:16 AM
                                  Subject: Re: [scrumdevelopment] Re: How do you explain one of the agile principles "Simplicity" to a group

                                  Avienaash,

                                  On 9/28/12 6:00 AM, avienaash@... wrote:
                                  > I still have a question, how do you comprehend the sentence "the art of
                                  > maximizing the amount of work not done--is essential"?

                                  When organizations set out to build software, they do many things that
                                  they think are a necessary part of the process of building software, but
                                  do not, in themselves, contribute to the final product. Consider, for
                                  example, the following:
                                    - Design documents are not necessary to design software.
                                    - Requirements documents are not necessary to understanding the
                                  requirements.
                                    - Handing off from programmer to tester is not necessary.
                                    - Estimating is not necessary for producing software.

                                  You may find that these things server a purpose in your organization,
                                  even though they do not directly lead to working software. If so, you
                                  might consider their purpose, and consider other ways to achieving the
                                  same purpose with less time and effort. This would be an example of
                                  increasing the amount of work not done.

                                  Does that help?

                                    - George

                                  --
                                    ----------------------------------------------------------------------
                                    * George Dinwiddie *                      http://blog.gdinwiddie.com
                                    Software Development                    http://www.idiacomputing.com
                                    Consultant and Coach                    http://www.agilemaryland.org
                                    ----------------------------------------------------------------------



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

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

                                  <*> To visit your group on the web, go to:
                                      http://groups.yahoo.com/group/scrumdevelopment/

                                  <*> Your email settings:
                                      Individual Email | Traditional

                                  <*> To change settings online go to:
                                      http://groups.yahoo.com/group/scrumdevelopment/join
                                      (Yahoo! ID required)

                                  <*> To change settings via email:
                                      scrumdevelopment-digest@yahoogroups.com
                                      scrumdevelopment-fullfeatured@yahoogroups.com

                                  <*> To unsubscribe from this group, send an email to:
                                      scrumdevelopment-unsubscribe@yahoogroups.com

                                  <*> Your use of Yahoo! Groups is subject to:
                                      http://docs.yahoo.com/info/terms/



                                • Cass Dalton
                                  One common example is the tendency of developers to want to design the generic, scalable framework first, before having more than one real example to implement
                                  Message 16 of 28 , Sep 28, 2012
                                  • 0 Attachment

                                    One common example is the tendency of developers to want to design the generic, scalable framework first, before having more than one real example to implement that uses the framework.  You never really know what generality you really need until you have several data points.  The leaner/agile solution would be to write the first implementation in the simple almost hackish way just to get the thing in front of people.  Once you have a need for a second or third case, then have a much better idea of how much of your generic framework is really generic and how much of what you would have written into the framework was either unneeded fluff or actually specific to the first implementation.  In this case, the simplicity allows you to not over engineer the software.

                                    On Sep 28, 2012 1:16 PM, "George Dinwiddie" <lists@...> wrote:
                                     

                                    Avienaash,

                                    On 9/28/12 6:00 AM, avienaash@... wrote:
                                    > I still have a question, how do you comprehend the sentence "the art of
                                    > maximizing the amount of work not done--is essential"?

                                    When organizations set out to build software, they do many things that
                                    they think are a necessary part of the process of building software, but
                                    do not, in themselves, contribute to the final product. Consider, for
                                    example, the following:
                                    - Design documents are not necessary to design software.
                                    - Requirements documents are not necessary to understanding the
                                    requirements.
                                    - Handing off from programmer to tester is not necessary.
                                    - Estimating is not necessary for producing software.

                                    You may find that these things server a purpose in your organization,
                                    even though they do not directly lead to working software. If so, you
                                    might consider their purpose, and consider other ways to achieving the
                                    same purpose with less time and effort. This would be an example of
                                    increasing the amount of work not done.

                                    Does that help?

                                    - George

                                    --
                                    ----------------------------------------------------------
                                    * George Dinwiddie * http://blog.gdinwiddie.com
                                    Software Development http://www.idiacomputing.com
                                    Consultant and Coach http://www.agilemaryland.org
                                    ----------------------------------------------------------

                                  • Daniel Wildt
                                    Every time I don t need to do something in my codebase, I m achieving simplicity. :-) It s the art of maximizing the work that is not being done right? --
                                    Message 17 of 28 , Sep 28, 2012
                                    • 0 Attachment
                                      Every time I don't need to do something in my codebase, I'm achieving simplicity. :-)

                                      It's the art of maximizing the work that is not being done right? 

                                      -- Daniel Wildt @dwildt


                                      On Fri, Sep 28, 2012 at 2:31 PM, Charles Bradley - Scrum Coach CSP CSM PSM I <chuck-lists2@...> wrote:
                                       

                                      Good answer from George.

                                      Avienaash,

                                      I have always just interpreted that phrase to mean inspecting closely to remove waste in the process.  People often think very hard about what they think is needed to accomplish a task.  They usually don't think about what *isn't* needed.  The optimum line between what is really needed, and what isn't really needed, is one that needs to be inspected often, especially with multiple pairs of eyes.
                                       
                                      -------
                                      Charles Bradley
                                      http://www.ScrumCrazy.com




                                      From: George Dinwiddie <lists@...>
                                      To: scrumdevelopment@yahoogroups.com
                                      Sent: Friday, September 28, 2012 11:16 AM
                                      Subject: Re: [scrumdevelopment] Re: How do you explain one of the agile principles "Simplicity" to a group

                                      Avienaash,

                                      On 9/28/12 6:00 AM, avienaash@... wrote:
                                      > I still have a question, how do you comprehend the sentence "the art of
                                      > maximizing the amount of work not done--is essential"?

                                      When organizations set out to build software, they do many things that
                                      they think are a necessary part of the process of building software, but
                                      do not, in themselves, contribute to the final product. Consider, for
                                      example, the following:
                                        - Design documents are not necessary to design software.
                                        - Requirements documents are not necessary to understanding the
                                      requirements.
                                        - Handing off from programmer to tester is not necessary.
                                        - Estimating is not necessary for producing software.

                                      You may find that these things server a purpose in your organization,
                                      even though they do not directly lead to working software. If so, you
                                      might consider their purpose, and consider other ways to achieving the
                                      same purpose with less time and effort. This would be an example of
                                      increasing the amount of work not done.

                                      Does that help?

                                        - George

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

                                        * George Dinwiddie *                      http://blog.gdinwiddie.com
                                        Software Development                    http://www.idiacomputing.com
                                        Consultant and Coach                    http://www.agilemaryland.org
                                        ----------------------------------------------------------------------



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


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

                                      <*> To visit your group on the web, go to:
                                          http://groups.yahoo.com/group/scrumdevelopment/

                                      <*> Your email settings:
                                          Individual Email | Traditional

                                      <*> To change settings online go to:
                                          http://groups.yahoo.com/group/scrumdevelopment/join
                                          (Yahoo! ID required)

                                      <*> To change settings via email:
                                          scrumdevelopment-digest@yahoogroups.com
                                          scrumdevelopment-fullfeatured@yahoogroups.com

                                      <*> To unsubscribe from this group, send an email to:
                                          scrumdevelopment-unsubscribe@yahoogroups.com

                                      <*> Your use of Yahoo! Groups is subject to:
                                          http://docs.yahoo.com/info/terms/




                                    • Daniel Wildt
                                      You can also think of every time you don t need to build a whole new feature but enhance one that already exist. That s also a way to look for simplicity. --
                                      Message 18 of 28 , Sep 28, 2012
                                      • 0 Attachment
                                        You can also think of every time you don't need to build a whole new feature but enhance one that already exist. That's also a way to look for simplicity. 

                                        -- Daniel Wildt @dwildt


                                        On Fri, Sep 28, 2012 at 5:51 PM, Daniel Wildt <dwildt@...> wrote:
                                        Every time I don't need to do something in my codebase, I'm achieving simplicity. :-)

                                        It's the art of maximizing the work that is not being done right? 

                                        -- Daniel Wildt @dwildt



                                        On Fri, Sep 28, 2012 at 2:31 PM, Charles Bradley - Scrum Coach CSP CSM PSM I <chuck-lists2@...> wrote:
                                         

                                        Good answer from George.

                                        Avienaash,

                                        I have always just interpreted that phrase to mean inspecting closely to remove waste in the process.  People often think very hard about what they think is needed to accomplish a task.  They usually don't think about what *isn't* needed.  The optimum line between what is really needed, and what isn't really needed, is one that needs to be inspected often, especially with multiple pairs of eyes.
                                         
                                        -------
                                        Charles Bradley
                                        http://www.ScrumCrazy.com




                                        From: George Dinwiddie <lists@...>
                                        To: scrumdevelopment@yahoogroups.com
                                        Sent: Friday, September 28, 2012 11:16 AM
                                        Subject: Re: [scrumdevelopment] Re: How do you explain one of the agile principles "Simplicity" to a group

                                        Avienaash,

                                        On 9/28/12 6:00 AM, avienaash@... wrote:
                                        > I still have a question, how do you comprehend the sentence "the art of
                                        > maximizing the amount of work not done--is essential"?

                                        When organizations set out to build software, they do many things that
                                        they think are a necessary part of the process of building software, but
                                        do not, in themselves, contribute to the final product. Consider, for
                                        example, the following:
                                          - Design documents are not necessary to design software.
                                          - Requirements documents are not necessary to understanding the
                                        requirements.
                                          - Handing off from programmer to tester is not necessary.
                                          - Estimating is not necessary for producing software.

                                        You may find that these things server a purpose in your organization,
                                        even though they do not directly lead to working software. If so, you
                                        might consider their purpose, and consider other ways to achieving the
                                        same purpose with less time and effort. This would be an example of
                                        increasing the amount of work not done.

                                        Does that help?

                                          - George

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

                                          * George Dinwiddie *                      http://blog.gdinwiddie.com
                                          Software Development                    http://www.idiacomputing.com
                                          Consultant and Coach                    http://www.agilemaryland.org
                                          ----------------------------------------------------------------------



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


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

                                        <*> To visit your group on the web, go to:
                                            http://groups.yahoo.com/group/scrumdevelopment/

                                        <*> Your email settings:
                                            Individual Email | Traditional

                                        <*> To change settings online go to:
                                            http://groups.yahoo.com/group/scrumdevelopment/join
                                            (Yahoo! ID required)

                                        <*> To change settings via email:
                                            scrumdevelopment-digest@yahoogroups.com
                                            scrumdevelopment-fullfeatured@yahoogroups.com

                                        <*> To unsubscribe from this group, send an email to:
                                            scrumdevelopment-unsubscribe@yahoogroups.com

                                        <*> Your use of Yahoo! Groups is subject to:
                                            http://docs.yahoo.com/info/terms/





                                      • avienaash@ymail.com
                                        George - very good example. Well articulated.Thanks.
                                        Message 19 of 28 , Sep 28, 2012
                                        • 0 Attachment
                                          George - very good example. Well articulated.Thanks.

                                          --- In scrumdevelopment@yahoogroups.com, George Dinwiddie <lists@...> wrote:
                                          >
                                          > Avienaash,
                                          >
                                          > On 9/28/12 6:00 AM, avienaash@... wrote:
                                          > > I still have a question, how do you comprehend the sentence "the art of
                                          > > maximizing the amount of work not done--is essential"?
                                          >
                                          > When organizations set out to build software, they do many things that
                                          > they think are a necessary part of the process of building software, but
                                          > do not, in themselves, contribute to the final product. Consider, for
                                          > example, the following:
                                          > - Design documents are not necessary to design software.
                                          > - Requirements documents are not necessary to understanding the
                                          > requirements.
                                          > - Handing off from programmer to tester is not necessary.
                                          > - Estimating is not necessary for producing software.
                                          >
                                          > You may find that these things server a purpose in your organization,
                                          > even though they do not directly lead to working software. If so, you
                                          > might consider their purpose, and consider other ways to achieving the
                                          > same purpose with less time and effort. This would be an example of
                                          > increasing the amount of work not done.
                                          >
                                          > Does that help?
                                          >
                                          > - George
                                          >
                                          > --
                                          > ----------------------------------------------------------------------
                                          > * George Dinwiddie * http://blog.gdinwiddie.com
                                          > Software Development http://www.idiacomputing.com
                                          > Consultant and Coach http://www.agilemaryland.org
                                          > ----------------------------------------------------------------------
                                          >
                                        • huetlandry
                                          Scope: Large systems and distributed teams working on Lean/Agile/Scrum etc. To date, I have not seen any tools for tracking Kanban/Scrum stories that
                                          Message 20 of 28 , Oct 4, 2012
                                          • 0 Attachment
                                            Scope: Large systems and distributed teams working on Lean/Agile/Scrum etc.

                                            To date, I have not seen any tools for tracking Kanban/Scrum stories that explicitly limit the size of story text or number of acceptance criteria. With many new teams using these tools, there is a tendancy for story size or the collection of acceptance criteria to grow quickly.

                                            A good coach will catch this trend, and some tools allow size of stories and numbers of criteria to be controlled in some fashion, but that means more work for the tool admin (or the Team).

                                            Even systems that use virtual "card" spaces tend to have little or no control out of the box for story size, though many limit the display size.

                                            (An interesting option would be to scale the stories and criteria to fit on a smartphone screen, but then w'd need two-sided phones to capture the backs of the cards. <g> )

                                            Comments, anyone?
                                          • Kevin Callahan
                                            ... Think you nailed it there :) The board is the artifact of agreement and commitment; the stories of conversations. If the artifacts smell, it seems likely
                                            Message 21 of 28 , Oct 4, 2012
                                            • 0 Attachment

                                              A good coach will catch this trend

                                              Think you nailed it there :) The board is the artifact of agreement and commitment; the stories of conversations. If the artifacts smell, it seems likely the interactions that produced them need work. A smaller piece of something rotten is still rotten :/

                                              -k

                                              On Oct 4, 2012, at 11:23 AM, huetlandry wrote:

                                               

                                              Scope: Large systems and distributed teams working on Lean/Agile/Scrum etc.

                                              To date, I have not seen any tools for tracking Kanban/Scrum stories that explicitly limit the size of story text or number of acceptance criteria. With many new teams using these tools, there is a tendancy for story size or the collection of acceptance criteria to grow quickly.

                                              A good coach will catch this trend, and some tools allow size of stories and numbers of criteria to be controlled in some fashion, but that means more work for the tool admin (or the Team).

                                              Even systems that use virtual "card" spaces tend to have little or no control out of the box for story size, though many limit the display size.

                                              (An interesting option would be to scale the stories and criteria to fit on a smartphone screen, but then w'd need two-sided phones to capture the backs of the cards. <g> )

                                              Comments, anyone?


                                              Kevin Callahan, CSP
                                              Scrum Master
                                              mobile: 207-691-2997
                                              AIM: kevmocal


                                            • Dan Greening
                                              My thinking is that arbitrary limits imposed by tools on individual teams are local optimizations, that contribute little or nothing to overall success. If
                                              Message 22 of 28 , Oct 4, 2012
                                              • 0 Attachment
                                                My thinking is that arbitrary limits imposed by tools on individual teams are "local optimizations," that contribute little or nothing to overall success. If your team could be run-by-robot, we would have invented robots by now that would make your team succeed. Hasn't happened yet.

                                                You should have an education program across the company that allows people to learn good PBI-writing skills, but don't make the tool enforce too many constraints. There's no "authority" that will argue ALL stories should have a certain form, etc.

                                                When people ask questions like this, I worry that they are limiting their view to "only what they control," namely the teams, but that may indicate the company has rigid communications and authority structures that limit productivity gains. So I counter by asking questions like these:
                                                1. Is there an adequate ScrumMaster community in the company, where ScrumMasters can share their ideas and practices, and where ScrumMasters can provide mutual support and motivation for continuous improvement?
                                                2. How is the communication between middle-level managers and ScrumMasters, not just within particular product silos, but across the company?
                                                3. What escalation paths do you have between teams and higher-level people to remove impediments (like cross-team dependencies) rapidly?
                                                4. Are the managers collaborating on strategic activities (i.e. activities that affect most people in engineering or multiple departments, like HR policies, etc.), and if so, are they involving representatives from the teams?
                                                5. Is there a training program that helps people advance their skills, not only with basic ScrumMaster and Product Owner behavior, but also well-beyond that, such as value stream analysis, A3, root cause, etc.?
                                                Anyway, maybe you can see my drift. I think as ScrumMasters, particularly in larger companies, we get stuck in a rut of optimizing only-the-team, but larger organizational issues probably impede your team's ability to contribute to the company's profitability and mission more than the specific structures of individual PBIs.  

                                                If you raise your eyes above the team boundary, you will likely find lots of ways to dramatically improve the company. Figuring out how to do this diplomatically will be an important learning experience, and could significantly advance your career (if you are careful).

                                                Dan Greening
                                                +1 (415) 754-8311

                                                On Thu, Oct 4, 2012 at 8:23 AM, huetlandry <hlandry@...> wrote:
                                                 

                                                Scope: Large systems and distributed teams working on Lean/Agile/Scrum etc.

                                                To date, I have not seen any tools for tracking Kanban/Scrum stories that explicitly limit the size of story text or number of acceptance criteria. With many new teams using these tools, there is a tendancy for story size or the collection of acceptance criteria to grow quickly.

                                                A good coach will catch this trend, and some tools allow size of stories and numbers of criteria to be controlled in some fashion, but that means more work for the tool admin (or the Team).

                                                Even systems that use virtual "card" spaces tend to have little or no control out of the box for story size, though many limit the display size.

                                                (An interesting option would be to scale the stories and criteria to fit on a smartphone screen, but then w'd need two-sided phones to capture the backs of the cards. <g> )

                                                Comments, anyone?


                                              • Charles Bradley - Scrum Coach CSP CSM PSM
                                                huetlandry, Are you suggesting that the tools mimic the physical limitation of the amount of stuff that can fit on a 5 x 8 User Story (index) card?   ...
                                                Message 23 of 28 , Oct 5, 2012
                                                • 0 Attachment
                                                  huetlandry,

                                                  Are you suggesting that the tools mimic the physical limitation of the amount of stuff that can fit on a 5" x 8" User Story (index) card?
                                                   
                                                  -------
                                                  Charles Bradley
                                                  http://www.ScrumCrazy.com




                                                  From: huetlandry <hlandry@...>
                                                  To: scrumdevelopment@yahoogroups.com
                                                  Sent: Thursday, October 4, 2012 9:23 AM
                                                  Subject: [scrumdevelopment] "Simplicity" and tools

                                                  Scope:  Large systems and distributed teams working on Lean/Agile/Scrum etc.

                                                  To date, I have not seen any tools for tracking Kanban/Scrum stories that explicitly limit the size of story text or number of acceptance criteria.  With many new teams using these tools, there is a tendancy for story size or the collection of acceptance criteria to grow quickly.

                                                  A good coach will catch this trend, and some tools allow size of stories and numbers of criteria to be controlled in some fashion, but that means more work for the tool admin (or the Team).

                                                  Even systems that use virtual "card" spaces tend to have little or no control out of the box for story size, though many limit the display size.

                                                  (An interesting option would be to scale the stories and criteria to fit on a smartphone screen, but then w'd need two-sided phones to capture the backs of the cards. <g> )

                                                  Comments, anyone?



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

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

                                                  <*> To visit your group on the web, go to:
                                                      http://groups.yahoo.com/group/scrumdevelopment/

                                                  <*> Your email settings:
                                                      Individual Email | Traditional

                                                  <*> To change settings online go to:
                                                      http://groups.yahoo.com/group/scrumdevelopment/join
                                                      (Yahoo! ID required)

                                                  <*> To change settings via email:
                                                      scrumdevelopment-digest@yahoogroups.com
                                                      scrumdevelopment-fullfeatured@yahoogroups.com

                                                  <*> To unsubscribe from this group, send an email to:
                                                      scrumdevelopment-unsubscribe@yahoogroups.com

                                                  <*> Your use of Yahoo! Groups is subject to:
                                                      http://docs.yahoo.com/info/terms/



                                                • RonJeffries
                                                  Charles, ... If a 5x8 is not large enough, use a 3x5. Ron Jeffries www.XProgramming.com It s true hard work never killed anybody, but I figure, why take the
                                                  Message 24 of 28 , Oct 5, 2012
                                                  • 0 Attachment
                                                    Charles,

                                                    On Oct 5, 2012, at 3:59 PM, Charles Bradley - Scrum Coach CSP CSM PSM I <chuck-lists2@...> wrote:

                                                    Are you suggesting that the tools mimic the physical limitation of the amount of stuff that can fit on a 5" x 8" User Story (index) card?

                                                    If a 5x8 is not large enough, use a 3x5.

                                                    Ron Jeffries
                                                    www.XProgramming.com
                                                    It's true hard work never killed anybody, but I figure, why take the chance?
                                                    -- Ronald Reagan



                                                  • Charles Bradley - Scrum Coach CSP CSM PSM
                                                    Amen.   ... Charles Bradley http://www.ScrumCrazy.com ... Amen. ------- Charles Bradley http://www.ScrumCrazy.com From: RonJeffries To:
                                                    Message 25 of 28 , Oct 5, 2012
                                                    • 0 Attachment
                                                      Amen.
                                                       
                                                      -------
                                                      Charles Bradley
                                                      http://www.ScrumCrazy.com




                                                      From: RonJeffries <ronjeffries@...>
                                                      To: scrumdevelopment@yahoogroups.com
                                                      Sent: Friday, October 5, 2012 2:14 PM
                                                      Subject: Re: [scrumdevelopment] "Simplicity" and tools



                                                      Charles,

                                                      On Oct 5, 2012, at 3:59 PM, Charles Bradley - Scrum Coach CSP CSM PSM I <chuck-lists2@...> wrote:

                                                      Are you suggesting that the tools mimic the physical limitation of the amount of stuff that can fit on a 5" x 8" User Story (index) card?

                                                      If a 5x8 is not large enough, use a 3x5.

                                                      Ron Jeffries
                                                      www.XProgramming.com
                                                      It's true hard work never killed anybody, but I figure, why take the chance?
                                                      -- Ronald Reagan







                                                    • Huet
                                                      That would be one approach, along with automatic downsizing when too many stories push the limits ;-) Another would be a kind of dashboard indicator of story
                                                      Message 26 of 28 , Oct 10, 2012
                                                      • 0 Attachment
                                                        That would be one approach, along with automatic downsizing when too many stories push the limits ;-)

                                                        Another would be a kind of dashboard indicator of story size and number of acceptance criteria across the enterprise.

                                                        Mostly, I was wondering if the issue has risen to the point where vendors had started to address it in their tools.

                                                        I'm not really looking for a tool to do this, but I have a customer that is in the storming/forming stage for a large enterprise agile adoption (be afraid.) There are many coaches/Scrum Masters and we have not formed a community (yet) to address this kind of issue across teams. Various tools are being used, with SharePoint being prominent. As expected, most teams have "smelly" processes, and story size/number of acceptance criteria is one of them.

                                                        These issues are being addressed by the teams, but having a tool that encourages minimization would be a help.

                                                        Thanks for the comments!
                                                        Huet

                                                        --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSP CSM PSM I <chuck-lists2@...> wrote:
                                                        >
                                                        > huetlandry,
                                                        >
                                                        > Are you suggesting that the tools mimic the physical limitation of the amount of stuff that can fit on a 5" x 8" User Story (index) card?
                                                        >
                                                        >  
                                                        > -------
                                                        > Charles Bradley
                                                        > http://www.ScrumCrazy.com
                                                        >
                                                        >
                                                        >
                                                        >
                                                        >
                                                        > >________________________________
                                                        > > From: huetlandry <hlandry@...>
                                                        > >To: scrumdevelopment@yahoogroups.com
                                                        > >Sent: Thursday, October 4, 2012 9:23 AM
                                                        > >Subject: [scrumdevelopment] "Simplicity" and tools
                                                        > >
                                                        > >Scope:  Large systems and distributed teams working on Lean/Agile/Scrum etc.
                                                        > >
                                                        > >To date, I have not seen any tools for tracking Kanban/Scrum stories that explicitly limit the size of story text or number of acceptance criteria.  With many new teams using these tools, there is a tendancy for story size or the collection of acceptance criteria to grow quickly.
                                                        > >
                                                        > >A good coach will catch this trend, and some tools allow size of stories and numbers of criteria to be controlled in some fashion, but that means more work for the tool admin (or the Team).
                                                        > >
                                                        > >Even systems that use virtual "card" spaces tend to have little or no control out of the box for story size, though many limit the display size.
                                                        > >
                                                        > >(An interesting option would be to scale the stories and criteria to fit on a smartphone screen, but then w'd need two-sided phones to capture the backs of the cards. <g> )
                                                        > >
                                                        > >Comments, anyone?
                                                        > >
                                                        > >
                                                        > >
                                                        > >------------------------------------
                                                        > >
                                                        > >To Post a message, send it to:  scrumdevelopment@...
                                                        > >To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                                                        > >
                                                        > >
                                                        > >
                                                        > >
                                                        > >
                                                        > >
                                                        >
                                                      • Charles Bradley - Scrum Coach CSP CSM PSM
                                                        Huet, I haven t seen a tool yet that in any way helps the user see that maybe a story is too big -- like what you re suggesting.  However, I think there is
                                                        Message 27 of 28 , Oct 10, 2012
                                                        • 0 Attachment
                                                          Huet,

                                                          I haven't seen a tool yet that in any way helps the user see that maybe a story is too big -- like what you're suggesting.  However, I think there is some merit there, and it would be cool if that was possible.

                                                          One tool I've seen, Pivotal Tracker tends to influence your Scrum/User Story implementation in a way similar to what you're suggesting.  For instance,
                                                          by default,
                                                          • the tool does not let you assign story points to bugs. 
                                                            • There is a setting to override this.  That setting says "Strongly discouraged!  Read More..." and it explains the reasons pretty well.
                                                          • the tool averages the velocity of the last 3 sprints and only puts that velocity worth of stuff into the current/next sprint -- and doesn't let you change it.
                                                            • There are ways to override this in the project settings-- the choices are average of last (1,2,3,4) sprints, or complete override for the current sprint (called "commit mode")
                                                          Tracker has other advantages and disadvantages I won't go into here.

                                                          My general philosophy on these things is that I like that the tools strongly push you towards the most accepted practices (GASPs?), but I think there should almost always be a way to override this behavior.  I'd even be ok with a message pop up every now and then that explains why you might not want to do something... so long as I can turn that off easily.  :-)
                                                           
                                                          -------
                                                          Charles Bradley
                                                          http://www.ScrumCrazy.com




                                                          From: Huet <hlandry@...>
                                                          To: scrumdevelopment@yahoogroups.com
                                                          Sent: Wednesday, October 10, 2012 11:37 AM
                                                          Subject: [scrumdevelopment] Re: "Simplicity" and tools

                                                          That would be one approach, along with automatic downsizing when too many stories push the limits ;-)

                                                          Another would be a kind of dashboard indicator of story size and number of acceptance criteria across the enterprise.

                                                          Mostly, I was wondering if the issue has risen to the point where vendors had started to address it in their tools.

                                                          I'm not really looking for a tool to do this, but I have a customer that is in the storming/forming stage for a large enterprise agile adoption (be afraid.)  There are many coaches/Scrum Masters and we have not formed a community (yet) to address this kind of issue across teams.  Various tools are being used, with SharePoint being prominent.  As expected, most teams have "smelly" processes, and story size/number of acceptance criteria is one of them.

                                                          These issues are being addressed by the teams, but having a tool that encourages minimization would be a help.

                                                          Thanks for the comments!
                                                          Huet

                                                          --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSP CSM PSM I <chuck-lists2@...> wrote:
                                                          >
                                                          > huetlandry,
                                                          >
                                                          > Are you suggesting that the tools mimic the physical limitation of the amount of stuff that can fit on a 5" x 8" User Story (index) card?
                                                          >
                                                          >  
                                                          > -------
                                                          > Charles Bradley
                                                          > http://www.ScrumCrazy.com
                                                          >
                                                          >
                                                          >
                                                          >
                                                          >
                                                          > >________________________________
                                                          > > From: huetlandry <hlandry@...>
                                                          > >To: scrumdevelopment@yahoogroups.com
                                                          > >Sent: Thursday, October 4, 2012 9:23 AM
                                                          > >Subject: [scrumdevelopment] "Simplicity" and tools
                                                          > >
                                                          > >Scope:  Large systems and distributed teams working on Lean/Agile/Scrum etc.
                                                          > >
                                                          > >To date, I have not seen any tools for tracking Kanban/Scrum stories that explicitly limit the size of story text or number of acceptance criteria.  With many new teams using these tools, there is a tendancy for story size or the collection of acceptance criteria to grow quickly.
                                                          > >
                                                          > >A good coach will catch this trend, and some tools allow size of stories and numbers of criteria to be controlled in some fashion, but that means more work for the tool admin (or the Team).
                                                          > >
                                                          > >Even systems that use virtual "card" spaces tend to have little or no control out of the box for story size, though many limit the display size.
                                                          > >
                                                          > >(An interesting option would be to scale the stories and criteria to fit on a smartphone screen, but then w'd need two-sided phones to capture the backs of the cards. <g> )
                                                          > >
                                                          > >Comments, anyone?
                                                          > >
                                                          > >
                                                          > >
                                                          > >------------------------------------
                                                          > >
                                                          > >To Post a message, send it to:  scrumdevelopment@...
                                                          > >To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                                                          > >
                                                          > >
                                                          > >
                                                          > >
                                                          > >
                                                          > >
                                                          >




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

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

                                                          <*> To visit your group on the web, go to:
                                                              http://groups.yahoo.com/group/scrumdevelopment/

                                                          <*> Your email settings:
                                                              Individual Email | Traditional

                                                          <*> To change settings online go to:
                                                              http://groups.yahoo.com/group/scrumdevelopment/join
                                                              (Yahoo! ID required)

                                                          <*> To change settings via email:
                                                              scrumdevelopment-digest@yahoogroups.com
                                                              scrumdevelopment-fullfeatured@yahoogroups.com

                                                          <*> To unsubscribe from this group, send an email to:
                                                              scrumdevelopment-unsubscribe@yahoogroups.com

                                                          <*> Your use of Yahoo! Groups is subject to:
                                                              http://docs.yahoo.com/info/terms/



                                                        • George Dinwiddie
                                                          Huet, ... If you can get people to come up with the concrete examples that illustrate the acceptance criteria, you not only get a solid indicator of stories
                                                          Message 28 of 28 , Oct 13, 2012
                                                          • 0 Attachment
                                                            Huet,

                                                            On 10/10/12 1:37 PM, Huet wrote:
                                                            > That would be one approach, along with automatic downsizing when too
                                                            > many stories push the limits ;-)
                                                            >
                                                            > Another would be a kind of dashboard indicator of story size and
                                                            > number of acceptance criteria across the enterprise.
                                                            >
                                                            > Mostly, I was wondering if the issue has risen to the point where
                                                            > vendors had started to address it in their tools.
                                                            >
                                                            > I'm not really looking for a tool to do this, but I have a customer
                                                            > that is in the storming/forming stage for a large enterprise agile
                                                            > adoption (be afraid.) There are many coaches/Scrum Masters and we
                                                            > have not formed a community (yet) to address this kind of issue
                                                            > across teams. Various tools are being used, with SharePoint being
                                                            > prominent. As expected, most teams have "smelly" processes, and
                                                            > story size/number of acceptance criteria is one of them.
                                                            >
                                                            > These issues are being addressed by the teams, but having a tool that
                                                            > encourages minimization would be a help.

                                                            If you can get people to come up with the concrete examples that
                                                            illustrate the acceptance criteria, you not only get a solid indicator
                                                            of stories that are too big, but an indicator of the "fault lines" for
                                                            splitting the story.

                                                            - George

                                                            --
                                                            ----------------------------------------------------------------------
                                                            * George Dinwiddie * http://blog.gdinwiddie.com
                                                            Software Development http://www.idiacomputing.com
                                                            Consultant and Coach http://www.agilemaryland.org
                                                            ----------------------------------------------------------------------
                                                          Your message has been successfully submitted and would be delivered to recipients shortly.