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

Re: [XP] Re: New Article on XProgramming.com

Expand Messages
  • Ron Jeffries
    ... Unless I miss my guess, most product companies measure number of products shipped, do they not? What s hard about that? And anyway, I m not proposing
    Message 1 of 2 , Jul 30, 2005
      On Saturday, July 30, 2005, at 5:13:21 PM, Kevin Rutherford wrote:

      > However (you knew that was coming), I have a couple of questions:

      > First, introducing throughput accounting (ie. measuring success by volume of
      > product) is notoriously difficult, as anyone in the Theory-of-Constraints or
      > Lean communities will attest.

      Unless I miss my guess, most product companies measure number of
      products shipped, do they not? What's hard about that?

      And anyway, I'm not proposing changing accounting, I'm proposing the
      executive telling his reports what he cares about, and what will
      make him happy: Features. It won't take a reorganization of the
      whole company to do that: software projects are already /supposed/
      to ship stuff. They just don't do so very often.

      > Have you seen this measure accepted
      > universally, or resisted by bean-counters?

      Neither, none of the above. But it's not hard, and not unknown: XP
      teams and Scrum teams, for example, measure velocity all the time.

      And again, we're not trying to change the bean-counters. They can
      count whatever they want to. Meanwhile, what counts in development,
      and in the eyes of its managers, should be getting stuff done.

      Offhand, I'd expect that to improve most any existing financial
      measure. (Although there may be some interesting issues relating to

      > Second, in a shop that's already running with legacy code and product, I
      > would expect a productivity /dip/ while the 'running' and 'tested' parets of
      > the RTF equation take hold. Do you find that? If not, how did you avoid it?

      Yes, you have to slow down to turn. On the other hand, since most
      non-Agile projects typically have zero features delivered in any
      given month, one feature would be an improvement. So even though
      overall progress /might/ slow, successful feature delivery could
      quite possibly start early on.

      And when the teams figure out that they have to be Agile, they'll
      likely go faster very quickly. Scrum and XP teams are, anecdotally
      at least, about twice as productive as the same team was before they
      started doing the Agile thing.

      Ron Jeffries
      How do I know what I think until I hear what I say? -- E M Forster
    Your message has been successfully submitted and would be delivered to recipients shortly.