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

3064Agile and predictability.

Expand Messages
  • Michael Kelly
    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?

      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
    • Show all 15 messages in this topic