Small Team, Multiple Projects plus ongoing support
Hi,
It's my first post here, so I hope I followed the rules. :-)
I searched for "multiple" and "multiple projects" but found nothing that matches my problem.
As the title says we have several problems that prevent us from introducing scrum (we tried, but failed so far).
First we are just 5 people. 2 senior developers, 3 juniors. The Role of PO and Scrum Master (we think) should be taken by the two seniors (which include myself). That leaves a team with just 3 junior developers. So I think at least one of the seniors have to take two roles. In our case that would be the prospective scrum master (me).
Is that a good practice? Or should I give the Scrum Master role to one of the juniors? I found very different opinions. Most stating that PO und SM should not be also member of the development team. That would mean we aren't able to use scrum at all.
The other problem is, that we don't have the one big project every two years that everybody ist committed to. We run 2 or 3 projects in parallel, and we have a lot of support for older projects to do that is hard to estimate.
So first the "support problem". We discussed several solutions. We could remove one of the already to small team and he is solely responsible for support (problem is that no one of us can support everything).
Or should the support and the work on the sprint should be timeboxed? That could be difficult because the nature of support cases is, that they are often urgent and hard to foresee.
Second the multiple project problem. The apparent solution is to have all projects in one backlog. Of course we try to focus every sprint to 70-80% on one project, if possible. But the problem is the estimation. The projects have often different platforms (like winform, wpf or asp.mvc) and the same task often has very differnet complexity depending on the platform it should be solved with. But such technical details should not influence the estimation as I understand it. On the other hand the Backlog Items are often of very different qualities. Simple Guis with just a few crud operations, complex algorithms for route optimization or RS232 Communication for device control. It is hard to estimate thoose things relative to each other and without regarding the platform. It would be comparing apples and oranges. We tried it, but we realized that "One Point" in one project (or platform) has a different meaning than "One Point" in an other. So it depends on the mixture of projects in a sprint, what the velocity will be. Therefore the velocity could never stabilize.
Thanks for suggestions.
Best regards,
Holger
> So I think at least one of the seniors have to take two roles. In our case that
> would be the prospective scrum master (me). Is that a good practice? Or
> should I give the Scrum Master role to one of the juniors?
The smallest recommended size for a Development Team is 3 people. Then again, there's nothing to stop the PO and the Scrum Master from also being members of the Development Team - so you could potentially have 5 developers. Best practice is to make sure that the PO and the SM are not the same person, due to a potential conflict of interests.
> Or should the support and the work on the sprint should be timeboxed? That could be difficult because the nature of support cases is, that they are often urgent and hard to foresee.
Yes, it should all be timeboxed. There are several models for accommodating support work in Scrum, including variations on a fast-track option for emergency items if project work is also being done. Many organizations prefer to use a dedicated Kanban team for support rather than Scrum.
> such technical details should not influence the estimation as I understand it
The only people who can really estimate are the people doing the actual work. They can estimate anything they like, from writing documents, to coding or configuration...or to going down to the supermarket and buying apples and oranges for comparison. All of these very different things, added together, can represent a sprint backlog. The sprint will be timeboxed, only certain resources will be available, and so the backlog can only be of a certain capacity. The developers have a responsibility to size each item accordingly so a sprint backlog can be formulated.
Thank you for the input. So our number is not as a big problem as i thought.
I Think I have to clarifiy my question about the estimation.
It was not the question who should estimate (of course the team and the people that do the actual work) and it is also clear what to estimate. The problem is how.
I should have explained that we tried to use the planning poker game with Fibonacci like numbers. The first step was to find a typical small backlog item, which everybody knows and understands. This one is given the value 1 or 2 (I'm not completely sure if it has to be a real or an invented item and if the item has to be the same for every ongoing estimation even 20 years later). Now all other items should be estimated with the Fibonacci numbers relative to that item. The metapher used for this is, that you look from a distance (where you can't see details) on a couple of houses (or Haystacks). You can't see Details, but you can easily state that one of them is double the size of another.
Know I see us in the situation of not looking at a series of different sized haystacks, but we look at one house, one car, one Tree and one haystack and we have problems to decide if one is double size of the other.
Even if I am the one doing the work, I have no idea, if implementing a saving heuristics algorithm for route optimization (well documented in literature) is 4times, 8times or 16times the size of a simple contact list with detail view and crud operations in winform. Or if the implementation of a well documented RS232 protocol is 2times or 4times the size. Or if a simple product list with crud operations in asp.mvc (and not winform) is the same size or double size.
Is it just a matter of excercising?
Or are there other systems for estimation? I thought that this relative estimation is on the core level of scrum.
The Support question:
So you think it ist possible to timebox the support? I fear that either the time allocated will not be constant over time (impacting the velocity if the sprint length is not adjusted accordingly). And what to do if the time budget is used up, but there are still important support cases to handle? And if the time needed is lower than expected, the developers will use the time for the sprint work, also impacting the velocity.
> Is it just a matter of excercising?
It certainly gets better with practice.
> Or are there other systems for estimation?
Apart from Planning Poker you could try "the estimation game", also called team sorting.
Another option (although controversial) is to assume one point per card (story counting), which encourages the authoring of smaller stories. I've had good results with this in certain cases. Martin Fowler had positive experiences with story counting as well, though only with advanced teams.
I wrote an article on these techniques: http://agile.dzone.com/articles/agile-estimation-practice
> So you think it ist possible to timebox the support? I fear that either the time allocated will not be constant over time...
It almost certainly won't be constant. If you use Kanban, it won't matter, because the timebox is just a period over which metrics are assessed. In Kanban, there's a backlog of work that is actioned, but no planning of items into a timebox or sprint.
In Scrum there are a number of options. Perhaps the most common is to operate fast-tracking for defects that cannot be deferred and planned into a future sprint. It isn't ideal, as the current sprint goal may be compromised by the inclusion of such unplanned work, but it is pragmatic.
btw
http://agile.dzone.com/articles/agile-estimation-practice not working
Working now :)
Hi,
Here is an explanation of how our small team handles multiple projects using Scrum:
https://rodrigopinho.com/2015/08/24/scrum-with-a-small-team-and-multipl…
Best regards,
Rodrigo Pinho