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

Lean Software Dev and Metrics

Expand Messages
  • PierG
    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
    Message 1 of 17 , Aug 31, 2005
    • 0 Attachment
      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.

      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.

      PierG
    • Jim Shore
      I agree with Mary 100%. I ve been looking for a good metric of software productivity for some time. All of the ones I ve found are subject to gaming.
      Message 2 of 17 , Sep 1, 2005
      • 0 Attachment
        I agree with Mary 100%. I've been looking for a good metric of software
        productivity for some time. All of the ones I've found are subject to
        gaming. There's the infamous lines of code, feature points, stories,
        velocity--none of these actually help us measure productivity. That's
        because

        productivity = features / time

        ...and we don't have an objective measurement of "features." What is a
        feature, anyway? How do you define it? A feature is something that the
        business values. It can be huge or it can be teensy. There's no
        objective comparison that I've found, and believe me, I've looked. I'm
        no expert in this area, so I could have missed something (I keep waiting
        for somebody to tell me I'm wrong about feature points), but so far, no
        luck.

        Okay, so let's switch gears. We can't measure features / time. Why do
        we want to? Well, so we can measure the productivity of the software
        developers. Presumably so we can jump around and (a) crow about how
        cool we are, or (b) fire those lazy bastards.

        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?

        The bottom line is... the bottom line. That's the only objective
        measure of productivity I've found.

        productivity = $ / time

        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?

        Cheers,
        Jim

        PierG 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.
        >
        > 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.
        >
        > PierG
        >
        >
        >
        >
        > 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
        >
        >
        >
        >
        >

        --
        James Shore--Titanium IT--Recipient of 2005 Gordon Pask award
        New Course! "Test-Driven ASP.NET" Sept 13-15 in Bellevue, WA.
        Details at http://nunitasp.sourceforge.net/tdd-course.html

        phone: 503-267-5490
        email: jshore@...
        web/blog: http://www.jamesshore.com
      • PierG
        ... software ... In my opinion it depends on what you need to measure. Let me do an example in car racing. Lap time is a VERY good metric to see if your car
        Message 3 of 17 , Sep 1, 2005
        • 0 Attachment
          --- In extremeprogramming@yahoogroups.com, Jim Shore <jshore@t...>
          wrote:
          > I agree with Mary 100%. I've been looking for a good metric of
          software
          > productivity for some time.

          In my opinion it depends on what you need to measure.

          Let me do an example in car racing. 'Lap time' is a VERY good metric
          to see if your car is gonna win or not. 'Max Speed' is not: you can
          be fast as hell in a straight but you don't have grip enough for
          corners so .. eve if you are fast you have an (may be VERY) higher
          lap time.
          But ... may be the only place in your track where you can overtake
          is at the end of the main straight where just your 'Max speed'
          counts so: you don't have the best 'lap time' but you have the
          best 'max speed' so you can overtake and no one can overtake you ..
          and you win.

          So measuring the efficiency/effectiveness of you sw dev team maybe
          is not measuring the market success of the product they build (yes
          you are right: the company will close if the product has no success
          even if they have the best sw dev team of the world but ... that's
          not related on how the develop sw). Of course ... in my opinion.

          PierG
        • 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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.