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

Re: [XP] Re: should we work on projects that can't be released after an iteration?

Expand Messages
  • Steve Howell
    ... Nope, just feedback. ... You get feedback that is much more speculative in nature than the feedback that you d get from having a real customer use your
    Message 1 of 22 , Dec 30, 2003
    • 0 Attachment
      Dale Emery wrote:

      >Hi Steve,
      >
      >
      >
      >>Here is the problem:
      >>
      >>Iterations without releases are very unsatisfying to me.
      >>
      >>
      >
      >What needs do you have that aren't met by iterations without
      >releases?
      >
      >You've already mentioned one need: feedback. Are there others?
      >
      >
      Nope, just feedback.

      >
      >
      >>Here are possible solutions:
      >>
      >>1) Work around non-releasable iterations by doing long-term
      >>Release Planning.
      >>2) Challenge the assumption that you can't release after just
      >>one iteration.
      >>3) Decide that releasability after one iteration will be a
      >>criterion for me in choosing software projects to work on.
      >>
      >>
      > > 4) Some other solution.
      >
      >Another possibility is to explore whether iterations without
      >releases offer valuable feedback than you are not currently
      >seeing. An experienced XP coach could probably help with that.
      >
      >What feedback do you get from iterations without releases?
      >
      >
      You get feedback that is much more speculative in nature than the
      feedback that you'd get from having a real customer use your software to
      do real work.

      >What feedback do you get from iterations with releases that you
      >don't get from iterations alone?
      >
      >
      You get feedback about how the software actually solves the business
      problems for the customer in daily use.
    • Dale Emery
      Hi Steve, ... I was assuming that you were asking your questions from a Developer perspective. But I want to check that. Are you in the Customer role or the
      Message 2 of 22 , Dec 30, 2003
      • 0 Attachment
        Hi Steve,

        >> What feedback do you get from iterations with releases that
        >> you don't get from iterations alone?
        >
        > You get feedback about how the software actually solves the
        > business problems for the customer in daily use.

        I was assuming that you were asking your questions from a
        Developer perspective. But I want to check that. Are you in the
        Customer role or the Developer role when you ask this question?
        Or some other role?

        Dale

        --
        Dale Emery -- Consultant -- Resistance as a Resource
        Web: http://www.dhemery.com
        Weblog: http://www.dhemery.com/cwd (Conversations with Dale)

        The weakness of a soul is proportionate to the number of truths
        which must be kept from it. --Eric Hoffer
      • Steve Howell
        ... Both parties get into the feedback loop when iterations get released for actual use. Customers get feedback on how accurately they assessed the business
        Message 3 of 22 , Dec 30, 2003
        • 0 Attachment
          Dale Emery wrote:

          >Hi Steve,
          >
          >
          >
          >>>What feedback do you get from iterations with releases that
          >>>you don't get from iterations alone?
          >>>
          >>>
          >>You get feedback about how the software actually solves the
          >>business problems for the customer in daily use.
          >>
          >>
          >
          >I was assuming that you were asking your questions from a
          >Developer perspective. But I want to check that. Are you in the
          >Customer role or the Developer role when you ask this question?
          >Or some other role?
          >
          >
          >
          Both parties get into the feedback loop when iterations get released for
          actual use.

          Customers get feedback on how accurately they assessed the business
          value of various stories. To give a concrete example, suppose you're
          doing a coffeehouse project and one of the stories was to compute tax.
          If the customer begins to use the tax computation engine at the counter,
          she may realize just how much time it's saving her, and she might decide
          that arithmetic reduction is a good thing in general to strive for in
          stories. On the other hand, she might see that the tax computation story
          doesn't really help her speed up at all, but the menu lookup really
          helps her and gives her the unexpected benefit of being able to give
          customers better service. In that case, she might focus more on stories
          that present useful information to the counterperson.

          Developers get feedback on how well they delivered business value in
          their implementation of stories. This is particularly true for user
          interface stories where the developer has some discretion about how to
          present or collect data from the users.
        • Ron Jeffries
          ... Yes. Note, however, that while actual use is certainly far preferable, much of the important feedback can usually be gained if the customer herself, plus
          Message 4 of 22 , Dec 30, 2003
          • 0 Attachment
            On Tuesday, December 30, 2003, at 3:54:24 PM, Steve Howell wrote:

            > Both parties get into the feedback loop when iterations get released for
            > actual use.

            > Customers get feedback on how accurately they assessed the business
            > value of various stories. To give a concrete example, suppose you're
            > doing a coffeehouse project and one of the stories was to compute tax.
            > If the customer begins to use the tax computation engine at the counter,
            > she may realize just how much time it's saving her, and she might decide
            > that arithmetic reduction is a good thing in general to strive for in
            > stories. On the other hand, she might see that the tax computation story
            > doesn't really help her speed up at all, but the menu lookup really
            > helps her and gives her the unexpected benefit of being able to give
            > customers better service. In that case, she might focus more on stories
            > that present useful information to the counterperson.

            > Developers get feedback on how well they delivered business value in
            > their implementation of stories. This is particularly true for user
            > interface stories where the developer has some discretion about how to
            > present or collect data from the users.

            Yes. Note, however, that while actual use is certainly far preferable, much
            of the important feedback can usually be gained if the customer herself,
            plus any helpers she may select, tries out the software. As John Roth
            points out, she's supposed to do that, and of course the team is supposed
            to have the software ready to ship at all times.

            Real release is always better, no doubt about it.

            (And even with real release every millisecond, there are things that only
            the overview provided by release planning or the equivalent can give us.)

            Ron Jeffries
            www.XProgramming.com
            Any errors you find in this are the work of Secret Villains,
            whose mad schemes will soon be revealed. -- Wil McCarthy
          • Steve Howell
            ... I m glad we agree on something. :) ... Well, if you could just get down to releasing every iteration, then you would roll all the practices of release
            Message 5 of 22 , Dec 30, 2003
            • 0 Attachment
              Ron Jeffries wrote:

              >
              >
              >Yes. Note, however, that while actual use is certainly far preferable, much
              >of the important feedback can usually be gained if the customer herself,
              >plus any helpers she may select, tries out the software. As John Roth
              >points out, she's supposed to do that, and of course the team is supposed
              >to have the software ready to ship at all times.
              >
              >Real release is always better, no doubt about it.
              >
              >
              I'm glad we agree on something. :)

              >(And even with real release every millisecond, there are things that only
              >the overview provided by release planning or the equivalent can give us.)
              >
              >
              >
              Well, if you could just get down to releasing every iteration, then you
              would roll all the practices of release planning into iteration
              planning, and be done with it, right?
            • Ron Jeffries
              ... I guess I don t care when you do release planning. What I m on about is that it is important to do it, because XP with release planning works better than
              Message 6 of 22 , Dec 30, 2003
              • 0 Attachment
                On Tuesday, December 30, 2003, at 4:15:34 PM, Steve Howell wrote:

                > Well, if you could just get down to releasing every iteration, then you
                > would roll all the practices of release planning into iteration
                > planning, and be done with it, right?

                I guess I don't care when you do release planning. What I'm on about is
                that it is important to do it, because XP with release planning works
                better than XP without. By which I mean there exist better results which
                can only be produced that way. Joe has already posted one such.

                Ron Jeffries
                www.XProgramming.com
                Inigo Montoya: You are wonderful!
                Man in Black: Thank you. I have worked hard to become so.
              • Gunjan Doshi
                I feel release is a better milestone for the team. On the last XP project I coached, the project community felt a sense of accomplishment after the release and
                Message 7 of 22 , Dec 30, 2003
                • 0 Attachment
                  I feel release is a better milestone for the team. On the last XP project I
                  coached, the project community felt a sense of accomplishment after the
                  release and they celebrated. Accomplishing a release motivated them for the
                  next release. Iterations were a routine for them.
                  Also, I feel release means more to the customers, sales, marketing teams
                  than iteration.

                  > Dale Emery wrote:
                  >
                  > >Hi Steve,
                  > >
                  > >
                  > >
                  > >>Here is the problem:
                  > >>
                  > >>Iterations without releases are very unsatisfying to me.
                  > >>
                  > >>
                  > >
                  > >What needs do you have that aren't met by iterations without
                  > >releases?
                  > >
                  > >You've already mentioned one need: feedback. Are there others?
                  > >
                  > >
                  I feel release is a better milestone for the team. On the last XP project I
                  coached, the project community felt a sense of accomplishment after the
                  release and they celebrated. Accomplishing a release motivated them for the
                  next release. Iterations were a routine for them.
                  Also, I feel release means more to the customers, sales, marketing teams
                  than iteration.

                  > Nope, just feedback.
                  >
                  > >
                  > >
                  > >>Here are possible solutions:
                  > >>
                  > >>1) Work around non-releasable iterations by doing long-term
                  > >>Release Planning.
                  > >>2) Challenge the assumption that you can't release after just
                  > >>one iteration.
                  > >>3) Decide that releasability after one iteration will be a
                  > >>criterion for me in choosing software projects to work on.
                  > >>
                  > >>
                  > > > 4) Some other solution.
                  > >
                  > >Another possibility is to explore whether iterations without
                  > >releases offer valuable feedback than you are not currently
                  > >seeing. An experienced XP coach could probably help with that.
                  > >
                  > >What feedback do you get from iterations without releases?
                  > >
                  > >
                  > You get feedback that is much more speculative in nature than the
                  > feedback that you'd get from having a real customer use your software to
                  > do real work.
                  >
                  > >What feedback do you get from iterations with releases that you
                  > >don't get from iterations alone?
                  > >
                  > >
                  > You get feedback about how the software actually solves the business
                  > problems for the customer in daily use.
                  >
                  >
                  >
                  > 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 visit your group on the web, go to:
                  > http://groups.yahoo.com/group/extremeprogramming/
                  >
                  > To unsubscribe from this group, send an email to:
                  > extremeprogramming-unsubscribe@yahoogroups.com
                  >
                  > Your use of Yahoo! Groups is subject to:
                  > http://docs.yahoo.com/info/terms/
                  >
                  >
                • Doug Swartz
                  ... No. We re working on a project to extend an existing system to meet the needs of a large new customer. Even though we can (and do) release the system to
                  Message 8 of 22 , Dec 31, 2003
                  • 0 Attachment
                    Tuesday, December 30, 2003, 3:15:34 PM, Steve Howell wrote:

                    > Ron Jeffries wrote:

                    >>(And even with real release every millisecond, there are things that only
                    >>the overview provided by release planning or the equivalent can give us.)
                    >>
                    >>
                    >>
                    > Well, if you could just get down to releasing every iteration, then you
                    > would roll all the practices of release planning into iteration
                    > planning, and be done with it, right?

                    No.

                    We're working on a project to extend an existing system to
                    meet the needs of a large new customer. Even though we can
                    (and do) release the system to the existing customers every
                    iteration, we still need the longer term view provided by
                    release planning to know if we're on target to meet our
                    deliverables two or three months in the future.

                    As Ron noted somewhere else in the thread: Iterations give
                    feedback which helps us optimize locally (hill climbing);
                    Release Planning gives us the longer term view (map reading to
                    see if we're in the right county).



                    --

                    Doug Swartz
                    daswartz@...
                  • Steve Bate
                    ... Hi Doug, I think that what Steve and myself and others are saying is that sometimes hill climbing is a valid primary strategy when the actual business
                    Message 9 of 22 , Dec 31, 2003
                    • 0 Attachment
                      > From: Doug Swartz [mailto:daswartz@...]
                      > > Well, if you could just get down to releasing every iteration, then you
                      > > would roll all the practices of release planning into iteration
                      > > planning, and be done with it, right?
                      >
                      > No.
                      >
                      > We're working on a project to extend an existing system to
                      > meet the needs of a large new customer. Even though we can
                      > (and do) release the system to the existing customers every
                      > iteration, we still need the longer term view provided by
                      > release planning to know if we're on target to meet our
                      > deliverables two or three months in the future.
                      >
                      > As Ron noted somewhere else in the thread: Iterations give
                      > feedback which helps us optimize locally (hill climbing);
                      > Release Planning gives us the longer term view (map reading to
                      > see if we're in the right county).

                      Hi Doug,

                      I think that what Steve and myself and others are saying is
                      that sometimes hill climbing is a valid primary strategy
                      when the actual business "terrain" is constantly shifting
                      and there are /no reliable maps/. This is when agility is
                      most needed. Fortunately, most projects don't operate in
                      this environment so map following works reasonably well.
                    • Ron Jeffries
                      ... What business terrain is such that no one thinks about what s going to be happening three, six, twelve months out? Examples of a kind of project where no
                      Message 10 of 22 , Dec 31, 2003
                      • 0 Attachment
                        On Wednesday, December 31, 2003, at 10:38:07 AM, Steve Bate wrote:

                        > I think that what Steve and myself and others are saying is
                        > that sometimes hill climbing is a valid primary strategy
                        > when the actual business "terrain" is constantly shifting
                        > and there are /no reliable maps/. This is when agility is
                        > most needed. Fortunately, most projects don't operate in
                        > this environment so map following works reasonably well.

                        What business terrain is such that no one thinks about what's going to be
                        happening three, six, twelve months out? Examples of a kind of project
                        where no one wants to know things like that?

                        Thanks,

                        Ron Jeffries
                        www.XProgramming.com
                        Fear is the mindkiller. --Bene Gesserit Litany Against Fear
                      • Steve Bate
                        ... From: Ron Jeffries To: Sent: Wednesday, December 31, 2003 9:52 AM Subject: Re: [XP]
                        Message 11 of 22 , Dec 31, 2003
                        • 0 Attachment
                          ----- Original Message -----
                          From: "Ron Jeffries" <ronjeffries@...>
                          To: <extremeprogramming@yahoogroups.com>
                          Sent: Wednesday, December 31, 2003 9:52 AM
                          Subject: Re: [XP] Re: should we work on projects that can't be released
                          after an iteration?


                          > On Wednesday, December 31, 2003, at 10:38:07 AM, Steve Bate wrote:
                          >
                          > > I think that what Steve and myself and others are saying is
                          > > that sometimes hill climbing is a valid primary strategy
                          > > when the actual business "terrain" is constantly shifting
                          > > and there are /no reliable maps/. This is when agility is
                          > > most needed. Fortunately, most projects don't operate in
                          > > this environment so map following works reasonably well.
                          >
                          > What business terrain is such that no one thinks about what's going to be
                          > happening three, six, twelve months out? Examples of a kind of project
                          > where no one wants to know things like that?

                          None that I've known.

                          I've never said we didn't think about general long term trends or
                          that we didn't want to know the future. Thinking about longer term
                          trends doesn't sound like a release plan, by your definition, although
                          we do set longer term high level goals/milestones (as described in the
                          Beck/Fowler book). Wanting to know and being able to know are two
                          different issues. When people don't separate those two issues there's
                          a risk that the result will be "wishful thinking". I've seen a few
                          projects succeed in spite of wishful thinking but I've seen a lot more
                          be seriously endangered because of it.

                          We don't know what a future, unknown end-user (a business in this
                          case) might want 6-12 months out. IOW, we don't know who those
                          companies will be and what features would be required to sell them
                          on signing up with us or keeping their business. The potential users
                          and their desired features change as new marketing opportunities arise
                          or dissipate.

                          To be somewhat more specific, the changing global economic terrain
                          has, and is, resulting in significant and sometimes rapid shifts within
                          the investment and trading industry (which is our domain). For example,
                          traders are experimenting with newly created financial instruments,
                          exchanges are changing protocols and merging and splitting, there are
                          shifts occurring between the ratio of manual vs. program trading, and
                          so on. At a lower level, the customer that we were wooing an iteration
                          ago and who wanted certain features may have gone out of business now
                          or decided to change their business strategies. In the meantime,
                          our marketing group may have identified several more potential
                          companies with their own wish list. For all these reasons, it's
                          very difficult for anybody to know with any accuracy what the most
                          profitable features will be very far into the future.
                        • Doug Swartz
                          ... You re right that sometimes hill climbing is all that s needed. I could certainly be wrong, but I ve gotten the sense from Steve s posts that he might
                          Message 12 of 22 , Dec 31, 2003
                          • 0 Attachment
                            Wednesday, December 31, 2003, 9:38:07 AM, Steve Bate wrote:

                            >> From: Doug Swartz [mailto:daswartz@...]
                            >> > Well, if you could just get down to releasing every iteration, then you
                            >> > would roll all the practices of release planning into iteration
                            >> > planning, and be done with it, right?
                            >>
                            >> No.
                            >>
                            >> We're working on a project to extend an existing system to
                            >> meet the needs of a large new customer. Even though we can
                            >> (and do) release the system to the existing customers every
                            >> iteration, we still need the longer term view provided by
                            >> release planning to know if we're on target to meet our
                            >> deliverables two or three months in the future.
                            >>
                            >> As Ron noted somewhere else in the thread: Iterations give
                            >> feedback which helps us optimize locally (hill climbing);
                            >> Release Planning gives us the longer term view (map reading to
                            >> see if we're in the right county).

                            > Hi Doug,

                            > I think that what Steve and myself and others are saying is
                            > that sometimes hill climbing is a valid primary strategy
                            > when the actual business "terrain" is constantly shifting
                            > and there are /no reliable maps/. This is when agility is
                            > most needed. Fortunately, most projects don't operate in
                            > this environment so map following works reasonably well.

                            You're right that sometimes hill climbing is all that's
                            needed. I could certainly be wrong, but I've gotten the sense
                            from Steve's posts that he might generally see little value in
                            the map. I'm aware of some domains, such as financial
                            derivatives, where the lifetime of an idea/plan can truly be
                            counted as days or weeks. However, I believe this is a very
                            tiny minority. I believe there are very few companies which
                            don't need to plan for at least a few months into the future
                            to remain viable. Or maybe I just believe this because I live
                            in the staid boring midwest.

                            Also, I don't think I ever said the release "map" is
                            particularly reliable. Perhaps because of the industry you
                            work in, you have a different view of where "the rest of us"
                            work.

                            <warning overreaching metaphor> Imagine that the business has
                            decided we need to take a road trip to Los Angeles. We have a
                            map that shows how to get there. Unfortunately it is a road
                            map of the country that our parents picked up at a Texaco
                            station in 1959. Most of the roads on the map still exist.
                            Some of them don't. Some are Interstate freeways now. The
                            little stars that show Texaco station locations are completely
                            useless. But the map can still give us useful information.
                            Chicago and Omaha and Denver are still in the same place. The
                            states are still in the same place. If we are in Denver, we
                            know that we're about 2/3 of the way across the country. We
                            can also figure out if we are headed in the right direction.
                            </warning overreaching metaphor>

                            While the metaphor rapidly breaks down, I think the "maps" we
                            often have at the beginning of a project are no more reliable
                            than that 1959 road map. Of course, with a release plan every
                            few iterations, our map (unlike the 1959 road map) gets better
                            each time. Because of this, I believe agile approaches are
                            just as valuable in other domains, as in those extremely
                            volatile domains like financial derivatives. The difference
                            is that the people programming for the derivatives companies
                            were forced to start being agile long before the rest of us. I
                            think this is because the rest of us had a road map. We just
                            lied to ourselves for a long time in thinking that it was
                            accurate, when, at best, it was only accurate in 1959.



                            --

                            Doug Swartz
                            daswartz@...
                          • Ron Jeffries
                            ... I really wonder whether the best strategy in those companies is just to continually code the most important thing like demons. It might be. Doesn t
                            Message 13 of 22 , Dec 31, 2003
                            • 0 Attachment
                              On Wednesday, December 31, 2003, at 7:06:25 PM, Doug Swartz wrote:

                              > The difference
                              > is that the people programming for the derivatives companies
                              > were forced to start being agile long before the rest of us.

                              I really wonder whether the best strategy in those companies is just to
                              continually code "the most important thing" like demons.

                              It might be. Doesn't really sound like fun. I suppose the money is good.

                              Ron Jeffries
                              www.XProgramming.com
                              You don't want to sell me waterfall.
                              You want to go home and rethink your life.
                            • Steve Bate
                              ... I agree. The coffeehouse domain could very well be more suited to relatively longer range planning. I don t know the domain well enough to say for sure. I
                              Message 14 of 22 , Jan 1, 2004
                              • 0 Attachment
                                > From: Doug Swartz [mailto:daswartz@...]
                                > You're right that sometimes hill climbing is all that's
                                > needed. I could certainly be wrong, but I've gotten the sense
                                > from Steve's posts that he might generally see little value in
                                > the map. I'm aware of some domains, such as financial
                                > derivatives, where the lifetime of an idea/plan can truly be
                                > counted as days or weeks. However, I believe this is a very
                                > tiny minority. I believe there are very few companies which
                                > don't need to plan for at least a few months into the future
                                > to remain viable. Or maybe I just believe this because I live
                                > in the staid boring midwest.

                                I agree. The coffeehouse domain could very well be more suited
                                to relatively longer range planning. I don't know the domain well
                                enough to say for sure. I also agree that domains that are this
                                dynamic are somewhat rare. Almost all the other projects I've
                                worked at previous companies on maintained longer term plans
                                (sometimes too long).

                                > Also, I don't think I ever said the release "map" is
                                > particularly reliable. Perhaps because of the industry you
                                > work in, you have a different view of where "the rest of us"
                                > work.

                                I've worked in a lot of different domains over the years. I
                                agree that the map is more or less reliable depending on
                                the nature of the project and the team.

                                >...
                                > While the metaphor rapidly breaks down, I think the "maps" we
                                > often have at the beginning of a project are no more reliable
                                > than that 1959 road map. Of course, with a release plan every
                                > few iterations, our map (unlike the 1959 road map) gets better
                                > each time. Because of this, I believe agile approaches are
                                > just as valuable in other domains, as in those extremely
                                > volatile domains like financial derivatives.

                                Agility is definitely valuable in many domains. Your metaphor
                                fits several (most?) of the projects I've worked on. Others
                                were either research projects or first of their kind development
                                and we didn't experience as much improvement in the map.

                                > The difference
                                > is that the people programming for the derivatives companies
                                > were forced to start being agile long before the rest of us. I
                                > think this is because the rest of us had a road map. We just
                                > lied to ourselves for a long time in thinking that it was
                                > accurate, when, at best, it was only accurate in 1959.

                                That's an interesting thought. I've used lightweight practices
                                on projects even before the XP/agile movement. Although the
                                previous domains were less dynamic, the drive to maximize
                                productivity was a strong motivator to streamline the development
                                approaches. We always assumed the map would change to some extent
                                and our planning approaches supported that flexibility.
                              • Steve Bate
                                ... If coding like demons means generating business value like a bat out of hell then that sounds accurate to me. :) When would coding the most important
                                Message 15 of 22 , Jan 1, 2004
                                • 0 Attachment
                                  > From: Ron Jeffries [mailto:ronjeffries@...]
                                  > On Wednesday, December 31, 2003, at 7:06:25 PM, Doug Swartz wrote:
                                  >
                                  > > The difference
                                  > > is that the people programming for the derivatives companies
                                  > > were forced to start being agile long before the rest of us.
                                  >
                                  > I really wonder whether the best strategy in those companies is just to
                                  > continually code "the most important thing" like demons.

                                  If "coding like demons" means generating business value "like a
                                  bat out of hell" then that sounds accurate to me. :) When would
                                  coding the most important things (the things with the most value)
                                  be a questionable strategy?

                                  > It might be. Doesn't really sound like fun. I suppose the money is good.

                                  We actually have a LOT of fun but I understand that the intensity and
                                  the dynamic business context might not be enjoyable for some people.
                                • Ron Jeffries
                                  ... I can only speculate, having never visited such a team to see what their problems are. I feel quite sure that they do have problems, that not everything
                                  Message 16 of 22 , Jan 1, 2004
                                  • 0 Attachment
                                    On Thursday, January 1, 2004, at 3:30:10 AM, Steve Bate wrote:

                                    >> From: Ron Jeffries [mailto:ronjeffries@...]
                                    >> On Wednesday, December 31, 2003, at 7:06:25 PM, Doug Swartz wrote:
                                    >>
                                    >> > The difference
                                    >> > is that the people programming for the derivatives companies
                                    >> > were forced to start being agile long before the rest of us.
                                    >>
                                    >> I really wonder whether the best strategy in those companies is just to
                                    >> continually code "the most important thing" like demons.

                                    > If "coding like demons" means generating business value "like a
                                    > bat out of hell" then that sounds accurate to me. :) When would
                                    > coding the most important things (the things with the most value)
                                    > be a questionable strategy?

                                    I can only speculate, having never visited such a team to see what their
                                    problems are. I feel quite sure that they do have problems, that not
                                    everything goes perfectly. What are those problems?

                                    I suspect the value focus is on things like instruments that we want to
                                    trade in tomorrow. I would expect that there is a certain value to
                                    reusability in the code, which would turn up in terms of faster
                                    implementation and higher reliability. I would expect that over time, the
                                    software would become -- at least in some areas -- difficult to maintain
                                    and potentially unreliable.

                                    If any of these things happened, then "most important" takes on a new
                                    dimension, one of what we might call sustainability.

                                    I would expect that there might be "infrastructure" kinds of things that
                                    the team can see, such that /if/ they had them, things would go better. It
                                    might be difficult to find time and money to invest in those things -- some
                                    teams hold back a small percentage of the team, to have them working on
                                    that sort of thing. That can work reasonably well. I would guess that in
                                    the business today there might, for example, be Java teams wishing that
                                    they could work in Smalltalk or LISP, but with no way to get there; or some
                                    equivalent kind of wish.

                                    Some organizations doing this kind of work start separate "framework"
                                    organizations aimed at doing things differently. It's very hard to make
                                    this work, even though the value is perceived to be high "if only".

                                    Why does an organization like this fall behind? What are the things that
                                    slow them down, the things they would invest in if they could? What do the
                                    programmers bitch about over lunch?

                                    >> It might be. Doesn't really sound like fun. I suppose the money is good.

                                    > We actually have a LOT of fun but I understand that the intensity and
                                    > the dynamic business context might not be enjoyable for some people.

                                    Yes, I mean of course that it doesn't sound like fun /to me/. Is there high
                                    voluntary turnover in this kind of work? Is there an age bias in the kind
                                    of people who enjoy the work and who are good at it, vs those who do not or
                                    are not? I would not be surprised. Is there a gender bias different from
                                    the overall gender bias in our business?

                                    I certainly hope that the people who do it find ways to enjoy it, and that
                                    most of those are healthy ways. I have seen teams -- perhaps we all have --
                                    where the "fun" was in knowing that there were other people suffering and
                                    dying just like we were. The camaraderie of soldiers on the front line.
                                    People can have fun anywhere, I guess. Some kinds of fun seem more ...
                                    legitimate, more human than others. I hope it's that kind of fun.

                                    And what are the issues, problems, unmet opportunities?

                                    Ron Jeffries
                                    www.XProgramming.com
                                    Anyone can make the simple complicated.
                                    Creativity is making the complicated simple. -- Charles Mingus
                                  • J. B. Rainsberger
                                    ... Well, there s the whole urgent v. important discussion. Some features are important, but not urgent, so they need to be done, but not necessarily very
                                    Message 17 of 22 , Jan 1, 2004
                                    • 0 Attachment
                                      Steve Bate wrote:

                                      >>From: Ron Jeffries [mailto:ronjeffries@...]
                                      >>On Wednesday, December 31, 2003, at 7:06:25 PM, Doug Swartz wrote:
                                      >>
                                      >>>The difference
                                      >>>is that the people programming for the derivatives companies
                                      >>>were forced to start being agile long before the rest of us.
                                      >>
                                      >>I really wonder whether the best strategy in those companies is just to
                                      >>continually code "the most important thing" like demons.
                                      >
                                      > If "coding like demons" means generating business value "like a
                                      > bat out of hell" then that sounds accurate to me. :) When would
                                      > coding the most important things (the things with the most value)
                                      > be a questionable strategy?

                                      Well, there's the whole "urgent v. important" discussion. Some features
                                      are important, but not urgent, so they need to be done, but not
                                      necessarily very soon. Create a 2D coordinate system with urgency and
                                      importance as the axes. Assuming positive means "more" and negative
                                      means "less", then you want to work on stories roughly from the
                                      top-right to the bottom-left of the graph, choosing urgent stories over
                                      important ones when you need to break a tie.
                                      --
                                      J. B. Rainsberger,
                                      Diaspar Software Services
                                      http://www.diasparsoftware.com :: +1 416 791-8603
                                      Let's write software that people understand
                                    • Steve Bate
                                      ... The value focus is on business value, almost always in the narrow sense I ve described in previous messages. ... sustainability. Yes, of course.
                                      Message 18 of 22 , Jan 1, 2004
                                      • 0 Attachment
                                        > From: Ron Jeffries [mailto:ronjeffries@...]
                                        >
                                        > I suspect the value focus is on things like instruments that we want to
                                        > trade in tomorrow.

                                        The value focus is on business value, almost always in the narrow sense
                                        I've described in previous messages.

                                        > I would expect that there is a certain value to
                                        > reusability in the code, which would turn up in terms of faster
                                        > implementation and higher reliability. I would expect that over time, the
                                        > software would become -- at least in some areas -- difficult to maintain
                                        > and potentially unreliable.> If any of these things happened, then "most
                                        > important" takes on a new dimension, one of what we might call
                                        sustainability.

                                        Yes, of course. Importance, for us, is predominately a function of
                                        estimated business value. Code that is difficult to maintain or is
                                        unreliable is a business value risk. Both of these issues could
                                        result is lost current and/or future revenues.

                                        > I would expect that there might be "infrastructure" kinds of things that
                                        > the team can see, such that /if/ they had them, things would go better. It
                                        > might be difficult to find time and money to invest in those things

                                        Most infrastructure development occurs as a side-effect of typical
                                        refactoring activities. Typically, it starts very simple and incrementally
                                        evolves. If we identify some type of infrastructure that would allow things
                                        to significantly "go better" we'd build it. Again, the focus is on business
                                        value. Our definition of "go better" would mean that we can better meet our
                                        present and future customers (end users) needs, resulting in
                                        increased revenues for the company.

                                        > some teams hold back a small percentage of the team, to have them working
                                        on
                                        > that sort of thing. That can work reasonably well. I would guess that in
                                        > the business today there might, for example, be Java teams wishing that
                                        > they could work in Smalltalk or LISP, but with no way to get
                                        > there; or some equivalent kind of wish.

                                        Are these wishes that would result in significantly increased
                                        business value or just personal preferences for one language over another?

                                        > Some organizations doing this kind of work start separate "framework"
                                        > organizations aimed at doing things differently. It's very hard to make
                                        > this work, even though the value is perceived to be high "if only".

                                        I don't think this approach would work nearly as well for us either.

                                        > Why does an organization like this fall behind? What are the things that
                                        > slow them down, the things they would invest in if they could? What do the
                                        > programmers bitch about over lunch?

                                        I'm not sure if you mean "organization" as the development group, or the
                                        project team, or the whole company. I'll answer the question at the
                                        project team level. I mentioned in a previous message that one of our
                                        current challenges is that the customer sometimes has difficulty providing
                                        stories in a timely manner. We are in the process of considering various
                                        potential refactorings of our customer organization to improve this
                                        situation. For example, one refactoring might involve adding additional
                                        product managers since our ratio of developers to customers is relatively
                                        high. I don't know of any things in the development organization
                                        that slows us down to any signficant extent.

                                        I'd say the story flow issue the most common lunch bitch recently, besides
                                        wishing we lived closer to an ocean and/or mountains (a much more common
                                        bitch).

                                        > >> It might be. Doesn't really sound like fun. I suppose the
                                        > money is good.
                                        >
                                        > > We actually have a LOT of fun but I understand that the intensity and
                                        > > the dynamic business context might not be enjoyable for some people.
                                        >
                                        > Yes, I mean of course that it doesn't sound like fun /to me/. Is
                                        > there high voluntary turnover in this kind of work?

                                        IIRC, there's been no voluntary developer turnover in the 2-3 years
                                        I've been here.

                                        > Is there an age bias in the kind of people who enjoy the work and
                                        > who are good at it, vs those who do not or are not? I would not be
                                        > surprised.

                                        The experience range varies from 15+ years to < 5.
                                        The low end is a bit misleading. The younger developers are extremely
                                        good, better than the typical senior developers I've seen on other
                                        projects. Developer attitudes such as the desire to be productive
                                        (generate business value), do excellent work, be flexible, and continually
                                        expand their skills seem to a much more important factors than age.

                                        > Is there a gender bias different from the overall gender bias in
                                        > our business?

                                        I don't think so. What is the ratio of men to women in very senior
                                        level ("architect") programming jobs?

                                        > I certainly hope that the people who do it find ways to enjoy it,
                                        > and that most of those are healthy ways. I have seen teams -- perhaps we
                                        > all have -- where the "fun" was in knowing that there were other
                                        > people suffering and dying just like we were. The camaraderie of
                                        > soldiers on the front line.

                                        I've never been on a full-blown death march but when I've been in
                                        situations somewhat like you describe (at previous companies) nobody
                                        labeled it as "fun".

                                        > People can have fun anywhere, I guess. Some kinds of fun seem more ...
                                        > legitimate, more human than others. I hope it's that kind of fun.

                                        It is.

                                        > And what are the issues, problems, unmet opportunities?

                                        Well, we sometimes get a little frustrated that we aren't millionaires
                                        yet. ;) I've never claimed it was a perfect situation. Several issues
                                        (none major) have been discussed in recent messages. There a constant
                                        challenge to remain aware of movement in a very dynamic market and use
                                        that knowledge to assess and re-assess business value of candidate
                                        stories. I believe that all businesses need to do this, but they can
                                        probably be much more laid back about it and survive longer than
                                        we could.
                                      • Steve Bate
                                        ... Yes, the terms are a bit ambiguous. For us, importance is primarily a function of business value which is a function of estimated revenue and time.
                                        Message 19 of 22 , Jan 1, 2004
                                        • 0 Attachment
                                          > From: J. B. Rainsberger [mailto:jbrains@...]
                                          > Steve Bate wrote:
                                          > > If "coding like demons" means generating business value "like a
                                          > > bat out of hell" then that sounds accurate to me. :) When would
                                          > > coding the most important things (the things with the most value)
                                          > > be a questionable strategy?
                                          >
                                          > Well, there's the whole "urgent v. important" discussion. Some features
                                          > are important, but not urgent, so they need to be done, but not
                                          > necessarily very soon.

                                          Yes, the terms are a bit ambiguous. For us, "importance" is primarily
                                          a function of business value which is a function of estimated revenue
                                          and time. That's why I qualified "importance" as "things with the most
                                          [business] value". I'm guessing this is some combination of what you
                                          call importance and urgency. I don't know how you define importance
                                          so I can't say for sure. Technology risk is another criteria that
                                          some teams use for story ordering. We don't use it exclusively but
                                          it is a factor we consider when it's likely to effect the ability
                                          to produce business value quickly.
                                        • J. B. Rainsberger
                                          ... Important := we should not end the project without doing it Urgent := we need to do it /now/ because someone else needs it done /now/ Example: it s
                                          Message 20 of 22 , Jan 1, 2004
                                          • 0 Attachment
                                            Steve Bate wrote:

                                            >>From: J. B. Rainsberger [mailto:jbrains@...]
                                            >>Steve Bate wrote:
                                            >>
                                            >>>If "coding like demons" means generating business value "like a
                                            >>>bat out of hell" then that sounds accurate to me. :) When would
                                            >>>coding the most important things (the things with the most value)
                                            >>>be a questionable strategy?
                                            >>
                                            >>Well, there's the whole "urgent v. important" discussion. Some features
                                            >>are important, but not urgent, so they need to be done, but not
                                            >>necessarily very soon.
                                            >
                                            > Yes, the terms are a bit ambiguous. For us, "importance" is primarily
                                            > a function of business value which is a function of estimated revenue
                                            > and time. That's why I qualified "importance" as "things with the most
                                            > [business] value". I'm guessing this is some combination of what you
                                            > call importance and urgency. I don't know how you define importance
                                            > so I can't say for sure. Technology risk is another criteria that
                                            > some teams use for story ordering. We don't use it exclusively but
                                            > it is a factor we consider when it's likely to effect the ability
                                            > to produce business value quickly.

                                            Important := we should not end the project without doing it
                                            Urgent := we need to do it /now/ because someone else needs it done /now/

                                            Example: it's important to store data in a DB2 database for
                                            interoperation with other applications we intend to build, but if that
                                            comes in iteration 12, that's OK, as long as it happens.
                                            --
                                            J. B. Rainsberger,
                                            Diaspar Software Services
                                            http://www.diasparsoftware.com :: +1 416 791-8603
                                            Let's write software that people understand
                                          • Ron Jeffries
                                            ... OK ... it s now narrow that focus is that is, of course, the focus of my questions and notions about longer-range planning. Looking ahead, your situation
                                            Message 21 of 22 , Jan 2, 2004
                                            • 0 Attachment
                                              On Thursday, January 1, 2004, at 1:22:56 PM, Steve Bate wrote:

                                              >> From: Ron Jeffries [mailto:ronjeffries@...]
                                              >>
                                              >> I suspect the value focus is on things like instruments that we want to
                                              >> trade in tomorrow.

                                              > The value focus is on business value, almost always in the narrow sense
                                              > I've described in previous messages.

                                              OK ... it's now narrow that focus is that is, of course, the "focus" of my
                                              questions and notions about longer-range planning. Looking ahead, your
                                              situation sounds pretty healthy to me. (Free team assessment coming up,
                                              worth every penny. :) )

                                              >> I would expect that there is a certain value to
                                              >> reusability in the code, which would turn up in terms of faster
                                              >> implementation and higher reliability. I would expect that over time, the
                                              >> software would become -- at least in some areas -- difficult to maintain
                                              >> and potentially unreliable.> If any of these things happened, then "most
                                              >> important" takes on a new dimension, one of what we might call
                                              > sustainability.

                                              > Yes, of course. Importance, for us, is predominately a function of
                                              > estimated business value. Code that is difficult to maintain or is
                                              > unreliable is a business value risk. Both of these issues could
                                              > result is lost current and/or future revenues.

                                              Yes, they could. And I gather that the team feels it has its eye on this
                                              ball. That sounds good.

                                              > Most infrastructure development occurs as a side-effect of typical
                                              > refactoring activities. Typically, it starts very simple and incrementally
                                              > evolves. If we identify some type of infrastructure that would allow things
                                              > to significantly "go better" we'd build it. Again, the focus is on business
                                              > value. Our definition of "go better" would mean that we can better meet our
                                              > present and future customers (end users) needs, resulting in
                                              > increased revenues for the company.

                                              Cool. If the team feels it has time to build things that it needs, that
                                              suggests a reasonably healthy situation. And I interpret the answer as
                                              indicating that there must be time to think about such things as well.

                                              >> some teams hold back a small percentage of the team, to have them working
                                              > on
                                              >> that sort of thing. That can work reasonably well. I would guess that in
                                              >> the business today there might, for example, be Java teams wishing that
                                              >> they could work in Smalltalk or LISP, but with no way to get
                                              >> there; or some equivalent kind of wish.

                                              > Are these wishes that would result in significantly increased
                                              > business value or just personal preferences for one language over another?

                                              Well, some people think that Smalltalk and LISP are inherently more
                                              productive than Java by a substantial margin. I don't recall anyone ever
                                              claiming that Java was substantially more productive than Smalltalk. :)

                                              >> Why does an organization like this fall behind? What are the things that
                                              >> slow them down, the things they would invest in if they could? What do the
                                              >> programmers bitch about over lunch?

                                              > I'm not sure if you mean "organization" as the development group, or the
                                              > project team, or the whole company. I'll answer the question at the
                                              > project team level. I mentioned in a previous message that one of our
                                              > current challenges is that the customer sometimes has difficulty providing
                                              > stories in a timely manner. We are in the process of considering various
                                              > potential refactorings of our customer organization to improve this
                                              > situation. For example, one refactoring might involve adding additional
                                              > product managers since our ratio of developers to customers is relatively
                                              > high. I don't know of any things in the development organization
                                              > that slows us down to any signficant extent.

                                              Delivering too much software to satisfy one customer sounds like a good
                                              problem to have ...

                                              > IIRC, there's been no voluntary developer turnover in the 2-3 years
                                              > I've been here.

                                              Sounds very good!

                                              >> Is there an age bias in the kind of people who enjoy the work and
                                              >> who are good at it, vs those who do not or are not? I would not be
                                              >> surprised.

                                              > The experience range varies from 15+ years to < 5.
                                              > The low end is a bit misleading. The younger developers are extremely
                                              > good, better than the typical senior developers I've seen on other
                                              > projects. Developer attitudes such as the desire to be productive
                                              > (generate business value), do excellent work, be flexible, and continually
                                              > expand their skills seem to a much more important factors than age.

                                              I like to think so. I was wondering whether there was a kind of "young
                                              person's" pressure going on.

                                              >> Is there a gender bias different from the overall gender bias in
                                              >> our business?

                                              > I don't think so. What is the ratio of men to women in very senior
                                              > level ("architect") programming jobs?

                                              I'm not sure. One out of five to ten would be a rough guess pulled entirely
                                              out of my subconscious, and I'm leaning toward eight.

                                              > Well, we sometimes get a little frustrated that we aren't millionaires
                                              > yet. ;) I've never claimed it was a perfect situation. Several issues
                                              > (none major) have been discussed in recent messages. There a constant
                                              > challenge to remain aware of movement in a very dynamic market and use
                                              > that knowledge to assess and re-assess business value of candidate
                                              > stories. I believe that all businesses need to do this, but they can
                                              > probably be much more laid back about it and survive longer than
                                              > we could.

                                              An interesting report. It sounds like you manage to have a decent overview
                                              of where you're at and how things are going, and if you're able to invest
                                              in refactoring toward better structure where it's needed, that sounds like
                                              a good balance. Plus, if you can tell the difference between a death march
                                              and what you're doing, that's a good sign!

                                              It would be interesting to have someone observe your team for a while and
                                              see whether they noticed anything interesting, but it certainly sounds like
                                              things are fairly healthy. It's hard for me to imagine a long series of
                                              stories that aren't actually headed somewhere, somewhere that we'd need to
                                              keep an eye on, but you seem confident that things are going well.

                                              Ron Jeffries
                                              www.XProgramming.com
                                              Will Turner: This is either madness or brilliance.
                                              Captain Jack Sparrow: It's remarkable how often those two traits coincide.
                                            • Steve Bate
                                              ... I ve never done any Smalltalk programmning but I did extensive LISP programming back when I was an AI researcher. I like LISP a lot and the techniques I
                                              Message 22 of 22 , Jan 2, 2004
                                              • 0 Attachment
                                                > From: Ron Jeffries [mailto:ronjeffries@...]
                                                > On Thursday, January 1, 2004, at 1:22:56 PM, Steve Bate wrote:
                                                >...
                                                > >> I would guess that in
                                                > >> the business today there might, for example, be Java teams wishing that
                                                > >> they could work in Smalltalk or LISP, but with no way to get
                                                > >> there; or some equivalent kind of wish.
                                                >
                                                > > Are these wishes that would result in significantly increased
                                                > > business value or just personal preferences for one language
                                                > > over another?
                                                >
                                                > Well, some people think that Smalltalk and LISP are inherently more
                                                > productive than Java by a substantial margin. I don't recall anyone ever
                                                > claiming that Java was substantially more productive than Smalltalk. :)

                                                I've never done any Smalltalk programmning but I did extensive
                                                LISP programming back when I was an AI researcher. I like LISP
                                                a lot and the techniques I used in LISP have influenced my Java
                                                programming. If we did a tradeoff analysis I think it's the vast
                                                quantity of third-party commercial and open source libraries for
                                                Java that would give it the advantage in overall productivity.
                                                Even at a language level, it's certainly not as cool as LISP, but
                                                I don't believe it's significantly slower to write code in Java
                                                than in LISP.

                                                > >> Is there a gender bias different from the overall gender bias in
                                                > >> our business?
                                                >
                                                > > I don't think so. What is the ratio of men to women in very senior
                                                > > level ("architect") programming jobs?
                                                >
                                                > I'm not sure. One out of five to ten would be a rough guess
                                                > pulled entirely out of my subconscious, and I'm leaning toward eight.

                                                Recently we hired some new developers. We were looking for high end
                                                Java developers. I think maybe 1 out of 30 or so resumes was a female.
                                                Until recently our team was 5 developers, all male, which seems consistent
                                                with the ratio in other businesses.

                                                >...
                                                > An interesting report. It sounds like you manage to have a decent overview
                                                > of where you're at and how things are going, and if you're able to invest
                                                > in refactoring toward better structure where it's needed, that sounds like
                                                > a good balance. Plus, if you can tell the difference between a death march
                                                > and what you're doing, that's a good sign!
                                                >
                                                > It would be interesting to have someone observe your team for a while and
                                                > see whether they noticed anything interesting, but it certainly
                                                > sounds like things are fairly healthy. It's hard for me to imagine a
                                                > long series of stories that aren't actually headed somewhere, somewhere
                                                > that we'd need to keep an eye on, but you seem confident that things are
                                                > going well.

                                                Like I've said before, it's not that the stories aren't heading anywhere.
                                                We have two areas of focus: 1) building customized solutions or special
                                                features for current or specific potential customers and 2) building general
                                                features that allow us to compete with similar businesses in the broad
                                                market and hopefully allows us to take some of their customers. The first
                                                category is the most dynamic. The second category does involve longer range
                                                objectives like "we'd like to have features X,Y,Z before the trade show
                                                because
                                                it will increases sales". However, features X, Y, Z may all be the "nice to
                                                have" type rather than an absolute need. Some of these features are rather
                                                complex and they are often more like incremental product definition (feature
                                                design at a functional level) than a description of existing requirements.
                                                I haven't thought about it extensively, but my impression is that doing
                                                detailed definition of all the new product features up front may have
                                                similar disadvantages as BDUF for software.

                                                As we approach an objective, like having certain features for a tradeshow,
                                                we tradeoff the immediate business needs (the very dynamic ones) with the
                                                relatively stable long range goals. Many times this tradeoff analysis is
                                                more art than science. Based on these tradeoffs, which occur before the
                                                actual iteration planning meetings, the customer does a just-in-time final
                                                definition of the new product features to be implemented in that iteration
                                                or over the next few iterations.

                                                There are also higher level objectives related to our parent company's
                                                strategy for how we fit with the larger multibusiness organization. All
                                                these are taken into account when planning. In a sense, we are almost
                                                constantly preparing for planning through many informal discussions
                                                between development, management, and our customers about where we are
                                                going, why, and what's the best way to make money along the way.
                                              Your message has been successfully submitted and would be delivered to recipients shortly.