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

Re: How do I sell scrum to developers?

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