3

I work in a team of 15 that implements scrum (as well as we can). Each person in the team has multiple products, that only they work on, and each of those products are unrelated to any other product on the team. However, put everything into one backlog to facilitate scrum.

We have a scrum master that leads the team, but no product owner (because there are so many products all unrelated, each member is responsible for their own backlogs).

We have noticed in daily stand ups that while it's good to catch up, whenever you are not speaking, the products you are hearing about from other members have nothing to do with your own work, and there isn't a single product that has more than one member working on it.

I would like to ask if it sounds like we should even be using scrum? If so - are there any ways we can make our standups and sprints more relevant for each member?

Thanks

  • 2
    If there's no central coherence, then there's no "team." Do you really have 15 people working independently on a portfolio of 30+ products, or are you confusing tasks with products? – Todd A. Jacobs Jan 28 '18 at 4:59
  • We have a central theme of health research via big data analysis, where we have projects in cancer, cardiovascular etc etc, where each person covers 2-3 disease areas, and any new project that comes in i.e a 6 month project on diabetes will be taken up by the person that specializes in diabetes. They meet with the client, do the work, write academic papers without the input of anyone else on the team. – brucezepplin Jan 28 '18 at 7:47
  • 2
    What motivated you to use scrum in the first place? What were you doing before? – Vicki Laidler Jan 29 '18 at 4:50
  • 1
    We were a new team told to adopt SCRUM as it fit with existing software development teams where we work. I.e arbitrarily – brucezepplin Jan 29 '18 at 14:55
  • Based on the terminology used, wanted to share The Scrum Guide that is the definition. – Alan Larimer Jan 31 '18 at 13:01
3

It seems that you're using some Scrum characteristics but not the Framework. There are some gaps in your description that I'm curious about:

  • Who manages the backlog and sets priorities?
  • Do you do plannings, reviews and retrospectives?

It's really hard for me to imagine how it would be a planning meeting for a group of people where each person works in a different product.

So, answering your questions:

it sounds like we should even be using scrum?

It doesn't. You could ask your managers why are you "using Scrum", if it's just because it's a trend then you could try something else. Also, I think it would be easier for you guys to filter the backlog based on each one's product, and start using a Kanban board to follow-up progress. It's simpler and it fits for teams and "solo teams" :D

are there any ways we can make our standups and sprints more relevant for each member?

You can define time-boxes for releasing your increments and call it a Sprint, it won't be in the Scrum perspective but it's a way to organize deliveries.

I would keep the standup meetings as you have some relation between what you call "different products", mostly because if they are pragmatic the team can always benefit from it, but I would try to see which products would be really involved in each of the standup meetings to avoid taking people time to listen to things they aren't involved.

  • 1
    Hi Leonardo - this is some really helpful advice. Each person is responsible for their own separate backlog - they are the leads on all their project,which gets fed into one big backlog. We do have retrospectives, where we discuss room for improvement - this could be anything concerning a project or time estimates. Having a separate board per project seems reasonable to me. thanks. – brucezepplin Jan 31 '18 at 20:49
2

It sounds like there are a few things at play here:

Product vs applications vs Project

That many products sounds abnormal - certainly difficult to maintain. Usually when I see people say they have so many products, they really mean applications or projects. There are two things I usually find helpful in discussing a product: first, what does the customer think? Would your customer say that your product is data analysis, or cardiovascular data analysis? And second, it your approach similar between the different types of data analysis. They don't have to be the exact same, but similarities in approach mean that improvements in one area can carry over to others if you treat them as 1 (or fewer) products). Think of Microsoft Office. Word, Excel, and Powerpoint all work very differently, but there are all ways to create documents of some sort or another and treating them like one product has huge advantages.

The Benefit of Teams

What you describe doesn't sound like a team. It sounds like a group of people who happen to share an office. A proper team can benefit from more flexibility as well as increased productivity. For example, if more work comes in for one type of work than another, a team can pivot their attention to field that work, but the setup you describe must force those projects to wait. Also, most work that a team takes on has some forms of repeat work between tasks. Often times teams working together can handle this work more efficiently so they gain higher productivity.

Where Teams Don't Work

If the work is radically divergent, it may be that each type of work requires complete attention and all of a person's time to keep up with developments in that type of work. This is very rare - usually only effecting bleeding edge research, but I don't know what kind of work you're in, so maybe this applies.

Using Scrum

Scrum is designed to help teams solve complex problems and iteratively develop products. It isn't that Scrum won't work for other things, but this is what it really excels at. If this isn't what you are doing, there may be better approaches for you.

  • Hi Daniel - the are a few things each product has in common - SQL / stats and machine learning all sourced from a common national dataset. And to produce academic papers showing the research. So think of each of those components as part of template for each product. It's just that each product has a separate person working on them. I.e I have usually three products at any given time, so split my sprints across those products. We certainly could start imposing that people share products, but that is seen by some as double the work or "checking someone else's work" unecassarily. – brucezepplin Jan 28 '18 at 18:26
  • "It isn't that Scrum won't work for other things" -- I would add to that. A lot of what Scrum teaches comes from common sense. In other words, a lot of Scrum's approach can be used in other settings as the one described by the OP. – Alex Jean Jan 30 '18 at 4:58
1

That is not working within the Scrum framework, but Scrum In Name Only (SINO).

Scrum is a framework for developing, delivering, and sustaining complex products.

When choosing to share people across multiple projects, efforts, products while calling it a team, the Scrum framework would be an improper force-fit. One way that ineffectiveness and inefficiency is being exposed is what you call the daily stand up, probably really a traditional status report.

This classical mismanagement may continue with its costs ignored. A better alternative is working toward changing the approach to a more dedicated personnel model, and change can be very challenging.

  • "Scrum in Name Only"... oow - need to adhere to a "pure Scrum" now? – Alex Jean Jan 30 '18 at 5:00
  • 1
    @AlexJean Yes. Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices. RTFM – Alan Larimer Jan 30 '18 at 19:27
  • 1
    Thanks - I never noticed but yes the last bit you shared is in the official documentation. – Alex Jean Jan 31 '18 at 4:29
  • 1
    @AlexJean I've started a chat for the Scrum framework if you want to have any additional discussions. – Alan Larimer Feb 9 '18 at 21:18
0

If the "products" (you can name it projects or whatever is suitable for you) are not related then there is no need to have a stand up together because the status is not important to the others, and in your case, you actually are not one team. One stand up meeting will distract the ones who are not interested in the information being shared in the stand up.

It is better to have the stand up with the related team members only to keep focusing on the project and the status of that project (milestones, issues, achievement... etc.) rather than to involve everyone.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.