41053Re: [scrumdevelopment] Scrum for the project - Kanban for the rest - rotating developers
- Sep 1, 2009Hello 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
Monday, August 31, 2009, 4:37:24 AM, you wrote:
> I am a manager responsible for a small team (2 server side developers)
> has been focussed on a single project for a couple of years. During that
> time we have quite successfully adopted Scrum and established a
> pace for adding features and maintaining the project. In parallel the
> 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
> That has been manageable up until now and the business knows what to
> from us. Now we want to expand and are hiring two more developers and
> be taking on more small projects which we want to run in parallel with
> 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
> things interesting. Of course I realise that not every developer is
> and that this might make the velocity unstable.
> I am really interested in people thoughts on this. Am I about to run
> trouble? I mainly want to find a way to keep up the good work on the
> project whilst getting a grip on all the other stuff which does not seem
> suited to iterative development.
> Kind regards
> James Brook
- << Previous post in topic