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

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

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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.