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

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

Expand Messages
  • 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 1 of 28 , Sep 26, 2012
      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
      > >
      > >
      >
    • 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 2 of 28 , Sep 27, 2012

        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 3 of 28 , Sep 28, 2012
          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 4 of 28 , Sep 28, 2012
            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 5 of 28 , Sep 28, 2012
              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 6 of 28 , Sep 28, 2012

                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 7 of 28 , Sep 28, 2012
                  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 8 of 28 , Sep 28, 2012
                    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 9 of 28 , Sep 28, 2012
                      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 10 of 28 , Oct 4, 2012
                        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 11 of 28 , Oct 4, 2012

                          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 12 of 28 , Oct 4, 2012
                            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 13 of 28 , Oct 5, 2012
                              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 14 of 28 , Oct 5, 2012
                                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 15 of 28 , Oct 5, 2012
                                  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 16 of 28 , Oct 10, 2012
                                    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 17 of 28 , Oct 10, 2012
                                      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 18 of 28 , Oct 13, 2012
                                        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.