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

Technical quality advocator

Expand Messages
  • Inanc Gumus
    As a SM, I advocate about technical quality standards to the team. But, most of the team members usually resist this kind of actions. They take a more
    Message 1 of 24 , Oct 1, 2009
    • 0 Attachment
      As a SM, I advocate about technical quality standards to the team. But, most of the team members usually resist this kind of actions. They take a more pragmatic attitude for the story goals. They say: "it is good enough for now, if that defect makes the system down, or decrease its performance then we can handle it that moment".

      What do you think about this? If a team tries to deliver high priority work ASAP by deferring the mediocre technical defects to later; should that work be accepted?
    • Kurt Häusler
      Excellent question. Normally the PO decides whether to accept such work, and if the work fulfils the requirements without any visible defects he will accept
      Message 2 of 24 , Oct 1, 2009
      • 0 Attachment
        Excellent question. Normally the PO decides whether to accept such work,
        and if the work fulfils the requirements without any visible defects he
        will accept it. I kind of think it is important to track things like
        technical debt, and make such issues visible to the PO and/or customer.
        This helps them get a better idea of the true state of things.

        I read an interesting blog article yesterday about it:

        http://theagileexecutive.com/2009/09/29/technical-debt-on-your-balance-sheet/

        QA people should also play a role here. Unfortunatley most QA people are in
        reality merely QC people. They just run tests that show that the software
        fulfils its requirements without any visible defects, and that is the
        limits to their definition of quality. In effect big balls of mud are
        judged to be quality software simply because they do what the customer
        wants! Issues such as maintainability etc are ignored by testing-obsessed
        "QA" people and I consider that incompetant.

        Another interesting idea is the Gilb's "Real QA Manifesto". This is an
        attempt to encourage QA people to concentrate just as much on software
        quality as they do on acceptance testing.

        http://www.gilb.com/Real+QA+Manifesto&structure=Community+Pages

        Traditional teams had managers that concentrated on scheduling and
        delegated quality to a secondary management role. Agile teams have the
        advantage of simplified scheduling that the team itself can take on. This
        opens up a nice gap for quality management to step up and become a primary
        management role in agile teams, focussing just as much on internal quality
        as tests. Especially when the team is not an agile
        dream team with 10 years experience with XP practices, such teams can
        probably keep a handle on TD themselves. But I suspect most average scrum
        teams could really do with some more leadership in the area of internal
        quality.

        On Thu, Oct 01, 2009 at 09:09:34AM -0000, Inanc Gumus wrote:
        > As a SM, I advocate about technical quality standards to the team. But, most of the team members usually resist this kind of actions. They take a more pragmatic attitude for the story goals. They say: "it is good enough for now, if that defect makes the system down, or decrease its performance then we can handle it that moment".
        >
        > What do you think about this? If a team tries to deliver high priority work ASAP by deferring the mediocre technical defects to later; should that work be accepted?
        >
      • JackM
        IMHO, this is a really bad attitude. Now let me clarify. I realize in many situations, one can t fix all bugs for whatever reason that s not practical.
        Message 3 of 24 , Oct 1, 2009
        • 0 Attachment
          IMHO, this is a really bad attitude. Now let me clarify. I realize in many situations, one can't fix all bugs for whatever reason that's not practical. However, the team needs to agree on their goals for the definition of done. And teams should strive to meet those goals. If it means that you're going to leave all low priority bugs fine, that's your definition fine - BUT you must understand that even small inconspicuous bugs starts to build technical debt into your codebase that in time will drive the team into a corner and will be forced to BEGIN AGAIN.

          That's why it's important that you refactor whenever you can (preferably all the time), You have extensive suites of unit tests, automated functional tests, you pair program, do code reviews etc. If you set the quality bar high it pays off in spades. Short term pain for long term gain.

          Jack
          blog.agilebuddy.com
          twitter.com/agilebuddy (for daily references to Agile articles, blogs, and more)


          --- In scrumdevelopment@yahoogroups.com, "Inanc Gumus" <inanc.gumus@...> wrote:
          >
          > As a SM, I advocate about technical quality standards to the team. But, most of the team members usually resist this kind of actions. They take a more pragmatic attitude for the story goals. They say: "it is good enough for now, if that defect makes the system down, or decrease its performance then we can handle it that moment".
          >
          > What do you think about this? If a team tries to deliver high priority work ASAP by deferring the mediocre technical defects to later; should that work be accepted?
          >
        • banshee858
          ... You are letting them off easy... I would suggest try to understand why good enough for now is the prevalent attitude on the Team. Ask around and see
          Message 4 of 24 , Oct 1, 2009
          • 0 Attachment
            >
            > As a SM, I advocate about technical quality standards to the team. But, most of the team
            > members usually resist this kind of actions. They take a more pragmatic attitude for the
            > story goals. They say: "it is good enough for now, if that defect makes the system down, or
            > decrease its performance then we can handle it that moment".
            >
            > What do you think about this? If a team tries to deliver high priority work ASAP by deferring
            > the mediocre technical defects to later; should that work be accepted?
            >
            You are letting them off easy...

            I would suggest try to understand why "good enough for now" is the prevalent attitude on the Team. Ask around and see what answers come up, then you can try to address the real issue rather than harass people about writing unit tests. No one will think about technical quality until this other factor has been removed or minimized.

            Carlton
          • Inanc Gumus
            Hello Carlton, ... attitude on the Team. Ask around and see what answers come up, then you can try to address the real issue rather than harass people about
            Message 5 of 24 , Oct 1, 2009
            • 0 Attachment
              Hello Carlton,
              --- In scrumdevelopment@yahoogroups.com, "banshee858" <cnett858@...> wrote:
              > You are letting them off easy...
              >
              > I would suggest try to understand why "good enough for now" is the prevalent
              attitude on the Team. Ask around and see what answers come up, then you can try
              to address the real issue rather than harass people about writing unit tests.
              No one will think about technical quality until this other factor has been
              removed or minimized.
              >

              Unit testing is not an issue. It is done here. But the real question is about
              something else:

              PO gets what he wants, but something technical about the story that may blow up
              the system sooner or later is not get discussed with PO. PO thinks as he gets what he
              wants, may also knows about the delivered story may blow up the system sometime, but he needs it now, and he accepts it. Does a SM should prevent this from happening?
              Cause we all know that business people are eager to get something done even if it is low on technical quality but high on business value. And they may not be aware of the
              consequences of rewriting even it is discussed.

              Also, if the team does not keep the product as an agile product which evolves
              rather than rewrites (business value zero reworks), should someone who is more
              experienced help the team members? Like a technical coach, but not a architect
              in an ivory tower...
            • victor oliveira
              First of all, the SM must be committed to transparency.To me, the decision of going live with a half-baked cookie is a real life decision, and many times a
              Message 6 of 24 , Oct 1, 2009
              • 0 Attachment
                First of all, the SM must be committed to transparency.
                To me, the decision of going live with a half-baked cookie is a real life decision, and many times a difficult one.

                What I think cannot happen is having people not knowing about the problems.
                The stakeholders should know about it, and I have seen many times the PO withholding this kind of information.
                The SM must make the choice transparent to the stakeholders, and strive for an understanding of the risks involved.

                Best Regards,
                Victor Hugo de Oliveira

                Scrum & Agile Blog
                http://csvo.wordpress.com

                Concrete Solutions
                new edition: http://www.concretesolutions.com.br/index_eng/

                On Thu, Oct 1, 2009 at 1:25 PM, Inanc Gumus <inanc.gumus@...> wrote:
                 

                Hello Carlton,
                --- In scrumdevelopment@yahoogroups.com, "banshee858" <cnett858@...> wrote:
                > You are letting them off easy...
                >
                > I would suggest try to understand why "good enough for now" is the prevalent
                attitude on the Team. Ask around and see what answers come up, then you can try
                to address the real issue rather than harass people about writing unit tests.
                No one will think about technical quality until this other factor has been
                removed or minimized.
                >

                Unit testing is not an issue. It is done here. But the real question is about
                something else:

                PO gets what he wants, but something technical about the story that may blow up
                the system sooner or later is not get discussed with PO. PO thinks as he gets what he
                wants, may also knows about the delivered story may blow up the system sometime, but he needs it now, and he accepts it. Does a SM should prevent this from happening?
                Cause we all know that business people are eager to get something done even if it is low on technical quality but high on business value. And they may not be aware of the

                consequences of rewriting even it is discussed.

                Also, if the team does not keep the product as an agile product which evolves
                rather than rewrites (business value zero reworks), should someone who is more
                experienced help the team members? Like a technical coach, but not a architect
                in an ivory tower...




                --

              • Ron Jeffries
                Hello, Inanc. On Thursday, October 1, 2009, at 5:09:34 AM, you ... In simple terms, the team has a bad definition of done, or is not living up to the
                Message 7 of 24 , Oct 1, 2009
                • 0 Attachment
                  Hello, Inanc. On Thursday, October 1, 2009, at 5:09:34 AM, you
                  wrote:

                  > As a SM, I advocate about technical quality standards to the
                  > team. But, most of the team members usually resist this kind of
                  > actions. They take a more pragmatic attitude for the story goals.
                  > They say: "it is good enough for now, if that defect makes the
                  > system down, or decrease its performance then we can handle it that moment".

                  > What do you think about this? If a team tries to deliver high
                  > priority work ASAP by deferring the mediocre technical defects to
                  > later; should that work be accepted?

                  In simple terms, the team has a bad definition of done, or is not
                  living up to the definition they have.

                  The more interesting question is why. What is making them value
                  shoddy work?

                  Ron Jeffries
                  www.XProgramming.com
                  www.xprogramming.com/blog
                  If you want to garden, you have to bend down and touch the soil.
                  Gardening is a practice, not an idea.
                  -- Thich Nhat Hanh
                • Inanc Gumus
                  Hello Ron, ... I asked this to the team, and they said: delivering something which business puts a very high value is most important . They say, in a future
                  Message 8 of 24 , Oct 1, 2009
                  • 0 Attachment
                    Hello Ron,
                    --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
                    > In simple terms, the team has a bad definition of done, or is not
                    > living up to the definition they have.
                    >
                    > The more interesting question is why. What is making them value
                    > shoddy work?
                    >
                    > Ron Jeffries
                    >

                    I asked this to the team, and they said: "delivering something which business puts a very high value is most important". They say, in a future time after the pressure decreases (which i think will never happen), they say they would be more quality-driven.

                    They don't see the stories as a chance to improve their architectures. Rather, when a story can be accomplished by doing a work-around solution in the system, they do that so. So, they're increasing their defect rates consciously.

                    Also, the team is trying to learn new knowledge about the technologies which they seem are valuable. This increases the re-work rate because they're doing something wrong at the 1st, 2nd time, and then they're thinking to re-write those parts from the begin again. They're mostly doing minor refactorings (like changing variable/method names etc), not doing something like evolving the architecture step by step.
                  • Inanc Gumus
                    Hello Victor, ... I agree. Can we come to a conclusion from what you have written: SM should strive for an understanding of the risk involved to the all
                    Message 9 of 24 , Oct 2, 2009
                    • 0 Attachment
                      Hello Victor,
                      --- In scrumdevelopment@yahoogroups.com, victor oliveira <victor.oliveira@...> wrote:
                      >
                      > First of all, the SM must be committed to transparency.To me, the decision
                      > of going live with a half-baked cookie is a real life decision, and many
                      > times a difficult one.
                      >
                      > What I think cannot happen is having people not knowing about the problems.
                      > The stakeholders should know about it, and I have seen many times the PO
                      > withholding this kind of information.
                      > The SM must make the choice transparent to the stakeholders, and strive for
                      > an understanding of the risks involved.
                      >
                      > Best Regards,
                      > Victor Hugo de Oliveira
                      >

                      I agree. Can we come to a conclusion from what you have written: SM should strive for an understanding of the risk involved to the all parties (stakeholders etc) even PO is trying to withold the information?
                    • Adam Sroka
                      ... One of the things I like about the way that XP describes planning, vs the way that Scrum does, is that it acknowledges that planning is a game. It is a
                      Message 10 of 24 , Oct 2, 2009
                      • 0 Attachment
                        On Thu, Oct 1, 2009 at 11:54 PM, Inanc Gumus <inanc.gumus@...> wrote:
                        >
                        >
                        >
                        > Hello Ron,
                        >
                        > --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
                        > > In simple terms, the team has a bad definition of done, or is not
                        > > living up to the definition they have.
                        > >
                        > > The more interesting question is why. What is making them value
                        > > shoddy work?
                        > >
                        > > Ron Jeffries
                        > >
                        >
                        > I asked this to the team, and they said: "delivering something which business puts a very high value is most important". They say, in a future time after the pressure decreases (which i think will never happen), they say they would be more quality-driven.
                        >

                        One of the things I like about the way that XP describes planning, vs
                        the way that Scrum does, is that it acknowledges that planning is a
                        game. It is a game because the PO and the team have different concerns
                        (rightly.) The PO's primary concerns are business value and business
                        risk. The team's primary concerns should be technical risk and
                        quality.

                        It sounds like your team is more concerned with pleasing the PO than
                        with serving their own interests. Likely because they don't recognize
                        that they are responsible for more than just checking stuff off as
                        done.

                        > They don't see the stories as a chance to improve their architectures. Rather, when a story can be accomplished by doing a work-around solution in the system, they do that so. So, they're increasing their defect rates consciously.
                        >

                        You need to convince them that working this way in unacceptable.
                        Introducing defects doesn't serve the PO's interests or theirs. Time
                        has to be spent fixing those defects and that time can't be spent
                        developing new features. They are "robbing Peter to pay Paul," as the
                        cliche goes. It's going to be an uphill battle, but you need to
                        convince everyone concerned that quality is in their best interests.

                        > Also, the team is trying to learn new knowledge about the technologies which they seem are valuable. This increases the re-work rate because they're doing something wrong at the 1st, 2nd time, and then they're thinking to re-write those parts from the begin again. They're mostly doing minor refactorings (like changing variable/method names etc), not doing something like evolving the architecture step by step.
                        >

                        It's not an easy thing to do. It's not even easy for those of us who
                        have devoted years to learning to do it that way. To be effective at
                        it you first have to accept that it is valuable. Then you have to work
                        hard at it to make it work. You will fail. You will produce crap which
                        you will look back at later and say, "That is crap."

                        But, it is worth it. You don't just have to take my word on it. There
                        are folks around who have been doing it a lot longer than me, some who
                        learned the lessons a lot harder than I did. Unfortunately, your team
                        is going to have to learn for themselves, and that first means
                        accepting the need to change. That will hurt, no way around it.
                      • Ron Jeffries
                        Hello, Inanc. On Friday, October 2, 2009, at 2:54:16 AM, you ... What does your Product Owner think? In particular, does your Product Owner care: - Whether
                        Message 11 of 24 , Oct 2, 2009
                        • 0 Attachment
                          Hello, Inanc. On Friday, October 2, 2009, at 2:54:16 AM, you
                          wrote:

                          > I asked this to the team, and they said: "delivering something
                          > which business puts a very high value is most important". They
                          > say, in a future time after the pressure decreases (which i think
                          > will never happen), they say they would be more quality-driven.

                          What does your Product Owner think? In particular, does your Product
                          Owner care:

                          - Whether the software works?
                          - Whether future progress can be made as rapidly as today?

                          > They don't see the stories as a chance to improve their
                          > architectures. Rather, when a story can be accomplished by doing a
                          > work-around solution in the system, they do that so. So, they're
                          > increasing their defect rates consciously.

                          Defects increasing? How does the Product Owner feel about this?

                          > Also, the team is trying to learn new knowledge about the
                          > technologies which they seem are valuable. This increases the
                          > re-work rate because they're doing something wrong at the 1st, 2nd
                          > time, and then they're thinking to re-write those parts from the
                          > begin again. They're mostly doing minor refactorings (like
                          > changing variable/method names etc), not doing something like
                          > evolving the architecture step by step.

                          There's clearly waste here. I wonder why they are doing that. I
                          wonder what makes them think what they are doing is best.

                          Ron Jeffries
                          www.XProgramming.com
                          www.xprogramming.com/blog
                          The greatest mistake we make is living in constant fear that we will make one.
                          -- John Maxwell
                        • Ron Jeffries
                          Hello, Inanc. On Friday, October 2, 2009, at 3:00:27 AM, you ... Everyone should understand everything in an ideal world. But what s this about the PO
                          Message 12 of 24 , Oct 2, 2009
                          • 0 Attachment
                            Hello, Inanc. On Friday, October 2, 2009, at 3:00:27 AM, you
                            wrote:

                            > I agree. Can we come to a conclusion from what you have written:
                            > SM should strive for an understanding of the risk involved to the
                            > all parties (stakeholders etc) even PO is trying to withold the information?

                            Everyone should understand everything in an ideal world. But what's
                            this about the PO withholding information? If that's happening it is
                            probably your biggest problem.

                            Ron Jeffries
                            www.XProgramming.com
                            www.xprogramming.com/blog
                            A man hears what he wants to hear, and disregards the rest. -- Paul Simon
                          • JackM
                            What I suggest you do is the following. Setup a lunch and learn. During that hour, have them watch the google tech talk video by Ken Schwabber. He covers the
                            Message 13 of 24 , Oct 2, 2009
                            • 0 Attachment
                              What I suggest you do is the following.

                              Setup a lunch and learn. During that hour, have them watch the google tech talk video by Ken Schwabber. He covers the technical debt issue really really well in this video.

                              http://video.google.com/videoplay?docid=-7230144396191025011#

                              Hope this helps
                              Jack

                              --- In scrumdevelopment@yahoogroups.com, "Inanc Gumus" <inanc.gumus@...> wrote:
                              >
                              > Hello Ron,
                              > --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@> wrote:
                              > > In simple terms, the team has a bad definition of done, or is not
                              > > living up to the definition they have.
                              > >
                              > > The more interesting question is why. What is making them value
                              > > shoddy work?
                              > >
                              > > Ron Jeffries
                              > >
                              >
                              > I asked this to the team, and they said: "delivering something which business puts a very high value is most important". They say, in a future time after the pressure decreases (which i think will never happen), they say they would be more quality-driven.
                              >
                              > They don't see the stories as a chance to improve their architectures. Rather, when a story can be accomplished by doing a work-around solution in the system, they do that so. So, they're increasing their defect rates consciously.
                              >
                              > Also, the team is trying to learn new knowledge about the technologies which they seem are valuable. This increases the re-work rate because they're doing something wrong at the 1st, 2nd time, and then they're thinking to re-write those parts from the begin again. They're mostly doing minor refactorings (like changing variable/method names etc), not doing something like evolving the architecture step by step.
                              >
                            • extremeprogrammer
                              There s a whole bunch of different quality issues explicit and implicit in your post. Let s take the obvious quality problem of a defect. If there is a defect,
                              Message 14 of 24 , Oct 2, 2009
                              • 0 Attachment
                                There's a whole bunch of different quality issues explicit and implicit in your post.

                                Let's take the obvious quality problem of a defect. If there is a defect, then something that you've spent time doing does not deliver the value to the business that it was supposed to. In that case, you could have not done that piece of work, because the decision has evidently been made that the business can now do without it. How much more pragmatic can you be than not doing something that the business can do without? Next time, spend a bit more time deciding what is really essential for the next release and then do it, making sure, by necessity, that everything you do works because everything is now essential.

                                Now let's think about internal quality issues. This one is actually harder for me. I like high quality code (by my definition of quality). When I produce and work with good quality code, I feel I'm doing a good job and that I can respond to the business needs faster and more reliably. Many people believe something different. I'm no longer interested in arguing with those people. They make their own hell and for the past seven or eight years I have arranged not to have to join them in it. I'm sure others will offer different advice on this one.

                                Finally, I am really tired of people doing and being payed for crap work that doesn't do what is needed and then saying they are being 'pragmatic', often at the same time complaining about the lack of quality in stuff that they depend on (open-source software, for example). This is not pragmatic; merely inadequate.

                                Regards,

                                Lance

                                --- In scrumdevelopment@yahoogroups.com, "Inanc Gumus" <inanc.gumus@...> wrote:
                                >
                                > As a SM, I advocate about technical quality standards to the team. But, most of the team members usually resist this kind of actions. They take a more pragmatic attitude for the story goals. They say: "it is good enough for now, if that defect makes the system down, or decrease its performance then we can handle it that moment".
                                >
                                > What do you think about this? If a team tries to deliver high priority work ASAP by deferring the mediocre technical defects to later; should that work be accepted?
                                >
                              • Malcolm Anderson
                                I advocate about technical quality standards to the team That way leads to madness. It s not your job to advocate about technical quality. Especially not
                                Message 15 of 24 , Oct 2, 2009
                                • 0 Attachment
                                  "I advocate about technical quality standards to the team"

                                  That way leads to madness.  It's not your job to advocate about technical quality. 
                                  Especially not technical quality "standards."

                                  One of the things that you are running into is the "above-average effect." 
                                  Roughly put, about 100% of the population believes that they are above average. 
                                  The bottom 25% tend to believe that they are in the top 65%

                                  Why bring this up?
                                  If you insinuate that your developers are not the superstars they think they are, it will not go well for you. 
                                  If however, you offer a suggestion when they are stuck, (and are, in the moment) asking for your suggestion, then, at that moment, your team *may* be interested in improving their abilities. 

                                  At that moment.

                                  Malcolm Anderson
                                  Agile Coach for Hire


                                  On Thu, Oct 1, 2009 at 4:09 AM, Inanc Gumus <inanc.gumus@...> wrote:

                                  As a SM, I advocate about technical quality standards to the team. But, most of the team members usually resist this kind of actions. They take a more pragmatic attitude for the story goals. They say: "it is good enough for now, if that defect makes the system down, or decrease its performance then we can handle it that moment".

                                  What do you think about this? If a team tries to deliver high priority work ASAP by deferring the mediocre technical defects to later; should that work be accepted?


                                • George Dinwiddie
                                  ... These two sentences tell me something. They tell me that you re not communicating with the team members in a way that entices them to follow. You ve
                                  Message 16 of 24 , Oct 2, 2009
                                  • 0 Attachment
                                    Inanc Gumus wrote:
                                    > As a SM, I advocate about technical quality standards to the team.
                                    > But, most of the team members usually resist this kind of actions.

                                    These two sentences tell me something. They tell me that you're not
                                    communicating with the team members in a way that entices them to
                                    follow. You've received many responses about why the team /should/ care
                                    more about the technical quality, but I'm not convinced that these
                                    responses will help you communicate that care to the team.

                                    Instead, I suggest looking at Dale Emery's "Resistance as a Resource"
                                    material on dhemery.com It's not easy to do what you want to do, but I
                                    think that might help.

                                    - George

                                    --
                                    ----------------------------------------------------------------------
                                    * George Dinwiddie * http://blog.gdinwiddie.com
                                    Software Development http://www.idiacomputing.com
                                    Consultant and Coach http://www.agilemaryland.org
                                    ----------------------------------------------------------------------
                                  • Inanc Gumus
                                    Hello Ron, ... Do you mean that all stakeholders should be informed about that PO is witholding some information?
                                    Message 17 of 24 , Oct 7, 2009
                                    • 0 Attachment
                                      Hello Ron,
                                      --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
                                      > Everyone should understand everything in an ideal world. But what's
                                      > this about the PO withholding information? If that's happening it is
                                      > probably your biggest problem.
                                      >
                                      > Ron Jeffries

                                      Do you mean that all stakeholders should be informed about that PO is witholding some information?
                                    • Inanc Gumus
                                      Hello Lance, ... I didn t understand what do you mean here. Do you mean: Business wants something and doing defected work giving them nothing? ... My original
                                      Message 18 of 24 , Oct 7, 2009
                                      • 0 Attachment
                                        Hello Lance,
                                        --- In scrumdevelopment@yahoogroups.com, "extremeprogrammer" <LanceWalton@...> wrote:
                                        > Let's take the obvious quality problem of a defect. If there is a defect, then something that you've spent time doing does not deliver the value to the business that it was supposed to. In that case, you could have not done that piece of work, because the decision has evidently been made that the business can now do without it.

                                        I didn't understand what do you mean here. Do you mean: Business wants something and doing defected work giving them nothing?


                                        > Now let's think about internal quality issues. This one is actually harder for me. I like high quality code (by my definition of quality). When I produce and work with good quality code, I feel I'm doing a good job and that I can respond to the business needs faster and more reliably. Many people believe something different. I'm no longer interested in arguing with those people. They make their own hell and for the past seven or eight years I have arranged not to have to join them in it. I'm sure others will offer different advice on this one.
                                        >

                                        My original question actually is: Who should coach the team to produce quality code? If there is no one, than if the whole team believes in pragmatism, what should we do if they produce defectful work?
                                      • Inanc Gumus
                                        Hello Malcolm, ... Then, who should coach them about producing working software (including quality)?
                                        Message 19 of 24 , Oct 7, 2009
                                        • 0 Attachment
                                          Hello Malcolm,
                                          --- In scrumdevelopment@yahoogroups.com, Malcolm Anderson <malcolm.b.anderson@...> wrote:
                                          >
                                          > "I advocate about technical quality standards to the team"
                                          >
                                          > That way leads to madness. It's not your job to advocate about technical
                                          > quality.
                                          > Especially not technical quality "standards."
                                          >
                                          > (...)
                                          >
                                          > Malcolm Anderson
                                          > Agile Coach for Hire

                                          Then, who should coach them about producing working software (including quality)?
                                        • Inanc Gumus
                                          Hello George, thanks for the to the point reference.
                                          Message 20 of 24 , Oct 7, 2009
                                          • 0 Attachment
                                            Hello George, thanks for the to the point reference.
                                          • Ron Jeffries
                                            Hello, Inanc. On Wednesday, October 7, 2009, at 4:53:05 AM, you ... I don t know what I d do because I don t know what is happening. I m just saying that if
                                            Message 21 of 24 , Oct 7, 2009
                                            • 0 Attachment
                                              Hello, Inanc. On Wednesday, October 7, 2009, at 4:53:05 AM, you
                                              wrote:

                                              > Hello Ron,
                                              > --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
                                              >> Everyone should understand everything in an ideal world. But what's
                                              >> this about the PO withholding information? If that's happening it is
                                              >> probably your biggest problem.
                                              >>
                                              >> Ron Jeffries

                                              > Do you mean that all stakeholders should be informed about that
                                              > PO is witholding some information?

                                              I don't know what I'd do because I don't know what is happening. I'm
                                              just saying that if the PO is withholding information, it's bad.

                                              Ron Jeffries
                                              www.XProgramming.com
                                              www.xprogramming.com/blog
                                              Keep away from people who try to belittle your ambitions. Small people
                                              always do that, but the really great make you feel that you, too, can
                                              become great. -- Mark Twain.
                                            • Ron Jeffries
                                              Hello, Inanc. On Wednesday, October 7, 2009, at 5:00:57 AM, you ... If no one is unhappy about current level of quality, it will continue. Does anyone care
                                              Message 22 of 24 , Oct 7, 2009
                                              • 0 Attachment
                                                Hello, Inanc. On Wednesday, October 7, 2009, at 5:00:57 AM, you
                                                wrote:

                                                > My original question actually is: Who should coach the team to
                                                > produce quality code? If there is no one, than if the whole team
                                                > believes in pragmatism, what should we do if they produce defectful work?

                                                If no one is unhappy about current level of quality, it will
                                                continue. Does anyone care besides you?

                                                Ron Jeffries
                                                www.XProgramming.com
                                                www.xprogramming.com/blog
                                                Learn from yesterday, live for today, hope for tomorrow.
                                                The important thing is to not stop questioning. --Albert Einstein
                                              • Kurt Häusler
                                                ... For the first question, you could hire a consultant to coach the team to improve their quality, or if you have strong QA people (not QC or testers), then
                                                Message 23 of 24 , Oct 7, 2009
                                                • 0 Attachment
                                                  On Wed, Oct 07, 2009 at 09:00:57AM -0000, Inanc Gumus wrote:
                                                  > My original question actually is: Who should coach the team to produce quality code? If there is no one, than if the whole team believes in pragmatism, what should we do if they produce defectful work?

                                                  For the first question, you could hire a consultant to coach the team to
                                                  improve their quality, or if you have strong QA people (not QC or testers),
                                                  then they could work with the developers to help with quality issues.

                                                  For the second question, I understand "defectful", or defective work to be work that
                                                  doesn't meet the requirements without visible defects. In this case, it
                                                  should simply not be accepted by the PO. If however by defectful you mean
                                                  software that does meet all acceptance criteria, without any visible
                                                  defects, but is a maintenance nightmare, and suffers from poor internal
                                                  quality, then that is where a strong QA person in a management role is
                                                  required. There is no scrum role for that, as I guess scrum assumes
                                                  quality-aware developers, so I would consider
                                                  them a team member as far as scrum goes.

                                                  But without such a role there is no incentive to clear away some of the
                                                  excess duct tape. The PO cannot even see it, so cannot be expected to be
                                                  concerned with anything beyond seeing his acceptance criteria being passed
                                                  without visible defects. A year later he might, when stories that used to
                                                  take a couple of hours end up taking a couple of weeks, but until then, if
                                                  the developers cannot get their duct tape aka technical debt aka crap in
                                                  order, then you need to hire someone who can help them with that.
                                                • extremeprogrammer
                                                  ... It will give the business something between a significant loss of money / reputation / lives / etc and a bit less than they wanted depending on the
                                                  Message 24 of 24 , Oct 7, 2009
                                                  • 0 Attachment
                                                    --- In scrumdevelopment@yahoogroups.com, "Inanc Gumus" <inanc.gumus@...> wrote:
                                                    >
                                                    > Hello Lance,
                                                    > --- In scrumdevelopment@yahoogroups.com, "extremeprogrammer" <LanceWalton@> wrote:
                                                    > > Let's take the obvious quality problem of a defect. If there is a defect, then something that you've spent time doing does not deliver the value to the business that it was supposed to. In that case, you could have not done that piece of work, because the decision has evidently been made that the business can now do without it.
                                                    >
                                                    > I didn't understand what do you mean here. Do you mean: Business wants something and doing defected work giving them nothing?

                                                    It will give the business something between a significant loss of money / reputation / lives / etc and "a bit less than they wanted" depending on the nature of the defect. In one case in my career, a defect actually saved a bank from a significant loss; this is probably not the way to bet though.

                                                    >
                                                    >
                                                    > > Now let's think about internal quality issues. This one is actually harder for me. I like high quality code (by my definition of quality). When I produce and work with good quality code, I feel I'm doing a good job and that I can respond to the business needs faster and more reliably. Many people believe something different. I'm no longer interested in arguing with those people. They make their own hell and for the past seven or eight years I have arranged not to have to join them in it. I'm sure others will offer different advice on this one.
                                                    > >
                                                    >
                                                    > My original question actually is: Who should coach the team to produce quality code? If there is no one, than if the whole team believes in pragmatism, what should we do if they produce defectful work?

                                                    They are not being pragmatic.

                                                    It is not necessarily their call to produce low quality code.

                                                    It is not at all their call to produce work that is defective according to the customer.

                                                    Before they can be taught to produce high quality code, they need to accept the possibility of and the merit in high quality work. Their insistence on 'pragmatism' suggests that they do not accept this. However, I know almost nothing about your situation; I could be wrong. I hope I am.

                                                    If the team wants to produce better work, and you have a way that produces better work, and they believe that you have a way that could produce better work, and if you have the inclination to teach them, then by all means, teach them.

                                                    If the team does not want to produce better work, then you will invest a lot of energy and probably suffer some stress with no benefit to anybody. It's up to the organisation what it wants to do with the team. It's up to you to decide whether you want to be a part of that team or not, assuming that this is not the only show in town.

                                                    Some disconnected thoughts follow...

                                                    Regarding some of the preconditions for quality, I wrote some of my thoughts about some of this a few months ago here: http://www.casualmiracles.com/blog/2009/06/22/demand-quality-you-get-what-you-ask-for/ - not particularly original stuff, I know, but maybe repetition will succeed where other approaches have yet to bear fruit.

                                                    For the small fraction of people who have a method that routinely produces the kind of good results with which many of the people on this list are familiar and which I describe in that article, it feels like occupying the lowest energy position possible - producing poorer results actually requires greater effort. For everybody else, it seems that achieving these kinds of results is like occupying a high energy position with slippery slopes all around.

                                                    Those in the 'small fraction' who have bothered to read this far probably know exactly what I'm talking about. Those in the larger fraction (not many of them in this group) will think that I'm talking nonsense, that I obviously don't work in the real world, that their situation is different, that they need to be pragmatic (for some definition of pragmatic that I don't understand), that I have a simplistic understanding of the problem, that I am arrogant (actually, they are right about that), etc. These people are unteachable until they become aware. They know not that they know not. Shun them.

                                                    Or.... maybe they have a point and it is I that am unaware. Could be. I hope not.

                                                    It seems to me that your team is more like the large fraction than the small fraction. However, I know almost nothing about your situation; I could be wrong. I hope I am.

                                                    Regards,

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