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

Controversial Dzone post - 7 Agile Best Practices that You Don’t Need to Follow

Expand Messages
  • tomjcorcoran
    A fellow practitioner sent me this link http://agile.dzone.com/articles/7-agile-best-practices-you 7 Agile Best Practices that You Don t Need to Follow *
    Message 1 of 8 , Jun 17, 2013
    • 0 Attachment
      A fellow practitioner sent me this link
      http://agile.dzone.com/articles/7-agile-best-practices-you

      7 Agile Best Practices that You Don't Need to Follow
      * Test-Driven Development
      * Pair Programming
      * Emergent Design and Metaphor
      * Daily Standups
      * Collective Code Ownership
      * Writing All Requirements as Stories
      * Relying on a Product Owner

      The post made my blood boil and I just wanted to make the community aware of it. Dialogue is good but this kind if dis-information does it no service.
    • Adam Sroka
      See comments inline ... I am familiar with the evidence he presents here, and I won t argue with it. I am skeptical about the comments about coupling/cohesion
      Message 2 of 8 , Jun 17, 2013
      • 0 Attachment
        See comments inline

        On Jun 17, 2013 12:46 PM, "tomjcorcoran" <boardtc@...> wrote:
         

        A fellow practitioner sent me this link
        http://agile.dzone.com/articles/7-agile-best-practices-you

        7 Agile Best Practices that You Don't Need to Follow
        * Test-Driven Development


        I am familiar with the evidence he presents here, and I won't argue with it. I am skeptical about the comments about coupling/cohesion being negatively effected by TDD. I could see how that could be true if you weren't aware of some techniques or if you were using libraries and frameworks that don't align well with TDD (e.g. most of the popular ones.) 
         

        * Pair Programming


        Again, the research he quotes is familiar. However, in my experience most of the folks researching/debating pair programming don't know how to do it, spend too little time learning it, and use questionable methods to evaluate it. 

        Pair programming works quite well, and the only substitute for it is to do a lot of code reviews and design sessions, a lot of team building, and a lot of brown bag sessions or other group training. All of these things are much slower and less "in the moment" than pair programming. They will slow you down. 
         

        * Emergent Design and Metaphor


        No one *ever* said you can't think about or talk about architecture in the context of emergent design. In fact, we talk about it all the time. It is actually *impossible* to write software without having conversations about, for example, what language you are going to use, where you are going to deploy it, whether it is a web app or a desktop app, etc. All of those things are architecture. Also, things like security, performance, reuse, etc. -- all the crap that architects like to sit in their ivory towers and wave their hands about -- are constant elements of the conversation while developing software. 

        The difference is that in the context of TDD/emergent design we listen to the code and the tests and revisit our decisions continuously based on the information they reveal. So, the architecture we start with is often quite different than the one we imagine in the beginning. From what I have observed this is also true when we architect up front, except that we just pretend like we built what we said we would and there are no safeguards in place to help us make the transition effectively. 

        Regarding metaphor, I readily take the point that most people have no idea what it is or how to use it. I have been on a number of XP projects where no effective metaphor was ever found, but I have been on at least a couple where the metaphor was very powerful and led us in innovative directions. 

        I think it is worth the effort to look for the metaphor and discuss it all the time. However, just because you can't come up with a good band name doesn't mean people won't come to the show... as long as the music doesn't suck. 
         

        * Daily Standups


        If you talk to each other every day that is good. If you don't that is bad. If you need to organize a meeting to remind yourself of this then do so. 
         

        * Collective Code Ownership


        It is often true that not everyone on the team has the requisite knowledge to solve a particular problem. It is also true that when there is insufficient communication around the code people will misinterpret what others' code does and make mistakes. 

        If you are building software that needs to work and needs to be maintained, possibly even in the face of life changes and/or turnover, then these are problems worth solving. They are also quite solvable, and collective ownership, collaboration, and review are the keys to solving them. 

        * Writing All Requirements as Stories


        I agree that there are many different ways to capture requirements and stories are just one good way. In fact, I have seen stories used very poorly in organizations that were new to Agile, and more than once I have coached a team not to use stories (at least for the time being.) 

        However, the key thing to understand here is that in Agile we want to minimize the amount of document or tool based communication and focus on collaborating with customers and demonstrating working software. User stories, when applied appropriately, reinforce that. If you can find another way consistent with the manifesto values that is great. 
         

        * Relying on a Product Owner


        I agree that having a single responsible person is not necessary nor, in certain contexts, a good idea. The ideal is to have programmers talking directly with customers. However, that is not always practical and there are a number of stopgaps that can be effective. 

        That said, I have worked with some really good product owners whose vision added a lot of value. I would generally advise that most teams should have one product owner, or at least a senior member of the customer team who is chosen as the leader/tie-breaker. This is particularly important in corporate contexts where there are a lot of competing stakeholder interests, and in consumer facing products where it is necessary to consider both the needs of various customers and the opportunities in the market in order to prioritize features effectively. 
         

        The post made my blood boil and I just wanted to make the community aware of it. Dialogue is good but this kind if dis-information does it no service.


        I was actually expecting something a lot more awful than what I read. 

        Also, as an aside, I think I could run a project pretty effectively by doing *only* these seven things he says I don't have to do ;-) _
      • Charles Bradley - Professional Scrum Trai
        All my opinion: Typical project manager who has no idea of what he s talking about.  He s a nobody.  Consider your source.  I ve been told by others that
        Message 3 of 8 , Jun 17, 2013
        • 0 Attachment
          All my opinion:

          Typical project manager who has no idea of what he's talking about.  He's a nobody.  Consider your source.  I've been told by others that DZone is also a joke, but I have no direct knowledge of that.  (By the way, not all PM's are "know nothings", but there are definitely some out there who think that they know more than they do about technical subjects)

          This guy's articles are of the "shock jock" / argue against a straw man "type" that appear a lot in articles about Agile.  He's taking what appears to be(on the surface) a controversial stance to gain attention.

          There seems be a developing vocal minority of "Agile Haters" out there.  One might view this as a sign of success and/or progress for Agile.

          He now joins the same chorus with David Anderson. (or at least how David used to be -- haven't followed him much lately)

          Sadly, it seems that his shock jock tactics are working, because this is the 2nd time this link has been sent to me in a month.

          -------
          Charles Bradley
          Professional Scrum Trainer
          Scrum Coach-in-Chief
          ScrumCrazy.com




          From: tomjcorcoran <boardtc@...>
          To: scrumdevelopment@yahoogroups.com
          Sent: Monday, June 17, 2013 8:14 AM
          Subject: [scrumdevelopment] Controversial Dzone post - 7 Agile Best Practices that You Don’t Need to Follow

          A fellow practitioner sent me this link
          http://agile.dzone.com/articles/7-agile-best-practices-you

          7 Agile Best Practices that You Don't Need to Follow
          * Test-Driven Development
          * Pair Programming
          * Emergent Design and Metaphor
          * Daily Standups
          * Collective Code Ownership
          * Writing All Requirements as Stories
          * Relying on a Product Owner

          The post made my blood boil and I just wanted to make the community aware of it. Dialogue is good but this kind if dis-information does it no service.



          ------------------------------------

          To Post a message, send it to:  scrumdevelopment@...
          To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

          <*> To visit your group on the web, go to:
              http://groups.yahoo.com/group/scrumdevelopment/

          <*> Your email settings:
              Individual Email | Traditional

          <*> To change settings online go to:
              http://groups.yahoo.com/group/scrumdevelopment/join
              (Yahoo! ID required)

          <*> To change settings via email:
              scrumdevelopment-digest@yahoogroups.com
              scrumdevelopment-fullfeatured@yahoogroups.com

          <*> To unsubscribe from this group, send an email to:
              scrumdevelopment-unsubscribe@yahoogroups.com

          <*> Your use of Yahoo! Groups is subject to:
              http://docs.yahoo.com/info/terms/



        • Pierre Neis
          I don t understand the controversy? Different thinkers are welcome. In the meantime, if you measure what really happen in agile team... Kind regards,
          Message 4 of 8 , Jun 17, 2013
          • 0 Attachment
            I don't understand the controversy?
            Different thinkers are welcome.

            In the meantime, if you measure what really happen in agile team...


            Kind regards, cordialement, mit freundlichen Grüssen,

            Pierre E. Neis, psm, cspo, csp 
            Scrum/Lean Coach - Senior Management Consultant



            19 place Bleech |L-7610 Larochette | Luxembourg
            M: +352 661 727 867

            email:  pierre.neis@...
            web:    http://wecompany.wordpress.com/ http://thescrumcoach.wordpress.com/
            Meet with mehttp://meetwith.me/pierreneis
             

            about.me LinkedIn
            Contact me: Skype pierre.neis


            On 17 June 2013 19:46, Charles Bradley - Professional Scrum Trainer and Coach <chuck-lists2@...> wrote:
             

            All my opinion:

            Typical project manager who has no idea of what he's talking about.  He's a nobody.  Consider your source.  I've been told by others that DZone is also a joke, but I have no direct knowledge of that.  (By the way, not all PM's are "know nothings", but there are definitely some out there who think that they know more than they do about technical subjects)

            This guy's articles are of the "shock jock" / argue against a straw man "type" that appear a lot in articles about Agile.  He's taking what appears to be(on the surface) a controversial stance to gain attention.

            There seems be a developing vocal minority of "Agile Haters" out there.  One might view this as a sign of success and/or progress for Agile.

            He now joins the same chorus with David Anderson. (or at least how David used to be -- haven't followed him much lately)

            Sadly, it seems that his shock jock tactics are working, because this is the 2nd time this link has been sent to me in a month.

            -------
            Charles Bradley
            Professional Scrum Trainer
            Scrum Coach-in-Chief
            ScrumCrazy.com




            From: tomjcorcoran <boardtc@...>
            To: scrumdevelopment@yahoogroups.com
            Sent: Monday, June 17, 2013 8:14 AM
            Subject: [scrumdevelopment] Controversial Dzone post - 7 Agile Best Practices that You Don’t Need to Follow

            A fellow practitioner sent me this link
            http://agile.dzone.com/articles/7-agile-best-practices-you

            7 Agile Best Practices that You Don't Need to Follow
            * Test-Driven Development
            * Pair Programming
            * Emergent Design and Metaphor
            * Daily Standups
            * Collective Code Ownership
            * Writing All Requirements as Stories
            * Relying on a Product Owner

            The post made my blood boil and I just wanted to make the community aware of it. Dialogue is good but this kind if dis-information does it no service.



            ------------------------------------

            To Post a message, send it to:  scrumdevelopment@...
            To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

            <*> To visit your group on the web, go to:
                http://groups.yahoo.com/group/scrumdevelopment/

            <*> Your email settings:
                Individual Email | Traditional

            <*> To change settings online go to:
                http://groups.yahoo.com/group/scrumdevelopment/join
                (Yahoo! ID required)

            <*> To change settings via email:
                scrumdevelopment-digest@yahoogroups.com
                scrumdevelopment-fullfeatured@yahoogroups.com

            <*> To unsubscribe from this group, send an email to:
                scrumdevelopment-unsubscribe@yahoogroups.com

            <*> Your use of Yahoo! Groups is subject to:
                http://docs.yahoo.com/info/terms/




          • Ron Jeffries
            Hi Pierre, ... As far as I can tell, if you don t test your code inside the Sprint, it will have defects in it. The defects will be discovered later, and
            Message 5 of 8 , Jun 18, 2013
            • 0 Attachment
              Hi Pierre,

              On Jun 17, 2013, at 3:47 PM, Pierre Neis <pierreneis@...> wrote:

              I don't understand the controversy?
              Different thinkers are welcome.

              As far as I can tell, if you don't test your code inside the Sprint, it will have defects in it. The defects will be discovered later, and you'll have to fix many of them. This will interfere with your planned level of new work, which means that your apparent ability to deliver done software overstates reality.

              This amounts to lying to yourself about how you're doing.

              There's no way out of that that I can see.

              Similarly with refactoring. If you don't improve the design as you go, you will slow down and increase defects, which will slow you down more until you crash and burn.

              Most of the technical practices are not optional if you actually plan to do Scrum. There may be new ways in the future, but just now, there are not.

              Ron Jeffries
              I'm really pissed off by what people are passing off as "agile" these days.
              You may have a red car, but that does not make it a Ferrari.
                -- Steve Hayes

            • Laurent Bossavit
              Hi Charles, ... Agreed, as far as this one article is concerned. The title is pure link-bait, and betrayed almost immediately in the first section which
              Message 6 of 8 , Jun 19, 2013
              • 0 Attachment
                Hi Charles,

                > This guy's articles are of the "shock jock" / argue against a straw man "type" that appear a lot in articles about Agile. He's taking what appears to be(on the surface) a controversial stance to gain attention.

                Agreed, as far as this one article is concerned.

                The title is pure link-bait, and betrayed almost immediately in the first section which weasels around a lukewarm condemnation of TDD - "if you like it, do it" - as if this were a matter of fashion.

                The section on pair programming contains at least one blatant distortion:

                ..."one study (Vanhanen and Lassenius 2007) found that people only pair between 1.5 and 4 hours a day on average"...

                The paper actually says something else (that typical pairing sessions last 1.5-4h; that does not preclude multiple sessions in a day).

                The rest is of even lower caliber - at least the first two sections introduce some evidence, though quite selective; the remaining sessions come across as padding, being much shorter and no more substantial than a statement of the author's opinions and prejudices.

                Cheers,
                Laurent
              • Charles Bradley - Professional Scrum Trai
                Well put, Laurent, agreed.  There are numerous other problems with the article, too -- I was just summarizing.  :-) Not worth my time to refute each idiotic
                Message 7 of 8 , Jun 19, 2013
                • 0 Attachment
                  Well put, Laurent, agreed.  There are numerous other problems with the article, too -- I was just summarizing.  :-)

                  Not worth my time to refute each idiotic statement he makes.

                  -------
                  Charles Bradley
                  Professional Scrum Trainer
                  Scrum Coach-in-Chief
                  ScrumCrazy.com




                  From: Laurent Bossavit <laurent@...>
                  To: scrumdevelopment@yahoogroups.com
                  Sent: Wednesday, June 19, 2013 4:34 AM
                  Subject: Re: [scrumdevelopment] Controversial Dzone post - 7 Agile Best Practices that You Don’t Need to Follow

                  Hi Charles,

                  > This guy's articles are of the "shock jock" / argue against a straw man "type" that appear a lot in articles about Agile.  He's taking what appears to be(on the surface) a controversial stance to gain attention.

                  Agreed, as far as this one article is concerned.

                  The title is pure link-bait, and betrayed almost immediately in the first section which weasels around a lukewarm condemnation of TDD - "if you like it, do it" - as if this were a matter of fashion.

                  The section on pair programming contains at least one blatant distortion:

                    ..."one study (Vanhanen and Lassenius 2007) found that people only pair between 1.5 and 4 hours a day on average"...

                  The paper actually says something else (that typical pairing sessions last 1.5-4h; that does not preclude multiple sessions in a day).

                  The rest is of even lower caliber - at least the first two sections introduce some evidence, though quite selective; the remaining sessions come across as padding, being much shorter and no more substantial than a statement of the author's opinions and prejudices.

                  Cheers,
                  Laurent



                  ------------------------------------

                  To Post a message, send it to:  scrumdevelopment@...
                  To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

                  <*> To visit your group on the web, go to:
                      http://groups.yahoo.com/group/scrumdevelopment/

                  <*> Your email settings:
                      Individual Email | Traditional

                  <*> To change settings online go to:
                      http://groups.yahoo.com/group/scrumdevelopment/join
                      (Yahoo! ID required)

                  <*> To change settings via email:
                      scrumdevelopment-digest@yahoogroups.com
                      scrumdevelopment-fullfeatured@yahoogroups.com

                  <*> To unsubscribe from this group, send an email to:
                      scrumdevelopment-unsubscribe@yahoogroups.com

                  <*> Your use of Yahoo! Groups is subject to:
                      http://docs.yahoo.com/info/terms/



                • Jeff M.
                  Please submit any free related events to us via the link below, and they will be listed on our facebook feed and our events section of our website.Thanks.
                  Message 8 of 8 , Jun 21, 2013
                  • 0 Attachment
                    Please submit any free related events to us via the link below, and they will be listed on our facebook feed and our events section of our website.
                    Thanks.

                    http://freescrum.com/add-something/

                  Your message has been successfully submitted and would be delivered to recipients shortly.