Forums

All of the software developers in my company recently took general scrum training. Several of us also took product owner and scrum master training.

My team consists of 5 developers and one product owner inside our company. We are contractors, and there are several stakeholders we deal with regularly at the company we do work for.

Our software products consist of plug-ins for an existing commercial software product. We all use similar technology, but each plug-in is different and usually has a different stakeholder at the parent company. We are currently working on 4 different plug-ins. Each plug-in sub-team consists of 1 - 2 developers.

We have decided that we would like to use Scrum beginning in January 2013. We currently use Visual Studio requirements, tasks, change requests, and bugs to manage our work items.

1) Do you think Scrum is appropriate for our situation?

2) How should we manage our product backlog? One big backlog, one backlog for each plug-in...? Each stakeholder will have input into prioritizing the backlog for their plug-in.

3) Would it help us if we switch to the Visual Studio Scrum template?

I can think of a lot other questions, but maybe this is enough to get started. Thanks in advance for your help.

Hi Mark,

those are a lot of questions - and they are not easy to answer. There is no clear "yes" or "no" in your case.

1) Scrum will work for you. However, you will quickly unearth problems in your current setup that lead to surfacing impediments. If you don't solve any of them, you will not reap much benefit from Scrum.

2) Each team should only be fed from one Backlog. On the other hand, every product should have it's own Product Backlog. There goes your first problem: Do you have many products or is it a single one? If there are multiple products, should the small teams (1-2 people) be fully dedicated to them or will they switch between products?
I cannot give you a clear recommendation here. Ponder the questions and try something - if it doesn't work, try something else. Your Product Owner will need quite some support from you though.

3) I don't give much on tools. Sticky notes on the wall are still the most productive way to plan and organize stuff. If you go for a tool (e.g. VS) just make sure you don't let the tool fool you. Don't change your processes because a tool forces you to.

If you have more questions, we are happy to discuss them with you. You probably will get better discussions though, if you just ask a single question per thread - that's at least what I would prefer :-)

Merry Christmas!

Dominik

Hi Mark

I'd agree with each of Dominik's points, but also point out that you need a Definition of Done that is appropriate for all items across the shared backlog.

Getting the Development Team and the Product Owner to agree on a DoD for all plug-ins, and which takes each item to the point where it is potentially releasable, will shake out a lot of issues and it should help a lot in decision making.

Hey Mark,
Your development team is awfully small (5 correct?). Normally your DT should be +- 7. Do you have enough resources allocated?

Your development team is awfully small (5 correct?). Normally your DT should be +- 7. Do you have enough resources allocated?

The appropriate DT size for Scrum is 6 + or - 3, so between 3 and 9 developers. As it turns out the smaller end of that range is much more productive than the top end of that range.

In summary, small dev teams are GOOD!

Mark,

It's hard giving advice without knowing full context. I coached a team with a similar situation to yours, except the products were mobile apps instead of plugins. That team had a really hard time having ~8 product backlogs, so they consolidated it into one "team backlog." Because they wanted to keep the team working together as a team, have a consistent focus for a while, and keep product skills cross-pollinated, they focused on release themes, and tagged their product backlog items according to the release theme the PBI belonged to.

So, as an example... Products(in your case, plugins) A, B, and C.
Sprint 4 might include PBI's tagged with "A v3.1" (Release 3.1 of product A), "B v5.2", etc
Sprint 5 might include PBI's tagged with "B v5.2" (finishing up the release), "A v3.2"(small), and "C v1.7"

The releases were done completely separate from the sprint end boundary(and occurred 1-2 times a sprint), though all code was "potentially shippable" pretty much all of the time. Scrum says that the end of sprint increment must be potentially releasable, but Scrum does not prohibit you from releasing any number of other releases at any time. This is something a lot of teams don't understand. At the minimum, the end of sprint increment must be potentially releasable. How many other releases you want to do is up to you.

The focus on one(or at max two) product at a time allowed for teamwork, swarming, cross pollination, and focus. The releases were small incremental releases so that no one product would "hog" the team's bandwidth for very long(or if it did, for good reason!), and this allowed the releases to essentially be ordered by value on the product backlog. It also allowed value to be assessed across products.

As you can imagine, the downsides of creating small separate teams/backlogs can be that the most valuable stuff is in product A, but there are only 1-2 A developers. Meanwhile B and C developers are working on things not nearly as valuable, because they are restricted to working on their own products. Also, this tends to silo the tribal knowledge about the products and doesn't allow for as much parallel development and bottleneck removal. Having said that, there may be a good reason to go with separate teams, so there are not clear cut answers here. There may be more to your context than we know.

Like Dominik said above -- start with something quickly and try to iterate towards a better way.