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

How do I sell scrum to developers?

Expand Messages
  • paulsiu1887
    I have wanted to implement scrum for a while, but until recently I lack the means to. Recently, staff changes have move me to a lead developer position in the
    Message 1 of 13 , Dec 29, 2006
    • 0 Attachment
      I have wanted to implement scrum for a while, but until recently I
      lack the means to. Recently, staff changes have move me to a lead
      developer position in the project. I thought this was a good
      opportunity to implement Scrum.

      However, I forsee difficulty selling it to the developers. Take
      stand up meetings. Developers hates meeting. Meeting everyday will
      be really hard to sell. My goals in these meetings are:

      - Reporting
      - Have the whole team understand the progress being made.
      - When there are issues, someone can volunteer and help.
      - Fix pain point with the database. Right now, people make database
      changes and other people don't know about them. The project manager
      tried to get the DBA to track them. Unfortunately, like most DBA's I
      know, the person is on a million other projects.

      Part of the problem will be perception in these meetings. Most
      developers (myself included) dread meetings. Daily standups can also
      be view as micromanagement. Most developers just want to send email
      to eachother.

      I am wondering if you folks have any advice on how to sell your
      development team on scrum.

      Paul
    • Amol Kasbekar
      What we did here is stop having weekly team meeting which would be around 1-1.5 hrs and replace it with 10-15min daily standup meetings. Most of our developers
      Message 2 of 13 , Dec 29, 2006
      • 0 Attachment
        What we did here is stop having weekly team meeting which would be around 1-1.5 hrs and replace it with 10-15min daily standup meetings.
        Most of our developers used to dread the previous team meeting and so cancelling it provided a good incentive to begin daily standups. We also make it a point to not let the standup extend beyond 15 mins. Any topic brought up that needs more discussion is handled after the meeting with only the required people. Our experience has been that developers tend to bring up issues in their work more often in daily standups than weekly meetings.
         
        Amol.


        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of paulsiu1887
        Sent: Friday, December 29, 2006 9:17 AM
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] How do I sell scrum to developers?

        I have wanted to implement scrum for a while, but until recently I
        lack the means to. Recently, staff changes have move me to a lead
        developer position in the project. I thought this was a good
        opportunity to implement Scrum.

        However, I forsee difficulty selling it to the developers. Take
        stand up meetings. Developers hates meeting. Meeting everyday will
        be really hard to sell. My goals in these meetings are:

        - Reporting
        - Have the whole team understand the progress being made.
        - When there are issues, someone can volunteer and help.
        - Fix pain point with the database. Right now, people make database
        changes and other people don't know about them. The project manager
        tried to get the DBA to track them. Unfortunately, like most DBA's I
        know, the person is on a million other projects.

        Part of the problem will be perception in these meetings. Most
        developers (myself included) dread meetings. Daily standups can also
        be view as micromanagement. Most developers just want to send email
        to eachother.

        I am wondering if you folks have any advice on how to sell your
        development team on scrum.

        Paul

      • Michael Vizdos
        Ask the team. Start an open dialog with them. And see if the perception is reality.... and if they want to change. Why do *you* want to implement Scrum? -
        Message 3 of 13 , Dec 29, 2006
        • 0 Attachment
          Ask the team.  Start an open dialog with them.  And see if the perception is reality.... and if they want to change.
           
          Why do *you* want to implement Scrum?
           
          - mike


           
          On 12/29/06, paulsiu1887 <paulsiu1887@...> wrote:

          I have wanted to implement scrum for a while, but until recently I
          lack the means to. Recently, staff changes have move me to a lead
          developer position in the project. I thought this was a good
          opportunity to implement Scrum.

          However, I forsee difficulty selling it to the developers. Take
          stand up meetings. Developers hates meeting. Meeting everyday will
          be really hard to sell. My goals in these meetings are:

          - Reporting
          - Have the whole team understand the progress being made.
          - When there are issues, someone can volunteer and help.
          - Fix pain point with the database. Right now, people make database
          changes and other people don't know about them. The project manager
          tried to get the DBA to track them. Unfortunately, like most DBA's I
          know, the person is on a million other projects.

          Part of the problem will be perception in these meetings. Most
          developers (myself included) dread meetings. Daily standups can also
          be view as micromanagement. Most developers just want to send email
          to eachother.

          I am wondering if you folks have any advice on how to sell your
          development team on scrum.

          Paul


        • Mike Bria
          ... Hi Paul -- You really have asked the million dollar question now haven t you? There certainly is no easy answer suitable for a mailing list, but let me
          Message 4 of 13 , Dec 29, 2006
          • 0 Attachment
            -- In scrumdevelopment@yahoogroups.com, "Amol Kasbekar" <apk@...> wrote:
            >
            > What we did here is stop having weekly team meeting which would be
            > around 1-1.5 hrs and replace it with 10-15min daily standup meetings.
            > Most of our developers used to dread the previous team meeting and so
            > cancelling it provided a good incentive to begin daily standups. We also
            > make it a point to not let the standup extend beyond 15 mins. Any topic
            > brought up that needs more discussion is handled after the meeting with
            > only the required people. Our experience has been that developers tend
            > to bring up issues in their work more often in daily standups than
            > weekly meetings.
            >
            > Amol.
            >
            >
            > ________________________________
            >
            > From: scrumdevelopment@yahoogroups.com
            > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of paulsiu1887
            > Sent: Friday, December 29, 2006 9:17 AM
            > To: scrumdevelopment@yahoogroups.com
            > Subject: [scrumdevelopment] How do I sell scrum to developers?
            >
            >
            >
            > I have wanted to implement scrum for a while, but until recently
            > I
            > lack the means to. Recently, staff changes have move me to a
            > lead
            > developer position in the project. I thought this was a good
            > opportunity to implement Scrum.
            >
            > However, I forsee difficulty selling it to the developers. Take
            > stand up meetings. Developers hates meeting. Meeting everyday
            > will
            > be really hard to sell. My goals in these meetings are:
            >
            > - Reporting
            > - Have the whole team understand the progress being made.
            > - When there are issues, someone can volunteer and help.
            > - Fix pain point with the database. Right now, people make
            > database
            > changes and other people don't know about them. The project
            > manager
            > tried to get the DBA to track them. Unfortunately, like most
            > DBA's I
            > know, the person is on a million other projects.
            >
            > Part of the problem will be perception in these meetings. Most
            > developers (myself included) dread meetings. Daily standups can
            > also
            > be view as micromanagement. Most developers just want to send
            > email
            > to eachother.
            >
            > I am wondering if you folks have any advice on how to sell your
            > development team on scrum.
            >
            > Paul
            >

            Hi Paul --

            You really have asked the million dollar question now haven't you?
            There certainly is no easy answer suitable for a mailing list, but let
            me offer a few preliminary, general thoughts that have helped me along
            the way:

            First, tread the "selling" lightly. What I mean by this is I
            encourage you wholeheartedly to bring scrum and agility into your
            team, but going at it from a "sales pitch" approach can tend to put
            people off sometimes. Pay attention to who seems to "get it" and
            focus on them initially.

            Most importantly...understand why YOU think that scrum is a good
            approach, how it is different from the way you work now, and why its
            better. Then have an open discussion with your team about those
            various points. Expect that people might be skeptacle, be patient
            with them and continue to be open and vocal about the reasons for the
            changes [improvements!] you suggest.

            As for the stand-up meetings specifically: be very clear and strict
            about the rules of the meeting: SHORT AND TO THE POINT. Everyone
            answers the 3 questions, and nothing more. Any other discussions that
            try to crop up get tabled for after the meeting. If you stick to
            this, it shouldn't take people long to not "dread" the meeting.

            My last suggestion is to get your team co-located if they are not
            already. Having everyone within an earshot of each other is
            absolutely priceless. Remember, one of the primary objectives you
            have to is foster *collaboration*, and sitting apart from each other
            really makes that difficult.

            Hope that helps, happy trails...
            --MB
          • James Cooper
            Hi Paul, Tell us more about how you re implementing Scrum. Daily standups are only a part of the process. Do you have a product backlog, or are you working
            Message 5 of 13 , Dec 29, 2006
            • 0 Attachment
              Hi Paul,

              Tell us more about how you're implementing Scrum.  Daily standups are only a part of the process.

              Do you have a product backlog, or are you working from traditional requirements docs?
              How are you estimating the backlog items/stories?
              Have you done a sprint planning session where the team agreed to commit to the work as a group?
              Is there a publicly visible task board that shows all the work in progress and to-do items?

              If you've done those activities then I suspect the team will welcome the daily standup, as it's really an activity for _them_ to help them meet their team commitment. 

              If you start with daily standups first, then it looks like you're micromanaging them against the old work plan (requirements doc, or whatever it happened to be). 

              -- James

              On 12/29/06, paulsiu1887 <paulsiu1887@...> wrote:

              I have wanted to implement scrum for a while, but until recently I
              lack the means to. Recently, staff changes have move me to a lead
              developer position in the project. I thought this was a good
              opportunity to implement Scrum.

              However, I forsee difficulty selling it to the developers. Take
              stand up meetings. Developers hates meeting. Meeting everyday will
              be really hard to sell. My goals in these meetings are:

              - Reporting
              - Have the whole team understand the progress being made.
              - When there are issues, someone can volunteer and help.
              - Fix pain point with the database. Right now, people make database
              changes and other people don't know about them. The project manager
              tried to get the DBA to track them. Unfortunately, like most DBA's I
              know, the person is on a million other projects.

              Part of the problem will be perception in these meetings. Most
              developers (myself included) dread meetings. Daily standups can also
              be view as micromanagement. Most developers just want to send email
              to eachother.

              I am wondering if you folks have any advice on how to sell your
              development team on scrum.

              Paul


            • Steven Gordon
              What are the current pain points in your software development process? How are these pain points affecting the developers? Is there lots of overtime and
              Message 6 of 13 , Dec 29, 2006
              • 0 Attachment
                What are the current pain points in your software development process?  How are these pain points affecting the developers?  Is there lots of overtime and other kinds of pressures?  The selling point is how Scrum would address these pain points and pressures.

                In my experience, if there is no visceral pain in the organization today, process change will be nearly impossible.

                Steve

                On 12/29/06, paulsiu1887 <paulsiu1887@...> wrote:

                I have wanted to implement scrum for a while, but until recently I
                lack the means to. Recently, staff changes have move me to a lead
                developer position in the project. I thought this was a good
                opportunity to implement Scrum.

                However, I forsee difficulty selling it to the developers. Take
                stand up meetings. Developers hates meeting. Meeting everyday will
                be really hard to sell. My goals in these meetings are:

                - Reporting
                - Have the whole team understand the progress being made.
                - When there are issues, someone can volunteer and help.
                - Fix pain point with the database. Right now, people make database
                changes and other people don't know about them. The project manager
                tried to get the DBA to track them. Unfortunately, like most DBA's I
                know, the person is on a million other projects.

                Part of the problem will be perception in these meetings. Most
                developers (myself included) dread meetings. Daily standups can also
                be view as micromanagement. Most developers just want to send email
                to eachother.

                I am wondering if you folks have any advice on how to sell your
                development team on scrum.

                Paul


              • Chris Leslie
                Question for the SCRUM experts ;-).... Do you see scrum being implemented mostly top down or bottom up. For the trainers coaches on the board, I would assume
                Message 7 of 13 , Dec 29, 2006
                • 0 Attachment
                  Question for the SCRUM experts ;-)....

                  Do you see scrum being implemented mostly top down or bottom up.
                  For the trainers\coaches on the board, I would assume for the most
                  part top down. I assume you get brought in by management to help
                  implement the process.
                  How many of you have seen it implemented by the developers themselves.
                  For the developers I know, they do not seem interested in the
                  process\methodology side of things.

                  I am in a similar position (dev manager + recent scrum master
                  training) trying to show the team the benefits of scrum, but finding
                  it difficult to get others (below and above me) in the organization
                  to actually buy in.

                  Everyone I have spoken to thinks it is a great idea, but I don't see
                  any real buy in or commitment to actually participate or help
                  implement change.

                  I implemented daily standups (even with all my explination\prompting
                  it still seems like a status reporting meeting) and weekly
                  iterations, which were great, but just prompted management to push
                  the team for more features - became more like RAD prototyping.
                  We accomplished a fantastic amount, but quality was a concern for me.
                  i.e Beiong able to demo features became more important than actual
                  code quality.

                  In the new year, I will try and fix things up a bit more.
                  I feel like I need a scrum buddy in the company to help out.

                  Thanks Chris

                  --- In scrumdevelopment@yahoogroups.com, "paulsiu1887"
                  <paulsiu1887@...> wrote:
                  >
                  > I have wanted to implement scrum for a while, but until recently I
                  > lack the means to. Recently, staff changes have move me to a lead
                  > developer position in the project. I thought this was a good
                  > opportunity to implement Scrum.
                • Siddharta Govindaraj
                  Hi Chris, ... You are right, developers are not as interested in the methodology side of things. The main reason I feel this is so is because companies don t
                  Message 8 of 13 , Dec 29, 2006
                  • 0 Attachment
                    Hi Chris,

                    --- In scrumdevelopment@yahoogroups.com, "Chris Leslie"
                    <chris_leslie01@...> wrote:
                    >
                    > Question for the SCRUM experts ;-)....
                    >
                    > Do you see scrum being implemented mostly top down or bottom up.
                    > For the trainers\coaches on the board, I would assume for the most
                    > part top down. I assume you get brought in by management to help
                    > implement the process.
                    > How many of you have seen it implemented by the developers themselves.
                    > For the developers I know, they do not seem interested in the
                    > process\methodology side of things.
                    >

                    You are right, developers are not as interested in the methodology
                    side of things. The main reason I feel this is so is because companies
                    don't allow them to see the bigger picture. Developers goals should be
                    delivering successful software, but in most places, their goals stop
                    with the piece of code that they write.

                    I'm a developer and I introduced agile in my previous company. There
                    were a few advantages + disadvantages that I faced -

                    Advantages

                    1. Being a developer, I was able to get the backing of my team
                    2. Being in a startup, where people have expanded responsibilities, it
                    was easier for us to think "release successful software" rather than
                    "complete my task"
                    3. We were able to embrace engineering practises easily: unit testing,
                    continuous integration, standups etc

                    Disadvantages

                    1. In the end, my team was the only one following agile, so practises
                    that involved the whole organisation were difficult to implement.
                    Example: Frequent customer interaction. The traditional way of using a
                    single person contact who would interface between the dev team and the
                    customer continued. In two years of trying, I was unable to improve
                    customer collaboration.
                    2. Lack of scrummaster/product owner: Again, being in a startup, we
                    didnt have manpower to spare, so I was sometimes playing the role of
                    developer + scrummaster + product owner

                    In the end, top-down implementations definately have the advantage
                    that you can go for it will full commitment, but you risk alienating
                    the developers. Bottom-up is certainly better as far as developers are
                    concerned, but you will always have to work around the system as you
                    do not have the authority to change the system right at the start.

                    --
                    Siddharta Govindaraj
                    http://siddhi.blogspot.com
                  • Justin T. Sampson
                    ... I ve actually found a daily standup to be a good first practice in some cases. It helps the team to know what everyone else is working on, regardless of
                    Message 9 of 13 , Dec 29, 2006
                    • 0 Attachment
                      On 12/29/06, James Cooper <jamespcooper@...> wrote:

                      > If you start with daily standups first, then it looks like you're
                      > micromanaging them against the old work plan (requirements
                      > doc, or whatever it happened to be).

                      I've actually found a daily standup to be a good first practice in
                      some cases. It helps the team to know what everyone else is
                      working on, regardless of how the work was assigned or
                      chosen. It's very easy and doesn't feel as much like a "process"
                      change. Often developers are craving to work closer together,
                      and this can be a small practice with a big impact. The most
                      important thing about the standup meeting is that it is for the
                      team, not for management.

                      Cheers,
                      Justin
                    • James Cooper
                      Hi Justin, Yes, if the team is onboard from the start, then I agree. As Steve mentioned, identifying and satisfying the pain points is the key. If the team
                      Message 10 of 13 , Dec 29, 2006
                      • 0 Attachment
                        Hi Justin,

                        Yes, if the team is onboard from the start, then I agree.

                         As Steve mentioned, identifying and satisfying the pain points is the key.  If the team wants to work more closely together, then the daily standups are a natural fit.

                        I think some managers use the meeting as an opportunity to update the spreadsheet, changing the purpose of the meeting away from team coordination and towards data reporting/oversight.  That's the example I had in mind when I cautioned against the perception of micromanagement.

                        -- James

                        On 12/29/06, Justin T. Sampson <justin@...> wrote:

                        On 12/29/06, James Cooper <jamespcooper@...> wrote:

                        > If you start with daily standups first, then it looks like you're
                        > micromanaging them against the old work plan (requirements
                        > doc, or whatever it happened to be).

                        I've actually found a daily standup to be a good first practice in
                        some cases. It helps the team to know what everyone else is
                        working on, regardless of how the work was assigned or
                        chosen. It's very easy and doesn't feel as much like a "process"
                        change. Often developers are craving to work closer together,
                        and this can be a small practice with a big impact. The most
                        important thing about the standup meeting is that it is for the
                        team, not for management.

                        Cheers,
                        Justin


                      • Kane Mar
                        ... An approach that has worked well for me in the past is to start a new Scrum project and have the team members self-select themselves for inclusion. The
                        Message 11 of 13 , Dec 29, 2006
                        • 0 Attachment
                          --- In scrumdevelopment@yahoogroups.com, "Chris Leslie"
                          <chris_leslie01@...> wrote:
                          > I am in a similar position (dev manager + recent scrum master
                          > training) trying to show the team the benefits of scrum, but finding
                          > it difficult to get others (below and above me) in the organization
                          > to actually buy in.
                          >
                          > Everyone I have spoken to thinks it is a great idea, but I don't see
                          > any real buy in or commitment to actually participate or help
                          > implement change.

                          An approach that has worked well for me in the past is to start a new
                          Scrum project and have the team members self-select themselves for
                          inclusion.

                          The benefits of this approach are that you have a team that are
                          tolerant of change and some initial confusion. The disadvantage is
                          that only a handful of people may be willing to volunteer ... but
                          that's another problem! =)

                          Best regards.
                          Kane Mar
                          W: http://www.Danube.com
                          B: http://KaneMar.Wordpress.com
                        • Ron Jeffries
                          Hello, Chris. On Friday, December 29, 2006, at 1:02:46 PM, you ... It would surprise me a bit to find developers implementing Scrum -- primarily because
                          Message 12 of 13 , Dec 30, 2006
                          • 0 Attachment
                            Hello, Chris. On Friday, December 29, 2006, at 1:02:46 PM, you
                            wrote:

                            > Do you see scrum being implemented mostly top down or bottom up.
                            > For the trainers\coaches on the board, I would assume for the most
                            > part top down. I assume you get brought in by management to help
                            > implement the process.
                            > How many of you have seen it implemented by the developers themselves.
                            > For the developers I know, they do not seem interested in the
                            > process\methodology side of things.

                            It would surprise me a bit to find developers implementing Scrum --
                            primarily because developers alone cannot implement Scrum. They
                            could implement some kind of fake Scrum, with iterative planning and
                            reporting, but without a Product Owner, they'd have to pretend, and
                            they'd have to create their own Backlog.

                            If they did, I suspect that someone from management would step in to
                            take over the Product Owner role, which could be a good thing, but
                            most developers are not quite that Machiavellian in style.

                            Most software developers are more interested in developing software
                            than anything else, which leads them to avoid politics if they can
                            ... and Scrum is politics, plain and simple.

                            > I am in a similar position (dev manager + recent scrum master
                            > training) trying to show the team the benefits of scrum, but finding
                            > it difficult to get others (below and above me) in the organization
                            > to actually buy in.

                            > Everyone I have spoken to thinks it is a great idea, but I don't see
                            > any real buy in or commitment to actually participate or help
                            > implement change.

                            > I implemented daily standups (even with all my explination\prompting
                            > it still seems like a status reporting meeting) and weekly
                            > iterations, which were great, but just prompted management to push
                            > the team for more features - became more like RAD prototyping.
                            > We accomplished a fantastic amount, but quality was a concern for me.
                            > i.e Beiong able to demo features became more important than actual
                            > code quality.

                            Sounds like you have not fully implemented a few key practices:

                            1. Done equals done. A Scrum team doesn't do prototypes, they do
                            complete, ready to run, demonstrable software.

                            2. Commitment. A Scrum team will be happy to hear about all the
                            features the company wants, in priority order. Then the team, not
                            its ScrumMaster or its management, draws the commitment line on the
                            chart, accepting the features which they commit to complete, done
                            equals done, by the end of the Sprint.

                            In your situation, I would work on those two things with the team.
                            If the team will focus on getting everything it undertakes
                            completely done, and on committing to what it can really accomplish,
                            that will induce management to guide by prioritizing, which is their
                            job in this situation.

                            > In the new year, I will try and fix things up a bit more.
                            > I feel like I need a scrum buddy in the company to help out.

                            It would surely help to find one there, or at least someone in your
                            local community to talk with.

                            Good luck,

                            Ron Jeffries
                            www.XProgramming.com
                            Make it real or else forget about it -- Carlos Santana
                          • paulsiu1887
                            Sorry, had to go away for a bit during the holidays and didn t have internet access. Actually, what we already practice now is a form of iterative release, but
                            Message 13 of 13 , Jan 10, 2007
                            • 0 Attachment
                              Sorry, had to go away for a bit during the holidays and didn't have
                              internet access. Actually, what we already practice now is a form of
                              iterative release, but it's not really based on any known
                              methodology. We have:

                              1. Monthly release based on a list of items.
                              2. Automated build.
                              3. A product backlog.
                              4. A test matrix (which serve as requirements)

                              For each month, there is a release. For each release, the project
                              manager looks through the product backlog and specifies which items
                              goes into the release and assigns them to different developers. Each
                              developers tend looks through the items they have been assigned to
                              and perform an estimates. If the developer has too much work, the
                              task gets assigned to someone else. If the developer has too little
                              work, then the they can take on other people's task or grab new ones
                              from the product backlog.

                              The pain point I have notice is that developers tend to work within
                              a silo. Each is somewhat aware of what the other person is doing,
                              but sometimes they step on each other's toe. In the past, this was
                              resolved by the chief architect, who gladly answered everyone's
                              question and resolved issues. Especially bad is database changes,
                              which goes through a single DBA, but that DBA also works on a dozen
                              other project and so can't really keep track of all of the changes.

                              Here's the issue coming up, we are now going into maintenance. The
                              team has been reduced. However, the project manager time is now
                              greatly reduced. The chief architect is leaving for another project.
                              What I really want to do is to increase communication and have the
                              developers assign themselves items for each release. I like global
                              knowledge not to be concentrated on just one person. I like
                              developers to share database changes at each daily standup meeting.

                              The problem is that most of the developers feel that the process has
                              worked well so far and therefore nothing needs to change. Some of
                              them will balk at daily standup meetings and rather they just email
                              changes to eachother.

                              I guess I will take the suggstion of folks here an start a dialog
                              with them and try to alleviate their concerns, but this is somewhat
                              of a new experience for me.
                            Your message has been successfully submitted and would be delivered to recipients shortly.