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

ScrumMaster only one trying to do Scrum

Expand Messages
  • Kerrie Valdiviezo
    If the ScrumMaster is supposed to enforce the Scrum Process but the rest of the Team disagrees with certain parts of the process...do we just go with that
    Message 1 of 19 , Mar 25, 2009
    • 0 Attachment
      If the ScrumMaster is supposed to enforce the Scrum Process but the rest of the Team disagrees with certain parts of the process...do we just go with that because it's a 'Team decision?' 

      I see that this particular team could use improvement mostly in communication and commitment.  However, if the team and product owner are happy with where the team is at and have no motivation for improvements...what next?  Do they no longer need retrospectives?  Do they no longer need a ScrumMaster?

      I see they have distractions...but when I have a conversation with them about that to find ways I can help, they insist that it's 'not that big of a deal'.
      -They work on stuff outside the project, but they are all comfortable with it when a team member does that...and so is the PO
      -they don't finish most of the stories in an iteration...but 80% of the stories are 80-90% done...so they and PO are satisfied with that
      -they pull in other stories mid iteration w/o first talking to rest of the team and sometimes the PO and yes...they and PO are all comfortable with that too. 
      these are some of the symptoms to the bigger problems, thats' what I think.

      Your thoughts?




    • patetobg
      The Scrum Master is supposed to guide the team, lead the daily standup and the retrospectives so that the team get the most out of these. From what you wrote
      Message 2 of 19 , Mar 25, 2009
      • 0 Attachment
        The Scrum Master is supposed to guide the team, lead the daily standup and the retrospectives so that the team get the most out of these.

        From what you wrote it seems that the team is happy the way it is. So if they do not want to understand the process and how things should be done, and after you have tried several times to teach them without any luck all you can do is either watch the release fail or speak with an upper level manager, the scrum coach (assuming you have one), etc. Any new process should get buy-in from the top of the organization so if the CEO does not understand the process you cannot expect to get a reasonable discussion with him/her about the issues that you see in that team.


        --- In scrumdevelopment@yahoogroups.com, Kerrie Valdiviezo <kerrie_valdiviezo@...> wrote:
        >
        > If the ScrumMaster is supposed to enforce the Scrum Process but the rest of the Team disagrees with certain parts of the process...do we just go with that because it's a 'Team decision?'�
        >
        > I see that this particular team could use improvement mostly in communication and commitment.� However, if the team and product owner are happy with where the team is at and have no motivation for improvements...what next?� Do they no longer need retrospectives?� Do they no longer need a ScrumMaster?
        >
        > I see they have distractions...but when I have a conversation with them about that to find ways I can help, they insist that it's 'not that big of a deal'.
        > -They work on stuff outside the project, but they are all comfortable with it when a team member does that...and so is the PO
        > -they don't finish most of the stories in an iteration...but 80% of the stories are 80-90% done...so they and PO are satisfied with that
        > -they pull in other stories mid iteration w/o first talking to rest of the team and sometimes the PO and yes...they and PO are all comfortable with that too.�
        > these are some of the symptoms to the bigger problems, thats' what I think.
        >
        > Your thoughts?
        >
      • woynam
        Simply put, they re not really doing Scrum...and they re comfortable with that. Mark
        Message 3 of 19 , Mar 25, 2009
        • 0 Attachment
          Simply put, they're not really doing Scrum...and they're comfortable with that.

          Mark


          --- In scrumdevelopment@yahoogroups.com, Kerrie Valdiviezo <kerrie_valdiviezo@...> wrote:
          >
          > If the ScrumMaster is supposed to enforce the Scrum Process but the rest of the Team disagrees with certain parts of the process...do we just go with that because it's a 'Team decision?' 
          >
          > I see that this particular team could use improvement mostly in communication and commitment.  However, if the team and product owner are happy with where the team is at and have no motivation for improvements...what next?  Do they no longer need retrospectives?  Do they no longer need a ScrumMaster?
          >
          > I see they have distractions...but when I have a conversation with them about that to find ways I can help, they insist that it's 'not that big of a deal'.
          > -They work on stuff outside the project, but they are all comfortable with it when a team member does that...and so is the PO
          > -they don't finish most of the stories in an iteration...but 80% of the stories are 80-90% done...so they and PO are satisfied with that
          > -they pull in other stories mid iteration w/o first talking to rest of the team and sometimes the PO and yes...they and PO are all comfortable with that too. 
          > these are some of the symptoms to the bigger problems, thats' what I think.
          >
          > Your thoughts?
          >
        • Plamen Balkanski
          I think the Scrum master is supposed to advocate for scrum. not sure about enforcing scrum.there should be some buy-in from the team, if not perhaps go back to
          Message 4 of 19 , Mar 25, 2009
          • 0 Attachment
            I think the Scrum master is supposed to advocate for scrum. not sure about enforcing scrum.
            there should be some buy-in from the team, if not perhaps go back to the start and ask them if they want to improve? if they do not want to you might be wasting your time. if they do then get them to agree on inspect and adapt and then improve retros. if there will be regular distractions (e.g. support work) try to timebox it in the sprint and make sure team does not exceed it. get the team to agree on definition of done. start with a single story and get them to do it. then let them accept more.
            i would say team decisions are good but not when you see that they contradict to scrum or generally introduce waste.
            sounds like PO does not understand his role as well. you may need to clarify to him what is meaningful progress and when to accept stories.
            hope this helps.

            Plamen Balkanski
            http://plamenbalkanski.blogspot.com/
            07912 780 927
            Charles Kettering  - "My interest is in the future because I am going to spend the rest of my life there."

            2009/3/25 Kerrie Valdiviezo <kerrie_valdiviezo@...>

            If the ScrumMaster is supposed to enforce the Scrum Process but the rest of the Team disagrees with certain parts of the process...do we just go with that because it's a 'Team decision?' 

            I see that this particular team could use improvement mostly in communication and commitment.  However, if the team and product owner are happy with where the team is at and have no motivation for improvements...what next?  Do they no longer need retrospectives?  Do they no longer need a ScrumMaster?

            I see they have distractions...but when I have a conversation with them about that to find ways I can help, they insist that it's 'not that big of a deal'.
            -They work on stuff outside the project, but they are all comfortable with it when a team member does that...and so is the PO
            -they don't finish most of the stories in an iteration...but 80% of the stories are 80-90% done...so they and PO are satisfied with that
            -they pull in other stories mid iteration w/o first talking to rest of the team and sometimes the PO and yes...they and PO are all comfortable with that too. 
            these are some of the symptoms to the bigger problems, thats' what I think.

            Your thoughts?





          • Xavier Quesada Allue
            Kerrie, When you put forward a situation like this to the list, you will probably get a lot of answers saying that if the team and PO think it s OK, then let
            Message 5 of 19 , Mar 25, 2009
            • 0 Attachment
              Kerrie,

              When you put forward a situation like this to the list, you will probably get a lot of answers saying that if the team and PO think it's OK, then let it be. And they are partly right, at least from the team/SM point of view. You might not be implementing Scrum correctly, but as long as you have clearly defined a Product Owner, and he/she understands his/her responsability, your hands are tied. Scrum is very simple: the responsibility of what is delivered lies with the PO. If the PO approves, then unfortunately for you, "all is well" (at least from the framework perspective). There is no such thing as saying "they only do 80-90% of stories but the PO is satisfied with that". The PO *defines the acceptance criteria*. At the end of the sprint, stories are either done or not done, and the PO is the only one who decides. This is why it's so critical to have a good Product Owner. (From reading your e-mail, it looks like your PO might need some coaching.)

              But in the meantime, you cannot (as SM) force change. Do as best as you can with the retrospectives. What you have to understand (or even better, Senior Management has to understand) is that this team is probably unproductive and risky. Or better put, it's less productive than it could be, and you are more at risk of not having a working product when your organization needs it than you could be. Whenever a team (or a person for that matter) says they don't need to improve, a warning light should go off in your head. *Something* is wrong there.

              Think about this: why do _you_ care, when everyone else (including most importantly the PO) doesn't? What sets you apart? Are you alone, or are there other people in the organization that think like you? (If you are alone, you might have higher quality standards than your organization... and while what I am going to say is very polemic, if your organization is surviving, you might be goldplating!).

              Hope it helps,
              Xavier


              On Wed, Mar 25, 2009 at 9:04 PM, Kerrie Valdiviezo <kerrie_valdiviezo@...> wrote:

              If the ScrumMaster is supposed to enforce the Scrum Process but the rest of the Team disagrees with certain parts of the process...do we just go with that because it's a 'Team decision?' 

              I see that this particular team could use improvement mostly in communication and commitment.  However, if the team and product owner are happy with where the team is at and have no motivation for improvements...what next?  Do they no longer need retrospectives?  Do they no longer need a ScrumMaster?

              I see they have distractions...but when I have a conversation with them about that to find ways I can help, they insist that it's 'not that big of a deal'.
              -They work on stuff outside the project, but they are all comfortable with it when a team member does that...and so is the PO
              -they don't finish most of the stories in an iteration...but 80% of the stories are 80-90% done...so they and PO are satisfied with that
              -they pull in other stories mid iteration w/o first talking to rest of the team and sometimes the PO and yes...they and PO are all comfortable with that too. 
              these are some of the symptoms to the bigger problems, thats' what I think.

              Your thoughts?





            • Roy Morien
              I guess the role of ScrumMaster becomes irrelevant once the team has voted with their feet to no longer do Scrum. What they are doing otherwise is not
              Message 6 of 19 , Mar 25, 2009
              • 0 Attachment
                I guess the role of ScrumMaster becomes irrelevant once the team has voted with their feet to no longer do Scrum. What they are doing otherwise is not particularly relevant, but it is not Scrum, so the ScrumMaster ceases to have a valid role.
                 
                The Scrum Master cannot be some sort of process fascist who can kick heads if people are not doing it 'right'.
                 
                I guess thia is, in a way, one of the problems of democratic and liberal systems. If the participants choose (as they are entitled to do) to throw off the yoke of freedom, and adopt a process that is command-and-control, punitive, planned and authoritarian etc. (sort of the Talebanization of software development) then so be it.
                 
                Perhaps I am overstating the case, though.
                 
                Regards,
                Roy Morien 
                 

                To: scrumdevelopment@yahoogroups.com
                From: kerrie_valdiviezo@...
                Date: Wed, 25 Mar 2009 13:04:22 -0700
                Subject: [scrumdevelopment] ScrumMaster only one trying to do Scrum

                If the ScrumMaster is supposed to enforce the Scrum Process but the rest of the Team disagrees with certain parts of the process...do we just go with that because it's a 'Team decision?' 

                I see that this particular team could use improvement mostly in communication and commitment.  However, if the team and product owner are happy with where the team is at and have no motivation for improvements. ..what next?  Do they no longer need retrospectives?  Do they no longer need a ScrumMaster?

                I see they have distractions. ..but when I have a conversation with them about that to find ways I can help, they insist that it's 'not that big of a deal'.
                -They work on stuff outside the project, but they are all comfortable with it when a team member does that...and so is the PO
                -they don't finish most of the stories in an iteration... but 80% of the stories are 80-90% done...so they and PO are satisfied with that
                -they pull in other stories mid iteration w/o first talking to rest of the team and sometimes the PO and yes...they and PO are all comfortable with that too. 
                these are some of the symptoms to the bigger problems, thats' what I think.

                Your thoughts?







                Let ninemsn property help. Need a new place to rent, share or buy?
              • Sarath Kummamuru
                Is the product getting delivered on time ? Is the quality of the product good? Are the release cycle goals that the top management is setting up being met.
                Message 7 of 19 , Mar 25, 2009
                • 0 Attachment
                  Is the product getting delivered on time ? Is the quality of the product good?
                  Are the release cycle goals that the top management is setting up being met.

                  Many times when teams donot do scrum they might still be achieving pretty good deliveries, with quality, etc.
                  Scrum surely can improve things further, but many time there might not be a motivation to improve further.

                  Many cases the motivation comes when the top management expectations, customer expecatations are not met.

                  What is the customer satisfaction (not just the PO) but the end customer satisfaction index?

                  Is your PO responsible for the product release and customer commitments?
                  What is the managements perspective about ROI that is being offered by the team, Is the team delivering enough value, with good quality in time?

                  These are real problems that any process would like to improve, so see if there are any impediments there. If there are you could use scrum to identify them and get the team to look at that perspective.

                  Other wise may be it is optimal to let the team fail before you try to advocate scrum (or worse try to enforce it).


                  thanks,
                  Sarath.



                  On Thu, Mar 26, 2009 at 1:34 AM, Kerrie Valdiviezo <kerrie_valdiviezo@...> wrote:

                  If the ScrumMaster is supposed to enforce the Scrum Process but the rest of the Team disagrees with certain parts of the process...do we just go with that because it's a 'Team decision?' 

                  I see that this particular team could use improvement mostly in communication and commitment.  However, if the team and product owner are happy with where the team is at and have no motivation for improvements...what next?  Do they no longer need retrospectives?  Do they no longer need a ScrumMaster?

                  I see they have distractions...but when I have a conversation with them about that to find ways I can help, they insist that it's 'not that big of a deal'.
                  -They work on stuff outside the project, but they are all comfortable with it when a team member does that...and so is the PO
                  -they don't finish most of the stories in an iteration...but 80% of the stories are 80-90% done...so they and PO are satisfied with that
                  -they pull in other stories mid iteration w/o first talking to rest of the team and sometimes the PO and yes...they and PO are all comfortable with that too. 
                  these are some of the symptoms to the bigger problems, thats' what I think.

                  Your thoughts?







                  --
                  Thanks,
                  Sarath.

                  Quad One Technologies | Mobile: +91 98490 05620 | Off: +91 40 2335 0221 | www.quadone.com
                • Ilja Preuß
                  The Scrummaster enforcing the process would be in direct conflict with the Agile Manifesto, as far as I can tell. There is a reason why the team members think
                  Message 8 of 19 , Mar 26, 2009
                  • 0 Attachment
                    The Scrummaster enforcing the process would be in direct conflict with
                    the Agile Manifesto, as far as I can tell. There is a reason why the
                    team members think they are good enough. Perhaps they really are. And
                    if not, they are clearly missing information. The role of the
                    Scrummaster then would be to make that information available and
                    facilitate the examination of the newly emerged problem.

                    But even if there isn't a problem, you might actually be able to help
                    the team find ways in which they *want* to improve. You don't need
                    problems to do a retrospective and be able to improve. Retrospectives
                    can as well be used to share newly learned things and make sure that
                    they don't get forgotten. That actually can be a lot of fun, give a
                    lot of energy and lead to stronger and more sustainable improvement
                    than "solving problems". Google for "Appreciative Retrospective" for a
                    possible format to use.

                    Hope this helps, Ilja

                    PS: And the team doesn't need to do Scrum to be able to benefit from a
                    "process facilitator".
                  • Greg Harisiades
                    Has the team been trained properly? Without the same level of training you ve had, they won t see the benefits of all the rituals that you see. Many
                    Message 9 of 19 , Mar 26, 2009
                    • 0 Attachment
                      Has the team been trained properly? Without the same level of training
                      you've had, they won't see the benefits of all the rituals that you see.

                      Many hyperproductive teams have trained all of their teams and are
                      certified ScrumMasters.


                      --- In scrumdevelopment@yahoogroups.com, Kerrie Valdiviezo
                      <kerrie_valdiviezo@...> wrote:
                      >
                      > If the ScrumMaster is supposed to enforce the Scrum Process but the
                      rest of the Team disagrees with certain parts of the process...do we
                      just go with that because it's a 'Team decision?'
                      >
                      > I see that this particular team could use improvement mostly in
                      communication and commitment. However, if the team and product owner
                      are happy with where the team is at and have no motivation for
                      improvements...what next? Do they no longer need retrospectives? Do
                      they no longer need a ScrumMaster?
                      >
                      > I see they have distractions...but when I have a conversation with
                      them about that to find ways I can help, they insist that it's 'not that
                      big of a deal'.
                      > -They work on stuff outside the project, but they are all comfortable
                      with it when a team member does that...and so is the PO
                      > -they don't finish most of the stories in an iteration...but 80% of
                      the stories are 80-90% done...so they and PO are satisfied with that
                      > -they pull in other stories mid iteration w/o first talking to rest of
                      the team and sometimes the PO and yes...they and PO are all comfortable
                      with that too.
                      > these are some of the symptoms to the bigger problems, thats' what I
                      think.
                      >
                      > Your thoughts?
                      >
                    • davenicolette
                      I hope this isn t the wrong venue to say things like this, but here goes: Scrum is a tool, not an end in itself. Our goal is not to enforce rules, but to
                      Message 10 of 19 , Mar 26, 2009
                      • 0 Attachment
                        I hope this isn't the wrong venue to say things like this, but here goes:

                        Scrum is a tool, not an end in itself. Our goal is not to enforce rules, but to deliver customer-defined value effectively. If the team isn't on board with the idea of adopting Scrum, then you may be able to approach the task of coaching them by avoiding Scrum buzzwords. Show them where their present mode of working includes waste, and suggest ways to minimize or eliminate that waste. You may have to show them how to connect the dots between the things they do and the results they achieve. Once they have experienced success with doing this, they will probably start doing it on their own.

                        Some teams respond well to training. In other cases, when you drop a large blob of training on top of a team, it only confuses them and turns them off. You know your situation better than we do. If it is your judgment that this team will respond better to incremental improvement, then you can approach it that way. What's the single biggest impediment they are currently facing (or causing) to delivery? That would be the thing to address first. If they are skeptical about Scrum, just don't say "scrum" or "sprint" or whatever. The substance of agile is the same regardless of the terminology you use.

                        If you see a process problem the team thinks is not a big deal, you might be able to expose the extent of the waste using a tool like Value Stream Mapping, Ishikawa Diagram, or Diagram of Effects. It's possible they don't understand the implications of some form of waste because they haven't looked at it in that way before, or they didn't know how to quantify it. Sometimes that opens a door and encourages people to accept help.

                        Cheers,
                        Dave
                        --- In scrumdevelopment@yahoogroups.com, Kerrie Valdiviezo <kerrie_valdiviezo@...> wrote:
                        >
                        > If the ScrumMaster is supposed to enforce the Scrum Process but the rest of the Team disagrees with certain parts of the process...do we just go with that because it's a 'Team decision?' 
                        >
                        > I see that this particular team could use improvement mostly in communication and commitment.  However, if the team and product owner are happy with where the team is at and have no motivation for improvements...what next?  Do they no longer need retrospectives?  Do they no longer need a ScrumMaster?
                        >
                        > I see they have distractions...but when I have a conversation with them about that to find ways I can help, they insist that it's 'not that big of a deal'.
                        > -They work on stuff outside the project, but they are all comfortable with it when a team member does that...and so is the PO
                        > -they don't finish most of the stories in an iteration...but 80% of the stories are 80-90% done...so they and PO are satisfied with that
                        > -they pull in other stories mid iteration w/o first talking to rest of the team and sometimes the PO and yes...they and PO are all comfortable with that too. 
                        > these are some of the symptoms to the bigger problems, thats' what I think.
                        >
                        > Your thoughts?
                        >
                      • Roy Morien
                        It is the Scrummaster s role to keep everyone on the straight and narrow in regard to Scrum, but only if the team is actually trying to use Scrum,
                        Message 11 of 19 , Mar 31, 2009
                        • 0 Attachment
                          It is the Scrummaster's role to keep everyone on the straight and narrow in regard to Scrum, but only if the team is actually trying to use Scrum, voluntarilly, with the intention of trying to gain the benefits of this approach. (the Scrummaster does have other aspects to their role, of course). This is a leadership role, a mentoring role, a protection role etc.
                           
                          But what is NOT the Scrummasters role is to be a policeman or enforcer to force people to use Scrum. If the team is not practicing Scrum, then there is no such role as Scrummaster;that role has become redundant or irrelevant in this circumstance.
                           
                          Regards,
                          Roy Morien
                           

                          To: scrumdevelopment@yahoogroups.com
                          From: xavier@...
                          Date: Wed, 25 Mar 2009 22:42:42 +0100
                          Subject: Re: [scrumdevelopment] ScrumMaster only one trying to do Scrum

                          Kerrie,

                          When you put forward a situation like this to the list, you will probably get a lot of answers saying that if the team and PO think it's OK, then let it be. And they are partly right, at least from the team/SM point of view. You might not be implementing Scrum correctly, but as long as you have clearly defined a Product Owner, and he/she understands his/her responsability, your hands are tied. Scrum is very simple: the responsibility of what is delivered lies with the PO. If the PO approves, then unfortunately for you, "all is well" (at least from the framework perspective) . There is no such thing as saying "they only do 80-90% of stories but the PO is satisfied with that". The PO *defines the acceptance criteria*. At the end of the sprint, stories are either done or not done, and the PO is the only one who decides. This is why it's so critical to have a good Product Owner. (From reading your e-mail, it looks like your PO might need some coaching.)

                          But in the meantime, you cannot (as SM) force change. Do as best as you can with the retrospectives. What you have to understand (or even better, Senior Management has to understand) is that this team is probably unproductive and risky. Or better put, it's less productive than it could be, and you are more at risk of not having a working product when your organization needs it than you could be. Whenever a team (or a person for that matter) says they don't need to improve, a warning light should go off in your head. *Something* is wrong there.

                          Think about this: why do _you_ care, when everyone else (including most importantly the PO) doesn't? What sets you apart? Are you alone, or are there other people in the organization that think like you? (If you are alone, you might have higher quality standards than your organization. .. and while what I am going to say is very polemic, if your organization is surviving, you might be goldplating! ).

                          Hope it helps,
                          Xavier


                          On Wed, Mar 25, 2009 at 9:04 PM, Kerrie Valdiviezo <kerrie_valdiviezo@ yahoo.com> wrote:


                          If the ScrumMaster is supposed to enforce the Scrum Process but the rest of the Team disagrees with certain parts of the process...do we just go with that because it's a 'Team decision?' 

                          I see that this particular team could use improvement mostly in communication and commitment.  However, if the team and product owner are happy with where the team is at and have no motivation for improvements. ..what next?  Do they no longer need retrospectives?  Do they no longer need a ScrumMaster?

                          I see they have distractions. ..but when I have a conversation with them about that to find ways I can help, they insist that it's 'not that big of a deal'.
                          -They work on stuff outside the project, but they are all comfortable with it when a team member does that...and so is the PO
                          -they don't finish most of the stories in an iteration... but 80% of the stories are 80-90% done...so they and PO are satisfied with that
                          -they pull in other stories mid iteration w/o first talking to rest of the team and sometimes the PO and yes...they and PO are all comfortable with that too. 
                          these are some of the symptoms to the bigger problems, thats' what I think.

                          Your thoughts?








                          Get what you want at ebay. View photos of singles in your area
                        • dgbabicz
                          My 2 cents: First off, in saying the PO is OK with all of these things...are the C-level folks OK with it? More likely, they re not aware of it. Are
                          Message 12 of 19 , Apr 1, 2009
                          • 0 Attachment
                            My 2 cents:

                            First off, in saying the PO is "OK" with all of these things...are the C-level folks OK with it? More likely, they're not aware of it. Are shippable product increments being released after each Sprint? If not, the consequences of not producing will come home to roost, sooner or later.

                            I'll break down the problems you note and answer each:

                            "Do they no longer need retrospectives?  Do they no longer need a ScrumMaster?"
                            ---IF they are going to do Scrum, they need both. Scrum has a minimum of roles/artifacts/ceremonies, and they need to be respected to be doing Scrum. Within that, though, the team can self-norm.

                            "I see they have distractions...They work on stuff outside the project"
                            ---These can be examples of things that effect your velocity. In my opinion, they probably should be impediments, but it seems this team and PO don't see them as keeping them from completing work, but more as part of the territory. As such, you should remove that time from your planning as overhead to reduce the amount of "productive" time the team will commit to for a sprint.

                            "they don't finish most of the stories in an iteration...but 80% of the stories are 80-90% done"
                            ---Depends on the definition of "done" you're using. Is "done" shippable and releasable? If so, what's the 10-20% of "done" they're not completing? I think you either need to adjust the definition of "done" or get clear with the PO about the ramifications of not releasing product.

                            "they pull in other stories mid iteration w/o first talking to the rest of the team and sometimes the PO and yes...they and PO are all comfortable with that too"
                            ---Are these different than the other things you mention them pulling in above? If so, this is a clear problem if it's being done unilaterally by one team member, because it's changing what the TEAM is committed to. I understand the PO is OK with it, but this one you have to curb.

                            Having said all that, I agree with what others have posted that you can't force the change as ScrumMaster. What's the old saying about how many psychologists it takes to change a lightbulb? One, but the lightbulb has to *want* to change. The same can be said of organizations adopting Scrum, or any organizational change. Also, people will do more to avoid pain than they ever will to gain pleasure. If the team is not shipping product, and there are no consequences, you are fighting an uphill battle against the organizational culture.

                            Have a heart to heart (NON-confrontational!) with the PO. See if the PO, and the team, can sign on to doing one light Sprint following the framework. Benchmark compare the success to what you've been seeing previously. If you can show them that they can produce more, and their daily experience can be better, you can get them to sign on to really doing Scrum.
                          • Kerrie Valdiviezo
                            Ok, I admit, enforce was too strong of a word for what a ScrumMaster does.. An earlier version of this team did in fact do Scrum, then about 6 months ago a
                            Message 13 of 19 , Apr 1, 2009
                            • 0 Attachment
                              Ok, I admit, "enforce" was too strong of a word for what a ScrumMaster does.

                              An earlier version of this team did in fact do Scrum, then about 6 months ago a new "Senior" Developer joined the team...and he arrived with bad habits and a "the rules don't apply to me" attitude.  There is no doubt that this new member is a smart and talented developer, the team respects him and looks up to him.  Which is great...however...what he says goes...they don't question him or argue with him on any subject and he is very satisfied with the team and the work they do....so that's what they think too. 

                              Regarding our 'shippable product'...Let's say we gave the PO an estimate for a project, based on our velocity...of June 1st.  Our sprints are 2 weeks long....the team will fail every iteration between now and the last iteration...for that last iteration...they will succeed and the project will go out as planned.  This is what is keeping the PO and the end users happy. 

                              It seems that everyone on the 'Stepford' team is happy, the PO is happy...however, as Xavier pointed out "it's less productive than it could be, and you are more at risk of not having a working product when your organization needs it than you could be"
                               

                              --- On Wed, 4/1/09, dgbabicz <davidbabicz@...> wrote:
                              From: dgbabicz <davidbabicz@...>
                              Subject: [scrumdevelopment] Re: ScrumMaster only one trying to do Scrum
                              To: scrumdevelopment@yahoogroups.com
                              Date: Wednesday, April 1, 2009, 6:59 AM

                              My 2 cents:

                              First off, in saying the PO is "OK" with all of these things...are the C-level folks OK with it? More likely, they're not aware of it. Are shippable product increments being released after each Sprint? If not, the consequences of not producing will come home to roost, sooner or later.

                              I'll break down the problems you note and answer each:

                              "Do they no longer need retrospectives?  Do they no longer need a ScrumMaster? "
                              ---IF they are going to do Scrum, they need both. Scrum has a minimum of roles/artifacts/ ceremonies, and they need to be respected to be doing Scrum. Within that, though, the team can self-norm.

                              "I see they have distractions. ..They work on stuff outside the project"
                              ---These can be examples of things that effect your velocity. In my opinion, they probably should be impediments, but it seems this team and PO don't see them as keeping them from completing work, but more as part of the territory. As such, you should remove that time from your planning as overhead to reduce the amount of "productive" time the team will commit to for a sprint.

                              "they don't finish most of the stories in an iteration... but 80% of the stories are 80-90% done"
                              ---Depends on the definition of "done" you're using. Is "done" shippable and releasable? If so, what's the 10-20% of "done" they're not completing? I think you either need to adjust the definition of "done" or get clear with the PO about the ramifications of not releasing product.

                              "they pull in other stories mid iteration w/o first talking to the rest of the team and sometimes the PO and yes...they and PO are all comfortable with that too"
                              ---Are these different than the other things you mention them pulling in above? If so, this is a clear problem if it's being done unilaterally by one team member, because it's changing what the TEAM is committed to. I understand the PO is OK with it, but this one you have to curb.

                              Having said all that, I agree with what others have posted that you can't force the change as ScrumMaster. What's the old saying about how many psychologists it takes to change a lightbulb? One, but the lightbulb has to *want* to change. The same can be said of organizations adopting Scrum, or any organizational change. Also, people will do more to avoid pain than they ever will to gain pleasure. If the team is not shipping product, and there are no consequences, you are fighting an uphill battle against the organizational culture.

                              Have a heart to heart (NON-confrontationa l!) with the PO. See if the PO, and the team, can sign on to doing one light Sprint following the framework. Benchmark compare the success to what you've been seeing previously. If you can show them that they can produce more, and their daily experience can be better, you can get them to sign on to really doing Scrum.


                            • Ilja Preuß
                              ... Is that a problem? Curious, Ilja
                              Message 14 of 19 , Apr 2, 2009
                              • 0 Attachment
                                2009/4/1 Kerrie Valdiviezo <kerrie_valdiviezo@...>:

                                > It seems that everyone on the 'Stepford' team is happy, the PO is
                                > happy...however, as Xavier pointed out "it's less productive than it could
                                > be, and you are more at risk of not having a working product when your
                                > organization needs it than you could be"

                                Is that a problem?

                                Curious, Ilja
                              • Adam Sroka
                                Hi Kerrie :-) On Wed, Apr 1, 2009 at 10:06 AM, Kerrie Valdiviezo ... What do you suppose would happen if he caught the bird flu and didn t contribute for an
                                Message 15 of 19 , Apr 2, 2009
                                • 0 Attachment
                                  Hi Kerrie :-)

                                  On Wed, Apr 1, 2009 at 10:06 AM, Kerrie Valdiviezo
                                  <kerrie_valdiviezo@...> wrote:
                                  > Ok, I admit, "enforce" was too strong of a word for what a ScrumMaster does.
                                  >
                                  > An earlier version of this team did in fact do Scrum, then about 6 months
                                  > ago a new "Senior" Developer joined the team...and he arrived with bad
                                  > habits and a "the rules don't apply to me" attitude.  There is no doubt that
                                  > this new member is a smart and talented developer, the team respects him and
                                  > looks up to him.  Which is great...however...what he says goes...they don't
                                  > question him or argue with him on any subject and he is very satisfied with
                                  > the team and the work they do....so that's what they think too.
                                  >

                                  What do you suppose would happen if he caught the bird flu and didn't
                                  contribute for an iteration or two? Does the rest of the team know
                                  what is going on? Do they feel confident that they could produce
                                  without his guidance?

                                  > Regarding our 'shippable product'...Let's say we gave the PO an estimate for
                                  > a project, based on our velocity...of June 1st.  Our sprints are 2 weeks
                                  > long....the team will fail every iteration between now and the last
                                  > iteration...for that last iteration...they will succeed and the project will
                                  > go out as planned.  This is what is keeping the PO and the end users happy.
                                  >

                                  Yuck! This only works if the requirements are well known in advance
                                  and don't change very much. How boring. What happens when something
                                  new comes along that isn't well understood? What if the priorities
                                  change midstream?

                                  > It seems that everyone on the 'Stepford' team is happy, the PO is
                                  > happy...however, as Xavier pointed out "it's less productive than it could
                                  > be, and you are more at risk of not having a working product when your
                                  > organization needs it than you could be"
                                  >

                                  If a tree falls in the forest and no one cares does it matter if it
                                  makes a sound? In this economy if everyone is happy with
                                  underproduction then count your blessings. I don't envy you, though.
                                  How boring.
                                • Ilja Preuß
                                  Hi Adam, ... Why boring? Just because the team doesn t feel the need to become more productive, doesn t mean that it has to be boring. Just because they won t
                                  Message 16 of 19 , Apr 2, 2009
                                  • 0 Attachment
                                    Hi Adam,

                                    > If a tree falls in the forest and no one cares does it matter if it
                                    > makes a sound? In this economy if everyone is happy with
                                    > underproduction then count your blessings. I don't envy you, though.
                                    > How boring.

                                    Why boring? Just because the team doesn't feel the need to become more
                                    productive, doesn't mean that it has to be boring. Just because they
                                    won't accept our idea of how they should change doesn't mean that they
                                    wouldn't welcome other interesting and exciting changes.
                                    http://radio.javaranch.com/ilja/2008/07/19/1216448097868.html

                                    Take it as an opportunity to try something totally different. Boring?
                                    Only if you choose to!

                                    Cheers, Ilja
                                  • Adam Sroka
                                    ... Well, in and of itself it sounds boring. Perhaps our preconceptions are different. I have worked with the OP directly, so perhaps I am reading something
                                    Message 17 of 19 , Apr 2, 2009
                                    • 0 Attachment
                                      On Thu, Apr 2, 2009 at 6:55 AM, Ilja Preuß <iljapreuss@...> wrote:
                                      > Hi Adam,
                                      >
                                      >> If a tree falls in the forest and no one cares does it matter if it
                                      >> makes a sound? In this economy if everyone is happy with
                                      >> underproduction then count your blessings. I don't envy you, though.
                                      >> How boring.
                                      >
                                      > Why boring? Just because the team doesn't feel the need to become more
                                      > productive, doesn't mean that it has to be boring. Just because they
                                      > won't accept our idea of how they should change doesn't mean that they
                                      > wouldn't welcome other interesting and exciting changes.
                                      > http://radio.javaranch.com/ilja/2008/07/19/1216448097868.html
                                      >
                                      > Take it as an opportunity to try something totally different. Boring?
                                      > Only if you choose to!
                                      >

                                      Well, in and of itself it sounds boring. Perhaps our preconceptions
                                      are different. I have worked with the OP directly, so perhaps I am
                                      reading something extra into her words. I'm not sure, actually.
                                    • Adam Sroka
                                      ... Hi Ilja: I thought about this, and I take your point. Boring was a poor word choice anyway. Here s where my brain is, though: I think that some teams
                                      Message 18 of 19 , Apr 2, 2009
                                      • 0 Attachment
                                        On Thu, Apr 2, 2009 at 6:55 AM, Ilja Preuß <iljapreuss@...> wrote:
                                        > Hi Adam,
                                        >
                                        >> If a tree falls in the forest and no one cares does it matter if it
                                        >> makes a sound? In this economy if everyone is happy with
                                        >> underproduction then count your blessings. I don't envy you, though.
                                        >> How boring.
                                        >
                                        > Why boring? Just because the team doesn't feel the need to become more
                                        > productive, doesn't mean that it has to be boring. Just because they
                                        > won't accept our idea of how they should change doesn't mean that they
                                        > wouldn't welcome other interesting and exciting changes.
                                        > http://radio.javaranch.com/ilja/2008/07/19/1216448097868.html
                                        >
                                        > Take it as an opportunity to try something totally different. Boring?
                                        > Only if you choose to!
                                        >

                                        Hi Ilja:

                                        I thought about this, and I take your point. Boring was a poor word
                                        choice anyway.

                                        Here's where my brain is, though: I think that some teams adopting
                                        Agile get stuck because they retain a culture that accepts mediocrity.
                                        It is quite possible to be going through the motions of doing Scrum -
                                        we write stories, we estimate them, we have meetings every couple of
                                        weeks where we talk about what we did and what we will do, etc. -
                                        without having Agile values.

                                        At a certain point, though, the values become important. There is a
                                        big difference between people who say, "We delivered something that
                                        resembles what was asked for, that is good enough," and people who are
                                        constantly striving to make things better. The difference is in the
                                        values that we embrace. The values in Agile are clearly designed for a
                                        mindset that is self-reflective and constantly striving to improve. It
                                        is inclusive, not exclusive - Agile teams should have neither heroes
                                        nor bystanders.

                                        IMHO, when you reach the point where you are basically doing the
                                        things that Scrum asks you to do, but things still don't seem "quite
                                        right," and they aren't getting any better, then it is time to examine
                                        your values and see if they look like these ones:
                                        http://agilemanifesto.org/ or these:
                                        http://manifesto.softwarecraftsmanship.org/ or these:
                                        http://en.wikipedia.org/wiki/Extreme_Programming#XP_values Things
                                        won't get any better until you identify all the individuals on your
                                        team whose values are not compatible with those and give them a swift
                                        kick out the door.
                                      • dgbabicz
                                        I think we ve found the issue. If your delivery date (go live?) is in June, assuming we re at April 1, why 2 week iterations? And why not deliver incremental,
                                        Message 19 of 19 , Apr 3, 2009
                                        • 0 Attachment
                                          I think we've found the issue.

                                          If your delivery date (go live?) is in June, assuming we're at April 1, why 2 week iterations? And why not deliver incremental, shippable product every 30 days?

                                          I would get together with the PO, and reprioritize the product backlog so there's something that could be picked off and worked on, start to finish, in a 30 day sprint. Extend from 2 weeks to 30 days, and have the team and PO agree to try to finish that piece in that sprint. That way, your PO has a better chance of seeing value in a sprint, and therefore the Scrum framework, because you're giving them somehing tangible, completed, as a work product from that single sprint. And the team will feel that sense of accomplishment. That will be powerful.

                                          As far as the rogue team member, what is he/she not participating in? Daily standups, something else? Need some more detail here.

                                          --- In scrumdevelopment@yahoogroups.com, Kerrie Valdiviezo <kerrie_valdiviezo@...> wrote:
                                          >
                                          > Ok, I admit, "enforce" was too strong of a word for what a ScrumMaster does..
                                          >
                                          > An earlier version of this team did in fact do Scrum, then about 6 months ago a new "Senior" Developer joined the team...and he arrived with bad habits and a "the rules don't apply to me" attitude.  There is no doubt that this new member is a smart and talented developer, the team respects him and looks up to him.  Which is great...however...what he says goes...they don't question him or argue with him on any subject and he is very satisfied with the team and the work they do....so that's what they think too. 
                                          >
                                          > Regarding our 'shippable product'...Let's say we gave the PO an estimate for a project, based on our velocity...of June 1st.  Our sprints are 2 weeks long....the team will fail every iteration between now and the
                                          > last iteration...for that last iteration...they will succeed and the project will go out as planned.  This is what is keeping the PO and the end users happy. 
                                          >
                                          > It seems that everyone on the 'Stepford' team is happy, the PO is happy...however, as Xavier pointed out "it's less productive than it could be, and you are more at risk of not
                                          > having a working product when your organization needs it than you could
                                          > be"
                                          >  
                                          >
                                          > --- On Wed, 4/1/09, dgbabicz <davidbabicz@...> wrote:
                                          > From: dgbabicz <davidbabicz@...>
                                          > Subject: [scrumdevelopment] Re: ScrumMaster only one trying to do Scrum
                                          > To: scrumdevelopment@yahoogroups.com
                                          > Date: Wednesday, April 1, 2009, 6:59 AM
                                        Your message has been successfully submitted and would be delivered to recipients shortly.