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

doing things right or doing the right thing?

Expand Messages
  • amr_samadisy
    There s an interesting article on the agile journal this month: http://agilejournal.com/articles/columns/articles/1223-requirements-come-second that basically
    Message 1 of 22 , Feb 23, 2009
      There's an interesting article on the agile journal this month:

      http://agilejournal.com/articles/columns/articles/1223-requirements-come-second

      that basically says that we really need to focus on getting a
      well-oiled development machine first before we work on big, grandiose
      things like business alignment.

      That resonates with my experience and the history of the Agile
      movement - especially XP.

      Thoughts?

      Amr
    • paymentexpert
      Nice Article! I just disagree that Agile methods don t care about requirements and business alignment. Just because they do it in a different way does not mean
      Message 2 of 22 , Feb 23, 2009
        Nice Article!
        I just disagree that Agile methods don't care about requirements and
        business alignment. Just because they do it in a different way does
        not mean they don't do it at all:

        http://www.jroller.com/sebastianKuebeck/entry/requirements_come_second

        Sebastian

        --- In extremeprogramming@yahoogroups.com, "amr_samadisy" <amr@...> wrote:
        >
        > There's an interesting article on the agile journal this month:
        >
        >
        http://agilejournal.com/articles/columns/articles/1223-requirements-come-second
        >
        > that basically says that we really need to focus on getting a
        > well-oiled development machine first before we work on big, grandiose
        > things like business alignment.
        >
        > That resonates with my experience and the history of the Agile
        > movement - especially XP.
        >
        > Thoughts?
        >
        > Amr
        >
      • Jonathon Golden
        A couple of thoughts. First of all I agree with Sebastian that the author s conclusion, Agile methods have had relatively little to say about requirements and
        Message 3 of 22 , Feb 23, 2009
          A couple of thoughts.

          First of all I agree with Sebastian that the author's conclusion, "Agile methods have had relatively little to say about requirements and business alignment" is false. A couple of examples: http://innovationgames.com/ and of course there's plenty on the subject here: http://blog.mountaingoatsoftware.com/.

          Second thought is what is to say that the these two processes (product management and development) can't be undergo agile transformations in parallel?

          - Jonathon





          ________________________________
          From: amr_samadisy <amr@...>
          To: extremeprogramming@yahoogroups.com
          Sent: Monday, February 23, 2009 6:54:45 AM
          Subject: [XP] doing things right or doing the right thing?


          There's an interesting article on the agile journal this month:

          http://agilejournal .com/articles/ columns/articles /1223-requiremen ts-come-second

          that basically says that we really need to focus on getting a
          well-oiled development machine first before we work on big, grandiose
          things like business alignment.

          That resonates with my experience and the history of the Agile
          movement - especially XP.

          Thoughts?

          Amr







          [Non-text portions of this message have been removed]
        • Adam Sroka
          ... I think the premise itself is false. Developing things which are a) useful to the customer and b) delivered in a timely fashion is the first goal. If you
          Message 4 of 22 , Feb 23, 2009
            On Mon, Feb 23, 2009 at 2:17 PM, Jonathon Golden <jgolden3@...> wrote:
            > A couple of thoughts.
            >
            > First of all I agree with Sebastian that the author's conclusion, "Agile
            > methods have had relatively little to say about requirements and business
            > alignment" is false. A couple of examples: http://innovationgames.com/ and
            > of course there's plenty on the subject here:
            > http://blog.mountaingoatsoftware.com/.
            >
            > Second thought is what is to say that the these two processes (product
            > management and development) can't be undergo agile transformations in
            > parallel?
            >

            I think the premise itself is false. Developing things which are a)
            useful to the customer and b) delivered in a timely fashion is the
            first goal. If you read the Agile Manifesto it is all about developers
            and business people working together to deliver working software.

            A separate and important issue is can we develop in a manner which is
            sustainable. This is where the remainder of the XP practices come into
            play. Delivering working software is the goal, but in order to do so
            consistently we need solid technical practices.

            The author refers to these to ideas as "doing the right things," and
            "doing things right". He proposes that "doing things right" must come
            before "doing the right things." However, I would counter that you
            cannot measure "doing things right" unless you are "doing the right
            things." How do you measure the quality of a piece of software that
            doesn't do anything? Who cares how well written your code is if it is
            never going to be used?

            Agile processes are designed to allow us to find out what the customer
            wants, deliver it in small portions and get immediate feedback, and
            then adjust and repeat. Solid technical practices are needed to make
            this sustainable, but without stories the process doesn't go anywhere.

            Furthermore, we get better at writing software by writing software.
            You aren't going to run off to some Tibetan monastery and come back a
            master coder. Learning how to do things the way XP suggests means
            starting with the stories, implementing the simplest thing that could
            possibly work with constant attention to quality, and improving
            continuously and incrementally.
          • Lior Friedman
            HI Amr ... At least on the surface, for me it kind of doesn t sit well with the SCRUM way. As I see it, Scrum has left many of the engineering practices out
            Message 5 of 22 , Feb 24, 2009
              HI Amr

              >That resonates with my experience and the history of the Agile
              >movement - especially XP.

              >Thoughts?



              At least on the surface, for me it kind of doesn't sit well with the SCRUM
              way.

              As I see it, Scrum has left many of the engineering practices out while
              focusing on management aspects.

              To me it would seem that scrum main focus is on business alignment and less
              on "oiling" the development machine.



              In light of this, the article may suggest that one should be extra careful
              when trying to implement scrum else we end in the "trap" zone.



              (BTW I'm still looking for a link to the full article.)



              Lior Friedman
              Blog - http://imistaken.blogspot.com <http://imistaken.blogspot.com/>







              [Non-text portions of this message have been removed]
            • amr_samadisy
              Good morning Lior, The easy one first, the link to the original Sloan Mngmt Rvw paper is here:
              Message 6 of 22 , Feb 24, 2009
                Good morning Lior,

                The easy one first, the link to the original Sloan Mngmt Rvw paper is
                here:
                http://sloanreview.mit.edu/the-magazine/articles/2007/fall/49102/avoidin\
                g-the-alignment-trap-in-it

                It is for purchase and costs about 6USD.

                I've been practicing both Scrum and XP for a long time also and while I
                agree with you that Scrum does address more management issues, and Scrum
                without supporting technical practices is similar. I would have to say
                that Scrum is inward focusing - the ScrumMaster as a blocker (anti)
                pattern.

                The Agile - and I say this loosely - practices for achieving alignment
                would be the product owner, onsite customer, and user stories. Are
                these sufficient? What I understand Allan is proposing is that they are
                not, they are only a beginning.

                Amr
                --- In extremeprogramming@yahoogroups.com, "Lior Friedman"
                <lfriedmal@...> wrote:
                >
                > HI Amr
                >
                > >That resonates with my experience and the history of the Agile
                > >movement - especially XP.
                >
                > >Thoughts?
                >
                >
                >
                > At least on the surface, for me it kind of doesn't sit well with the
                SCRUM
                > way.
                >
                > As I see it, Scrum has left many of the engineering practices out
                while
                > focusing on management aspects.
                >
                > To me it would seem that scrum main focus is on business alignment and
                less
                > on "oiling" the development machine.
                >
                >
                >
                > In light of this, the article may suggest that one should be extra
                careful
                > when trying to implement scrum else we end in the "trap" zone.
                >
                >
                >
                > (BTW I'm still looking for a link to the full article.)
                >
                >
                >
                > Lior Friedman
                > Blog - http://imistaken.blogspot.com <http://imistaken.blogspot.com/>
                >
                >
                >
                >
                >
                >
                >
                > [Non-text portions of this message have been removed]
                >
              • George Dinwiddie
                ... I think it s highly dependent on context, and the identification of the current worst problems. Ultimately both the right thing and things right have to
                Message 7 of 22 , Feb 24, 2009
                  amr_samadisy wrote:
                  > There's an interesting article on the agile journal this month:
                  >
                  > http://agilejournal.com/articles/columns/articles/1223-requirements-come-second
                  >
                  > that basically says that we really need to focus on getting a
                  > well-oiled development machine first before we work on big, grandiose
                  > things like business alignment.
                  >
                  > That resonates with my experience and the history of the Agile
                  > movement - especially XP.

                  I think it's highly dependent on context, and the identification of the
                  current worst problems. Ultimately both the right thing and things
                  right have to be done to excel.

                  I've generally found that working on both simultaneously is needed. One
                  or the other will proceed more quickly, however, because it's easier to
                  improve on that one in that particular context. Which one is easier can
                  vary between sister teams in the same organization.

                  When I see which is improving more quickly, I try to provide extra
                  effort on the other without abandoning the effort on this one.

                  - George

                  --
                  ----------------------------------------------------------------------
                  * George Dinwiddie * http://blog.gdinwiddie.com
                  Software Development http://www.idiacomputing.com
                  Consultant and Coach http://www.agilemaryland.org
                  ----------------------------------------------------------------------
                • davenicolette
                  Hi Amr, Thanks for pointing out the article. I read through it briefly and I m going to take a closer look at it later. First impression is not positive.
                  Message 8 of 22 , Feb 25, 2009
                    Hi Amr,

                    Thanks for pointing out the article. I read through it briefly and I'm
                    going to take a closer look at it later. First impression is not
                    positive.

                    Cheers,
                    Dave

                    --- In extremeprogramming@yahoogroups.com, "amr_samadisy" <amr@...> wrote:
                    >
                    > There's an interesting article on the agile journal this month:
                    >
                    >
                    http://agilejournal.com/articles/columns/articles/1223-requirements-come-second
                    >
                    > that basically says that we really need to focus on getting a
                    > well-oiled development machine first before we work on big, grandiose
                    > things like business alignment.
                    >
                    > That resonates with my experience and the history of the Agile
                    > movement - especially XP.
                    >
                    > Thoughts?
                    >
                    > Amr
                    >
                  • Jeff Grigg
                    I found it interesting. Very interesting. I bought ($6.50) and read the original MIT Sloan Management Review article, Avoiding the Alignment Trap in IT
                    Message 9 of 22 , Feb 25, 2009
                      I found it interesting. Very interesting.

                      I bought ($6.50) and read the original MIT Sloan Management Review
                      article, "Avoiding the Alignment Trap in IT"

                      http://sloanreview.mit.edu/the-magazine/articles/2007/fall/49102/avoiding-the-alignment-trap-in-it/?purchase=yes

                      I've been talking with our top management and sales staff about it. I
                      plan to use it to enhance our competitive advantage in agile
                      consulting. It could be the most important thing I've read in the
                      last year.

                      Thank you very much for pointing it out.
                      - jeff


                      --- "amr_samadisy" <amr@> wrote:
                      There's an interesting article on the agile journal this month:

                      http://agilejournal.com/articles/columns/articles/1223-requirements-come-second

                      that basically says that we really need to focus on getting a
                      well-oiled development machine first before we work on big, grandiose
                      things like business alignment.

                      That resonates with my experience and the history of the Agile
                      movement - especially XP.
                      Thoughts?
                      Amr
                    • davenicolette
                      I ve seen the quadrant thing elsewhere. Initially it s counterintuitive to think doing the wrong thing well serves an enterprise better than doing the right
                      Message 10 of 22 , Feb 25, 2009
                        I've seen the quadrant thing elsewhere. Initially it's
                        counterintuitive to think doing the wrong thing well serves an
                        enterprise better than doing the right thing badly, but it seems to be
                        the case.

                        That line of reasoning isn't what struck me negatively about the
                        article. In fact, I think you're quite right to expect you can use the
                        material to gain a competitive edge in agile consulting. The reason I
                        think you can is that the vast majority of IT organizations are
                        structured badly and are highly dysfunctional. You can introduce
                        improvements that can deliver significant benefits to them just by
                        "picking the low-hanging fruit."

                        What interests me more is the less-accessible fruit and the relatively
                        larger gains that could be made by picking it. The problems described
                        in the article can all be explained as structural problems in
                        organizations. "Alignment" isn't the solution. It's a band-aid. The
                        solution is "integration." The teams that build business applications
                        ought to be part of the business units that need the applications. The
                        whole matter of "requests" and so forth *is* the problem.

                        I don't disagree with the author's conclusions; I just think the
                        article represents limited thinking about the issues.

                        Cheers,
                        Dave


                        --- In extremeprogramming@yahoogroups.com, "Jeff Grigg"
                        <jeffgrigg@...> wrote:
                        >
                        > I found it interesting. Very interesting.
                        >
                        > I bought ($6.50) and read the original MIT Sloan Management Review
                        > article, "Avoiding the Alignment Trap in IT"
                        >
                        >
                        http://sloanreview.mit.edu/the-magazine/articles/2007/fall/49102/avoiding-the-alignment-trap-in-it/?purchase=yes
                        >
                        > I've been talking with our top management and sales staff about it. I
                        > plan to use it to enhance our competitive advantage in agile
                        > consulting. It could be the most important thing I've read in the
                        > last year.
                        >
                        > Thank you very much for pointing it out.
                        > - jeff
                        >
                        >
                        > --- "amr_samadisy" <amr@> wrote:
                        > There's an interesting article on the agile journal this month:
                        >
                        >
                        http://agilejournal.com/articles/columns/articles/1223-requirements-come-second
                        >
                        > that basically says that we really need to focus on getting a
                        > well-oiled development machine first before we work on big, grandiose
                        > things like business alignment.
                        >
                        > That resonates with my experience and the history of the Agile
                        > movement - especially XP.
                        > Thoughts?
                        > Amr
                        >
                      • Jeff Grigg
                        ... Like 75% of them, according to the articles. ... I think the articles support this interpretation. As... o 11% increase in sales from picking the
                        Message 11 of 22 , Feb 25, 2009
                          --- "davenicolette" <dnicolet@...> wrote:
                          > [...] The reason I think you can is that the vast majority
                          > of IT organizations are structured badly and are highly
                          > dysfunctional. [...]

                          Like 75% of them, according to the articles.

                          > What interests me more is the less-accessible fruit and
                          > the relatively larger gains that could be made by picking
                          > it. The problems described in the article can all be
                          > explained as structural problems in organizations.

                          I think the articles support this interpretation. As...
                          o 11% increase in sales from "picking the low-hanging fruit" / "doing
                          things right"
                          -vs-
                          o 35% increase in sales from doing it all -- both alignment and
                          effectiveness.

                          Doing the math suggests that the benefits gained by "harvesting the
                          less-accessible fruit" (after the low-hanging fruit) is an additional
                          21% increase in sales (21.6% computed) -- above and beyond the initial
                          gains.

                          BUT here's the important part:
                          Judging by the information they gathered, attempting the "high" fruit
                          (+21% sales) first will ACTUALLY put you in the "Alignment Trap"
                          causing you to LOSE 14% on sales -- annually. I think that's the
                          unintuitive part. ;->


                          > "Alignment" isn't the solution. [...] The solution is
                          > "integration."

                          The MIT Sloan Management Review article seems to emphasize these
                          points too.

                          > The teams that build business applications ought to be
                          > part of the business units that need the applications. [...]

                          WAIT...
                          The Sloan article specifically points out this approach as part of the
                          problem -- that it leads to the "Alignment Trap:"

                          "At National City, for instance, IT used to be closely aligned with
                          the company's business units. [...] McCartin reorganized IT to focus
                          not on business units but on core processes and capabilities, such as
                          lending and call centers."

                          "That may mean giving up, for the moment, some of the
                          division-specific applications [...], just as De Beers and National
                          City had to do."
                        • William E Caputo
                          ... http://agilejournal.com/articles/columns/articles/1223-requirements-come-second ... I found the article a great summary of the pressures on a software
                          Message 12 of 22 , Feb 25, 2009
                            --- In extremeprogramming@yahoogroups.com, "amr_samadisy" <amr@...> wrote:
                            >
                            > There's an interesting article on the agile journal this month:
                            >
                            >
                            http://agilejournal.com/articles/columns/articles/1223-requirements-come-second
                            >
                            > that basically says that we really need to focus on getting a
                            > well-oiled development machine first before we work on big, grandiose
                            > things like business alignment.

                            I found the article a great summary of the pressures on a software team.

                            I found the "alignment trap" concept particularly apt - looking
                            back over my XP/Agile adoption experiences, I'd say this trap is
                            always right in front of any "well-oiled machine" development team,
                            in that there's always pressure to do more, and the temptation to cave
                            in the quest for better alignment is great (especially for those team
                            members/leaders who don't have a hands-on perspective).

                            The saddest ones were those teams who were able start doing things
                            right, got traction, built trust and really started to reliably ship
                            quality code and then a year later had largely abandoned it all
                            because they botched getting aligned (usually by raising expectations
                            too high on what they could deliver).

                            Best,
                            Bill
                          • davenicolette
                            Maybe I should re-read the articles. It seems I may agree with them more than I realized! National City begged investors for $7 billion to stay afloat early in
                            Message 13 of 22 , Feb 25, 2009
                              Maybe I should re-read the articles. It seems I may agree with them
                              more than I realized!

                              National City begged investors for $7 billion to stay afloat early in
                              2008. By the end of 2008, they had been bought out. I don't think it
                              is a positive example.

                              The alignment trap at National City is not the same model as I'm
                              talking about when I say "integration." The agile development teams
                              were never employed directly by the lines of business. They always
                              worked for the IT department and "served" the lines of business.
                              Application development/support groups within the IT department were
                              supposed to be "aligned" with each line of business. It was exactly
                              the problem you describe; the alignment trap. It didn't work.

                              When I talk about "integration," I'm absolutely not talking about
                              "alignment."

                              Cheers,
                              Dave

                              --- In extremeprogramming@yahoogroups.com, "Jeff Grigg"
                              <jeffgrigg@...> wrote:
                              >
                              > --- "davenicolette" <dnicolet@> wrote:
                              > > [...] The reason I think you can is that the vast majority
                              > > of IT organizations are structured badly and are highly
                              > > dysfunctional. [...]
                              >
                              > Like 75% of them, according to the articles.
                              >
                              > > What interests me more is the less-accessible fruit and
                              > > the relatively larger gains that could be made by picking
                              > > it. The problems described in the article can all be
                              > > explained as structural problems in organizations.
                              >
                              > I think the articles support this interpretation. As...
                              > o 11% increase in sales from "picking the low-hanging fruit" / "doing
                              > things right"
                              > -vs-
                              > o 35% increase in sales from doing it all -- both alignment and
                              > effectiveness.
                              >
                              > Doing the math suggests that the benefits gained by "harvesting the
                              > less-accessible fruit" (after the low-hanging fruit) is an additional
                              > 21% increase in sales (21.6% computed) -- above and beyond the initial
                              > gains.
                              >
                              > BUT here's the important part:
                              > Judging by the information they gathered, attempting the "high" fruit
                              > (+21% sales) first will ACTUALLY put you in the "Alignment Trap"
                              > causing you to LOSE 14% on sales -- annually. I think that's the
                              > unintuitive part. ;->
                              >
                              >
                              > > "Alignment" isn't the solution. [...] The solution is
                              > > "integration."
                              >
                              > The MIT Sloan Management Review article seems to emphasize these
                              > points too.
                              >
                              > > The teams that build business applications ought to be
                              > > part of the business units that need the applications. [...]
                              >
                              > WAIT...
                              > The Sloan article specifically points out this approach as part of the
                              > problem -- that it leads to the "Alignment Trap:"
                              >
                              > "At National City, for instance, IT used to be closely aligned with
                              > the company's business units. [...] McCartin reorganized IT to focus
                              > not on business units but on core processes and capabilities, such as
                              > lending and call centers."
                              >
                              > "That may mean giving up, for the moment, some of the
                              > division-specific applications [...], just as De Beers and National
                              > City had to do."
                              >
                            • Tim Ottinger
                              I want to do good work well. I am not sure about ordering. Tim Ottinger http://agileinaflash.blogspot.com/ http://agileotter.blogspot.com/
                              Message 14 of 22 , Feb 25, 2009
                                I want to do good work well. I am not sure about ordering.

                                Tim Ottinger
                                http://agileinaflash.blogspot.com/
                                http://agileotter.blogspot.com/
                              • Adam Sroka
                                ... Me too. I reread the article, and it seems the important part is that *only* addressing the requirements process and ignoring the technical aspects won t
                                Message 15 of 22 , Feb 25, 2009
                                  On Wed, Feb 25, 2009 at 9:02 PM, Tim Ottinger <linux_tim@...> wrote:
                                  > I want to do good work well. I am not sure about ordering.
                                  >

                                  Me too.

                                  I reread the article, and it seems the important part is that *only*
                                  addressing the requirements process and ignoring the technical aspects
                                  won't leave you any better off. I think that is a valuable, if
                                  somewhat obvious, observation.

                                  We know that we need to address both. The author suggests that we need
                                  to address technical concerns first. I think that addressing either
                                  exclusively is likely not to be useful until you have addressed both.
                                  It seems to me that XP addresses both, and it does so every iteration.
                                  That would be the way I would prefer to do it.
                                • Lior Friedman
                                  Adam, ... I think the author goes one step further. He actually says that addressing the requirements bits only will leave you in a worse place. ... Actually
                                  Message 16 of 22 , Feb 25, 2009
                                    Adam,

                                    >I reread the article, and it seems the important part is that *only*
                                    >addressing the requirements process and ignoring the technical aspects
                                    >won't leave you any better off. I think that is a valuable, if
                                    >somewhat obvious, observation.

                                    I think the author goes one step further. He actually says that addressing
                                    the requirements bits only will leave you in a worse place.


                                    >We know that we need to address both. The author suggests that we need
                                    >to address technical concerns first. I think that addressing either
                                    >exclusively is likely not to be useful until you have addressed both.
                                    >It seems to me that XP addresses both, and it does so every iteration.
                                    >That would be the way I would prefer to do it.

                                    Actually according to the given numbers, addressing Technical concerns only
                                    end with an improvement. This resonate with my experience that there is real
                                    value in adopting technical practices only, (TDD, refactoring & CI).

                                    Of course the benefit of doing it all is much greater. However when starting
                                    out sometime I didn't have the privilege of doing it all.

                                    Lior



                                    [Non-text portions of this message have been removed]
                                  • Adam Sroka
                                    ... I m not impressed by numbers. They re too easy to get wrong. I m also not impressed by the notion of doing technical things right unless we have a means
                                    Message 17 of 22 , Feb 25, 2009
                                      On Wed, Feb 25, 2009 at 11:40 PM, Lior Friedman <lfriedmal@...> wrote:
                                      > Adam,
                                      >
                                      >>I reread the article, and it seems the important part is that *only*
                                      >>addressing the requirements process and ignoring the technical aspects
                                      >>won't leave you any better off. I think that is a valuable, if
                                      >>somewhat obvious, observation.
                                      >
                                      > I think the author goes one step further. He actually says that addressing
                                      > the requirements bits only will leave you in a worse place.
                                      >
                                      >>We know that we need to address both. The author suggests that we need
                                      >>to address technical concerns first. I think that addressing either
                                      >>exclusively is likely not to be useful until you have addressed both.
                                      >>It seems to me that XP addresses both, and it does so every iteration.
                                      >>That would be the way I would prefer to do it.
                                      >
                                      > Actually according to the given numbers, addressing Technical concerns only
                                      > end with an improvement. This resonate with my experience that there is real
                                      > value in adopting technical practices only, (TDD, refactoring & CI).
                                      >

                                      I'm not impressed by numbers. They're too easy to get wrong. I'm also
                                      not impressed by the notion of doing technical things "right" unless
                                      we have a means to deliver business value in the process.

                                      > Of course the benefit of doing it all is much greater. However when starting
                                      > out sometime I didn't have the privilege of doing it all.
                                      >

                                      I'm willing to accept that *only* getting the requirements right will
                                      *not* lead to increased productivity. That matches my expectation and
                                      my experience. I am not willing to accept that getting the technical
                                      parts all perfectly right without understanding what the customer
                                      wants is useful or productive either. That doesn't match my
                                      experience, doesn't make much sense, and contrary to what the author
                                      says is *not Agile*.
                                    • Lior Friedman
                                      Adam, ... I totally agree, I m probably more impressed with number the you are though (at least enough to make sure I ll check the raw data myself). ... I
                                      Message 18 of 22 , Feb 26, 2009
                                        Adam,

                                        >I'm not impressed by numbers. They're too easy to get wrong. I'm also
                                        >not impressed by the notion of doing technical things "right" unless
                                        >we have a means to deliver business value in the process.

                                        I totally agree, I'm probably more impressed with number the you are though
                                        (at least enough to make sure I'll check the raw data myself).



                                        >I'm willing to accept that *only* getting the requirements right will
                                        >*not* lead to increased productivity. That matches my expectation and
                                        >my experience. I am not willing to accept that getting the technical
                                        >parts all perfectly right without understanding what the customer
                                        >wants is useful or productive either. That doesn't match my
                                        >experience, doesn't make much sense, and contrary to what the author
                                        >says is *not Agile*.

                                        I don't think it's that black or white situation. In any given organization
                                        there is some sort of business understanding.

                                        While it may not be "perfect" it's still there. (I assume that companies
                                        which completely err on understanding their market have a very short life
                                        span)



                                        I think that if we simplify things the author claim that in a given
                                        situation, there is business value in improving the technical bits first.

                                        While there is a risk that investing the time in improving the business
                                        understanding first will actually put you in a worse position (or least wont
                                        be worth it).

                                        It the end however in order to excel you will need to do both.



                                        Lior



                                        [Non-text portions of this message have been removed]
                                      • Adam Sroka
                                        ... Since the end comes every week or two we better hurry up and get to both.
                                        Message 19 of 22 , Feb 26, 2009
                                          On Thu, Feb 26, 2009 at 12:28 AM, Lior Friedman <lfriedmal@...> wrote:
                                          > Adam,
                                          >
                                          >>I'm not impressed by numbers. They're too easy to get wrong. I'm also
                                          >>not impressed by the notion of doing technical things "right" unless
                                          >>we have a means to deliver business value in the process.
                                          >
                                          > I totally agree, I'm probably more impressed with number the you are though
                                          > (at least enough to make sure I'll check the raw data myself).
                                          >
                                          >>I'm willing to accept that *only* getting the requirements right will
                                          >>*not* lead to increased productivity. That matches my expectation and
                                          >>my experience. I am not willing to accept that getting the technical
                                          >>parts all perfectly right without understanding what the customer
                                          >>wants is useful or productive either. That doesn't match my
                                          >>experience, doesn't make much sense, and contrary to what the author
                                          >>says is *not Agile*.
                                          >
                                          > I don't think it's that black or white situation. In any given organization
                                          > there is some sort of business understanding.
                                          >
                                          > While it may not be "perfect" it's still there. (I assume that companies
                                          > which completely err on understanding their market have a very short life
                                          > span)
                                          >
                                          > I think that if we simplify things the author claim that in a given
                                          > situation, there is business value in improving the technical bits first.
                                          >
                                          > While there is a risk that investing the time in improving the business
                                          > understanding first will actually put you in a worse position (or least wont
                                          > be worth it).
                                          >
                                          > It the end however in order to excel you will need to do both.
                                          >

                                          Since "the end" comes every week or two we better hurry up and get to both.
                                        • Ron Jeffries
                                          Hello, Adam. On Thursday, February 26, 2009, at 2:49:06 AM, you ... True. But getting them right and then implementing them can. :) Ron Jeffries
                                          Message 20 of 22 , Feb 26, 2009
                                            Hello, Adam. On Thursday, February 26, 2009, at 2:49:06 AM, you
                                            wrote:

                                            > I'm willing to accept that *only* getting the requirements right will
                                            > *not* lead to increased productivity.

                                            True. But getting them right and then implementing them can. :)

                                            Ron Jeffries
                                            www.XProgramming.com
                                            www.xprogramming.com/blog
                                            Attend our CSM Plus Course!
                                            http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28
                                            Yesterday's code should be as good as we could make it yesterday.
                                            The fact that we know more today, and are more capable today,
                                            is good news about today, not bad news about yesterday.
                                          • J. B. Rainsberger
                                            ... I used to think this way, and at least in the small, I find it important to do both together. That might change at larger scales--I don t have much direct
                                            Message 21 of 22 , Mar 4, 2009
                                              On 2009-02-23, at 08:54 , amr_samadisy wrote:
                                              > There's an interesting article on the agile journal this month:
                                              >
                                              > http://agilejournal.com/articles/columns/articles/1223-requirements-come-second
                                              >
                                              > that basically says that we really need to focus on getting a
                                              > well-oiled development machine first before we work on big, grandiose
                                              > things like business alignment.
                                              >
                                              > That resonates with my experience and the history of the Agile
                                              > movement - especially XP.
                                              >
                                              > Thoughts?
                                              >
                                              I used to think this way, and at least in the small, I find it
                                              important to do both together. That might change at larger scales--I
                                              don't have much direct experience with anything above a few hundred
                                              people. I worry that when we focus on oiling the development
                                              mechanism, we start building a lot of legacy software--not legacy
                                              because of poor design, but legacy because of poor business fitness.

                                              Take care.
                                              ----
                                              J. B. (Joe) Rainsberger :: http://www.jbrains.ca
                                              Your guide to software craftsmanship
                                              JUnit Recipes: Practical Methods for Programmer Testing
                                              2005 Gordon Pask Award for contributions to Agile Software Practice
                                            • jmilunsky
                                              I actually posted a response to this on my own blog at blog.agilebuddy.com Basically, I don t think that it s that hard to address both simultaneously
                                              Message 22 of 22 , Mar 4, 2009
                                                I actually posted a response to this on my own blog at

                                                blog.agilebuddy.com

                                                Basically, I don't think that it's that hard to address both simultaneously especially if you're doing Scrum.

                                                Jack


                                                --- In extremeprogramming@yahoogroups.com, "J. B. Rainsberger" <jbrains762@...> wrote:
                                                >
                                                > On 2009-02-23, at 08:54 , amr_samadisy wrote:
                                                > > There's an interesting article on the agile journal this month:
                                                > >
                                                > > http://agilejournal.com/articles/columns/articles/1223-requirements-come-second
                                                > >
                                                > > that basically says that we really need to focus on getting a
                                                > > well-oiled development machine first before we work on big, grandiose
                                                > > things like business alignment.
                                                > >
                                                > > That resonates with my experience and the history of the Agile
                                                > > movement - especially XP.
                                                > >
                                                > > Thoughts?
                                                > >
                                                > I used to think this way, and at least in the small, I find it
                                                > important to do both together. That might change at larger scales--I
                                                > don't have much direct experience with anything above a few hundred
                                                > people. I worry that when we focus on oiling the development
                                                > mechanism, we start building a lot of legacy software--not legacy
                                                > because of poor design, but legacy because of poor business fitness.
                                                >
                                                > Take care.
                                                > ----
                                                > J. B. (Joe) Rainsberger :: http://www.jbrains.ca
                                                > Your guide to software craftsmanship
                                                > JUnit Recipes: Practical Methods for Programmer Testing
                                                > 2005 Gordon Pask Award for contributions to Agile Software Practice
                                                >
                                              Your message has been successfully submitted and would be delivered to recipients shortly.