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

Re: [scrumdevelopment] Nesting weekly iterations within monthly sprints

Expand Messages
  • David Vydra
    Daniel, ... is a long time . We re like the primitive tribe whose counting system goes 1, 2, 3, many. A month is on the many side. The brain doesn t seem
    Message 1 of 14 , Dec 2, 2003
    • 0 Attachment
      Daniel,
      >
      > We seem to be running up against a basic block: psychologically, a month
      is "a long time". We're like the primitive tribe whose counting system goes
      "1, 2, 3, many." A month is on the "many" side. The brain doesn't seem to
      take it seriously enough. Only when the deadline (the sprint review) moves
      within the 'serious' range does reality kick in. At that point focus seems
      to occur spontaneously. But we're left regretting our lack of focus earlier
      in the sprint.
      >

      This is a very interesting observation. I wonder if the 'slack' that you
      feel in week one is actually good for the process. Often you need to be
      'relaxed' when experimenting or learning.

      This question has come up many times before. I will make a prediction that
      many mature Agile teams will move to a variable length iteration, perhaps on
      a bell curve, because at the beginning and tail end of a project shorter
      iterations seem more appropriate. (hmm, this idea may earn me some serious
      flame)

      Regards,
      David
    • Ron Jeffries
      ... Yes ... C3 ran one-week iterations for quite a while prior to one release. That s the longest time I ve ever spent in that mode. I found it tiring and
      Message 2 of 14 , Dec 3, 2003
      • 0 Attachment
        On Wednesday, December 3, 2003, at 2:27:36 AM, David Vydra wrote:

        > This is a very interesting observation. I wonder if the 'slack' that you
        > feel in week one is actually good for the process. Often you need to be
        > 'relaxed' when experimenting or learning.

        Yes ...

        C3 ran one-week iterations for quite a while prior to one release. That's
        the longest time I've ever spent in that mode. I found it tiring and
        maddening after a while, like pounding away at a dead run forever. I
        believe that most of the team found it so.

        An interation seems to want to have a kind of relaxed opening. Warming up,
        stretching the muscles, finding where we are tight or a little bit achy.
        Then we reach our stride, moving along at our best pace, running almost
        effortlessly, as if we could do it forever. Then the finish line looms. We
        gather it all up and push hard, down to the end.

        In XP, it's probably not good to collapse at the finish line like a runner
        who has given it all. But there is a sense of a gathering final sprint
        nonetheless.

        > This question has come up many times before. I will make a prediction that
        > many mature Agile teams will move to a variable length iteration, perhaps on
        > a bell curve, because at the beginning and tail end of a project shorter
        > iterations seem more appropriate.

        I'm inclined, almost, to agree. A sharp team can start at one week -- I'm
        working with one now who, despite just beginning with XP, are doing fine.
        On the other hand, the first few iterations were pretty shaky.

        I do believe that the one-week cycle enables -- requires -- the team to
        learn how to break big things down into fine bites, and that has immense
        value. Most teams feel that they can do almost anything in a month, and
        they're right. What they don't know is that almost anything can be broken
        down into steps that take a day -- even a couple of hours. That's well
        worth learning.

        I still fear one-month iterations. But Scrum does them successfully, and
        Alistair has seen them work successfully, so I don't doubt that they can be
        good. I do think that two weeks, or even one, will shake out a higher level
        of performance and learning of a certain kind. But one-weekers for a year?
        I don't think I'd like that either.


        Something to think about: If an iteration works well when it can have a
        sense of loosening up, hitting stride, sprinting to the finish, perhaps a
        project should have that same feeling. Perhaps variable-length iterations
        could give it that.

        Ron Jeffries
        www.XProgramming.com
        FEAR = Fantasy Experienced As Reality
      • slightlynew
        Brad, ... I was in a discussion of this topic only yesterday. Can you provide a link to this article? Daniel
        Message 3 of 14 , Dec 3, 2003
        • 0 Attachment
          Brad,

          > I remember a short article written by Jim Highsmith entitled
          > "Release, Milestone and Iteration Planning" which described
          > the need for all three of those things in an agile project
          > (i.e. a Release plan that has both milestones and iterations
          > planned within it) where the iterations are smaller-grained
          > than the milestones

          I was in a discussion of this topic only yesterday. Can you provide a
          link to this article?

          Daniel
        • Brad Appleton
          ... I looked for it on Google and at the cutter sight as well as Highsmith s site. Alas I could not find it. I can send you a copy of the email I received - I
          Message 4 of 14 , Dec 3, 2003
          • 0 Attachment
            On Wed, Dec 03, 2003 at 05:29:00PM -0000, slightlynew wrote:
            > Brad,
            >
            > > I remember a short article written by Jim Highsmith entitled
            > > "Release, Milestone and Iteration Planning" which described
            > > the need for all three of those things in an agile project
            > > (i.e. a Release plan that has both milestones and iterations
            > > planned within it) where the iterations are smaller-grained
            > > than the milestones
            >
            > I was in a discussion of this topic only yesterday. Can you provide a
            > link to this article?

            I looked for it on Google and at the cutter sight as well as Highsmith's site.
            Alas I could not find it. I can send you a copy of the email I received - I worry about posting it to the list in its entirety without permission. Maybe Highsmith himself can advise (or make it available on the web) as I've Cc:ed him on this message.

            --
            Brad Appleton <brad@...> www.bradapp.net
            Software CM Patterns (www.scmpatterns.com)
            Effective Teamwork, Practical Integration
            "And miles to go before I sleep." -- Robert Frost
          • Brad Appleton
            ... Jim Highsmith said it was in an e-advisory newsletter from the cutter consortium. He gave me permission (via personal email) to post the newsletter to
            Message 5 of 14 , Dec 3, 2003
            • 0 Attachment
              On Wed, Dec 03, 2003 at 05:29:00PM -0000, slightlynew wrote:
              > Brad,
              >
              > > I remember a short article written by Jim Highsmith entitled
              > > "Release, Milestone and Iteration Planning" which described
              > > the need for all three of those things in an agile project
              > > (i.e. a Release plan that has both milestones and iterations
              > > planned within it) where the iterations are smaller-grained
              > > than the milestones
              >
              > I was in a discussion of this topic only yesterday. Can you
              > provide a link to this article?

              Jim Highsmith said it was in an "e-advisory" newsletter from
              the cutter consortium. He gave me permission (via personal
              email) to post the newsletter to the list provided I did so
              in its entirety (including the ads). Here it is after my
              email signature below.

              Cheers!
              --
              Brad Appleton <brad@...> www.bradapp.net
              Software CM Patterns (www.scmpatterns.com)
              Effective Teamwork, Practical Integration
              "And miles to go before I sleep." -- Robert Frost

              ************************************************************


              Welcome to the Agile Project Management E-Mail Advisor, a
              weekly electronic briefing from Cutter Consortium's Agile Project
              Management Advisory Service.

              RELEASE, MILESTONE,
              AND ITERATION PLANNING

              by Jim Highsmith, Director, Agile Project Management Practice
              http://www.cutter.com/consultants/jhbio.html

              When people first learn about agile or iterative development, they
              often think just in terms of short timeboxed iterations. However,
              there are two components to iterative planning -- the short iterations
              and the use of features rather than tasks. Basing plans on the
              product's features (and its architecture, which is instantiated by
              features) keeps the project team and the product's customers
              synchronized (because the customers understand the product
              even though they may not understand the technical activities). It also
              focuses the team on delivering the product rather than focusing on
              intermediate documentation artifacts.

              It's not that documentation artifacts are not useful; no one would
              consider building, say, an airplane or an automobile without extensive
              documentation. The problem is not documentation per se but that
              project teams often get lost producing intermediate artifacts that
              have little bearing on the final product. Feature-based planning
              attempts to overcome this problem.

              Many project managers can't fathom a 12-month project broken
              down into two-week iterations -- and in some ways this is
              understandable. Once projects go beyond four to five months, they
              usually need interim checkpoints at two-week intervals and at the
              project's end. Larger projects that employ distributed teams or
              vendor-supplied components will have problems synchronizing
              every two weeks. So, many projects will require three (or even
              more) levels of iteration.

              The longest period is the release cycle. Products are generally
              released to customers periodically -- once every year or 18
              months, for example. As such, "release" implies a release for
              customer use.

              On the other end of the spectrum, an iteration is used by a
              development team to focus on small increments of work. In agile
              software development, an iteration might be two weeks (XP), 30
              days (Scrum), or slightly longer for some projects. If you're building
              an airplane, the iterations will surely be longer.

              Milestones are intermediate points -- usually from one to three
              months. Milestones can have both a project management function
              and a technical function. From a project management perspective,
              milestones provide a chance to review progress and make more
              significant project adjustments. For example, while most agilests
              recommend project mini-retrospectives at the end of each iteration,
              most would actually employ them every two to three iterations if
              the iterations were short (two weeks). Milestones can also be used
              as major synchronization and integration points. For a product that
              has both hardware and software components, monthly (or even
              longer) synchronizations may be entirely adequate. On the other
              hand, if less-frequent synchronizations are going poorly, it might
              indicate that the synchronization should occur more frequently.

              Iterations produce acceptance-tested features. The goal is to have
              a partial-feature product that could be deployed at the end of any
              iteration -- that is, the features, testing, documentation, and other
              product deliverables could be packaged up and deployed. Iterative
              and incremental development are differentiated by this actual
              deployment. In some types of software development -- many Web-
              based systems, for example -- this goal can be achieved. By early
              deployment of partially completed products, early returns can
              boost ROI, and early feedback from customers can enhance the
              development during subsequent iterations. For other products
              (including a number of software products), this goal of being able
              to deploy at any iteration keeps the team on its toes but won't
              always be achievable. If a competitor has a product on the market
              with a certain capability, it won't be feasible to deploy your product
              until it has comparable capability.

              Some people think agile development gives them an opportunity to
              dive in and build (or code, in the software arena). They condemn
              agile methods, saying they spend little or no time on early
              requirements gathering or architectural issues. On the other hand,
              there has been an equally negative reaction to months and months
              of planning, requirements specification, and architectural
              philosophizing. There is obviously a balance point, but many
              arguments imply there is no middle ground. Iteration 0 is a practice
              to help teams find that middle ground. The "zero" implies that nothing
              useful to the customer -- features, in other words -- gets delivered
              in this time period. However, the fact that we have designated an
              iteration implies that the work is useful to some other stakeholder.

              Though the range of issues can be broad, the outcome is the same --
              some projects require more extensive initialization work than others.
              The key to effectively utilizing Iteration 0 is to balance the possible
              advantages of further planning with the growing disadvantage of
              lack of customer-deliverable features. There are always tradeoffs.
              If the cost of a technical platform change is very high, then additional
              work to improve the odds of an initial correct decision may be
              justified. Iteration 0 for a next-generation jumbo jetliner will be
              much different than that for a standalone software product.

              Iterative planning is an integral part of agile project management;
              however, there are many variations on the theme that are determined
              by the specifics of a particular product or project. There isn't a
              single right way or a single iteration length that works for every
              project.

              -- Jim Highsmith, Director, Agile Project Management Practice
              http://www.cutter.com/consultants/jhbio.html
              +++++++++++++++++++++++++++++++++++

              Learn more about iterative planning and agile project management
              when you bring Jim Highsmith and his highly popular *Agile Project
              Management: Innovation in Action* workshop into your training
              room! For more information, visit
              http://www.cutter.com/workshops/22.html , call David Gijsbers
              at +1 781 641 5104 or send e-mail to david@....
              +++++++++++++++++++++++++++++++++++

              The Cutter Consortium report *The Politics of Software Testing*
              explores approaches for performing just enough testing to create
              quality software without compromising your IT budget. It reveals how
              agile and risk-based testing approaches can provide a practical and
              cost-effective solution to your software testing challenges.

              This report also explains how to develop an enterprise-wide,
              structured approach to testing that incorporates business risk
              management. With this approach, you'll conduct more consistent and
              rigorous testing, realize quicker returns on your investment and
              continually reduce testing costs.

              Order your copy of *The Politics of Software Testing* today for just
              US $249 (US $264 outside North America). Order online at
              http://www.cutter.com/bookstore/testing.html , or call
              +1 781 648 8700, send a fax to +1 781 648 1950 or send e-mail
              to service@....
              +++++++++++++++++++++++++++++++++++

              If you'd like to comment on today's Agile Project Management
              E-Mail Advisor, send e-mail to apm@..., or send a letter
              by fax to +1 781 648 8707 or by mail to The Agile Project
              Management E-Mail Advisor, Cutter Consortium, 37 Broadway,
              Suite 1, Arlington, MA 02474-5552, USA.
              +++++++++++++++++++++++++++++++++++

              To unsubscribe to the Agile Project Management E-Mail Advisor,
              send e-mail to majordomo@... and include the message
              "unsubscribe agile_list your-e-mail@..." in the body of
              the message. Please use all lowercase letters and verify that your
              e-mail address is correct. Do not include anything but the message
              "unsubscribe agile_list" and your e-mail address in the body of the
              message. If you have any problems, please contact Ron Pulicari
              at rpulicari@....

              (c) 2003 Cutter Consortium. All rights reserved. Unauthorized
              reproduction in any form, including forwarding, photocopying,
              faxing and image scanning, is against the law.

              To sample our other weekly E-Mail Advisors, you can register at
              http://www.cutter.com/advisors .
            Your message has been successfully submitted and would be delivered to recipients shortly.