Re:Multi-project and Multi-po
- Very interesting to hear your perspective, David!
We have struggled with many of these issues as well. Our CEO definitely likes to get status updates. And, like, you our different POs never seem to agree on what they want up front, it is always after-the-fact, and based on 'what, i really need xxx", not any kind of strategic plan or even value proposition.
We are also a single dev team, so we have also had to make the 'support time is outside the scrum' adjustment. I have a team of 7 developers. Like you, essentially 1 FTE is consumed doing maintenance activities. This 1 FTE is highly variable: some days all day, other days nothing. The question is, how do you handle support requests, and all items considered too small to make a project?
I have read two approaches to handling this:
(1) designate a firefighting team, and give production issues and support to this person( or people). Their activities are outside the scrum, and presumably, the scrum is largely unbothered.
(2) have only one team, and have them all come to the scrums, but list firefighting as an impediment.
We have been doing (2), but I am beginnign to think (1) might be better. What do you do?
--- In email@example.com, David A Barrett <dave.barrett@...> wrote:
> >I have read many of the threads on this topic already,
> >so I know that the best approach is simply to avoid
> >these. And, at least in part, I will continue to try that
> >as 'plan A'.
> I'm struggling trying to agree with you. Mostly because the situation you
> describe is close to what we've been doing for the past 6 years. And we
> find that Scrum works quite well.
> We have a single code base and about six departments (Finance,
> Underwriting, Claims, Title Insurance, Loss Control, and Communications)
> that are all looking for changes and enhancements to the system. Luckily,
> each department tends to want work done in a specific part of the system
> which is primarily their "turf", so we don't get into conflicting requests
> about functionality all that often.
> Yes, you need to bend a bit. There is no "Sprint Goal". It takes a week
> to get all of the PO's into meetings to review progress and identify new
> items for the next Sprint. So we have a gap in between Sprints to allow
> this to happen.
> Right from the get-go, our concern was that after we'd have all of our
> meeting and then sat down as a team to decide what we could and could not
> put into the Sprint Backlog that we'd leave out something some department
> really wanted and they'd kick up a fuss. So we've scheduled the whole
> thing so that we publish an "Included & Deferred" list on Monday
> afternoon. The weekly department head meeting happens on Tuesday morning,
> and our CIO brings the list as an agenda item to that meeting. The idea
> is that if anyone is bent out of shape by our selections, all of the
> people needed to make a compromise are already in the room, and they can
> decide who's item will get ditched in order to make space for the other
> In six years, this has never happened. Not even once.
> One of our planning meetings is with the CEO, she'll sometimes have her
> own projects, but more often than not she simply wants to keep oversight
> on the department projects. To makes sure that they're keeping in line
> with department and company goals and to deal with contentious issues.
> So do we consider the department contacts that we meet with every Sprint
> "Product Owners", or just the CEO, or maybe the Senior Management Team?
> Honestly, I don't think it matters. They fill the role of PO for 99.9% of
> the things that we deal with them on, and the only time they ever might
> not be the final word on priorities is if the Sr. Mgmt team needs to
> juggle inter-departmental stuff.
> Furthermore, the Development Team comprises all of the programming
> resources in company. So the Team members are also collectively
> responsible for handling all of the support issues that come up during the
> Sprint. We've built that into our available time for project work each
> Sprint, and we have rules about how big, unurgent or unimportant something
> can get before it has to drop out of the "support" queue and into the
> "project" queue (Product Backlog).
> Communication is trickier, too. There's too many people to keep track of
> to rely on the normal one on one interactions to keep everyone informed of
> what's going on. We've taken to publishing a weekly status report of all
> the Sprint Items. It's actually a single document that we keep updated
> contstantly, but we send out a link to it each week. I was reluctant to
> go there, but we've found that it seems to quell a lot of anxiety amongst
> the users if we do it. Our CIO and the CEO seem to like it too, even
> though anyone could just walk over and look at the whiteboard any time
> they wanted.
> Is it still Scrum? I think so. Others may not. I'm trying to avoid,
> "Scrum but...". I've tried to keep pretty tightly to the principles, and
> adapt the practices where necessary to make it work.
> Dave Barrett
> This e-mail may be privileged and/or confidential, and the sender does not
> waive any related rights and obligations. Any distribution, use or copying
> of this e-mail or the information it contains by other than an intended
> recipient is unauthorized. If you received this e-mail in error, please
> delete it and advise me (by return e-mail or otherwise) immediately.
> Ce courrier électronique est confidentiel et protégé. L'expéditeur ne
> renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion,
> utilisation ou copie de ce message ou des renseignements qu'il contient
> par une personne autre que le (les) destinataire(s) désigné(s) est
> interdite. Si vous recevez ce courrier électronique par erreur, veuillez
> le supprimer et m'en aviser immédiatement, par retour de courrier
> électronique ou par un autre moyen.