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

Re: [scrumdevelopment] Technical quality advocator

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