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

Re: Highsmith article on "Release, Milestone and Iteration Planning" (was Re: Nesting weekly iterations within monthly sprints)

Expand Messages
  • 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 1 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.

      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.


      by Jim Highsmith, Director, Agile Project Management Practice

      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

      -- Jim Highsmith, Director, Agile Project Management Practice

      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.