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

Advice on whether adopting a scrum-ish approach for my case is a good idea

Expand Messages
  • Denis Haskin
    (I ll apologize in advance because I need to re-review my scrum book and it s at home, but I thought I d throw my scenario out and see what comments I get.) I
    Message 1 of 4 , Jul 20, 2004
    • 0 Attachment
      (I'll apologize in advance because I need to re-review my scrum book and
      it's at home, but I thought I'd throw my scenario out and see what
      comments I get.)

      I have not actually used scrum yet, but a long time ago I used some
      similar practices in another setting, so when I read the book the
      approach made a lot of sense to me.

      Here's the situation: I have just joined a new company and I'm software
      development manager, with a group of 17 developers. Each developer is
      on one or more projects, and each project has a lead developer who is
      responsible for technical direction and day-to-day management. The
      development staff is for the most part very amenable to agile practices,
      although we've been adopting them piecemeal.

      Our "customers" are customer proxies--project managers and analysts who
      deal with the external client, did all the requirements and design work,
      decided the budget, schedule, etc. (I know, I know, alarm bells are
      going off.) For the project in question. these folks are in different
      cities than we are (alarm bells #2).

      Most of the projects are making satisfactory progress, but one project
      in particular has a lot of issues. I'm wondering whether adopting scrum
      on that project is a good approach.

      There are 4 developers on the project: the lead and an intern are
      full-time, and then 2 other developers are currently half-time. This
      project was already underway when I joined the company.

      The lead developer has stated, several times, that he believes the
      project cannot be completed in the time or budget allocated, and he
      estimates it will take 2-3x that. Unfortunately, he refuses to detail
      his estimate beyond a *total* # of hours for the entire project (alarm
      bells #3).

      I think he may well be right. But not surprisingly, without some kind
      of more detailed justification or evidence the project managers--and my
      manager--remain unconvinced.

      The developers have been ostensibly working on this project for about 6
      weeks now, but they've been pretty much only working on learning the
      infrastructure we're using on this project (e.g. webwork, sitemesh,
      hibernate, etc) and have not delivered any functionality yet (alarm
      bells #4).

      My thinking is we need a pretty radical shift, and need to really focus
      the developers on delivering functional features. This will make the
      stakeholders a little more comfortable, will let us really get a handle
      on how long this might take, and have empirical evidence to refine and
      support our estimates. Hence scrum comes to mind.

      I'm under no illusion that adopting scrum will necessarily let us finish
      this on time or on budget. But I'm hoping it might get us closer to
      what we need to do.

      Here's some of the issues I'm concerned about:

      * Who's the appropriate person to be scrum master? I suspect me, not
      the lead developer.

      * Are we nuts to try using scrum without an external coach? Nobody here
      as used it before. (Unclear whether we have the budget for a scrum coach).

      * Is the fact that none of our "customers" are physically here too much
      of a problem? And the project managers are already resistant to "too
      many questions from the developers"...

      * What else should I be concerned about? (lots, I know...)

      Thanks,

      dwh
    • Mike Cohn
      Hi Denis-- You should clearly be the ScrumMaster. The project sounds like a good one to start with Scrum on because it sounds important and it doesn t sound
      Message 2 of 4 , Jul 21, 2004
      • 0 Attachment
        Hi Denis--
        You should clearly be the ScrumMaster.
        The project sounds like a good one to start with Scrum on because it sounds
        important and it doesn't sound like the status quo will succeed.

        You absolutely must get the team focused on delivering working software. You
        don't say how long the project is so I can't really recommend a sprint
        length. Standard Scrum says 30 days. With a team that is floundering and
        spending its time on "infrastructure" I personally wouldn't give them that
        long. I'd start with a two week sprint. Start by having the customer
        (whichever 1 or more people you decide that is) prioritize their top dozen
        or so items. You'll want all the features prioritized later but a dozen is
        likely a good start. Give the dozen (in one sorted list) to the team and
        tell them to break them out into the tasks they'd need to do to deliver the
        first item, then the second, the third, etc. Tell them to stop detailing
        tasks as soon as they feel they cannot commit to any more. They will be
        committing to delivering truly usable software--not something that needs
        more testing, etc.

        Things are always easier with a Scrum coach and many organizations need to
        hear things that can only be said by an outsider who isn't planning a
        long-term with the company. I think you mitigate some of the risk of going
        without a coach if you do the shorter sprints.

        I think you'll be fine with remote customers. I've done that dozens of
        times.

        Tell the project managers its their choice: Either put up with the questions
        from the programmers or accept delivery of whatever software the programmers
        deliver. That is, "we'll ask questions and deliver what you want or we'll
        take guesses and deliver something wrong." There's an example of an issue
        best pushed by an outside coach. :) You may be able to push with your boss
        or someone to get someone in just to lay the groundwork like that for a few
        days and then forego any long-term coaching, which should save some money.

        I'd also suggest looking for ways to make the two part-timers permanent. Can
        you trade two halvess for a whole, for example? When a Scrum team does their
        sprint planning meeting they make a *commitment* that they'll deliver what
        they say they will. This type of serious commitment is hard if half the team
        can get pulled onto other projects. Additionally, it's tough for someone on
        two teams to make commitments to both teams.

        Good luck

        --Mike Cohn
        Author of User Stories Applied for Agile Software Development
        www.userstories.com
        www.mountaingoatsoftware.com


        -----Original Message-----
        From: Denis Haskin [mailto:Denis@...]
        Sent: Tuesday, July 20, 2004 3:27 PM
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] Advice on whether adopting a scrum-ish approach
        for my case is a good idea

        (I'll apologize in advance because I need to re-review my scrum book and
        it's at home, but I thought I'd throw my scenario out and see what
        comments I get.)

        I have not actually used scrum yet, but a long time ago I used some
        similar practices in another setting, so when I read the book the
        approach made a lot of sense to me.

        Here's the situation: I have just joined a new company and I'm software
        development manager, with a group of 17 developers. Each developer is
        on one or more projects, and each project has a lead developer who is
        responsible for technical direction and day-to-day management. The
        development staff is for the most part very amenable to agile practices,
        although we've been adopting them piecemeal.

        Our "customers" are customer proxies--project managers and analysts who
        deal with the external client, did all the requirements and design work,
        decided the budget, schedule, etc. (I know, I know, alarm bells are
        going off.) For the project in question. these folks are in different
        cities than we are (alarm bells #2).

        Most of the projects are making satisfactory progress, but one project
        in particular has a lot of issues. I'm wondering whether adopting scrum
        on that project is a good approach.

        There are 4 developers on the project: the lead and an intern are
        full-time, and then 2 other developers are currently half-time. This
        project was already underway when I joined the company.

        The lead developer has stated, several times, that he believes the
        project cannot be completed in the time or budget allocated, and he
        estimates it will take 2-3x that. Unfortunately, he refuses to detail
        his estimate beyond a *total* # of hours for the entire project (alarm
        bells #3).

        I think he may well be right. But not surprisingly, without some kind
        of more detailed justification or evidence the project managers--and my
        manager--remain unconvinced.

        The developers have been ostensibly working on this project for about 6
        weeks now, but they've been pretty much only working on learning the
        infrastructure we're using on this project (e.g. webwork, sitemesh,
        hibernate, etc) and have not delivered any functionality yet (alarm
        bells #4).

        My thinking is we need a pretty radical shift, and need to really focus
        the developers on delivering functional features. This will make the
        stakeholders a little more comfortable, will let us really get a handle
        on how long this might take, and have empirical evidence to refine and
        support our estimates. Hence scrum comes to mind.

        I'm under no illusion that adopting scrum will necessarily let us finish
        this on time or on budget. But I'm hoping it might get us closer to
        what we need to do.

        Here's some of the issues I'm concerned about:

        * Who's the appropriate person to be scrum master? I suspect me, not
        the lead developer.

        * Are we nuts to try using scrum without an external coach? Nobody here
        as used it before. (Unclear whether we have the budget for a scrum coach).

        * Is the fact that none of our "customers" are physically here too much
        of a problem? And the project managers are already resistant to "too
        many questions from the developers"...

        * What else should I be concerned about? (lots, I know...)

        Thanks,

        dwh





        To Post a message, send it to: scrumdevelopment@...
        To Unsubscribe, send a blank message to:
        scrumdevelopment-unsubscribe@...
        Yahoo! Groups Links
      • Denis Haskin
        Mike -- thanks for the response. Very encouraging! (I really like your User Stories book, btw.) Some comments below. ... It s extremely important... ... My
        Message 3 of 4 , Jul 21, 2004
        • 0 Attachment
          Mike -- thanks for the response. Very encouraging! (I really like your
          User Stories book, btw.) Some comments below.

          Mike Cohn wrote:

          > Hi Denis--
          > You should clearly be the ScrumMaster.
          > The project sounds like a good one to start with Scrum on because it
          > sounds
          > important and it doesn't sound like the status quo will succeed.

          It's extremely important...

          >
          > You absolutely must get the team focused on delivering working
          > software. You
          > don't say how long the project is so I can't really recommend a sprint
          > length. Standard Scrum says 30 days. With a team that is floundering and
          > spending its time on "infrastructure" I personally wouldn't give them that
          > long. I'd start with a two week sprint.

          My inclination as well but I think I'm going to get serious pushback
          from the lead developer. I'll try but may be more like 3 week iterations.

          > Start by having the customer
          > (whichever 1 or more people you decide that is) prioritize their top dozen
          > or so items. You'll want all the features prioritized later but a dozen is
          > likely a good start. Give the dozen (in one sorted list) to the team and
          > tell them to break them out into the tasks they'd need to do to
          > deliver the
          > first item, then the second, the third, etc. Tell them to stop detailing
          > tasks as soon as they feel they cannot commit to any more. They will be
          > committing to delivering truly usable software--not something that needs
          > more testing, etc.

          We've already got prioritized use cases, they need to be broken out into
          tasks and we'll see how much we can get in the first iteration.
          Probably not even complete use cases--they're really not granular enough.

          >
          > Things are always easier with a Scrum coach and many organizations need to
          > hear things that can only be said by an outsider who isn't planning a
          > long-term with the company. I think you mitigate some of the risk of going
          > without a coach if you do the shorter sprints.

          I'll keep that in mind.

          >
          > I think you'll be fine with remote customers. I've done that dozens of
          > times.

          -whew-

          >
          > Tell the project managers its their choice: Either put up with the
          > questions
          > from the programmers or accept delivery of whatever software the
          > programmers
          > deliver. That is, "we'll ask questions and deliver what you want or we'll
          > take guesses and deliver something wrong." There's an example of an issue
          > best pushed by an outside coach. :) You may be able to push with your boss
          > or someone to get someone in just to lay the groundwork like that for
          > a few
          > days and then forego any long-term coaching, which should save some money.

          Good idea.

          >
          > I'd also suggest looking for ways to make the two part-timers
          > permanent. Can
          > you trade two halvess for a whole, for example? When a Scrum team does
          > their
          > sprint planning meeting they make a *commitment* that they'll deliver what
          > they say they will. This type of serious commitment is hard if half
          > the team
          > can get pulled onto other projects. Additionally, it's tough for
          > someone on
          > two teams to make commitments to both teams.

          I agree, having these 2 people split between 2 projects has concerned me
          from day 1... Hmm...

          >
          > Good luck

          Thanks!
        • Mike Cohn
          Denis-- Since you re got use cases already, start by working through the highest priority scenarios through the highest-priority use cases. So, that might mean
          Message 4 of 4 , Jul 21, 2004
          • 0 Attachment
            Denis--
            Since you're got use cases already, start by working through the highest
            priority scenarios through the highest-priority use cases. So, that might
            mean doing the main success scenario through the top two use cases the first
            sprint. Then next sprint add some alternative scenarios. It works well but
            some programmers have a hard time distinguishing between an error condition
            on a scenario being developed and an alternate scenario--that is, be careful
            to make sure you're getting fully tested and ready-to-deploy code (even
            though you'd be unlikely to deploy it).

            --Mike Cohn
            Author of User Stories Applied for Agile Software Development
            www.userstories.com
            www.mountaingoatsoftware.com


            -----Original Message-----
            From: Denis Haskin [mailto:Denis@...]
            Sent: Wednesday, July 21, 2004 9:13 AM
            To: scrumdevelopment@yahoogroups.com
            Subject: Re: [scrumdevelopment] Advice on whether adopting a scrum-ish
            approach for my case is a good idea

            Mike -- thanks for the response. Very encouraging! (I really like your
            User Stories book, btw.) Some comments below.

            Mike Cohn wrote:

            > Hi Denis--
            > You should clearly be the ScrumMaster.
            > The project sounds like a good one to start with Scrum on because it
            > sounds
            > important and it doesn't sound like the status quo will succeed.

            It's extremely important...

            >
            > You absolutely must get the team focused on delivering working
            > software. You
            > don't say how long the project is so I can't really recommend a sprint
            > length. Standard Scrum says 30 days. With a team that is floundering and
            > spending its time on "infrastructure" I personally wouldn't give them that
            > long. I'd start with a two week sprint.

            My inclination as well but I think I'm going to get serious pushback
            from the lead developer. I'll try but may be more like 3 week iterations.

            > Start by having the customer
            > (whichever 1 or more people you decide that is) prioritize their top dozen
            > or so items. You'll want all the features prioritized later but a dozen is
            > likely a good start. Give the dozen (in one sorted list) to the team and
            > tell them to break them out into the tasks they'd need to do to
            > deliver the
            > first item, then the second, the third, etc. Tell them to stop detailing
            > tasks as soon as they feel they cannot commit to any more. They will be
            > committing to delivering truly usable software--not something that needs
            > more testing, etc.

            We've already got prioritized use cases, they need to be broken out into
            tasks and we'll see how much we can get in the first iteration.
            Probably not even complete use cases--they're really not granular enough.

            >
            > Things are always easier with a Scrum coach and many organizations need to
            > hear things that can only be said by an outsider who isn't planning a
            > long-term with the company. I think you mitigate some of the risk of going
            > without a coach if you do the shorter sprints.

            I'll keep that in mind.

            >
            > I think you'll be fine with remote customers. I've done that dozens of
            > times.

            -whew-

            >
            > Tell the project managers its their choice: Either put up with the
            > questions
            > from the programmers or accept delivery of whatever software the
            > programmers
            > deliver. That is, "we'll ask questions and deliver what you want or we'll
            > take guesses and deliver something wrong." There's an example of an issue
            > best pushed by an outside coach. :) You may be able to push with your boss
            > or someone to get someone in just to lay the groundwork like that for
            > a few
            > days and then forego any long-term coaching, which should save some money.

            Good idea.

            >
            > I'd also suggest looking for ways to make the two part-timers
            > permanent. Can
            > you trade two halvess for a whole, for example? When a Scrum team does
            > their
            > sprint planning meeting they make a *commitment* that they'll deliver what
            > they say they will. This type of serious commitment is hard if half
            > the team
            > can get pulled onto other projects. Additionally, it's tough for
            > someone on
            > two teams to make commitments to both teams.

            I agree, having these 2 people split between 2 projects has concerned me
            from day 1... Hmm...

            >
            > Good luck

            Thanks!





            To Post a message, send it to: scrumdevelopment@...
            To Unsubscribe, send a blank message to:
            scrumdevelopment-unsubscribe@...
            Yahoo! Groups Links
          Your message has been successfully submitted and would be delivered to recipients shortly.