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

Re: [scrumdevelopment] Scrum for the project - Kanban for the rest - rotating developers

Expand Messages
  • daswartz@prodigy
    Hello James, I see you haven t grown the team yet, so here are my thoughts. Things are working well for you today. The nature of your business and customer s
    Message 1 of 3 , Sep 1, 2009
      Hello James,

      I see you haven't grown the team yet, so here are my thoughts.

      Things are working well for you today. The nature of your business
      and customer's needs are that you need a couple of more people. Great!

      If I were in your shoes, I would ask your team (those two people who
      have been doing great things together), how they think you all should
      approach the growth. I think you should discuss the fact that overall
      team productivity will go down for a while as the two new
      developers get up to speed, regardless of how you organize the work.

      If I were in your shoes, I would probably suggest to the team that we e
      add the two developers and continue to organize the work as we have in
      the past until we get a better handle on how the new doubled in size
      team works. If the two developers don't pair program today, I would
      suggest we use pair programming to help the new team members get up to
      speed more quickly. If the developers are pair programming today
      that's even better because they are in practice at it and will be even
      better mentors to the new team members.

      After the larger team is working together for a while, if you and the
      rest of the team feel during a retrospective that flow is suffering,
      or work prioritization is difficult, or "the small urgent projects" are
      suffering, I would float the idea of changing how we organize
      ourselves and our work. I would look for ideas from the other members
      of the team first, but if none are forthcoming, I might suggest
      something similar to what you have laid out.

      Personally, I would try very hard to not make it a "rotate between
      teams" situation. I would definitely keep one team of four people. I
      would definitely keep one daily meeting. With four people I would
      likely suggest two people working on the "big project", and two people
      working on the "support and little projects". I would probably suggest
      trying a schedule where one person moves focus from the big
      project tasks to the little project tasks each week, and vice versa.

      Now, I would probably take this approach because something very
      similar works for us. We have a team of 6 developers. Ignoring
      vacations, etc., our "project" always has 4 developers and the
      other two developers do support and small projects. We pair program
      almost everything, and switch pairs at least every two days, and
      usually more often.

      Each week, one person moves focus between project and support on
      Monday, and one person moves focus between project and support on
      Thursday. Thus, while there are always two people doing support and
      small projects they don't switch their focus on the same day, and
      nobody stays on support and small projects longer than a week at a

      Our small projects and support tasks are managed in a kanban
      pull type manner on a flip chart. A new flip chart sheet is created
      each morning, usually, with about five things on the "to-do" list; a
      mixture of small project and support tasks. For us, a small project
      almost never takes more than three of four days of a pair's time.

      Upsides: We have one team. In the space of a month, everyone
      works on "the project", and everyone does support and small
      project work. We maintain good continuity and whole team knowledge of
      both the larger project and support work.

      Downside: Our morning meeting takes somewhat longer than a solely
      software development meeting would.

      I think it's important to note that no-one sat down and thought out
      the way we manage ourselves and our work. Over several years we evolved
      our process to its current state. While it has been pretty stable for
      the last couple of years, we might decide to try an improvement at any

      Doug Swartz

      Monday, August 31, 2009, 4:37:24 AM, you wrote:

      > I am a manager responsible for a small team (2 server side developers)
      > that
      > has been focussed on a single project for a couple of years. During that
      > time we have quite successfully adopted Scrum and established a
      > sustainable
      > pace for adding features and maintaining the project. In parallel the
      > team
      > has allowed time outside of the ideal man hours set aside for the
      > project to
      > cope with 'operational' work on other projects and smaller more chaotic
      > projects.

      > That has been manageable up until now and the business knows what to
      > expect
      > from us. Now we want to expand and are hiring two more developers and
      > will
      > be taking on more small projects which we want to run in parallel with
      > the
      > Scrum project.

      > I am considering dividing developers time between the Scrum project and
      > using Kanban to manage everything else. I guess that we would need to
      > establish a focus factor for the Scrum project based on a percentage
      > of the
      > total ideal man hours available and then the team will need to learn to
      > estimate appropriately.

      > I am also considering a scheme to rotate developers on and off the Scrum
      > project every sprint (two weeks) to promote shared code ownership and
      > keep
      > things interesting. Of course I realise that not every developer is
      > equal
      > and that this might make the velocity unstable.

      > I am really interested in people thoughts on this. Am I about to run
      > into
      > trouble? I mainly want to find a way to keep up the good work on the
      > Scrum
      > project whilst getting a grip on all the other stuff which does not seem
      > suited to iterative development.

      > Kind regards
      > James Brook
    Your message has been successfully submitted and would be delivered to recipients shortly.