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

Re: [scrumdevelopment] agile and product roadmaps

Expand Messages
  • Ron Jeffries
    ... I don t think of it this way. An Agile team might not make terribly specific long-term promises, for these reasons: We expect that the value of each of the
    Message 1 of 14 , Nov 1, 2005
    View Source
    • 0 Attachment
      On Tuesday, November 1, 2005, at 6:07:13 PM, March, Steven wrote:

      > Thanks to those who responded to my question on agile and product
      > roadmaps.
      >
      > It seems, summarizing the responses, that the general sense is that when
      > you become an agile shop you stop making long-term promises in favor of
      > making near-term promises while holding long-term intentions that you
      > don't take too seriously because they will inevitably need to change.

      I don't think of it this way. An Agile team might not make terribly
      specific long-term promises, for these reasons:

      We expect that the value of each of the features promised is not
      well known.

      We expect that the value in the future of those features will not
      be the same as it is now.

      We expect that new feature ideas will emerge which are more
      valuable than many of the currently-contemplated features.

      We expect that some of the currently-contemplated features will
      turn out to be of little or no value at all.

      We do not -- and cannot -- know the specific cost of each feature.

      So Agile teams do not commit to these things. Agile or not, any team
      that /does/ commit to specific features over the long term is
      dealing with the same uncertainties. The inevitable result is that
      projects take longer than expected and deliver features that no one
      really wants, while missing out features that would be really good
      but weren't in the original list.

      An Agile team can and will commit, however, to something far more
      valuable than a specific list of features imagined up front. The
      Agile team will commit to deliver, on specified dates during the
      entire lifetime of the project, the customer's own selection of
      features, based on the customer's estimate of value and the team's
      estimate of cost.

      In short, an Agile team commits to let the customer build the best
      product he can think of, within the budget he wants to spend. That
      is, I suggest, a much more valuable promise than a list of features,
      and a much more accurate promise as well.
      >
      > So I get this and think there is a lot of pragmatic wisdom in holding
      > long-term plans this way. However, from the customer's perspective that
      > doesn't give them much that they can count on. It leaves our customers
      > in uncertainty and not knowing if they can trust us to fulfill their
      > needs or not as a supplier. Why would a customer want to establish a
      > long-term relationship with a supplier if the supplier is only willing
      > to make near-term commitments.

      As I've listed above, I suggest that the Agile promise is stronger
      than the conventional fixed-scope fixed-resource promise ... and far
      more likely to come true.
      >
      > It seems to me that when faced with uncertainty we have at least two
      > responses: 1) drift into the future or 2) commit to creating a certain
      > future. The first option doesn't allow our customers to coordinate
      > effectively with us. With the later option, responding to uncertainty
      > with a commitment, enables customers to coordinate with us (even in the
      > cases where we have to revoke our commitments and make new ones).
      > Naturally, having to revoke commitments will impact our customer's trust
      > in us if we don't revoke our commitments with care and responsibility
      > for the impact we have on them. With the former option, responding to
      > uncertainty with drifting, there is no possibility to coordinate
      > effectively in the long-term and to build trust.

      Agile projects are emphatically NOT about drifting. Non-Agile
      projects are ballistic missiles, aimed at some point far away and
      landing nearby, subject to errors in assessing where to aim and
      errors in guessing how the winds would be. Agile projects are guided
      missiles, steering their way to the target, even if the target
      moves.
      >
      > I don't see anything inherently incompatible between the practice of
      > product roadmaps (longer-term commitments) and agile ... IF ... we can
      > responsibly revoke commitments and re-commit when we have to. However,
      > I see a few business drawbacks by not making longer-term commitments.

      If we find ourselves "revoking" commitments, then those commitments
      should have been revoked using any other process, not just Agile.
      The other processes have no information at the beginning that the
      Agile process does not have: therefore the Agile project's initial
      guess is just as good as any other process's.

      But the Agile process provides information that the non-Agile
      process cannot, namely real information about cost of development.
      We don't cost more: we just know better what things cost.

      And the Agile process provides control that the non-Agile process
      cannot. The Agile process can drop any feature and add any new
      feature, at any point in the entire project.

      Agile, as I see it, is stronger than non-Agile in every respect.
      >
      > I'm wondering what you all think of that and how you see this. Thanks
      > for the conversation.

      Regards,

      Ron Jeffries
      www.XProgramming.com
      If not now, when? -- The Talmud
    • murdocj2000
      ... that when ... favor of ... you ... change. ... You re assuming that everything that the agile team commits to is a feature. In some cases, that isn t
      Message 2 of 14 , Nov 2, 2005
      View Source
      • 0 Attachment
        --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
        <ronjeffries@X...> wrote:
        >
        > On Tuesday, November 1, 2005, at 6:07:13 PM, March, Steven wrote:
        >
        > > Thanks to those who responded to my question on agile and product
        > > roadmaps.
        > >
        > > It seems, summarizing the responses, that the general sense is
        that when
        > > you become an agile shop you stop making long-term promises in
        favor of
        > > making near-term promises while holding long-term intentions that
        you
        > > don't take too seriously because they will inevitably need to
        change.
        >
        > I don't think of it this way. An Agile team might not make terribly
        > specific long-term promises, for these reasons:
        >
        > We expect that the value of each of the features promised is not
        > well known.
        >
        > We expect that the value in the future of those features will not
        > be the same as it is now.
        >
        > We expect that new feature ideas will emerge which are more
        > valuable than many of the currently-contemplated features.
        >
        > We expect that some of the currently-contemplated features will
        > turn out to be of little or no value at all.
        >
        > We do not -- and cannot -- know the specific cost of each feature.
        >
        > So Agile teams do not commit to these things. Agile or not, any team
        > that /does/ commit to specific features over the long term is
        > dealing with the same uncertainties. The inevitable result is that
        > projects take longer than expected and deliver features that no one
        > really wants, while missing out features that would be really good
        > but weren't in the original list.
        >
        > An Agile team can and will commit, however, to something far more
        > valuable than a specific list of features imagined up front. The
        > Agile team will commit to deliver, on specified dates during the
        > entire lifetime of the project, the customer's own selection of
        > features, based on the customer's estimate of value and the team's
        > estimate of cost.

        You're assuming that everything that the agile team commits to is a
        feature. In some cases, that isn't true. For example, a team might
        commit to supporting a product on a particular platform for a
        particular period of time. Or of migrating the code over time to
        support a particular set of databases. Customers may make other
        decisions about what software and hardware they install, based on the
        longterm support roadmap that a vendor lays out.
      • Joseph Snively
        If I understand it correctly, customers don t often know what they want right from the start. What the system should look like evolves over time NO MATTER
        Message 3 of 14 , Nov 2, 2005
        View Source
        • 0 Attachment
          If I understand it correctly, customers don't often know what they want right from the start.  What the system should look like evolves over time NO MATTER WHAT methodology you use (waterfall or agile).
           
          Also, the most needed requirements and capabilities are implemented first in Agile methods.  So, the customer is assured of a certain level of functionality and usually far more quickly than in waterfall methods.
           
          Finally, who said customers want to make long term commitments?  Wasn't it the software community that demanded tight requirements and developed all the controls for managing requirements creep?


          "March, Steven" <steve.march@...> wrote:
          Hello,
           
          Thanks to those who responded to my question on agile and product roadmaps.
           
          It seems, summarizing the responses, that the general sense is that when you become an agile shop you stop making long-term promises in favor of making near-term promises while holding long-term intentions that you don't take too seriously because they will inevitably need to change.
           
          So I get this and think there is a lot of pragmatic wisdom in holding long-term plans this way. However, from the customer's perspective that doesn't give them much that they can count on. It leaves our customers in uncertainty and not knowing if they can trust us to fulfill their needs or not as a supplier. Why would a customer want to establish a long-term relationship with a supplier if the supplier is only willing to make near-term commitments.
           
          It seems to me that when faced with uncertainty we have at least two responses: 1) drift into the future or 2) commit to creating a certain future. The first option doesn't allow our customers to coordinate effectively with us. With the later option, responding to uncertainty with a commitment, enables customers to coordinate with us (even in the cases where we have to revoke our commitments and make new ones). Naturally, having to revoke commitments will impact our customer's trust in us if we don't revoke our commitments with care and responsibility for the impact we have on them.  With the former option, responding to uncertainty with drifting, there is no possibility to coordinate effectively in the long-term and to build trust.
           
          I don't see anything inherently incompatible between the practice of product roadmaps (longer-term commitments) and agile ... IF ... we can responsibly revoke commitments and re-commit when we have to.  However, I see a few business drawbacks by not making longer-term commitments.
           
          I'm wondering what you all think of that and how you see this.  Thanks for the conversation.
           
          Take care,
           
          -Steve

          From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Mike Cohn
          Sent: Tuesday, October 25, 2005 12:34 PM
          To: Scrumdevelopment
          Subject: Re: [scrumdevelopment] agile and product roadmaps

          I think it is important (in most environments) to have some level of long-range plan and goals. To see why, imagine you are hiking and want to cross a particular summit. You look up the trail and aim for the highest thing you see (that must be the summit, you reason). However, once you reach that point you realize it was a false summit and that it obscured the real summit, which you know head for only to realize it too was a false summit. Never looking further ahead than the current sprint is like this. It is possible to have a series of successful sprints that do not necessarily lead to the most satisfying overall 6-month release.

          Another example since we’re winding down baseball season: A team doesn’t decide “who is the one best batter we can send to the plate next?” They put a bit of forethought into that and sort players based on a variety of factors (e.g., you wouldn’t want your best base-stealer to follow your slowest guy who almost always gets on base).

          Planning ahead is critical to reliably achieving long-term project success.

          You don’t, however, want to take the plans too seriously. They are point-in-time guesses and should be updated after each sprint based on new knowledge.

          As I saw in another post, I describe this via a “planning onion”. Innermost in the onion is the daily plan (made in the daily scrum), outside that is the sprint plan, outside that is the release plan. Continuing to the outside are the product plan (a perhaps 1-2 view of the life of this product), followed by portfolio planning (which products fit with what we know and do and whom we market to), followed by company strategy. It’s possible to have a few more layers in this onion in some companies (e.g., product platform strategy in some cases). Each of these layers of the onion needs deliberate thought and planning and each looks forward to a differing degree. Not all are the specific concern of a dev team but hopefully someone is thinking about these outer layers. The key is to have an agile mindset when doing so—for example, realize that any 18-month plan is going to change.

          Regards,
          Mike Cohn
          Author:
              Agile Estimating and Planning
              User Stories Applied for Agile Software Development
          www.mountaingoatsoftware.com



          On 10/25/05 9:38 AM, "March, Steven" <steve.march@...> wrote:

          Hello,
           
          My organization has a practice of publishing 18 month product roadmaps of releases with promised features.  We are not an agile shop today but are considering moving in this direction.
           
          How do organizations that practice agile do this?
           
          Thanks.
           
          -Steve
           


          To Post a message, send it to:   scrumdevelopment@...
          To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...

            

           
           SPONSORED LINKS
                    
            Scrum <http://groups.yahoo.com/gads?t=ms&k=Scrum&w1=Scrum&c=1&s=11&.sig=KvDTKhw7ncC9XbB25jdApQ>          
           
           

          YAHOO! GROUPS LINKS


           





          V/R,
          Joey
           
          Would you rather have a nice life or interesting stories?


          Yahoo! FareChase - Search multiple travel sites in one click.

        • jhoover6672000
          ... You can make commitments with agile. What you cannot do is predict the future. Predicting the future is what we try to do when we promise to deliver on
          Message 4 of 14 , Nov 2, 2005
          View Source
          • 0 Attachment
            > "March, Steven" <steve.march@w...> wrote:
            > I don't see anything inherently incompatible between the practice of
            >product roadmaps (longer-term commitments) and agile ... IF ... we can
            >responsibly revoke commitments and re-commit when we have to. However,
            >I see a few business drawbacks by not making longer-term commitments.

            You can make commitments with agile. What you cannot do is predict
            the future. Predicting the future is what we try to do when we
            promise to deliver on an exact date a product with all the requested
            features with high quality within a set budget.

            Agile can do what any other project management methodology can do in
            terms of commitment. The difference with Agile is that you have the
            opportunity to see real progress (or lack thereof) more immediately so
            that you can adjust the plan. Also, with Agile, you have the
            opportunity to deliver the most valuable features regardless of what
            the original plan was. Other methodologies that are concerned with
            "hitting the plan" and enforcing "change management" aren't driven by
            delivering value, their focus is on sticking to a plan, no matter how
            acurate that plan turns out to be.

            If people focus on delivering the most value within a set deadline I
            think it would help get everyone closer to the solution that is
            project management.

            Josh Hoover
          • Stephen J. Bobick
            ... And it is worth pointing out to the PO and other stakeholder that other, non-agile methodologies can NOT do this either. These methodologies pretend to
            Message 5 of 14 , Nov 2, 2005
            View Source
            • 0 Attachment
              >From: jhoover6672000 <jhoover6672000@...>
              >You can make commitments with agile. What you cannot do is predict
              >the future. Predicting the future is what we try to do when we
              >promise to deliver on an exact date a product with all the requested
              >features with high quality within a set budget.

              And it is worth pointing out to the PO and other stakeholder that other, non-agile methodologies can NOT do this either. These methodologies pretend to have this ability, veiled in ceremony and SOPs - but it is an illusion, a big lie.

              -- Stephen
            • todd
              ... When you buy software you are often making a long term commitment. The cost of moving OSes for example can be massive to nearly impossible. For example, if
              Message 6 of 14 , Nov 2, 2005
              View Source
              • 0 Attachment
                Joseph Snively wrote:

                >
                > Finally, who said customers want to make long term commitments?

                When you buy software you are often making a long term commitment. The
                cost of moving OSes for example can be massive to nearly impossible.

                For example, if we use Wind River for our embedded system that is
                deployed on 1000s of devices out in the real world we have made a long
                term commitment. So have they.

                Let's say we want to make use of a new processor, we want to know when
                they will support it and we want to see it on their roadmap. A roadmap
                is usually by quarters so it's not that small a target. We will make all
                our schedules dependent on that data. If they don't hit then the
                consequences are dire. We don't want to hear anything like we think we
                don't know when we'll implement that feature because we use methodology X.
              • Ron Jeffries
                ... I can predict the future. Just not quite that well. But neither can any other process predict the future that well. Ron Jeffries www.XProgramming.com Do
                Message 7 of 14 , Nov 2, 2005
                View Source
                • 0 Attachment
                  On Wednesday, November 2, 2005, at 3:13:50 PM, jhoover6672000 wrote:

                  >> "March, Steven" <steve.march@w...> wrote:
                  >> I don't see anything inherently incompatible between the practice of
                  >>product roadmaps (longer-term commitments) and agile ... IF ... we can
                  >>responsibly revoke commitments and re-commit when we have to. However,
                  >>I see a few business drawbacks by not making longer-term commitments.

                  > You can make commitments with agile. What you cannot do is predict
                  > the future. Predicting the future is what we try to do when we
                  > promise to deliver on an exact date a product with all the requested
                  > features with high quality within a set budget.

                  I can predict the future. Just not quite that well. But neither can
                  any other process predict the future that well.

                  Ron Jeffries
                  www.XProgramming.com
                  Do only what is necessary. Keep only what you need.
                Your message has been successfully submitted and would be delivered to recipients shortly.