Developing multiple small Products within one Scrum Team

Julia,

You might want to consider this question...

Is this a problem with Scrum, or is this a problem exposed by Scrum?

I struggled with how to reply to this thread. This encompasses what I
wanted to say and does so with nearly 2 less paragraphs. Well said.

On Thu, Dec 13, 2012 at 1:05 PM, <ScrumForum@scrum.org> wrote:

>

Hi Julia

being a novice (just passed my first course and still introducing Scrum in our team), I still feel an urge to reply, because our situation is exactly the same.

I think two things are crucial to change:
- enforce a SPREAD knowledge across the team, so that the whole team can work on more or less all products
- whenever possible, try to focus on only one product per sprint (not necessarily a strict rule, but probably best to enforce the know how as well, plus allowing a clearer picture of what the product owner(s? as in our case) want(s) to achieve in the sprint

Hope this helps.

Without that, I think it might be called scrum, but is not really giving you any of the potential benefits (like team autonomy etc). And I can give this harsh judgement as "our mess" is exactly that ;-))

Cheers

Well said.

Thanks Ryan, I'll take that as a compliment, especially since I'm not well known for my brevity...

In fairness to Julia, though, I responded to a question with a question -- which may appear to some as unhelpful. I hope she understands that I really am trying to help, and my advice to her will be very different depending on how she answers that first question. Such is the nature of "complexity" I guess.

In my opinion, Guido points to where the main focus should be:
The team should aim to share knowledge of all the products.

There are several techniques that might help:

Pair-programming
- make sure that developers are always paired up when working on code that is not widely known in the team
- this will ensure, that knowledge is spread gradually throughout the team

Always pick the highest priority task
- instead of having the developers pick their favorite tasks (for instance on the product only they know), let them always pick the highest priority task
- even though this will result in a productivity set-back at first, since developers are working with unfamiliar code, the investment will pay back quite fast
- the developers will be forced to acquaint themselves with the code, which will lead to fewer bottlenecks and higher productivity

I would not try running single-product sprints, because in the real world, that is often not possible or feasible.

While I think all of these are great options for the team to choose from, I
would recommend you focus on helping the team understand the importance of
filling in the gaps and shared knowledge. You may need to investigate why
they feel so tied to a production (assuming that's the case) and have not
yet been compelled to work across product lines. This often requires
creating an environment where it's OK to lament external or social
pressures.

Once the team understands a) silos are limiting them and b) they are
capable of solving the problem, only then would I suggest they explore ways
to do so, including this forum thread as a source of ideas.

My only concern with previous responses is they suggest - in language, not
intent I'm sure - you are the one to solve this problem for them by
deciding or enforcing a tactical way of working. This would not be
appropriate for a Scrum Master.

On Fri, Dec 14, 2012 at 4:35 AM, <ScrumForum@scrum.org> wrote:

>

I agree with Charles and Ryan.

One additional thought: Is Scrum the best way to organize your lone gunmen right now?
Scrum aims for teams - from what you wrote, I do not see that you have more than loosely coupled individuals.

Thank you for all your statements.....my thoughts are the following:
- I think it is more a problem of our business being a small company working with a lot of different clients than a problem of the people or the team working here. I can see that they want to become a team but have those obstacles in their way!
- I like the idea to spread the knowledge by always working on the task with the highjest priority, that might be a chance. We absolutely don't have the opportunity to work on one single product during a sprint, that is not practicable for us. My question here would be, from a work psychology point of view...is it ok when every person works on 4-5 products at the same time?

Is there anybody in this forum who actuality dealed with the same problem and found a good way?

From my point of view, If the stories are really INVEST, it doesn't matter, if they are related to one or different projects.
Yo only have different sprint goals regarded to the different projects but nothing and nobody prevent you from working at the stories form top to low priority with the whole team.

Think about how you handle issues when person with the knowlege is not around. If you haven't then there is a business risk.

> is it ok when every person works on 4-5 products at the same time?

Two things. Firstly, it's OK as long as you have a Product Owner who can prioritise the backlog for *all* of these items in a fair and competent manner. That's a tall order, but it does happen with some BAU (Business as Usual) workstreams. Secondly, even if you have such a PO, the developers will *all* need to be versed in *each* of the product areas so there is a collective team ownership of the backlog. You've already indicated that this is a problem in your situation.

> Is there anybody in this forum who actuality dealed with the same problem and found a good way?

I wouldn't say "good", but I found a sustainable workaround. I inherited a BAU workstream with 5 developers and 6 different products to be maintained. Two of the developers were reasonably cross trained in one product. Everything else was in silos, and the team had all of the problems that entailed.

I started to knock down the silos by associating each backlog item with a level of risk. The developer who knew about the relevant product would assert (during planning) how big they thought the risk was. The low risk items were then tackled by pair programming with another developer. Soon that "other developer" was able to handle low risk items themselves, and within a couple of months they were handling higher risk items.

I remember I had 3 main challenges to overcome while implementing this change.

Firstly, I had to convince the Product Owner that it would be worthwhile taking a slight short-term hit in productivity while time was spent cross training. That was actually the easy part, because the PO knew he would end up with a more resilient and multi-skilled delivery team.

Secondly, I (with the PO's support), had to convince *all* of the team members that they should be cross-trained across all products. That was the hard part. Really hard. Two of the five were in their comfort areas and did not want to leave. It took a collaborative organisational effort to persuade them of the benefits of extending their skill-sets. It took months to get those two developers on board.

The third challenge was a bit more obscure. Some of the backlog items were mini-projects in their own right and did not play well with the rest of the backlog in terms of breakdown or prioritisation. This was arguably the PO's problem rather than the team's problem, but we found a solution by breaking out two team members from the BAU workstream to form a Small Change Scrum that handled these small projects. In retrospect I shouldn't have allowed the term "Scrum" to be applied to that team, because it only had two members. But more importantly, as ScrumMaster I had to manage the demarcation of work carefully with the Product Owner and the teams. I point this out because although the principle of sharing a backlog across teams is valid, it can encourage the development of unwanted silos unless you stay on top of it.

Hey Ian,

thanks for your reply. Your story thounds very interesting. Maybe I can transfer some of your solutions to solve our problems!

Julia,

I promised I would give some further advice above, so I'll add a few bits.

I think the first thing to realize is that this is not a problem with Scrum so much as Scrum "telling you something." The second thing to realize is that this sounds like an issue that is primarily intra team(though maybe there are external forces you didn't mention). As trainers here at Scrum.org, we teach that intra team problems/challenges should generally be solved by the team, not the Scrum Master, because the Dev Team is "self organizing." The term "impediments" in the Scrum Guide refers more to the Scrum Master solving problems with external(outside the Scrum team) forces involved or needing to be involved. One of the ways Scrum encourages teamwork is by encouraging the Dev Team to identify and solve challenges on their own. This is not to say that the Scrum Master shouldn't help facilitate the discussion -- maybe they should. I think this is why Ryan was suggesting above that you first get the team to identify the challenge. If they don't think your challenge is any big deal, then they will probably never truly solve the challenge.

Referring back to external forces, are there organizational forces that essentially encourage team members to be "individuals" and "lone rangers"? Also, if those forces stay in place, again, the challenge will probably never be resolved. OTOH, maybe you could work with the organization to help all involved realize that what you really want is a "team", not a group of individuals. Once that goal is established, then using the pairing techniques above should get you where you want to go. Start small, and work up to spreading the knowledge around the team.

I have coached a team that was in a similar situation(though they weren't really 'lone guns' -- more of small sub-teams within the team, which isn't really allowed in Scrum). I worked with the org to figure out that indeed we wanted to spread the knowledge around so that if one of the lone guns were to become unavailable (sick, vacation, leave company, hit by a bus, etc), the business would not be put at undue risk. Once the organization established knowledge spreading as a goal, they realized that there might be some short term costs involved when pairing happened, and explicitly let the team know that this was just fine, because it was in line with organizational goals.

Wrt pairing, true paired programming is a big investment of energy and commitment. While I generally like the paired programming practice, I prefer to ease developers (whether they be testers, BA's, programmers, etc) into it by doing what I call "casual pairing." Casual pairing is essentially what Ian described above -- two developers sitting together, working on something that is not high risk.

As part of the "casual pairing" approach, I encourage a couple of things:
1. In this casual pairing approach, usually there is a driver who is leading and talking and a passenger who is observing and trying to learn^1.
2. Don't speak up every time you disagree with the path that's being taken. Instead, choose your spots and ask questions to understand. Don't be afraid to disagree, just try to do it sparingly and when you feel like it's important to do so.
3. Don't feel like you both have to agree on every path that is chosen. Defer to the driver, and try to make sure that drivers and passengers take turns playing each role.
4. If you can do it without appearing combative, when you seem to disagree heartily on something, ask for a 3rd opinion. Remember, "individuals and interactions" and "self-organization"!

^1 Contrast this with the much different approach in true Paired Programming where the person without the keyboard is giving navigation direction(the "navigator"), and the driver is the one fulfilling that navigation by operating the keyboard, generally following whatever navigation advice the navigator gives. Again, these folks "choose their spots", ask a lot of questions, and may disagree at times.

My point about casual pairing is that it is a middle ground approach between lone guns/silos and true paired programming. Once teams get comfortable and happy with the casual pairing, I encourage them to read up on and experiment with paired programming. Again, start small, and iterate in small increments!

I think there is no short term solution to this situation

There is only long term solution that is knowledge sharing

Additionally I recommend you/your team to use pie chart to know if work is evenly distributed in team, because sometimes it happens that 1 or 2 people in team are overloaded, which becomes bottleneck (if we don't see pie chart we don't realise what is happening)