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

Re: [scrumdevelopment] Re: Nesting weekly iterations within monthly sprints

Expand Messages
  • Ron Jeffries
    ... Yes, please do! If we can help, let us know! Ron Jeffries www.XProgramming.com I could be wrong, of course. It s just not the way to bet.
    Message 1 of 14 , Dec 2, 2003
    • 0 Attachment
      On Tuesday, December 2, 2003, at 1:48:14 AM, Daniel Gackle wrote:

      > Thanks to everyone who replied about shorter iterations. If anything
      > interesting comes of our experiment I'll report back.

      Yes, please do! If we can help, let us know!

      Ron Jeffries
      www.XProgramming.com
      I could be wrong, of course. It's just not the way to bet.
    • Brad Appleton
      ... I remember a short article written by Jim Highsmith entitled Release, Milestone and Iteration Planning which described the need for all three of those
      Message 2 of 14 , Dec 2, 2003
      • 0 Attachment
        On Mon, Dec 01, 2003 at 11:48:14PM -0700, Daniel Gackle wrote:
        > I'm still intrigued by the thought that perhaps the monthly and weekly
        > cycles don't contradict each other, but address two different concerns.

        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:

        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.

        He then goes on to talk about the lengths/durations of each
        above as being relative, and can certainly be longer or shorter,
        but the relative "scale" of each as compared to the other
        seems to stay consistent.
        --
        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
      • 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 3 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 4 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 5 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 6 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 7 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.