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

Agile and predictability.

Expand Messages
  • Michael Kelly
    ... Despite the relative success of Agile methods for engineering, our counterparts on the business side continue to have a need to make decisions based upon
    Message 1 of 15 , Sep 28, 2014
      Core Question:
      --------------------
      Despite the relative success of Agile methods for engineering, our counterparts on the business side continue to have a need to make decisions based upon (and communicate with customers, and business partners, and other internal departments about) what will likely happen in the future. Do/can Agile methods provide any help with that?

      Discussion:
      ---------------
      I recently came across a job posting for a local PDX company that was looking for someone to manage the company's Agile adoption. Specifically, they wanted someone that would apply agile "best practices" so as to improve predictability.

      My first response, of course, was "Good luck with that." It seems pretty clear to me that Agile takes as its first principle that software development is inherently unpredictable, and that the "best practices" are all about dealing with that fact. You see this in the literature of all of Agile's leaders:
      • Kent Beck: Embrace change.
      • Jeff Sutherland: Writes about software as the product of a Complex Adaptive System (CAS), a key feature of which is unpredictability.
      • Mike Cohen: Describes "Agile planning" as something that is spread throughout the project, is more focused on planning than The Plan, encourages change, and results in plans that are easily changed.
      Part of the answer here seems to be to push the notion of agility further up the organizational hierarchy. To the extent that commitments need to be made, the heads of departments, VPs, CTOs, CEOs, etc. need to make those commitments as late as possible and make them as general as possible: "The software will be delivered in the 3rd quarter, and will contain a solution for tracking widgets.", not "The software will be delivered September 4th, and will provide three widget tracking reports, late delivery notifications, and a customize-able dashboard."

      One thing that seems to help with pushing the notion of agility up the organizational hierarchy is greater visibility. When stakeholders get regular and concrete evidence of the progress made by software development teams (e.g. regular demos), then the realities of the inevitable uncertainty of the endeavor becomes clear to all.

      But even with these things in place, the pressure for predictability persists. 
      1. Customers making buying decisions want information about what's in the pipeline, and often insist on having the details.
      2. Product Owners typically get one or two chances a year to talk about the future of their products at trade shows, and they have pressures to give details about the coming year (see item #1 above).
      3. Sales people are under similar pressures when trying to close a deal.
      4. Executives trying to make decisions about the corporate direction need information about the cost of various options.
      5. Business partners and other internal departments need to coordinate their efforts with ours.
      As a developer, I could look at these pressures and say (and, no doubt, have said) "Good luck with that." But I can't help but feel that this response makes me something less than a full collaborative partner in the objectives of the enterprise, and that I should be able to provide an Agile response that is more...helpful.

      What thinks you all?

      -
      Michael Kelly
      DAT Solutions
    • James Shore
      It s entirely possible to make predictions with Agile. They re just as good as predictions made with other methods, and with XP practices, they can be much
      Message 2 of 15 , Sep 28, 2014
        It's entirely possible to make predictions with Agile. They're just as good as predictions made with other methods, and with XP practices, they can be much better. Agile leaders talk about embracing change because that has more potential value than making predictions.

        Software *is* inherently unpredictable. So is the weather. Forecasts (predictions) are possible in both situations, given sufficient rigor. How your team approaches predictions depends on what level of fluency they have (http://www.agilefluency.com).

        One-star teams adapt their plans and work in terms of business results. However, they don't have rigorous engineering practices, which means their predictions have wide error bars, on par with typical non-Agile teams (for 90% reliability, need 4x estimate*). They believe predictions are impossible in Agile.

        Two-star teams use rigorous engineering practices such as test-driven development, continuous integration, and the other good stuff from XP. They can make predictions with reasonable precision (for 90% reliability, need 1.8x estimate*). They can and do provide reliable predictions.

        Three- and four-star teams conduct experiments and change direction depending on market opportunities. They can make predictions as well as two-star teams, but estimating and predicting has a cost, and that cost often has no real value in the market. They often choose not to incur the waste of making predictions.

        So if a company were to talk to me about improving predictability, I would talk to them about what sort of fluency they wanted to achieve, why, and the investments they need to make to get there. For some organizations, *3 fluency isn't desired. It's too big of a cultural shift. In those cases, a *2 team is a great fit, and can provide the predictability they want.

        I describe the "how to" of making predictions in Agile in "Use Risk Management to Make Solid Commitments." http://www.jamesshore.com/Blog/Use-Risk-Management-to-Make-Solid-Commitments.html

        Cheers,
        Jim

        *These numbers are approximate and depend on the team. See the "Use Risk Management" essay for an explanation of where they come from.



        On Sep 28, 2014, at 11:11 AM, "Michael Kelly m.sean.kelly@... [AgilePDX]" <AgilePDX@yahoogroups.com> wrote:



        Core Question:
        --------------------
        Despite the relative success of Agile methods for engineering, our counterparts on the business side continue to have a need to make decisions based upon (and communicate with customers, and business partners, and other internal departments about) what will likely happen in the future. Do/can Agile methods provide any help with that?

        Discussion:
        ---------------
        I recently came across a job posting for a local PDX company that was looking for someone to manage the company's Agile adoption. Specifically, they wanted someone that would apply agile "best practices" so as to improve predictability.

        My first response, of course, was "Good luck with that." It seems pretty clear to me that Agile takes as its first principle that software development is inherently unpredictable, and that the "best practices" are all about dealing with that fact. You see this in the literature of all of Agile's leaders:
        • Kent Beck: Embrace change.
        • Jeff Sutherland: Writes about software as the product of a Complex Adaptive System (CAS), a key feature of which is unpredictability.
        • Mike Cohen: Describes "Agile planning" as something that is spread throughout the project, is more focused on planning than The Plan, encourages change, and results in plans that are easily changed.
        Part of the answer here seems to be to push the notion of agility further up the organizational hierarchy. To the extent that commitments need to be made, the heads of departments, VPs, CTOs, CEOs, etc. need to make those commitments as late as possible and make them as general as possible: "The software will be delivered in the 3rd quarter, and will contain a solution for tracking widgets.", not "The software will be delivered September 4th, and will provide three widget tracking reports, late delivery notifications, and a customize-able dashboard."

        One thing that seems to help with pushing the notion of agility up the organizational hierarchy is greater visibility. When stakeholders get regular and concrete evidence of the progress made by software development teams (e.g. regular demos), then the realities of the inevitable uncertainty of the endeavor becomes clear to all.

        But even with these things in place, the pressure for predictability persists. 
        1. Customers making buying decisions want information about what's in the pipeline, and often insist on having the details.
        2. Product Owners typically get one or two chances a year to talk about the future of their products at trade shows, and they have pressures to give details about the coming year (see item #1 above).
        3. Sales people are under similar pressures when trying to close a deal.
        4. Executives trying to make decisions about the corporate direction need information about the cost of various options.
        5. Business partners and other internal departments need to coordinate their efforts with ours.
        As a developer, I could look at these pressures and say (and, no doubt, have said) "Good luck with that." But I can't help but feel that this response makes me something less than a full collaborative partner in the objectives of the enterprise, and that I should be able to provide an Agile response that is more...helpful.

        What thinks you all?

        -
        Michael Kelly
        DAT Solutions




        --
        James Shore - The Art of Agile
        recipient of Gordon Pask Award for Contributions to Agile Practice
        co-author of The Art of Agile Development

        voice: 503-267-5490
        email: jshore@...
        blog: http://jamesshore.com

      • Michael Kelly
        Wow, thanks Jim. Much appreciated. It s almost as if you had this one all prepared. :-) On Sep 28, 2014 11:55 AM, James Shore jshore@jamesshore.com
        Message 3 of 15 , Sep 28, 2014

          Wow, thanks Jim. Much appreciated. It's almost as if you had this one all prepared. :-)

          On Sep 28, 2014 11:55 AM, "James Shore jshore@... [AgilePDX]" <AgilePDX@yahoogroups.com> wrote:
           

          It's entirely possible to make predictions with Agile. They're just as good as predictions made with other methods, and with XP practices, they can be much better. Agile leaders talk about embracing change because that has more potential value than making predictions.


          Software *is* inherently unpredictable. So is the weather. Forecasts (predictions) are possible in both situations, given sufficient rigor. How your team approaches predictions depends on what level of fluency they have (http://www.agilefluency.com).

          One-star teams adapt their plans and work in terms of business results. However, they don't have rigorous engineering practices, which means their predictions have wide error bars, on par with typical non-Agile teams (for 90% reliability, need 4x estimate*). They believe predictions are impossible in Agile.

          Two-star teams use rigorous engineering practices such as test-driven development, continuous integration, and the other good stuff from XP. They can make predictions with reasonable precision (for 90% reliability, need 1.8x estimate*). They can and do provide reliable predictions.

          Three- and four-star teams conduct experiments and change direction depending on market opportunities. They can make predictions as well as two-star teams, but estimating and predicting has a cost, and that cost often has no real value in the market. They often choose not to incur the waste of making predictions.

          So if a company were to talk to me about improving predictability, I would talk to them about what sort of fluency they wanted to achieve, why, and the investments they need to make to get there. For some organizations, *3 fluency isn't desired. It's too big of a cultural shift. In those cases, a *2 team is a great fit, and can provide the predictability they want.

          I describe the "how to" of making predictions in Agile in "Use Risk Management to Make Solid Commitments." http://www.jamesshore.com/Blog/Use-Risk-Management-to-Make-Solid-Commitments.html

          Cheers,
          Jim

          *These numbers are approximate and depend on the team. See the "Use Risk Management" essay for an explanation of where they come from.



          On Sep 28, 2014, at 11:11 AM, "Michael Kelly m.sean.kelly@... [AgilePDX]" <AgilePDX@yahoogroups.com> wrote:



          Core Question:
          --------------------
          Despite the relative success of Agile methods for engineering, our counterparts on the business side continue to have a need to make decisions based upon (and communicate with customers, and business partners, and other internal departments about) what will likely happen in the future. Do/can Agile methods provide any help with that?

          Discussion:
          ---------------
          I recently came across a job posting for a local PDX company that was looking for someone to manage the company's Agile adoption. Specifically, they wanted someone that would apply agile "best practices" so as to improve predictability.

          My first response, of course, was "Good luck with that." It seems pretty clear to me that Agile takes as its first principle that software development is inherently unpredictable, and that the "best practices" are all about dealing with that fact. You see this in the literature of all of Agile's leaders:
          • Kent Beck: Embrace change.
          • Jeff Sutherland: Writes about software as the product of a Complex Adaptive System (CAS), a key feature of which is unpredictability.
          • Mike Cohen: Describes "Agile planning" as something that is spread throughout the project, is more focused on planning than The Plan, encourages change, and results in plans that are easily changed.
          Part of the answer here seems to be to push the notion of agility further up the organizational hierarchy. To the extent that commitments need to be made, the heads of departments, VPs, CTOs, CEOs, etc. need to make those commitments as late as possible and make them as general as possible: "The software will be delivered in the 3rd quarter, and will contain a solution for tracking widgets.", not "The software will be delivered September 4th, and will provide three widget tracking reports, late delivery notifications, and a customize-able dashboard."

          One thing that seems to help with pushing the notion of agility up the organizational hierarchy is greater visibility. When stakeholders get regular and concrete evidence of the progress made by software development teams (e.g. regular demos), then the realities of the inevitable uncertainty of the endeavor becomes clear to all.

          But even with these things in place, the pressure for predictability persists. 
          1. Customers making buying decisions want information about what's in the pipeline, and often insist on having the details.
          2. Product Owners typically get one or two chances a year to talk about the future of their products at trade shows, and they have pressures to give details about the coming year (see item #1 above).
          3. Sales people are under similar pressures when trying to close a deal.
          4. Executives trying to make decisions about the corporate direction need information about the cost of various options.
          5. Business partners and other internal departments need to coordinate their efforts with ours.
          As a developer, I could look at these pressures and say (and, no doubt, have said) "Good luck with that." But I can't help but feel that this response makes me something less than a full collaborative partner in the objectives of the enterprise, and that I should be able to provide an Agile response that is more...helpful.

          What thinks you all?

          -
          Michael Kelly
          DAT Solutions




          --
          James Shore - The Art of Agile
          recipient of Gordon Pask Award for Contributions to Agile Practice
          co-author of The Art of Agile Development

          voice: 503-267-5490
          email: jshore@...
          blog: http://jamesshore.com

        • Patrick Logan
          One can predict anything as long as no one cares how accurate the prediction. The questions become: what do you want to predict, what are the benefits of
          Message 4 of 15 , Sep 28, 2014

            One can predict anything as long as no one cares how accurate the prediction. The questions become: what do you want to predict, what are the benefits of spending time on that,  and what are they consequences for being off by some factor?

            On Sep 28, 2014 11:12 AM, "Michael Kelly m.sean.kelly@... [AgilePDX]" <AgilePDX@yahoogroups.com> wrote:
             

            Core Question:
            --------------------
            Despite the relative success of Agile methods for engineering, our counterparts on the business side continue to have a need to make decisions based upon (and communicate with customers, and business partners, and other internal departments about) what will likely happen in the future. Do/can Agile methods provide any help with that?

            Discussion:
            ---------------
            I recently came across a job posting for a local PDX company that was looking for someone to manage the company's Agile adoption. Specifically, they wanted someone that would apply agile "best practices" so as to improve predictability.

            My first response, of course, was "Good luck with that." It seems pretty clear to me that Agile takes as its first principle that software development is inherently unpredictable, and that the "best practices" are all about dealing with that fact. You see this in the literature of all of Agile's leaders:
            • Kent Beck: Embrace change.
            • Jeff Sutherland: Writes about software as the product of a Complex Adaptive System (CAS), a key feature of which is unpredictability.
            • Mike Cohen: Describes "Agile planning" as something that is spread throughout the project, is more focused on planning than The Plan, encourages change, and results in plans that are easily changed.
            Part of the answer here seems to be to push the notion of agility further up the organizational hierarchy. To the extent that commitments need to be made, the heads of departments, VPs, CTOs, CEOs, etc. need to make those commitments as late as possible and make them as general as possible: "The software will be delivered in the 3rd quarter, and will contain a solution for tracking widgets.", not "The software will be delivered September 4th, and will provide three widget tracking reports, late delivery notifications, and a customize-able dashboard."

            One thing that seems to help with pushing the notion of agility up the organizational hierarchy is greater visibility. When stakeholders get regular and concrete evidence of the progress made by software development teams (e.g. regular demos), then the realities of the inevitable uncertainty of the endeavor becomes clear to all.

            But even with these things in place, the pressure for predictability persists. 
            1. Customers making buying decisions want information about what's in the pipeline, and often insist on having the details.
            2. Product Owners typically get one or two chances a year to talk about the future of their products at trade shows, and they have pressures to give details about the coming year (see item #1 above).
            3. Sales people are under similar pressures when trying to close a deal.
            4. Executives trying to make decisions about the corporate direction need information about the cost of various options.
            5. Business partners and other internal departments need to coordinate their efforts with ours.
            As a developer, I could look at these pressures and say (and, no doubt, have said) "Good luck with that." But I can't help but feel that this response makes me something less than a full collaborative partner in the objectives of the enterprise, and that I should be able to provide an Agile response that is more...helpful.

            What thinks you all?

            -
            Michael Kelly
            DAT Solutions
          • James Shore
            I ve thought about it a lot. :-) ... -- James Shore - The Art of Agile recipient of Gordon Pask Award for Contributions to Agile Practice co-author of The Art
            Message 5 of 15 , Sep 28, 2014
              I've thought about it a lot. :-)

              On Sep 28, 2014, at 12:02 PM, Michael Kelly m.sean.kelly@... [AgilePDX] <AgilePDX@yahoogroups.com> wrote:

              Wow, thanks Jim. Much appreciated. It's almost as if you had this one all prepared. :-)

              On Sep 28, 2014 11:55 AM, "James Shore jshore@... [AgilePDX]" <AgilePDX@yahoogroups.com> wrote:
               

              It's entirely possible to make predictions with Agile. They're just as good as predictions made with other methods, and with XP practices, they can be much better. Agile leaders talk about embracing change because that has more potential value than making predictions.


              Software *is* inherently unpredictable. So is the weather. Forecasts (predictions) are possible in both situations, given sufficient rigor. How your team approaches predictions depends on what level of fluency they have (http://www.agilefluency.com).

              One-star teams adapt their plans and work in terms of business results. However, they don't have rigorous engineering practices, which means their predictions have wide error bars, on par with typical non-Agile teams (for 90% reliability, need 4x estimate*). They believe predictions are impossible in Agile.

              Two-star teams use rigorous engineering practices such as test-driven development, continuous integration, and the other good stuff from XP. They can make predictions with reasonable precision (for 90% reliability, need 1.8x estimate*). They can and do provide reliable predictions.

              Three- and four-star teams conduct experiments and change direction depending on market opportunities. They can make predictions as well as two-star teams, but estimating and predicting has a cost, and that cost often has no real value in the market. They often choose not to incur the waste of making predictions.

              So if a company were to talk to me about improving predictability, I would talk to them about what sort of fluency they wanted to achieve, why, and the investments they need to make to get there. For some organizations, *3 fluency isn't desired. It's too big of a cultural shift. In those cases, a *2 team is a great fit, and can provide the predictability they want.

              I describe the "how to" of making predictions in Agile in "Use Risk Management to Make Solid Commitments." http://www.jamesshore.com/Blog/Use-Risk-Management-to-Make-Solid-Commitments.html

              Cheers,
              Jim

              *These numbers are approximate and depend on the team. See the "Use Risk Management" essay for an explanation of where they come from.



              On Sep 28, 2014, at 11:11 AM, "Michael Kelly m.sean.kelly@... [AgilePDX]" <AgilePDX@yahoogroups.com> wrote:



              Core Question:
              --------------------
              Despite the relative success of Agile methods for engineering, our counterparts on the business side continue to have a need to make decisions based upon (and communicate with customers, and business partners, and other internal departments about) what will likely happen in the future. Do/can Agile methods provide any help with that?

              Discussion:
              ---------------
              I recently came across a job posting for a local PDX company that was looking for someone to manage the company's Agile adoption. Specifically, they wanted someone that would apply agile "best practices" so as to improve predictability.

              My first response, of course, was "Good luck with that." It seems pretty clear to me that Agile takes as its first principle that software development is inherently unpredictable, and that the "best practices" are all about dealing with that fact. You see this in the literature of all of Agile's leaders:
              • Kent Beck: Embrace change.
              • Jeff Sutherland: Writes about software as the product of a Complex Adaptive System (CAS), a key feature of which is unpredictability.
              • Mike Cohen: Describes "Agile planning" as something that is spread throughout the project, is more focused on planning than The Plan, encourages change, and results in plans that are easily changed.
              Part of the answer here seems to be to push the notion of agility further up the organizational hierarchy. To the extent that commitments need to be made, the heads of departments, VPs, CTOs, CEOs, etc. need to make those commitments as late as possible and make them as general as possible: "The software will be delivered in the 3rd quarter, and will contain a solution for tracking widgets.", not "The software will be delivered September 4th, and will provide three widget tracking reports, late delivery notifications, and a customize-able dashboard."

              One thing that seems to help with pushing the notion of agility up the organizational hierarchy is greater visibility. When stakeholders get regular and concrete evidence of the progress made by software development teams (e.g. regular demos), then the realities of the inevitable uncertainty of the endeavor becomes clear to all.

              But even with these things in place, the pressure for predictability persists. 
              1. Customers making buying decisions want information about what's in the pipeline, and often insist on having the details.
              2. Product Owners typically get one or two chances a year to talk about the future of their products at trade shows, and they have pressures to give details about the coming year (see item #1 above).
              3. Sales people are under similar pressures when trying to close a deal.
              4. Executives trying to make decisions about the corporate direction need information about the cost of various options.
              5. Business partners and other internal departments need to coordinate their efforts with ours.
              As a developer, I could look at these pressures and say (and, no doubt, have said) "Good luck with that." But I can't help but feel that this response makes me something less than a full collaborative partner in the objectives of the enterprise, and that I should be able to provide an Agile response that is more...helpful.

              What thinks you all?

              -
              Michael Kelly
              DAT Solutions




              --
              James Shore - The Art of Agile
              recipient of Gordon Pask Award for Contributions to Agile Practice
              co-author of The Art of Agile Development

              voice: 503-267-5490
              email: jshore@...
              blog: http://jamesshore.com






              --
              James Shore - The Art of Agile
              recipient of Gordon Pask Award for Contributions to Agile Practice
              co-author of The Art of Agile Development

              voice: 503-267-5490
              email: jshore@...
              blog: http://jamesshore.com

            • Michael Kelly
              Thanks James, much appreciated. If I understand what you re saying, a rigorous process (with automated tests, velocity tracking, continuous integration, etc.)
              Message 6 of 15 , Sep 29, 2014
                Thanks James, much appreciated. If I understand what you're saying, a rigorous process (with automated tests, velocity tracking, continuous integration, etc.) helps with predictability. That makes sense to me, especially when you're predicting the end-game of a project that has already started and has a track record. And that's helpful. But new projects and existing projects experiencing significant disruptions (changes in team members, technology, or features) don't really have any velocity as a starting point, much less a stable one. And frequently, they don't have a well-groomed backlog with story points.

                Is our answer in this case "good luck with that"? Is the answer essentially that Agile estimation doesn't kick in until you've already adopted the practices and had them in place for a while? Or is there some "agile" method for iterative provisional estimation of schedule and cost that contains something about the degree of uncertainty--an iterative process that drives down the uncertainty to the point where a decision can be made, but no further. If there is, I'm not aware of it. And I'm not even clear such a thing is feasible, I'm just asking the question.


                -
                Michael

                On Sun, Sep 28, 2014 at 11:55 AM, James Shore jshore@... [AgilePDX] <AgilePDX@yahoogroups.com> wrote:
                 

                It's entirely possible to make predictions with Agile. They're just as good as predictions made with other methods, and with XP practices, they can be much better. Agile leaders talk about embracing change because that has more potential value than making predictions.


                Software *is* inherently unpredictable. So is the weather. Forecasts (predictions) are possible in both situations, given sufficient rigor. How your team approaches predictions depends on what level of fluency they have (http://www.agilefluency.com).

                One-star teams adapt their plans and work in terms of business results. However, they don't have rigorous engineering practices, which means their predictions have wide error bars, on par with typical non-Agile teams (for 90% reliability, need 4x estimate*). They believe predictions are impossible in Agile.

                Two-star teams use rigorous engineering practices such as test-driven development, continuous integration, and the other good stuff from XP. They can make predictions with reasonable precision (for 90% reliability, need 1.8x estimate*). They can and do provide reliable predictions.

                Three- and four-star teams conduct experiments and change direction depending on market opportunities. They can make predictions as well as two-star teams, but estimating and predicting has a cost, and that cost often has no real value in the market. They often choose not to incur the waste of making predictions.

                So if a company were to talk to me about improving predictability, I would talk to them about what sort of fluency they wanted to achieve, why, and the investments they need to make to get there. For some organizations, *3 fluency isn't desired. It's too big of a cultural shift. In those cases, a *2 team is a great fit, and can provide the predictability they want.

                I describe the "how to" of making predictions in Agile in "Use Risk Management to Make Solid Commitments." http://www.jamesshore.com/Blog/Use-Risk-Management-to-Make-Solid-Commitments.html

                Cheers,
                Jim

                *These numbers are approximate and depend on the team. See the "Use Risk Management" essay for an explanation of where they come from.



                On Sep 28, 2014, at 11:11 AM, "Michael Kelly m.sean.kelly@... [AgilePDX]" <AgilePDX@yahoogroups.com> wrote:



                Core Question:
                --------------------
                Despite the relative success of Agile methods for engineering, our counterparts on the business side continue to have a need to make decisions based upon (and communicate with customers, and business partners, and other internal departments about) what will likely happen in the future. Do/can Agile methods provide any help with that?

                Discussion:
                ---------------
                I recently came across a job posting for a local PDX company that was looking for someone to manage the company's Agile adoption. Specifically, they wanted someone that would apply agile "best practices" so as to improve predictability.

                My first response, of course, was "Good luck with that." It seems pretty clear to me that Agile takes as its first principle that software development is inherently unpredictable, and that the "best practices" are all about dealing with that fact. You see this in the literature of all of Agile's leaders:
                • Kent Beck: Embrace change.
                • Jeff Sutherland: Writes about software as the product of a Complex Adaptive System (CAS), a key feature of which is unpredictability.
                • Mike Cohen: Describes "Agile planning" as something that is spread throughout the project, is more focused on planning than The Plan, encourages change, and results in plans that are easily changed.
                Part of the answer here seems to be to push the notion of agility further up the organizational hierarchy. To the extent that commitments need to be made, the heads of departments, VPs, CTOs, CEOs, etc. need to make those commitments as late as possible and make them as general as possible: "The software will be delivered in the 3rd quarter, and will contain a solution for tracking widgets.", not "The software will be delivered September 4th, and will provide three widget tracking reports, late delivery notifications, and a customize-able dashboard."

                One thing that seems to help with pushing the notion of agility up the organizational hierarchy is greater visibility. When stakeholders get regular and concrete evidence of the progress made by software development teams (e.g. regular demos), then the realities of the inevitable uncertainty of the endeavor becomes clear to all.

                But even with these things in place, the pressure for predictability persists. 
                1. Customers making buying decisions want information about what's in the pipeline, and often insist on having the details.
                2. Product Owners typically get one or two chances a year to talk about the future of their products at trade shows, and they have pressures to give details about the coming year (see item #1 above).
                3. Sales people are under similar pressures when trying to close a deal.
                4. Executives trying to make decisions about the corporate direction need information about the cost of various options.
                5. Business partners and other internal departments need to coordinate their efforts with ours.
                As a developer, I could look at these pressures and say (and, no doubt, have said) "Good luck with that." But I can't help but feel that this response makes me something less than a full collaborative partner in the objectives of the enterprise, and that I should be able to provide an Agile response that is more...helpful.

                What thinks you all?

                -
                Michael Kelly
                DAT Solutions




                --
                James Shore - The Art of Agile
                recipient of Gordon Pask Award for Contributions to Agile Practice
                co-author of The Art of Agile Development

                voice: 503-267-5490
                email: jshore@...
                blog: http://jamesshore.com


              • Millard Ellingsworth
                I m guessing that the root desire is improperly stated: being more predictable is easily achieved -- promise less. Most teams can reliably do almost nothing.
                Message 7 of 15 , Sep 29, 2014
                  I'm guessing that the root desire is improperly stated: being more predictable is easily achieved -- promise less. Most teams can reliably do almost nothing.

                  Whenever possible, I think the answer here is to continuously deliver and have a transparent backlog. Rather than an annual release with high uncertainty, deliver each feature as quickly as you can with bracketed estimates for the backlog items. Now anyone can look at feature #4 on the list and say "could be in before Halloween, should definitely be in before Thanksgiving". If you need it sooner, negotiate it to next in line. Because we all know it is inherently unpredictable and when you multiply probabilities, likelihood (and confidence) drops quickly.

                  You could try the other route: establish a dependable velocity and use that to predict the future, but I've yet to encounter a team in person that could do that (though my encounters do tend to skew to teams adopting agile or having trouble doing so). The time it takes to learn to write good stories, do story points reasonably, build up some experience and start delivering reliably from your backlog is often longer than the team remains whole. Any change destabilizes things and immediately jeopardizes any long-term commitment. As you said "good luck with that".

                  The core of your question, if I may restate, could be "How do we define a business process in which development is a full partner rather than a limiting factor?" That likely deserves a thread (or conference) of its own.

                  Millard

                  On Sun, Sep 28, 2014 at 12:14 PM, James Shore jshore@... [AgilePDX] <AgilePDX@yahoogroups.com> wrote:
                   

                  I've thought about it a lot. :-)


                  On Sep 28, 2014, at 12:02 PM, Michael Kelly m.sean.kelly@... [AgilePDX] <AgilePDX@yahoogroups.com> wrote:

                  Wow, thanks Jim. Much appreciated. It's almost as if you had this one all prepared. :-)

                  On Sep 28, 2014 11:55 AM, "James Shore jshore@... [AgilePDX]" <AgilePDX@yahoogroups.com> wrote:
                   

                  It's entirely possible to make predictions with Agile. They're just as good as predictions made with other methods, and with XP practices, they can be much better. Agile leaders talk about embracing change because that has more potential value than making predictions.


                  Software *is* inherently unpredictable. So is the weather. Forecasts (predictions) are possible in both situations, given sufficient rigor. How your team approaches predictions depends on what level of fluency they have (http://www.agilefluency.com).

                  One-star teams adapt their plans and work in terms of business results. However, they don't have rigorous engineering practices, which means their predictions have wide error bars, on par with typical non-Agile teams (for 90% reliability, need 4x estimate*). They believe predictions are impossible in Agile.

                  Two-star teams use rigorous engineering practices such as test-driven development, continuous integration, and the other good stuff from XP. They can make predictions with reasonable precision (for 90% reliability, need 1.8x estimate*). They can and do provide reliable predictions.

                  Three- and four-star teams conduct experiments and change direction depending on market opportunities. They can make predictions as well as two-star teams, but estimating and predicting has a cost, and that cost often has no real value in the market. They often choose not to incur the waste of making predictions.

                  So if a company were to talk to me about improving predictability, I would talk to them about what sort of fluency they wanted to achieve, why, and the investments they need to make to get there. For some organizations, *3 fluency isn't desired. It's too big of a cultural shift. In those cases, a *2 team is a great fit, and can provide the predictability they want.

                  I describe the "how to" of making predictions in Agile in "Use Risk Management to Make Solid Commitments." http://www.jamesshore.com/Blog/Use-Risk-Management-to-Make-Solid-Commitments.html

                  Cheers,
                  Jim

                  *These numbers are approximate and depend on the team. See the "Use Risk Management" essay for an explanation of where they come from.



                  On Sep 28, 2014, at 11:11 AM, "Michael Kelly m.sean.kelly@... [AgilePDX]" <AgilePDX@yahoogroups.com> wrote:



                  Core Question:
                  --------------------
                  Despite the relative success of Agile methods for engineering, our counterparts on the business side continue to have a need to make decisions based upon (and communicate with customers, and business partners, and other internal departments about) what will likely happen in the future. Do/can Agile methods provide any help with that?

                  Discussion:
                  ---------------
                  I recently came across a job posting for a local PDX company that was looking for someone to manage the company's Agile adoption. Specifically, they wanted someone that would apply agile "best practices" so as to improve predictability.

                  My first response, of course, was "Good luck with that." It seems pretty clear to me that Agile takes as its first principle that software development is inherently unpredictable, and that the "best practices" are all about dealing with that fact. You see this in the literature of all of Agile's leaders:
                  • Kent Beck: Embrace change.
                  • Jeff Sutherland: Writes about software as the product of a Complex Adaptive System (CAS), a key feature of which is unpredictability.
                  • Mike Cohen: Describes "Agile planning" as something that is spread throughout the project, is more focused on planning than The Plan, encourages change, and results in plans that are easily changed.
                  Part of the answer here seems to be to push the notion of agility further up the organizational hierarchy. To the extent that commitments need to be made, the heads of departments, VPs, CTOs, CEOs, etc. need to make those commitments as late as possible and make them as general as possible: "The software will be delivered in the 3rd quarter, and will contain a solution for tracking widgets.", not "The software will be delivered September 4th, and will provide three widget tracking reports, late delivery notifications, and a customize-able dashboard."

                  One thing that seems to help with pushing the notion of agility up the organizational hierarchy is greater visibility. When stakeholders get regular and concrete evidence of the progress made by software development teams (e.g. regular demos), then the realities of the inevitable uncertainty of the endeavor becomes clear to all.

                  But even with these things in place, the pressure for predictability persists. 
                  1. Customers making buying decisions want information about what's in the pipeline, and often insist on having the details.
                  2. Product Owners typically get one or two chances a year to talk about the future of their products at trade shows, and they have pressures to give details about the coming year (see item #1 above).
                  3. Sales people are under similar pressures when trying to close a deal.
                  4. Executives trying to make decisions about the corporate direction need information about the cost of various options.
                  5. Business partners and other internal departments need to coordinate their efforts with ours.
                  As a developer, I could look at these pressures and say (and, no doubt, have said) "Good luck with that." But I can't help but feel that this response makes me something less than a full collaborative partner in the objectives of the enterprise, and that I should be able to provide an Agile response that is more...helpful.

                  What thinks you all?

                  -
                  Michael Kelly
                  DAT Solutions




                  --
                  James Shore - The Art of Agile
                  recipient of Gordon Pask Award for Contributions to Agile Practice
                  co-author of The Art of Agile Development

                  voice: 503-267-5490
                  email: jshore@...
                  blog: http://jamesshore.com






                  --
                  James Shore - The Art of Agile
                  recipient of Gordon Pask Award for Contributions to Agile Practice
                  co-author of The Art of Agile Development

                  voice: 503-267-5490
                  email: jshore@...
                  blog: http://jamesshore.com


                • Patrick Logan
                  A good resource for anyone who has to perform or rely on predictions of any consequence would do all to work through the book and this site...
                  Message 8 of 15 , Sep 29, 2014

                    A good resource for anyone who has to perform or rely on predictions of any consequence would do all to work through the book and this site...
                    http://www.howtomeasureanything.com

                    On Sep 29, 2014 9:53 AM, "Michael Kelly m.sean.kelly@... [AgilePDX]" <AgilePDX@yahoogroups.com> wrote:
                     

                    Thanks James, much appreciated. If I understand what you're saying, a rigorous process (with automated tests, velocity tracking, continuous integration, etc.) helps with predictability. That makes sense to me, especially when you're predicting the end-game of a project that has already started and has a track record. And that's helpful. But new projects and existing projects experiencing significant disruptions (changes in team members, technology, or features) don't really have any velocity as a starting point, much less a stable one. And frequently, they don't have a well-groomed backlog with story points.

                    Is our answer in this case "good luck with that"? Is the answer essentially that Agile estimation doesn't kick in until you've already adopted the practices and had them in place for a while? Or is there some "agile" method for iterative provisional estimation of schedule and cost that contains something about the degree of uncertainty--an iterative process that drives down the uncertainty to the point where a decision can be made, but no further. If there is, I'm not aware of it. And I'm not even clear such a thing is feasible, I'm just asking the question.


                    -
                    Michael

                    On Sun, Sep 28, 2014 at 11:55 AM, James Shore jshore@... [AgilePDX] <AgilePDX@yahoogroups.com> wrote:
                     

                    It's entirely possible to make predictions with Agile. They're just as good as predictions made with other methods, and with XP practices, they can be much better. Agile leaders talk about embracing change because that has more potential value than making predictions.


                    Software *is* inherently unpredictable. So is the weather. Forecasts (predictions) are possible in both situations, given sufficient rigor. How your team approaches predictions depends on what level of fluency they have (http://www.agilefluency.com).

                    One-star teams adapt their plans and work in terms of business results. However, they don't have rigorous engineering practices, which means their predictions have wide error bars, on par with typical non-Agile teams (for 90% reliability, need 4x estimate*). They believe predictions are impossible in Agile.

                    Two-star teams use rigorous engineering practices such as test-driven development, continuous integration, and the other good stuff from XP. They can make predictions with reasonable precision (for 90% reliability, need 1.8x estimate*). They can and do provide reliable predictions.

                    Three- and four-star teams conduct experiments and change direction depending on market opportunities. They can make predictions as well as two-star teams, but estimating and predicting has a cost, and that cost often has no real value in the market. They often choose not to incur the waste of making predictions.

                    So if a company were to talk to me about improving predictability, I would talk to them about what sort of fluency they wanted to achieve, why, and the investments they need to make to get there. For some organizations, *3 fluency isn't desired. It's too big of a cultural shift. In those cases, a *2 team is a great fit, and can provide the predictability they want.

                    I describe the "how to" of making predictions in Agile in "Use Risk Management to Make Solid Commitments." http://www.jamesshore.com/Blog/Use-Risk-Management-to-Make-Solid-Commitments.html

                    Cheers,
                    Jim

                    *These numbers are approximate and depend on the team. See the "Use Risk Management" essay for an explanation of where they come from.



                    On Sep 28, 2014, at 11:11 AM, "Michael Kelly m.sean.kelly@... [AgilePDX]" <AgilePDX@yahoogroups.com> wrote:



                    Core Question:
                    --------------------
                    Despite the relative success of Agile methods for engineering, our counterparts on the business side continue to have a need to make decisions based upon (and communicate with customers, and business partners, and other internal departments about) what will likely happen in the future. Do/can Agile methods provide any help with that?

                    Discussion:
                    ---------------
                    I recently came across a job posting for a local PDX company that was looking for someone to manage the company's Agile adoption. Specifically, they wanted someone that would apply agile "best practices" so as to improve predictability.

                    My first response, of course, was "Good luck with that." It seems pretty clear to me that Agile takes as its first principle that software development is inherently unpredictable, and that the "best practices" are all about dealing with that fact. You see this in the literature of all of Agile's leaders:
                    • Kent Beck: Embrace change.
                    • Jeff Sutherland: Writes about software as the product of a Complex Adaptive System (CAS), a key feature of which is unpredictability.
                    • Mike Cohen: Describes "Agile planning" as something that is spread throughout the project, is more focused on planning than The Plan, encourages change, and results in plans that are easily changed.
                    Part of the answer here seems to be to push the notion of agility further up the organizational hierarchy. To the extent that commitments need to be made, the heads of departments, VPs, CTOs, CEOs, etc. need to make those commitments as late as possible and make them as general as possible: "The software will be delivered in the 3rd quarter, and will contain a solution for tracking widgets.", not "The software will be delivered September 4th, and will provide three widget tracking reports, late delivery notifications, and a customize-able dashboard."

                    One thing that seems to help with pushing the notion of agility up the organizational hierarchy is greater visibility. When stakeholders get regular and concrete evidence of the progress made by software development teams (e.g. regular demos), then the realities of the inevitable uncertainty of the endeavor becomes clear to all.

                    But even with these things in place, the pressure for predictability persists. 
                    1. Customers making buying decisions want information about what's in the pipeline, and often insist on having the details.
                    2. Product Owners typically get one or two chances a year to talk about the future of their products at trade shows, and they have pressures to give details about the coming year (see item #1 above).
                    3. Sales people are under similar pressures when trying to close a deal.
                    4. Executives trying to make decisions about the corporate direction need information about the cost of various options.
                    5. Business partners and other internal departments need to coordinate their efforts with ours.
                    As a developer, I could look at these pressures and say (and, no doubt, have said) "Good luck with that." But I can't help but feel that this response makes me something less than a full collaborative partner in the objectives of the enterprise, and that I should be able to provide an Agile response that is more...helpful.

                    What thinks you all?

                    -
                    Michael Kelly
                    DAT Solutions




                    --
                    James Shore - The Art of Agile
                    recipient of Gordon Pask Award for Contributions to Agile Practice
                    co-author of The Art of Agile Development

                    voice: 503-267-5490
                    email: jshore@...
                    blog: http://jamesshore.com


                  • Charlie Poole
                    I d like to temporarily bypass the question of how predictable agile is (although I pretty much agree with Jim on that) to raise the question of what
                    Message 9 of 15 , Sep 29, 2014
                      I'd like to temporarily bypass the question of how predictable agile is (although I pretty much agree with Jim on that) to raise the question of what Predictability means to people here.

                      I ask this, because I have noted in the wild that many folks confuse predictions with promises. Sometimes, these folks are managers, which leads to an insistence that estimates must be met, not 50% of the time as one would logically expect with an estimate, but close to 100% of the time. Sometimes the developers are infected with the same belief, leading them to padding of estimates.

                      I wonder if it may be possible to achieve good predictability of software in the context of the biases that such confusion instills. I doubt it.

                      So... what does predictability mean to us here?

                      Charlie

                      On Mon, Sep 29, 2014 at 9:58 AM, Patrick Logan patrickdlogan@... [AgilePDX] <AgilePDX@yahoogroups.com> wrote:
                       

                      A good resource for anyone who has to perform or rely on predictions of any consequence would do all to work through the book and this site...
                      http://www.howtomeasureanything.com

                      On Sep 29, 2014 9:53 AM, "Michael Kelly m.sean.kelly@... [AgilePDX]" <AgilePDX@yahoogroups.com> wrote:
                       

                      Thanks James, much appreciated. If I understand what you're saying, a rigorous process (with automated tests, velocity tracking, continuous integration, etc.) helps with predictability. That makes sense to me, especially when you're predicting the end-game of a project that has already started and has a track record. And that's helpful. But new projects and existing projects experiencing significant disruptions (changes in team members, technology, or features) don't really have any velocity as a starting point, much less a stable one. And frequently, they don't have a well-groomed backlog with story points.

                      Is our answer in this case "good luck with that"? Is the answer essentially that Agile estimation doesn't kick in until you've already adopted the practices and had them in place for a while? Or is there some "agile" method for iterative provisional estimation of schedule and cost that contains something about the degree of uncertainty--an iterative process that drives down the uncertainty to the point where a decision can be made, but no further. If there is, I'm not aware of it. And I'm not even clear such a thing is feasible, I'm just asking the question.


                      -
                      Michael

                      On Sun, Sep 28, 2014 at 11:55 AM, James Shore jshore@... [AgilePDX] <AgilePDX@yahoogroups.com> wrote:
                       

                      It's entirely possible to make predictions with Agile. They're just as good as predictions made with other methods, and with XP practices, they can be much better. Agile leaders talk about embracing change because that has more potential value than making predictions.


                      Software *is* inherently unpredictable. So is the weather. Forecasts (predictions) are possible in both situations, given sufficient rigor. How your team approaches predictions depends on what level of fluency they have (http://www.agilefluency.com).

                      One-star teams adapt their plans and work in terms of business results. However, they don't have rigorous engineering practices, which means their predictions have wide error bars, on par with typical non-Agile teams (for 90% reliability, need 4x estimate*). They believe predictions are impossible in Agile.

                      Two-star teams use rigorous engineering practices such as test-driven development, continuous integration, and the other good stuff from XP. They can make predictions with reasonable precision (for 90% reliability, need 1.8x estimate*). They can and do provide reliable predictions.

                      Three- and four-star teams conduct experiments and change direction depending on market opportunities. They can make predictions as well as two-star teams, but estimating and predicting has a cost, and that cost often has no real value in the market. They often choose not to incur the waste of making predictions.

                      So if a company were to talk to me about improving predictability, I would talk to them about what sort of fluency they wanted to achieve, why, and the investments they need to make to get there. For some organizations, *3 fluency isn't desired. It's too big of a cultural shift. In those cases, a *2 team is a great fit, and can provide the predictability they want.

                      I describe the "how to" of making predictions in Agile in "Use Risk Management to Make Solid Commitments." http://www.jamesshore.com/Blog/Use-Risk-Management-to-Make-Solid-Commitments.html

                      Cheers,
                      Jim

                      *These numbers are approximate and depend on the team. See the "Use Risk Management" essay for an explanation of where they come from.



                      On Sep 28, 2014, at 11:11 AM, "Michael Kelly m.sean.kelly@... [AgilePDX]" <AgilePDX@yahoogroups.com> wrote:



                      Core Question:
                      --------------------
                      Despite the relative success of Agile methods for engineering, our counterparts on the business side continue to have a need to make decisions based upon (and communicate with customers, and business partners, and other internal departments about) what will likely happen in the future. Do/can Agile methods provide any help with that?

                      Discussion:
                      ---------------
                      I recently came across a job posting for a local PDX company that was looking for someone to manage the company's Agile adoption. Specifically, they wanted someone that would apply agile "best practices" so as to improve predictability.

                      My first response, of course, was "Good luck with that." It seems pretty clear to me that Agile takes as its first principle that software development is inherently unpredictable, and that the "best practices" are all about dealing with that fact. You see this in the literature of all of Agile's leaders:
                      • Kent Beck: Embrace change.
                      • Jeff Sutherland: Writes about software as the product of a Complex Adaptive System (CAS), a key feature of which is unpredictability.
                      • Mike Cohen: Describes "Agile planning" as something that is spread throughout the project, is more focused on planning than The Plan, encourages change, and results in plans that are easily changed.
                      Part of the answer here seems to be to push the notion of agility further up the organizational hierarchy. To the extent that commitments need to be made, the heads of departments, VPs, CTOs, CEOs, etc. need to make those commitments as late as possible and make them as general as possible: "The software will be delivered in the 3rd quarter, and will contain a solution for tracking widgets.", not "The software will be delivered September 4th, and will provide three widget tracking reports, late delivery notifications, and a customize-able dashboard."

                      One thing that seems to help with pushing the notion of agility up the organizational hierarchy is greater visibility. When stakeholders get regular and concrete evidence of the progress made by software development teams (e.g. regular demos), then the realities of the inevitable uncertainty of the endeavor becomes clear to all.

                      But even with these things in place, the pressure for predictability persists. 
                      1. Customers making buying decisions want information about what's in the pipeline, and often insist on having the details.
                      2. Product Owners typically get one or two chances a year to talk about the future of their products at trade shows, and they have pressures to give details about the coming year (see item #1 above).
                      3. Sales people are under similar pressures when trying to close a deal.
                      4. Executives trying to make decisions about the corporate direction need information about the cost of various options.
                      5. Business partners and other internal departments need to coordinate their efforts with ours.
                      As a developer, I could look at these pressures and say (and, no doubt, have said) "Good luck with that." But I can't help but feel that this response makes me something less than a full collaborative partner in the objectives of the enterprise, and that I should be able to provide an Agile response that is more...helpful.

                      What thinks you all?

                      -
                      Michael Kelly
                      DAT Solutions




                      --
                      James Shore - The Art of Agile
                      recipient of Gordon Pask Award for Contributions to Agile Practice
                      co-author of The Art of Agile Development

                      voice: 503-267-5490
                      email: jshore@...
                      blog: http://jamesshore.com



                    • Patrick Logan
                      I d just reiterate that, 1. I agree with Charlie, and 2. the reference I provided addresses those kind of issues (and others) really well. It will help you
                      Message 10 of 15 , Sep 29, 2014

                        I'd just reiterate that, 1. I agree with Charlie, and 2. the reference I provided addresses those kind of issues (and others) really well. It will help you think and communicate  clearly about these kinds of complicated situations.

                        On Sep 29, 2014 10:33 AM, "Charlie Poole charliepoole@... [AgilePDX]" <AgilePDX@yahoogroups.com> wrote:
                         

                        I'd like to temporarily bypass the question of how predictable agile is (although I pretty much agree with Jim on that) to raise the question of what Predictability means to people here.

                        I ask this, because I have noted in the wild that many folks confuse predictions with promises. Sometimes, these folks are managers, which leads to an insistence that estimates must be met, not 50% of the time as one would logically expect with an estimate, but close to 100% of the time. Sometimes the developers are infected with the same belief, leading them to padding of estimates.

                        I wonder if it may be possible to achieve good predictability of software in the context of the biases that such confusion instills. I doubt it.

                        So... what does predictability mean to us here?

                        Charlie

                        On Mon, Sep 29, 2014 at 9:58 AM, Patrick Logan patrickdlogan@... [AgilePDX] <AgilePDX@yahoogroups.com> wrote:
                         

                        A good resource for anyone who has to perform or rely on predictions of any consequence would do all to work through the book and this site...
                        http://www.howtomeasureanything.com

                        On Sep 29, 2014 9:53 AM, "Michael Kelly m.sean.kelly@... [AgilePDX]" <AgilePDX@yahoogroups.com> wrote:
                         

                        Thanks James, much appreciated. If I understand what you're saying, a rigorous process (with automated tests, velocity tracking, continuous integration, etc.) helps with predictability. That makes sense to me, especially when you're predicting the end-game of a project that has already started and has a track record. And that's helpful. But new projects and existing projects experiencing significant disruptions (changes in team members, technology, or features) don't really have any velocity as a starting point, much less a stable one. And frequently, they don't have a well-groomed backlog with story points.

                        Is our answer in this case "good luck with that"? Is the answer essentially that Agile estimation doesn't kick in until you've already adopted the practices and had them in place for a while? Or is there some "agile" method for iterative provisional estimation of schedule and cost that contains something about the degree of uncertainty--an iterative process that drives down the uncertainty to the point where a decision can be made, but no further. If there is, I'm not aware of it. And I'm not even clear such a thing is feasible, I'm just asking the question.


                        -
                        Michael

                        On Sun, Sep 28, 2014 at 11:55 AM, James Shore jshore@... [AgilePDX] <AgilePDX@yahoogroups.com> wrote:
                         

                        It's entirely possible to make predictions with Agile. They're just as good as predictions made with other methods, and with XP practices, they can be much better. Agile leaders talk about embracing change because that has more potential value than making predictions.


                        Software *is* inherently unpredictable. So is the weather. Forecasts (predictions) are possible in both situations, given sufficient rigor. How your team approaches predictions depends on what level of fluency they have (http://www.agilefluency.com).

                        One-star teams adapt their plans and work in terms of business results. However, they don't have rigorous engineering practices, which means their predictions have wide error bars, on par with typical non-Agile teams (for 90% reliability, need 4x estimate*). They believe predictions are impossible in Agile.

                        Two-star teams use rigorous engineering practices such as test-driven development, continuous integration, and the other good stuff from XP. They can make predictions with reasonable precision (for 90% reliability, need 1.8x estimate*). They can and do provide reliable predictions.

                        Three- and four-star teams conduct experiments and change direction depending on market opportunities. They can make predictions as well as two-star teams, but estimating and predicting has a cost, and that cost often has no real value in the market. They often choose not to incur the waste of making predictions.

                        So if a company were to talk to me about improving predictability, I would talk to them about what sort of fluency they wanted to achieve, why, and the investments they need to make to get there. For some organizations, *3 fluency isn't desired. It's too big of a cultural shift. In those cases, a *2 team is a great fit, and can provide the predictability they want.

                        I describe the "how to" of making predictions in Agile in "Use Risk Management to Make Solid Commitments." http://www.jamesshore.com/Blog/Use-Risk-Management-to-Make-Solid-Commitments.html

                        Cheers,
                        Jim

                        *These numbers are approximate and depend on the team. See the "Use Risk Management" essay for an explanation of where they come from.



                        On Sep 28, 2014, at 11:11 AM, "Michael Kelly m.sean.kelly@... [AgilePDX]" <AgilePDX@yahoogroups.com> wrote:



                        Core Question:
                        --------------------
                        Despite the relative success of Agile methods for engineering, our counterparts on the business side continue to have a need to make decisions based upon (and communicate with customers, and business partners, and other internal departments about) what will likely happen in the future. Do/can Agile methods provide any help with that?

                        Discussion:
                        ---------------
                        I recently came across a job posting for a local PDX company that was looking for someone to manage the company's Agile adoption. Specifically, they wanted someone that would apply agile "best practices" so as to improve predictability.

                        My first response, of course, was "Good luck with that." It seems pretty clear to me that Agile takes as its first principle that software development is inherently unpredictable, and that the "best practices" are all about dealing with that fact. You see this in the literature of all of Agile's leaders:
                        • Kent Beck: Embrace change.
                        • Jeff Sutherland: Writes about software as the product of a Complex Adaptive System (CAS), a key feature of which is unpredictability.
                        • Mike Cohen: Describes "Agile planning" as something that is spread throughout the project, is more focused on planning than The Plan, encourages change, and results in plans that are easily changed.
                        Part of the answer here seems to be to push the notion of agility further up the organizational hierarchy. To the extent that commitments need to be made, the heads of departments, VPs, CTOs, CEOs, etc. need to make those commitments as late as possible and make them as general as possible: "The software will be delivered in the 3rd quarter, and will contain a solution for tracking widgets.", not "The software will be delivered September 4th, and will provide three widget tracking reports, late delivery notifications, and a customize-able dashboard."

                        One thing that seems to help with pushing the notion of agility up the organizational hierarchy is greater visibility. When stakeholders get regular and concrete evidence of the progress made by software development teams (e.g. regular demos), then the realities of the inevitable uncertainty of the endeavor becomes clear to all.

                        But even with these things in place, the pressure for predictability persists. 
                        1. Customers making buying decisions want information about what's in the pipeline, and often insist on having the details.
                        2. Product Owners typically get one or two chances a year to talk about the future of their products at trade shows, and they have pressures to give details about the coming year (see item #1 above).
                        3. Sales people are under similar pressures when trying to close a deal.
                        4. Executives trying to make decisions about the corporate direction need information about the cost of various options.
                        5. Business partners and other internal departments need to coordinate their efforts with ours.
                        As a developer, I could look at these pressures and say (and, no doubt, have said) "Good luck with that." But I can't help but feel that this response makes me something less than a full collaborative partner in the objectives of the enterprise, and that I should be able to provide an Agile response that is more...helpful.

                        What thinks you all?

                        -
                        Michael Kelly
                        DAT Solutions




                        --
                        James Shore - The Art of Agile
                        recipient of Gordon Pask Award for Contributions to Agile Practice
                        co-author of The Art of Agile Development

                        voice: 503-267-5490
                        email: jshore@...
                        blog: http://jamesshore.com



                      • Michael Kelly
                        Millard: I think you re getting at the heart of the issue. I guess I d turn your question around and ask, If we re full partners in the 10k foot level
                        Message 11 of 15 , Sep 29, 2014
                          Millard: I think you're getting at the heart of the issue. I guess I'd turn your question around and ask, "If we're full partners in the 10k foot level business process, what does Agile add at that level?"

                          Charlie: For me, I think it's about information used to make decisions. The best information we can provide. This includes the degree of uncertainty. And, to be sure, the fact that this information is frequently taken as a "promise" is part of challenge.

                          I know that there's been some work in the area of Agile at the executive level. I assume that it includes a better understanding about the uncertainty of estimates and the importance of making your commitments as late as possible and making them as general as possible. Who does that work? What are they saying?
                           

                          -
                          Michael

                          On Mon, Sep 29, 2014 at 10:33 AM, Charlie Poole charliepoole@... [AgilePDX] <AgilePDX@yahoogroups.com> wrote:
                           

                          I'd like to temporarily bypass the question of how predictable agile is (although I pretty much agree with Jim on that) to raise the question of what Predictability means to people here.

                          I ask this, because I have noted in the wild that many folks confuse predictions with promises. Sometimes, these folks are managers, which leads to an insistence that estimates must be met, not 50% of the time as one would logically expect with an estimate, but close to 100% of the time. Sometimes the developers are infected with the same belief, leading them to padding of estimates.

                          I wonder if it may be possible to achieve good predictability of software in the context of the biases that such confusion instills. I doubt it.

                          So... what does predictability mean to us here?

                          Charlie

                          On Mon, Sep 29, 2014 at 9:58 AM, Patrick Logan patrickdlogan@... [AgilePDX] <AgilePDX@yahoogroups.com> wrote:
                           

                          A good resource for anyone who has to perform or rely on predictions of any consequence would do all to work through the book and this site...
                          http://www.howtomeasureanything.com

                          On Sep 29, 2014 9:53 AM, "Michael Kelly m.sean.kelly@... [AgilePDX]" <AgilePDX@yahoogroups.com> wrote:
                           

                          Thanks James, much appreciated. If I understand what you're saying, a rigorous process (with automated tests, velocity tracking, continuous integration, etc.) helps with predictability. That makes sense to me, especially when you're predicting the end-game of a project that has already started and has a track record. And that's helpful. But new projects and existing projects experiencing significant disruptions (changes in team members, technology, or features) don't really have any velocity as a starting point, much less a stable one. And frequently, they don't have a well-groomed backlog with story points.

                          Is our answer in this case "good luck with that"? Is the answer essentially that Agile estimation doesn't kick in until you've already adopted the practices and had them in place for a while? Or is there some "agile" method for iterative provisional estimation of schedule and cost that contains something about the degree of uncertainty--an iterative process that drives down the uncertainty to the point where a decision can be made, but no further. If there is, I'm not aware of it. And I'm not even clear such a thing is feasible, I'm just asking the question.


                          -
                          Michael

                          On Sun, Sep 28, 2014 at 11:55 AM, James Shore jshore@... [AgilePDX] <AgilePDX@yahoogroups.com> wrote:
                           

                          It's entirely possible to make predictions with Agile. They're just as good as predictions made with other methods, and with XP practices, they can be much better. Agile leaders talk about embracing change because that has more potential value than making predictions.


                          Software *is* inherently unpredictable. So is the weather. Forecasts (predictions) are possible in both situations, given sufficient rigor. How your team approaches predictions depends on what level of fluency they have (http://www.agilefluency.com).

                          One-star teams adapt their plans and work in terms of business results. However, they don't have rigorous engineering practices, which means their predictions have wide error bars, on par with typical non-Agile teams (for 90% reliability, need 4x estimate*). They believe predictions are impossible in Agile.

                          Two-star teams use rigorous engineering practices such as test-driven development, continuous integration, and the other good stuff from XP. They can make predictions with reasonable precision (for 90% reliability, need 1.8x estimate*). They can and do provide reliable predictions.

                          Three- and four-star teams conduct experiments and change direction depending on market opportunities. They can make predictions as well as two-star teams, but estimating and predicting has a cost, and that cost often has no real value in the market. They often choose not to incur the waste of making predictions.

                          So if a company were to talk to me about improving predictability, I would talk to them about what sort of fluency they wanted to achieve, why, and the investments they need to make to get there. For some organizations, *3 fluency isn't desired. It's too big of a cultural shift. In those cases, a *2 team is a great fit, and can provide the predictability they want.

                          I describe the "how to" of making predictions in Agile in "Use Risk Management to Make Solid Commitments." http://www.jamesshore.com/Blog/Use-Risk-Management-to-Make-Solid-Commitments.html

                          Cheers,
                          Jim

                          *These numbers are approximate and depend on the team. See the "Use Risk Management" essay for an explanation of where they come from.



                          On Sep 28, 2014, at 11:11 AM, "Michael Kelly m.sean.kelly@... [AgilePDX]" <AgilePDX@yahoogroups.com> wrote:



                          Core Question:
                          --------------------
                          Despite the relative success of Agile methods for engineering, our counterparts on the business side continue to have a need to make decisions based upon (and communicate with customers, and business partners, and other internal departments about) what will likely happen in the future. Do/can Agile methods provide any help with that?

                          Discussion:
                          ---------------
                          I recently came across a job posting for a local PDX company that was looking for someone to manage the company's Agile adoption. Specifically, they wanted someone that would apply agile "best practices" so as to improve predictability.

                          My first response, of course, was "Good luck with that." It seems pretty clear to me that Agile takes as its first principle that software development is inherently unpredictable, and that the "best practices" are all about dealing with that fact. You see this in the literature of all of Agile's leaders:
                          • Kent Beck: Embrace change.
                          • Jeff Sutherland: Writes about software as the product of a Complex Adaptive System (CAS), a key feature of which is unpredictability.
                          • Mike Cohen: Describes "Agile planning" as something that is spread throughout the project, is more focused on planning than The Plan, encourages change, and results in plans that are easily changed.
                          Part of the answer here seems to be to push the notion of agility further up the organizational hierarchy. To the extent that commitments need to be made, the heads of departments, VPs, CTOs, CEOs, etc. need to make those commitments as late as possible and make them as general as possible: "The software will be delivered in the 3rd quarter, and will contain a solution for tracking widgets.", not "The software will be delivered September 4th, and will provide three widget tracking reports, late delivery notifications, and a customize-able dashboard."

                          One thing that seems to help with pushing the notion of agility up the organizational hierarchy is greater visibility. When stakeholders get regular and concrete evidence of the progress made by software development teams (e.g. regular demos), then the realities of the inevitable uncertainty of the endeavor becomes clear to all.

                          But even with these things in place, the pressure for predictability persists. 
                          1. Customers making buying decisions want information about what's in the pipeline, and often insist on having the details.
                          2. Product Owners typically get one or two chances a year to talk about the future of their products at trade shows, and they have pressures to give details about the coming year (see item #1 above).
                          3. Sales people are under similar pressures when trying to close a deal.
                          4. Executives trying to make decisions about the corporate direction need information about the cost of various options.
                          5. Business partners and other internal departments need to coordinate their efforts with ours.
                          As a developer, I could look at these pressures and say (and, no doubt, have said) "Good luck with that." But I can't help but feel that this response makes me something less than a full collaborative partner in the objectives of the enterprise, and that I should be able to provide an Agile response that is more...helpful.

                          What thinks you all?

                          -
                          Michael Kelly
                          DAT Solutions




                          --
                          James Shore - The Art of Agile
                          recipient of Gordon Pask Award for Contributions to Agile Practice
                          co-author of The Art of Agile Development

                          voice: 503-267-5490
                          email: jshore@...
                          blog: http://jamesshore.com




                        • Michael Kelly
                          Thanks Patrick, I ll look into it. - Michael On Mon, Sep 29, 2014 at 10:52 AM, Patrick Logan patrickdlogan@gmail.com
                          Message 12 of 15 , Sep 29, 2014
                            Thanks Patrick, I'll look into it.

                            -
                            Michael

                            On Mon, Sep 29, 2014 at 10:52 AM, Patrick Logan patrickdlogan@... [AgilePDX] <AgilePDX@yahoogroups.com> wrote:
                             

                            I'd just reiterate that, 1. I agree with Charlie, and 2. the reference I provided addresses those kind of issues (and others) really well. It will help you think and communicate  clearly about these kinds of complicated situations.

                            On Sep 29, 2014 10:33 AM, "Charlie Poole charliepoole@... [AgilePDX]" <AgilePDX@yahoogroups.com> wrote:
                             

                            I'd like to temporarily bypass the question of how predictable agile is (although I pretty much agree with Jim on that) to raise the question of what Predictability means to people here.

                            I ask this, because I have noted in the wild that many folks confuse predictions with promises. Sometimes, these folks are managers, which leads to an insistence that estimates must be met, not 50% of the time as one would logically expect with an estimate, but close to 100% of the time. Sometimes the developers are infected with the same belief, leading them to padding of estimates.

                            I wonder if it may be possible to achieve good predictability of software in the context of the biases that such confusion instills. I doubt it.

                            So... what does predictability mean to us here?

                            Charlie

                            On Mon, Sep 29, 2014 at 9:58 AM, Patrick Logan patrickdlogan@... [AgilePDX] <AgilePDX@yahoogroups.com> wrote:
                             

                            A good resource for anyone who has to perform or rely on predictions of any consequence would do all to work through the book and this site...
                            http://www.howtomeasureanything.com

                            On Sep 29, 2014 9:53 AM, "Michael Kelly m.sean.kelly@... [AgilePDX]" <AgilePDX@yahoogroups.com> wrote:
                             

                            Thanks James, much appreciated. If I understand what you're saying, a rigorous process (with automated tests, velocity tracking, continuous integration, etc.) helps with predictability. That makes sense to me, especially when you're predicting the end-game of a project that has already started and has a track record. And that's helpful. But new projects and existing projects experiencing significant disruptions (changes in team members, technology, or features) don't really have any velocity as a starting point, much less a stable one. And frequently, they don't have a well-groomed backlog with story points.

                            Is our answer in this case "good luck with that"? Is the answer essentially that Agile estimation doesn't kick in until you've already adopted the practices and had them in place for a while? Or is there some "agile" method for iterative provisional estimation of schedule and cost that contains something about the degree of uncertainty--an iterative process that drives down the uncertainty to the point where a decision can be made, but no further. If there is, I'm not aware of it. And I'm not even clear such a thing is feasible, I'm just asking the question.


                            -
                            Michael

                            On Sun, Sep 28, 2014 at 11:55 AM, James Shore jshore@... [AgilePDX] <AgilePDX@yahoogroups.com> wrote:
                             

                            It's entirely possible to make predictions with Agile. They're just as good as predictions made with other methods, and with XP practices, they can be much better. Agile leaders talk about embracing change because that has more potential value than making predictions.


                            Software *is* inherently unpredictable. So is the weather. Forecasts (predictions) are possible in both situations, given sufficient rigor. How your team approaches predictions depends on what level of fluency they have (http://www.agilefluency.com).

                            One-star teams adapt their plans and work in terms of business results. However, they don't have rigorous engineering practices, which means their predictions have wide error bars, on par with typical non-Agile teams (for 90% reliability, need 4x estimate*). They believe predictions are impossible in Agile.

                            Two-star teams use rigorous engineering practices such as test-driven development, continuous integration, and the other good stuff from XP. They can make predictions with reasonable precision (for 90% reliability, need 1.8x estimate*). They can and do provide reliable predictions.

                            Three- and four-star teams conduct experiments and change direction depending on market opportunities. They can make predictions as well as two-star teams, but estimating and predicting has a cost, and that cost often has no real value in the market. They often choose not to incur the waste of making predictions.

                            So if a company were to talk to me about improving predictability, I would talk to them about what sort of fluency they wanted to achieve, why, and the investments they need to make to get there. For some organizations, *3 fluency isn't desired. It's too big of a cultural shift. In those cases, a *2 team is a great fit, and can provide the predictability they want.

                            I describe the "how to" of making predictions in Agile in "Use Risk Management to Make Solid Commitments." http://www.jamesshore.com/Blog/Use-Risk-Management-to-Make-Solid-Commitments.html

                            Cheers,
                            Jim

                            *These numbers are approximate and depend on the team. See the "Use Risk Management" essay for an explanation of where they come from.



                            On Sep 28, 2014, at 11:11 AM, "Michael Kelly m.sean.kelly@... [AgilePDX]" <AgilePDX@yahoogroups.com> wrote:



                            Core Question:
                            --------------------
                            Despite the relative success of Agile methods for engineering, our counterparts on the business side continue to have a need to make decisions based upon (and communicate with customers, and business partners, and other internal departments about) what will likely happen in the future. Do/can Agile methods provide any help with that?

                            Discussion:
                            ---------------
                            I recently came across a job posting for a local PDX company that was looking for someone to manage the company's Agile adoption. Specifically, they wanted someone that would apply agile "best practices" so as to improve predictability.

                            My first response, of course, was "Good luck with that." It seems pretty clear to me that Agile takes as its first principle that software development is inherently unpredictable, and that the "best practices" are all about dealing with that fact. You see this in the literature of all of Agile's leaders:
                            • Kent Beck: Embrace change.
                            • Jeff Sutherland: Writes about software as the product of a Complex Adaptive System (CAS), a key feature of which is unpredictability.
                            • Mike Cohen: Describes "Agile planning" as something that is spread throughout the project, is more focused on planning than The Plan, encourages change, and results in plans that are easily changed.
                            Part of the answer here seems to be to push the notion of agility further up the organizational hierarchy. To the extent that commitments need to be made, the heads of departments, VPs, CTOs, CEOs, etc. need to make those commitments as late as possible and make them as general as possible: "The software will be delivered in the 3rd quarter, and will contain a solution for tracking widgets.", not "The software will be delivered September 4th, and will provide three widget tracking reports, late delivery notifications, and a customize-able dashboard."

                            One thing that seems to help with pushing the notion of agility up the organizational hierarchy is greater visibility. When stakeholders get regular and concrete evidence of the progress made by software development teams (e.g. regular demos), then the realities of the inevitable uncertainty of the endeavor becomes clear to all.

                            But even with these things in place, the pressure for predictability persists. 
                            1. Customers making buying decisions want information about what's in the pipeline, and often insist on having the details.
                            2. Product Owners typically get one or two chances a year to talk about the future of their products at trade shows, and they have pressures to give details about the coming year (see item #1 above).
                            3. Sales people are under similar pressures when trying to close a deal.
                            4. Executives trying to make decisions about the corporate direction need information about the cost of various options.
                            5. Business partners and other internal departments need to coordinate their efforts with ours.
                            As a developer, I could look at these pressures and say (and, no doubt, have said) "Good luck with that." But I can't help but feel that this response makes me something less than a full collaborative partner in the objectives of the enterprise, and that I should be able to provide an Agile response that is more...helpful.

                            What thinks you all?

                            -
                            Michael Kelly
                            DAT Solutions




                            --
                            James Shore - The Art of Agile
                            recipient of Gordon Pask Award for Contributions to Agile Practice
                            co-author of The Art of Agile Development

                            voice: 503-267-5490
                            email: jshore@...
                            blog: http://jamesshore.com




                          • Michael Kelly
                            OK Patrick, I took a look at the web site, read some reviews of the book, and bought a copy. It looks like a fruitful direction. Thanks. I d still like to know
                            Message 13 of 15 , Sep 29, 2014

                              OK Patrick, I took a look at the web site, read some reviews of the book, and bought a copy. It looks like a fruitful direction. Thanks.

                              I'd still like to know what folks are saying to the executives at Agile conferences, and whose saying it.

                              On Sep 29, 2014 10:57 AM, "Michael Kelly" <m.sean.kelly@...> wrote:
                              Thanks Patrick, I'll look into it.

                              -
                              Michael

                              On Mon, Sep 29, 2014 at 10:52 AM, Patrick Logan patrickdlogan@... [AgilePDX] <AgilePDX@yahoogroups.com> wrote:
                               

                              I'd just reiterate that, 1. I agree with Charlie, and 2. the reference I provided addresses those kind of issues (and others) really well. It will help you think and communicate  clearly about these kinds of complicated situations.

                              On Sep 29, 2014 10:33 AM, "Charlie Poole charliepoole@... [AgilePDX]" <AgilePDX@yahoogroups.com> wrote:
                               

                              I'd like to temporarily bypass the question of how predictable agile is (although I pretty much agree with Jim on that) to raise the question of what Predictability means to people here.

                              I ask this, because I have noted in the wild that many folks confuse predictions with promises. Sometimes, these folks are managers, which leads to an insistence that estimates must be met, not 50% of the time as one would logically expect with an estimate, but close to 100% of the time. Sometimes the developers are infected with the same belief, leading them to padding of estimates.

                              I wonder if it may be possible to achieve good predictability of software in the context of the biases that such confusion instills. I doubt it.

                              So... what does predictability mean to us here?

                              Charlie

                              On Mon, Sep 29, 2014 at 9:58 AM, Patrick Logan patrickdlogan@... [AgilePDX] <AgilePDX@yahoogroups.com> wrote:
                               

                              A good resource for anyone who has to perform or rely on predictions of any consequence would do all to work through the book and this site...
                              http://www.howtomeasureanything.com

                              On Sep 29, 2014 9:53 AM, "Michael Kelly m.sean.kelly@... [AgilePDX]" <AgilePDX@yahoogroups.com> wrote:
                               

                              Thanks James, much appreciated. If I understand what you're saying, a rigorous process (with automated tests, velocity tracking, continuous integration, etc.) helps with predictability. That makes sense to me, especially when you're predicting the end-game of a project that has already started and has a track record. And that's helpful. But new projects and existing projects experiencing significant disruptions (changes in team members, technology, or features) don't really have any velocity as a starting point, much less a stable one. And frequently, they don't have a well-groomed backlog with story points.

                              Is our answer in this case "good luck with that"? Is the answer essentially that Agile estimation doesn't kick in until you've already adopted the practices and had them in place for a while? Or is there some "agile" method for iterative provisional estimation of schedule and cost that contains something about the degree of uncertainty--an iterative process that drives down the uncertainty to the point where a decision can be made, but no further. If there is, I'm not aware of it. And I'm not even clear such a thing is feasible, I'm just asking the question.


                              -
                              Michael

                              On Sun, Sep 28, 2014 at 11:55 AM, James Shore jshore@... [AgilePDX] <AgilePDX@yahoogroups.com> wrote:
                               

                              It's entirely possible to make predictions with Agile. They're just as good as predictions made with other methods, and with XP practices, they can be much better. Agile leaders talk about embracing change because that has more potential value than making predictions.


                              Software *is* inherently unpredictable. So is the weather. Forecasts (predictions) are possible in both situations, given sufficient rigor. How your team approaches predictions depends on what level of fluency they have (http://www.agilefluency.com).

                              One-star teams adapt their plans and work in terms of business results. However, they don't have rigorous engineering practices, which means their predictions have wide error bars, on par with typical non-Agile teams (for 90% reliability, need 4x estimate*). They believe predictions are impossible in Agile.

                              Two-star teams use rigorous engineering practices such as test-driven development, continuous integration, and the other good stuff from XP. They can make predictions with reasonable precision (for 90% reliability, need 1.8x estimate*). They can and do provide reliable predictions.

                              Three- and four-star teams conduct experiments and change direction depending on market opportunities. They can make predictions as well as two-star teams, but estimating and predicting has a cost, and that cost often has no real value in the market. They often choose not to incur the waste of making predictions.

                              So if a company were to talk to me about improving predictability, I would talk to them about what sort of fluency they wanted to achieve, why, and the investments they need to make to get there. For some organizations, *3 fluency isn't desired. It's too big of a cultural shift. In those cases, a *2 team is a great fit, and can provide the predictability they want.

                              I describe the "how to" of making predictions in Agile in "Use Risk Management to Make Solid Commitments." http://www.jamesshore.com/Blog/Use-Risk-Management-to-Make-Solid-Commitments.html

                              Cheers,
                              Jim

                              *These numbers are approximate and depend on the team. See the "Use Risk Management" essay for an explanation of where they come from.



                              On Sep 28, 2014, at 11:11 AM, "Michael Kelly m.sean.kelly@... [AgilePDX]" <AgilePDX@yahoogroups.com> wrote:



                              Core Question:
                              --------------------
                              Despite the relative success of Agile methods for engineering, our counterparts on the business side continue to have a need to make decisions based upon (and communicate with customers, and business partners, and other internal departments about) what will likely happen in the future. Do/can Agile methods provide any help with that?

                              Discussion:
                              ---------------
                              I recently came across a job posting for a local PDX company that was looking for someone to manage the company's Agile adoption. Specifically, they wanted someone that would apply agile "best practices" so as to improve predictability.

                              My first response, of course, was "Good luck with that." It seems pretty clear to me that Agile takes as its first principle that software development is inherently unpredictable, and that the "best practices" are all about dealing with that fact. You see this in the literature of all of Agile's leaders:
                              • Kent Beck: Embrace change.
                              • Jeff Sutherland: Writes about software as the product of a Complex Adaptive System (CAS), a key feature of which is unpredictability.
                              • Mike Cohen: Describes "Agile planning" as something that is spread throughout the project, is more focused on planning than The Plan, encourages change, and results in plans that are easily changed.
                              Part of the answer here seems to be to push the notion of agility further up the organizational hierarchy. To the extent that commitments need to be made, the heads of departments, VPs, CTOs, CEOs, etc. need to make those commitments as late as possible and make them as general as possible: "The software will be delivered in the 3rd quarter, and will contain a solution for tracking widgets.", not "The software will be delivered September 4th, and will provide three widget tracking reports, late delivery notifications, and a customize-able dashboard."

                              One thing that seems to help with pushing the notion of agility up the organizational hierarchy is greater visibility. When stakeholders get regular and concrete evidence of the progress made by software development teams (e.g. regular demos), then the realities of the inevitable uncertainty of the endeavor becomes clear to all.

                              But even with these things in place, the pressure for predictability persists. 
                              1. Customers making buying decisions want information about what's in the pipeline, and often insist on having the details.
                              2. Product Owners typically get one or two chances a year to talk about the future of their products at trade shows, and they have pressures to give details about the coming year (see item #1 above).
                              3. Sales people are under similar pressures when trying to close a deal.
                              4. Executives trying to make decisions about the corporate direction need information about the cost of various options.
                              5. Business partners and other internal departments need to coordinate their efforts with ours.
                              As a developer, I could look at these pressures and say (and, no doubt, have said) "Good luck with that." But I can't help but feel that this response makes me something less than a full collaborative partner in the objectives of the enterprise, and that I should be able to provide an Agile response that is more...helpful.

                              What thinks you all?

                              -
                              Michael Kelly
                              DAT Solutions




                              --
                              James Shore - The Art of Agile
                              recipient of Gordon Pask Award for Contributions to Agile Practice
                              co-author of The Art of Agile Development

                              voice: 503-267-5490
                              email: jshore@...
                              blog: http://jamesshore.com




                            • James Shore
                              Most of my consulting engagements happen at the executive level, and what I use is the Agile Fluency model. It works well because it focuses the conversation
                              Message 14 of 15 , Sep 29, 2014
                                Most of my consulting engagements happen at the executive level, and what I use is the Agile Fluency model. It works well because it focuses the conversation on investments and results.

                                In terms of talking with executives about predictions, I don't find it to be a big deal. I ask "why do you want better estimates [sic]?" Then I listen. Often, the desire for better estimates is actually about controlling waste or limiting risk, not predictions per se. So I restate the desire in those terms and that shifts the conversation away from predictions. But sometimes there's a real desire for predictability. Either way, I say, "We can do that." And then we go do it.

                                When there's a strong desire for predictability, I don't push back. You have to build trust before you can make real changes to organizational culture, and reliably making and meeting commitments is a fantastic way to build trust. Actions speak louder than words.

                                Cheers,
                                Jim


                                On Sep 29, 2014, at 1:31 PM, Michael Kelly m.sean.kelly@... [AgilePDX] <AgilePDX@yahoogroups.com> wrote:



                                OK Patrick, I took a look at the web site, read some reviews of the book, and bought a copy. It looks like a fruitful direction. Thanks.

                                I'd still like to know what folks are saying to the executives at Agile conferences, and whose saying it.

                                On Sep 29, 2014 10:57 AM, "Michael Kelly" <m.sean.kelly@...> wrote:
                                Thanks Patrick, I'll look into it.

                                -
                                Michael

                                On Mon, Sep 29, 2014 at 10:52 AM, Patrick Logan patrickdlogan@... [AgilePDX] <AgilePDX@yahoogroups.com> wrote:
                                 

                                I'd just reiterate that, 1. I agree with Charlie, and 2. the reference I provided addresses those kind of issues (and others) really well. It will help you think and communicate  clearly about these kinds of complicated situations.

                                On Sep 29, 2014 10:33 AM, "Charlie Poole charliepoole@... [AgilePDX]" <AgilePDX@yahoogroups.com> wrote:
                                 

                                I'd like to temporarily bypass the question of how predictable agile is (although I pretty much agree with Jim on that) to raise the question of what Predictability means to people here.

                                I ask this, because I have noted in the wild that many folks confuse predictions with promises. Sometimes, these folks are managers, which leads to an insistence that estimates must be met, not 50% of the time as one would logically expect with an estimate, but close to 100% of the time. Sometimes the developers are infected with the same belief, leading them to padding of estimates.

                                I wonder if it may be possible to achieve good predictability of software in the context of the biases that such confusion instills. I doubt it.

                                So... what does predictability mean to us here?

                                Charlie

                                On Mon, Sep 29, 2014 at 9:58 AM, Patrick Logan patrickdlogan@... [AgilePDX] <AgilePDX@yahoogroups.com> wrote:
                                 

                                A good resource for anyone who has to perform or rely on predictions of any consequence would do all to work through the book and this site... 
                                http://www.howtomeasureanything.com

                                On Sep 29, 2014 9:53 AM, "Michael Kelly m.sean.kelly@... [AgilePDX]" <AgilePDX@yahoogroups.com> wrote:
                                 

                                Thanks James, much appreciated. If I understand what you're saying, a rigorous process (with automated tests, velocity tracking, continuous integration, etc.) helps with predictability. That makes sense to me, especially when you're predicting the end-game of a project that has already started and has a track record. And that's helpful. But new projects and existing projects experiencing significant disruptions (changes in team members, technology, or features) don't really have any velocity as a starting point, much less a stable one. And frequently, they don't have a well-groomed backlog with story points.

                                Is our answer in this case "good luck with that"? Is the answer essentially that Agile estimation doesn't kick in until you've already adopted the practices and had them in place for a while? Or is there some "agile" method for iterative provisional estimation of schedule and cost that contains something about the degree of uncertainty--an iterative process that drives down the uncertainty to the point where a decision can be made, but no further. If there is, I'm not aware of it. And I'm not even clear such a thing is feasible, I'm just asking the question.


                                -
                                Michael

                                On Sun, Sep 28, 2014 at 11:55 AM, James Shore jshore@... [AgilePDX]<AgilePDX@yahoogroups.com> wrote:
                                 

                                It's entirely possible to make predictions with Agile. They're just as good as predictions made with other methods, and with XP practices, they can be much better. Agile leaders talk about embracing change because that has more potential value than making predictions.


                                Software *is* inherently unpredictable. So is the weather. Forecasts (predictions) are possible in both situations, given sufficient rigor. How your team approaches predictions depends on what level of fluency they have (http://www.agilefluency.com).

                                One-star teams adapt their plans and work in terms of business results. However, they don't have rigorous engineering practices, which means their predictions have wide error bars, on par with typical non-Agile teams (for 90% reliability, need 4x estimate*). They believe predictions are impossible in Agile.

                                Two-star teams use rigorous engineering practices such as test-driven development, continuous integration, and the other good stuff from XP. They can make predictions with reasonable precision (for 90% reliability, need 1.8x estimate*). They can and do provide reliable predictions.

                                Three- and four-star teams conduct experiments and change direction depending on market opportunities. They can make predictions as well as two-star teams, but estimating and predicting has a cost, and that cost often has no real value in the market.They often choose not to incur the waste of making predictions.

                                So if a company were to talk to me about improving predictability, I would talk to them about what sort of fluency they wanted to achieve, why, and the investments they need to make to get there. For some organizations, *3 fluency isn't desired. It's too big of a cultural shift. In those cases, a *2 team is a great fit, and can provide the predictability they want.

                                I describe the "how to" of making predictions in Agile in "Use Risk Management to Make Solid Commitments." http://www.jamesshore.com/Blog/Use-Risk-Management-to-Make-Solid-Commitments.html

                                Cheers,
                                Jim

                                *These numbers are approximate and depend on the team. See the "Use Risk Management" essay for an explanation of where they come from.



                                On Sep 28, 2014, at 11:11 AM, "Michael Kelly m.sean.kelly@... [AgilePDX]" <AgilePDX@yahoogroups.com> wrote:



                                Core Question:
                                --------------------
                                Despite the relative success of Agile methods for engineering, our counterparts on the business side continue to have a need to make decisions based upon (and communicate with customers, and business partners, and other internal departments about) what will likely happen in the future. Do/can Agile methods provide any help with that?

                                Discussion:
                                ---------------
                                I recently came across a job posting for a local PDX company that was looking for someone to manage the company's Agile adoption. Specifically, they wanted someone that would apply agile "best practices" so as to improve predictability.

                                My first response, of course, was "Good luck with that." It seems pretty clear to me that Agile takes as its first principle that software development is inherently unpredictable, and that the "best practices" are all about dealing with that fact. You see this in the literature of all of Agile's leaders:
                                • Kent Beck: Embrace change.
                                • Jeff Sutherland: Writes about software as the product of a Complex Adaptive System (CAS), a key feature of which is unpredictability.
                                • Mike Cohen: Describes "Agile planning" as something that is spread throughout the project, is more focused on planning than The Plan, encourages change, and results in plans that are easily changed.
                                Part of the answer here seems to be to push the notion of agility further up the organizational hierarchy. To the extent that commitments need to be made, the heads of departments, VPs, CTOs, CEOs, etc. need to make those commitments as late as possible and make them as general as possible: "The software will be delivered in the 3rd quarter, and will contain a solution for tracking widgets.", not "The software will be delivered September 4th, and will provide three widget tracking reports, late delivery notifications, and a customize-able dashboard."

                                One thing that seems to help with pushing the notion of agility up the organizational hierarchy is greater visibility. When stakeholders get regular and concrete evidence of the progress made by software development teams (e.g. regular demos), then the realities of the inevitable uncertainty of the endeavor becomes clear to all.

                                But even with these things in place, the pressure for predictability persists. 
                                1. Customers making buying decisions want information about what's in the pipeline, and often insist on having the details.
                                2. Product Owners typically get one or two chances a year to talk about the future of their products at trade shows, and they have pressures to give details about the coming year (see item #1 above).
                                3. Sales people are under similar pressures when trying to close a deal.
                                4. Executives trying to make decisions about the corporate direction need information about the cost of various options.
                                5. Business partners and other internal departments need to coordinate their efforts with ours.
                                As a developer, I could look at these pressures and say (and, no doubt, have said) "Good luck with that." But I can't help but feel that this response makes me something less than a full collaborative partner in the objectives of the enterprise, and that I should be able to provide an Agile response that is more...helpful.

                                What thinks you all?

                                -
                                Michael Kelly
                                DAT Solutions




                                --
                                James Shore - The Art of Agile
                                recipient of Gordon Pask Award for Contributions to Agile Practice
                                co-author of The Art of Agile Development

                                voice: 503-267-5490
                                email: jshore@...
                                blog: http://jamesshore.com













                                --
                                James Shore - The Art of Agile
                                recipient of Gordon Pask Award for Contributions to Agile Practice
                                co-author of The Art of Agile Development

                                voice: 503-267-5490
                                email: jshore@...
                                blog: http://jamesshore.com

                              • Patrick Logan
                                I would concur with that... most of the time people want to know direction, not detail; what are the risks, and how they will be mitigated; and how will
                                Message 15 of 15 , Sep 29, 2014
                                  I would concur with that... most of the time people want to know direction, not detail; what are the risks, and how they will be mitigated; and how will decisions be made, and made visible. And budgets.

                                  On Mon, Sep 29, 2014 at 1:46 PM, James Shore jshore@... [AgilePDX] <AgilePDX@yahoogroups.com> wrote:
                                   

                                  Most of my consulting engagements happen at the executive level, and what I use is the Agile Fluency model. It works well because it focuses the conversation on investments and results.


                                  In terms of talking with executives about predictions, I don't find it to be a big deal. I ask "why do you want better estimates [sic]?" Then I listen. Often, the desire for better estimates is actually about controlling waste or limiting risk, not predictions per se. So I restate the desire in those terms and that shifts the conversation away from predictions. But sometimes there's a real desire for predictability. Either way, I say, "We can do that." And then we go do it.

                                  When there's a strong desire for predictability, I don't push back. You have to build trust before you can make real changes to organizational culture, and reliably making and meeting commitments is a fantastic way to build trust. Actions speak louder than words.

                                  Cheers,
                                  Jim


                                  On Sep 29, 2014, at 1:31 PM, Michael Kelly m.sean.kelly@... [AgilePDX] <AgilePDX@yahoogroups.com> wrote:



                                  OK Patrick, I took a look at the web site, read some reviews of the book, and bought a copy. It looks like a fruitful direction. Thanks.

                                  I'd still like to know what folks are saying to the executives at Agile conferences, and whose saying it.

                                  On Sep 29, 2014 10:57 AM, "Michael Kelly" <m.sean.kelly@...> wrote:
                                  Thanks Patrick, I'll look into it.

                                  -
                                  Michael

                                  On Mon, Sep 29, 2014 at 10:52 AM, Patrick Logan patrickdlogan@... [AgilePDX] <AgilePDX@yahoogroups.com> wrote:
                                   

                                  I'd just reiterate that, 1. I agree with Charlie, and 2. the reference I provided addresses those kind of issues (and others) really well. It will help you think and communicate  clearly about these kinds of complicated situations.

                                  On Sep 29, 2014 10:33 AM, "Charlie Poole charliepoole@... [AgilePDX]" <AgilePDX@yahoogroups.com> wrote:
                                   

                                  I'd like to temporarily bypass the question of how predictable agile is (although I pretty much agree with Jim on that) to raise the question of what Predictability means to people here.

                                  I ask this, because I have noted in the wild that many folks confuse predictions with promises. Sometimes, these folks are managers, which leads to an insistence that estimates must be met, not 50% of the time as one would logically expect with an estimate, but close to 100% of the time. Sometimes the developers are infected with the same belief, leading them to padding of estimates.

                                  I wonder if it may be possible to achieve good predictability of software in the context of the biases that such confusion instills. I doubt it.

                                  So... what does predictability mean to us here?

                                  Charlie

                                  On Mon, Sep 29, 2014 at 9:58 AM, Patrick Logan patrickdlogan@... [AgilePDX] <AgilePDX@yahoogroups.com> wrote:
                                   

                                  A good resource for anyone who has to perform or rely on predictions of any consequence would do all to work through the book and this site... 
                                  http://www.howtomeasureanything.com

                                  On Sep 29, 2014 9:53 AM, "Michael Kelly m.sean.kelly@... [AgilePDX]" <AgilePDX@yahoogroups.com> wrote:
                                   

                                  Thanks James, much appreciated. If I understand what you're saying, a rigorous process (with automated tests, velocity tracking, continuous integration, etc.) helps with predictability. That makes sense to me, especially when you're predicting the end-game of a project that has already started and has a track record. And that's helpful. But new projects and existing projects experiencing significant disruptions (changes in team members, technology, or features) don't really have any velocity as a starting point, much less a stable one. And frequently, they don't have a well-groomed backlog with story points.

                                  Is our answer in this case "good luck with that"? Is the answer essentially that Agile estimation doesn't kick in until you've already adopted the practices and had them in place for a while? Or is there some "agile" method for iterative provisional estimation of schedule and cost that contains something about the degree of uncertainty--an iterative process that drives down the uncertainty to the point where a decision can be made, but no further. If there is, I'm not aware of it. And I'm not even clear such a thing is feasible, I'm just asking the question.


                                  -
                                  Michael

                                  On Sun, Sep 28, 2014 at 11:55 AM, James Shore jshore@... [AgilePDX]<AgilePDX@yahoogroups.com> wrote:
                                   

                                  It's entirely possible to make predictions with Agile. They're just as good as predictions made with other methods, and with XP practices, they can be much better. Agile leaders talk about embracing change because that has more potential value than making predictions.


                                  Software *is* inherently unpredictable. So is the weather. Forecasts (predictions) are possible in both situations, given sufficient rigor. How your team approaches predictions depends on what level of fluency they have (http://www.agilefluency.com).

                                  One-star teams adapt their plans and work in terms of business results. However, they don't have rigorous engineering practices, which means their predictions have wide error bars, on par with typical non-Agile teams (for 90% reliability, need 4x estimate*). They believe predictions are impossible in Agile.

                                  Two-star teams use rigorous engineering practices such as test-driven development, continuous integration, and the other good stuff from XP. They can make predictions with reasonable precision (for 90% reliability, need 1.8x estimate*). They can and do provide reliable predictions.

                                  Three- and four-star teams conduct experiments and change direction depending on market opportunities. They can make predictions as well as two-star teams, but estimating and predicting has a cost, and that cost often has no real value in the market.They often choose not to incur the waste of making predictions.

                                  So if a company were to talk to me about improving predictability, I would talk to them about what sort of fluency they wanted to achieve, why, and the investments they need to make to get there. For some organizations, *3 fluency isn't desired. It's too big of a cultural shift. In those cases, a *2 team is a great fit, and can provide the predictability they want.

                                  I describe the "how to" of making predictions in Agile in "Use Risk Management to Make Solid Commitments." http://www.jamesshore.com/Blog/Use-Risk-Management-to-Make-Solid-Commitments.html

                                  Cheers,
                                  Jim

                                  *These numbers are approximate and depend on the team. See the "Use Risk Management" essay for an explanation of where they come from.



                                  On Sep 28, 2014, at 11:11 AM, "Michael Kelly m.sean.kelly@... [AgilePDX]" <AgilePDX@yahoogroups.com> wrote:



                                  Core Question:
                                  --------------------
                                  Despite the relative success of Agile methods for engineering, our counterparts on the business side continue to have a need to make decisions based upon (and communicate with customers, and business partners, and other internal departments about) what will likely happen in the future. Do/can Agile methods provide any help with that?

                                  Discussion:
                                  ---------------
                                  I recently came across a job posting for a local PDX company that was looking for someone to manage the company's Agile adoption. Specifically, they wanted someone that would apply agile "best practices" so as to improve predictability.

                                  My first response, of course, was "Good luck with that." It seems pretty clear to me that Agile takes as its first principle that software development is inherently unpredictable, and that the "best practices" are all about dealing with that fact. You see this in the literature of all of Agile's leaders:
                                  • Kent Beck: Embrace change.
                                  • Jeff Sutherland: Writes about software as the product of a Complex Adaptive System (CAS), a key feature of which is unpredictability.
                                  • Mike Cohen: Describes "Agile planning" as something that is spread throughout the project, is more focused on planning than The Plan, encourages change, and results in plans that are easily changed.
                                  Part of the answer here seems to be to push the notion of agility further up the organizational hierarchy. To the extent that commitments need to be made, the heads of departments, VPs, CTOs, CEOs, etc. need to make those commitments as late as possible and make them as general as possible: "The software will be delivered in the 3rd quarter, and will contain a solution for tracking widgets.", not "The software will be delivered September 4th, and will provide three widget tracking reports, late delivery notifications, and a customize-able dashboard."

                                  One thing that seems to help with pushing the notion of agility up the organizational hierarchy is greater visibility. When stakeholders get regular and concrete evidence of the progress made by software development teams (e.g. regular demos), then the realities of the inevitable uncertainty of the endeavor becomes clear to all.

                                  But even with these things in place, the pressure for predictability persists. 
                                  1. Customers making buying decisions want information about what's in the pipeline, and often insist on having the details.
                                  2. Product Owners typically get one or two chances a year to talk about the future of their products at trade shows, and they have pressures to give details about the coming year (see item #1 above).
                                  3. Sales people are under similar pressures when trying to close a deal.
                                  4. Executives trying to make decisions about the corporate direction need information about the cost of various options.
                                  5. Business partners and other internal departments need to coordinate their efforts with ours.
                                  As a developer, I could look at these pressures and say (and, no doubt, have said) "Good luck with that." But I can't help but feel that this response makes me something less than a full collaborative partner in the objectives of the enterprise, and that I should be able to provide an Agile response that is more...helpful.

                                  What thinks you all?

                                  -
                                  Michael Kelly
                                  DAT Solutions




                                  --
                                  James Shore - The Art of Agile
                                  recipient of Gordon Pask Award for Contributions to Agile Practice
                                  co-author of The Art of Agile Development

                                  voice: 503-267-5490
                                  email: jshore@...
                                  blog: http://jamesshore.com













                                  --
                                  James Shore - The Art of Agile
                                  recipient of Gordon Pask Award for Contributions to Agile Practice
                                  co-author of The Art of Agile Development

                                  voice: 503-267-5490
                                  email: jshore@...
                                  blog: http://jamesshore.com


                                Your message has been successfully submitted and would be delivered to recipients shortly.