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

Re: [scrumdevelopment] Nesting weekly iterations within monthly sprints

Expand Messages
  • 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 1 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 2 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 3 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 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?

            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.