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

Re: Lean Software Dev and Metrics

Expand Messages
  • Uberto Barbini
    ... I read the book, and I agree. Maybe it s not the best metric but it s the only that really count. More precisely I d rather say business value, because
    Message 1 of 17 , Sep 1, 2005
    • 0 Attachment
      --- In extremeprogramming@yahoogroups.com, "PierG"
      <piergiorgio_grossi@h...> wrote:
      > Hi,
      > I've just listened to the very intersting podcast 'Mary Poppendieck -
      > Lean Software Dev' (Agile 2005).
      >
      > Mary says that the best (only?) metric for the team success is the sw
      > product revenues.

      I read the book, and I agree. Maybe it's not the best metric but it's
      the only that really count.
      More precisely I'd rather say business value, because most of software
      it's not directly sold out on shelves.


      > In my opinion this can be a very good metric for the product team (dev
      > team + marketing + sales ...) but ... what if the dev team has
      > developed 'running tested features' respecting time, costs and
      > quality ... and the problem is the perception of the market of
      > the 'internal' customer (product marketing, sales .. or so)??
      > Does poor revenues mean that the dev team has bad performed?
      > Whell ok, it didn't produce 'value' ($) but ... it produced the value
      > he was asked for.

      Ok, but ultimetely we're not interested to increase that, we're
      interested to increase business value. Maybe Marketing team has to
      collaborate more strictly to the developers or whatever but with
      "business value" goal is simpler to collaborate than with "I did what
      you asked for" attitude.
      My 0.2 cents.

      Bye Uberto
    • Ron Jeffries
      ... I bet the group would love to have a link for this ... is it on the web somewhere? ... This has been one of Mary s big points in the past couple of years,
      Message 2 of 17 , Sep 1, 2005
      • 0 Attachment
        On Thursday, September 1, 2005, at 2:58:15 AM, PierG wrote:

        > I've just listened to the very intersting podcast 'Mary Poppendieck -
        > Lean Software Dev' (Agile 2005).

        I bet the group would love to have a link for this ... is it on the
        web somewhere?

        > Mary says that the best (only?) metric for the team success is the sw
        > product revenues.

        > In my opinion this can be a very good metric for the product team
        > (dev team + marketing + sales ...) but ... what if the dev team
        > has developed 'running tested features' respecting time, costs and
        > quality ... and the problem is the perception of the market of the
        > 'internal' customer (product marketing, sales .. or so)?? Does
        > poor revenues mean that the dev team has bad performed? Whell ok,
        > it didn't produce 'value' ($) but ... it produced the value he was
        > asked for.

        > I'd like to have your feedback about this topic.

        This has been one of Mary's big points in the past couple of years,
        and it's a strong one. As Jim Shore has said, the bottom line is the
        bottom line.

        On the other hand, there's a long way from President and VP of
        Marketing down to Lowly Programmer, and the LP's influence on the
        VP's decisions is limited.

        I don't think there's anything wrong with setting out "just" to be a
        good programmer. There's more than a lifetime's learning to be had
        there. And I don't think there's anything wrong with setting out to
        be a really good development team. Again, there's more learning than
        we have time for.

        But imagine two teams. Both are full of people who are Programmers
        for Life, both have top velocity and no defects. On their last five
        projects, Team A shipped them all, and they all succeeded. Team B
        shipped them all, and three of them "failed in the market".

        You get to choose which team to use for your next product. Would you
        go with A? I would.


        Yesterday Ken Boucher asked about C3. C3 paid 10,000 actual
        employees for about four years. It paid them accurately and well.
        The original plan was to pay all of Chrysler's then 250,000
        employees. C3 never got there, despite the development team's
        ability to deliver features at high quality in short time.

        There were lots of problems:

        The second customer vacillated about features. After the project
        ended, he said that he never really thought it was supposed to
        deploy. I guess he thought it was some kind of very expensive
        exercise.

        But the team didn't successfully push the product out, nor did
        they figure out a way to deploy it piecemeal. That might have
        changed things.

        The second customer didn't support the payroll operations guy's
        needs, making an enemy in high places.

        But the team didn't figure out a way to bring the operations guy
        into the picture: they washed their hands of it and told him his
        problem was with the customer. Doing otherwise might have
        changed things.

        The customer and team manager wouldn't put together a Release
        Plan, resulting in upper management's expectations deviating from
        reality.

        The team didn't figure out a way to make this happen, though
        they knew it was needed. Heck, they could have just done it.
        Doing so might have changed things.

        When a release plan was finally created, the team manager said,
        referring to Pat, the next level up manager, and this is a direct
        quote: "I can't tell Pat that."

        Someone on the team could have gone up the chain of command and
        told the truth. I think that perhaps I should have gone to the
        CIO. Her door would have been open to me, once. Doing that might
        have changed things.

        Literally every manager but one, on both the IT side and the
        finance side, changed out over the last two or three years of the
        project. There was no one left who had supported the project.

        Someone on the team could have gone to those new managers and
        hooked them up with the project, what it was doing, why it was
        important and so on. Doing that might have changed things.

        Every single time that something has gone wrong, on any project I've
        been on, where the project has been less than successful, I've been
        able to think of something that I, or someone near me, could have
        done, that might have changed things.

        With our eye on the bottom line, I think we're more likely to think
        of the things we could do, that might change things. I think the
        team that's full of people who do that is more likely to ship
        successful product than one that does it less.

        So, Mary's right.

        //And// I still think that being the best programmer we can be is
        an honorable path to take. Someday, that path may lead to becoming a
        leader, a manager, a coach, or a thorn in people's sides. It's all
        good. It's all choice.

        There is no dishonor in being a great garbage collector. None.

        Ron Jeffries
        www.XProgramming.com
        To be on the wire is life. The rest is waiting. --Karl Wallenda
      • Greg Akins
        ... There are a few other good podcasts, along with Mary s, at http://agiletoolkit.libsyn.com/
        Message 3 of 17 , Sep 1, 2005
        • 0 Attachment
          --- Ron Jeffries <ronjeffries@...> wrote:

          > On Thursday, September 1, 2005, at 2:58:15 AM, PierG
          > wrote:
          >
          > > I've just listened to the very intersting podcast
          > 'Mary Poppendieck -
          > > Lean Software Dev' (Agile 2005).
          >
          > I bet the group would love to have a link for this
          > ... is it on the
          > web somewhere?

          There are a few other good podcasts, along with
          Mary's, at http://agiletoolkit.libsyn.com/
        • PierG
          ... I see your point and I agree on the idea (correct me if i m wrong) that there is always something more that the dev team (in general, everyone) can do to
          Message 4 of 17 , Sep 1, 2005
          • 0 Attachment
            --- In extremeprogramming@yahoogroups.com, Ron Jeffries
            <ronjeffries@X...> wrote:
            >
            > So, Mary's right.
            >

            I see your point and I agree on the idea (correct me if i'm wrong)
            that there is always something more that the dev team (in general,
            everyone) can do to deliver a better results ... and this is
            something that can be real part of the'process' and not something
            theorical or left to the feeling of each component of the team.

            But ... is this a metric that can drive everyday's team choices?

            Well yes, I'd prefer team A in your example but ... it's a 'many
            years' time frame: the team as to change/adapt day by day to have
            bettere results. Don't you agree?? (for this topic ... there is
            another beautiful podcast in the same site (thank you Greg) from
            Arlo Belshee).

            PierG
          • Ron Jeffries
            ... A metric? I don t know what metric I d collect. But an everyday focus? Sure, why not? ... Day by day, hour by hour, month by month, year by year ... Ron
            Message 5 of 17 , Sep 1, 2005
            • 0 Attachment
              On Thursday, September 1, 2005, at 8:48:58 AM, PierG wrote:

              > I see your point and I agree on the idea (correct me if i'm wrong)
              > that there is always something more that the dev team (in general,
              > everyone) can do to deliver a better results ... and this is
              > something that can be real part of the'process' and not something
              > theorical or left to the feeling of each component of the team.

              > But ... is this a metric that can drive everyday's team choices?

              A metric? I don't know what metric I'd collect. But an everyday
              focus? Sure, why not?

              > Well yes, I'd prefer team A in your example but ... it's a 'many
              > years' time frame: the team as to change/adapt day by day to have
              > bettere results. Don't you agree?? (for this topic ... there is
              > another beautiful podcast in the same site (thank you Greg) from
              > Arlo Belshee).

              Day by day, hour by hour, month by month, year by year ...

              Ron Jeffries
              www.XProgramming.com
              Sometimes you just have to stop holding on with both hands, both
              feet, and your tail, to get someplace better. Of course you might
              plummet to the earth and die, but probably not:
              You were made for this.
            • Ken Boucher
              ... Get rid of all those job titles because they seem to be getting in the way?
              Message 6 of 17 , Sep 1, 2005
              • 0 Attachment
                --- In extremeprogramming@yahoogroups.com, Jim Shore <jshore@t...>
                wrote:
                > Wait a second. That's not very agile. Why would we want to
                > measure just the programmers? Aren't the testers part of the team?
                > Aren't the business experts? What about that guy who developed
                > a 500-line program that resulted in millions of dollars of sales
                > just because it copied order status from a mainframe to a webpage?
                > What about the team that hired an army of temps to do data
                > entry rather than writing a program, and saved the company
                > hundreds of thousands and three months of programming effort?

                ...

                > But wait! We don't want to punish the programmers if they have a
                > lousy business expert on the team! The business expert has a
                > much bigger impact on this metric than the programmers do!
                >
                > ...oh, really? Huh. THAT'S interesting. What does it tell us
                > about the important things for a programming team to do?

                Get rid of all those job titles because they seem to be getting in
                the way?
              • Chris Wheeler
                ... ... This is timely. Our company wanted metrics for our XP project, and so after much wrangling our management decided it was best to report LOC,
                Message 7 of 17 , Sep 1, 2005
                • 0 Attachment
                  >
                  > The bottom line is... the bottom line. That's the only objective
                  > measure of productivity I've found.
                  >
                  > productivity = $ / time


                  <Snip>

                  ...oh, really? Huh. THAT'S interesting. What does it tell us about
                  > the important things for a programming team to do?
                  >


                  This is timely. Our company wanted metrics for our XP project, and so after
                  much wrangling our management decided it was best to report LOC, number of
                  classes, cyclomatic complexity, and code coverage, to measure programmer
                  something-or-other.

                  Recently, after almost a year of reporting this stuff, the execs said "Those
                  things aren't useful to us. We want to know how much progress is being made
                  on our project over time". Essentially, they didn't care about
                  programmer-something-or-other, or even customer-someting-or-other. They just
                  wanted to know if their money was being spent wisely and how long before
                  they would see some money coming back to them.

                  How to do that is another story that I'm thinking about right now. THe
                  simplest way I can think of is showing a burndown of features. They also
                  want to see that the team is not shipping buggy products, so we could report
                  defects fixed vs. found. And they want to know how productive the team is,
                  so I'm thinking that because we report velocity in pair-hours, and seperate
                  hours coding vs. hours of accepted features, we could show that too ( I know
                  some teams don't like to report velocity, but time is money...)

                  Chris.

                  --
                  ---------------------
                  Chris Wheeler
                  Extreme Programmer & Coach
                  Visit my new site! http://www.agilelectric.com


                  [Non-text portions of this message have been removed]
                • Robert Watkins
                  ... This is the biggest problem with rewarding the team for value earned - if the team isn t earning much value, there may be a single or few points of
                  Message 8 of 17 , Sep 1, 2005
                  • 0 Attachment
                    Ron Jeffries <ronjeffries@...> wrote:
                    > This has been one of Mary's big points in the past couple of years,
                    > and it's a strong one. As Jim Shore has said, the bottom line is the
                    > bottom line.
                    >
                    > On the other hand, there's a long way from President and VP of
                    > Marketing down to Lowly Programmer, and the LP's influence on the
                    > VP's decisions is limited.

                    This is the biggest problem with rewarding the team for value earned -
                    if the team isn't earning much value, there may be a single or few
                    "points of failure" that explain why. For example, the developers may
                    have produced zero-defect software quickly and predicatably, but it
                    was the wrong software because the feature set implemented was wrong.

                    If you want to push all the risk and reward down to the team level,
                    you need to push all the responsibility _and_ authority as well. There
                    is very little more demoralising to a team then to find out your much
                    anticipated bonus for a good well done just went up in smoke because
                    the director of marketing couldn't find a product niche to save their
                    life. About the only things more demoralising I can think of is:
                    everyone on the team knew about the problem, but couldn't get
                    management to notice; and the director of marketing gets _his_ bonus.

                    It's a decidely non-trivial problem, and the solution depends on
                    context. If the team is a "work-for-hire" group that sells software
                    development services, then you don't have the risk of building an
                    unsuccesful product due to poor feature choices - that's your clients
                    problem, not yours. In an internal development shop, however, your
                    bonuses are dependent on the whole company's performance - this gives
                    you risk that you can't control, which tends to be offputting.

                    (At a previous job, we were told that our business units would be
                    expected to operate like they were their own company - the "battling
                    business units" model. I made the possibly CLM of noting that, if it
                    was _my_ business, I'd start looking for better customers)

                    Another thing to remember here that failure to deliver an anticipated
                    or promised reward _is_ punishment. Punishment that is perceived to be
                    unjust is usually a morale killer - you could easily lose the heart of
                    a mostly talented team this way.

                    --
                    "Software is too expensive to build cheaply"
                    Robert Watkins http://twasink.net/ robertdw@...
                  • J. B. Rainsberger
                    ... Indeed. ROI and cashflow. What else matters? -- J. B. (Joe) Rainsberger Diaspar Software Services http://www.diasparsoftware.com 2005 Gordon Pask Award
                    Message 9 of 17 , Sep 1, 2005
                    • 0 Attachment
                      Chris Wheeler wrote:

                      > This is timely. Our company wanted metrics for our XP project, and so after
                      > much wrangling our management decided it was best to report LOC, number of
                      > classes, cyclomatic complexity, and code coverage, to measure programmer
                      > something-or-other.
                      >
                      > Recently, after almost a year of reporting this stuff, the execs said "Those
                      > things aren't useful to us. We want to know how much progress is being made
                      > on our project over time". Essentially, they didn't care about
                      > programmer-something-or-other, or even customer-someting-or-other. They just
                      > wanted to know if their money was being spent wisely and how long before
                      > they would see some money coming back to them.

                      Indeed. ROI and cashflow. What else matters?
                      --
                      J. B. (Joe) Rainsberger
                      Diaspar Software Services
                      http://www.diasparsoftware.com
                      2005 Gordon Pask Award Winner for contribution to Agile practice
                      Author, JUnit Recipes: Practical Methods for Programmer Testing
                    • Anthony Moralez
                      ... Apparently he is better at marketing himself ;)
                      Message 10 of 17 , Sep 2, 2005
                      • 0 Attachment
                        On 9/1/05, Robert Watkins <yahoo@...> wrote:

                        > About the only things more demoralising I can think of is:
                        > everyone on the team knew about the problem, but couldn't get
                        > management to notice; and the director of marketing gets _his_ bonus.
                        >

                        Apparently he is better at marketing himself ;)
                      • Ron Jeffries
                        ... In all seriousness, I ve often found this to be the case. When development and Sales&Marketing are at odds, the communications skills of these individuals
                        Message 11 of 17 , Sep 2, 2005
                        • 0 Attachment
                          On Friday, September 2, 2005, at 9:43:45 AM, Anthony Moralez wrote:

                          > On 9/1/05, Robert Watkins <yahoo@...> wrote:

                          >> About the only things more demoralising I can think of is:
                          >> everyone on the team knew about the problem, but couldn't get
                          >> management to notice; and the director of marketing gets _his_ bonus.
                          >>

                          > Apparently he is better at marketing himself ;)

                          In all seriousness, I've often found this to be the case. When
                          development and Sales&Marketing are at odds, the communications
                          skills of these individuals often seem to me to keep them looking
                          better than they should, and development looking worse.

                          The core issue, though, is that we were at odds. One of the things I
                          like best about XP and Agile methods is that they give us ways not
                          to be so much at odds, but instead to be working from the same side
                          of the table.

                          Had I known then what I know now, I would have one or more much
                          nicer cars. And at least one company would have a chance of still
                          being in business.

                          Ron Jeffries
                          www.XProgramming.com
                          There is no art without intention. -- Duke Ellington
                        • Cory Foy
                          ... As a wise conference speaker put it one time, if a RTF isn t making money, it s inventory. If it s inventory, it s cost. That s bad. ;) Cory
                          Message 12 of 17 , Sep 26, 2005
                          • 0 Attachment
                            J. B. Rainsberger wrote:
                            > Indeed. ROI and cashflow. What else matters?

                            As a wise conference speaker put it one time, if a RTF isn't making
                            money, it's inventory. If it's inventory, it's cost. That's bad. ;)

                            Cory
                          • Kay A. Pentecost
                            For those who were not at XPDay Washington, that wise conference speaker was our own J.B. Rainsberger, who gave an awesome talk called Introduction to XP.
                            Message 13 of 17 , Sep 26, 2005
                            • 0 Attachment
                              For those who were not at XPDay Washington, that wise conference speaker was
                              our own J.B. Rainsberger, who gave an awesome talk called "Introduction to
                              XP." Although I was introduced to XP three years ago, I found his way of
                              presenting it to be extremely valuable, and I fully intend to rip it off
                              when I talk about XP to people.

                              Kay Pentecost


                              > -----Original Message-----
                              > From: extremeprogramming@yahoogroups.com
                              > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Cory Foy
                              > Sent: Monday, September 26, 2005 5:19 PM
                              > To: extremeprogramming@yahoogroups.com
                              > Subject: Re: [XP] Lean Software Dev and Metrics
                              >
                              > J. B. Rainsberger wrote:
                              > > Indeed. ROI and cashflow. What else matters?
                              >
                              > As a wise conference speaker put it one time, if a RTF isn't making
                              > money, it's inventory. If it's inventory, it's cost. That's bad. ;)
                              >
                              > Cory
                              >
                              >
                              >
                              >
                              > To Post a message, send it to: extremeprogramming@...
                              >
                              > To Unsubscribe, send a blank message to:
                              > extremeprogramming-unsubscribe@...
                              >
                              > ad-free courtesy of objectmentor.com
                              > Yahoo! Groups Links
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                            • Chris Clark
                              As a technology manager... For many years I have known about XP techniques. I have had the books in my library collecting dust for years :) But unfortunately I
                              Message 14 of 17 , Sep 26, 2005
                              • 0 Attachment
                                As a technology manager...

                                For many years I have known about XP techniques. I have had the books in my
                                library collecting dust for years :) But unfortunately I haven't been
                                practicing XP.

                                At XPDay, I found J.B. Rainsberger's method of presenting very revealing. I
                                answer to our investors and they completely understand the
                                manufacturing/factory model when they talk about companies. Specifically,
                                when they talk about our company they usually have a factory analogy in
                                mind. J.B. makes things easy to understand by using a manufacturing analogy
                                that I can easily rip off and describe to others as to why XP makes sense.

                                I appreciate Cory twisting my arm to get me to XPDay in Washington. It was
                                time well spent. I was very impressed by the emersion I felt while working
                                on a XP team developing a system. It brought all the ideas together into
                                something more real that I could touch and see in action.

                                I plan on pursuing XP for our development team at MobileHWY in the very near
                                future due to this experience.


                                -----Original Message-----
                                From: extremeprogramming@yahoogroups.com
                                [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Kay A. Pentecost
                                Sent: Monday, September 26, 2005 6:45 PM
                                To: extremeprogramming@yahoogroups.com
                                Subject: RE: [XP] Lean Software Dev and Metrics

                                For those who were not at XPDay Washington, that wise conference speaker was
                                our own J.B. Rainsberger, who gave an awesome talk called "Introduction to
                                XP." Although I was introduced to XP three years ago, I found his way of
                                presenting it to be extremely valuable, and I fully intend to rip it off
                                when I talk about XP to people.

                                Kay Pentecost


                                > -----Original Message-----
                                > From: extremeprogramming@yahoogroups.com
                                > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Cory Foy
                                > Sent: Monday, September 26, 2005 5:19 PM
                                > To: extremeprogramming@yahoogroups.com
                                > Subject: Re: [XP] Lean Software Dev and Metrics
                                >
                                > J. B. Rainsberger wrote:
                                > > Indeed. ROI and cashflow. What else matters?
                                >
                                > As a wise conference speaker put it one time, if a RTF isn't making
                                > money, it's inventory. If it's inventory, it's cost. That's bad. ;)
                                >
                                > Cory
                                >
                                >
                                >
                                >
                                > To Post a message, send it to: extremeprogramming@...
                                >
                                > To Unsubscribe, send a blank message to:
                                > extremeprogramming-unsubscribe@...
                                >
                                > ad-free courtesy of objectmentor.com
                                > Yahoo! Groups Links
                                >
                                >
                                >
                                >
                                >
                                >
                                >




                                To Post a message, send it to: extremeprogramming@...

                                To Unsubscribe, send a blank message to:
                                extremeprogramming-unsubscribe@...

                                ad-free courtesy of objectmentor.com
                                Yahoo! Groups Links
                              Your message has been successfully submitted and would be delivered to recipients shortly.