Shared resources in SCRUM

[Sita Pun]

Hi ,
I would like to know how do we handle the situation when resources are limited and team members have to be shared among the multiple projects especially while implementing scrum?

Regards,
Sita

[Ron Jeffries]

Setting priorities and doing most important projects first is the
best thing I know.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
You can observe a lot by watching. --Yogi Berra

[Gustavo Cebrian Garcia]

It is not the ideal scenario, but, If you do not have anyother way:
=======
Scrum and XP from the Trenches by Henrik Kniberg

16.7
If you have one person that will divide his time among multiple teams, like teh aforementioned DBA, it is a good idea to still have him primarily assigned to one team. Figure out which team is likely to need him the most, and make that this "home team". When nobody else is dragging him off, he will attend that teams daily scrums. sprint planning meetings, retrospectives, etc
=======

Additionaly, I would say he can attend all the daily scrum meetings ( you need different times for the daily meetings, of course, which I think it is something advisable )

Is that OK?

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To post to this group, send email to scruma...@googlegroups.com.
To unsubscribe from this group, send email to scrumallianc...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.

[Bob Sarni]

Hello, Sita.  On Wednesday, July 7, 2010, at 7:08:55 AM, you wrote:

> I would like to know how do we handle the situation when resources are
> limited and team members have to be shared among the multiple projects
> especially while implementing scrum?

Hello Sita – what Ron suggests should be the first course of action – setting priorities and doing the most important projects first. Has your organization spent any time looking at the impacts of not doing this? Is having resources spread among many projects providing any value? What if they focused on doing the most important projects first and then moving to the next project(s)? They could be seeing ROI sooner instead of having many projects in the pipeline and timelines for releases taking longer because of shared resources.

Then again, maybe they have done this analysis and still determine it is best to have people shared amongst projects. You still can do Scrum but capacity and velocity will be impacted. Your Scrum teams will have to have some crucial conversations about priority among projects, capacity of team members for Sprints, and especially the inefficiency of task switching.

Here is a good article on InfoQ on the impacts of task switching from a fellow certified Scrum coach (CSC), Roger Brown -  http://www.infoq.com/articles/multitasking-problems

Bob Sarni, CSC, CST

[Gustavo Cebrian Garcia]

Hello Bob,

What do you think it is the best practice if you do not have a choice?

Thanks.

Gustavo.

--

[Bob Sarni]

On 7/7/10 7:38 AM, "Gustavo Cebrian Garcia" <g.cebria...@gmail.com> wrote:

Hello Bob,

What do you think it is the best practice if you do not have a choice?

Thanks.

Gustavo.

If you really have no choice, I mean really – If I were the ScrumMaster, I would be working with the team to help them understand the impacts of shared team members and having them discuss what they can do to limit or deal with those impacts. I have worked with teams that were in similar situations where the team can up with some very innovative ways to deal with this. In one case, the shared/limited team member was testing so the development team took on most of the testing activities and used the testing person more as an SME. This of course impacted velocity in the beginning but eventually they got to the point where they did not need the “testing” person (I do not like the term resource). It is always better, I think, when the team can move past the point where activities are associated with a person. The “team” is responsible for producing potentially shippable product increments. There will always be SMEs and the team should utilize SMEs when needed, but maybe more as an advisor and not a bottleneck. I had other situations with other skills – data modeling, compliance auditors, technical writers – fill in the blank. In the end, using shared resources has its impacts, the team and stakeholders should be aware of how this impacts release dates, quality, morale, team dynamics, etc. Visibility, visibility, visibility....

Bob Sarni, CSC, CST

[Ron Jeffries]

Hello, Bob. On Wednesday, July 7, 2010, at 8:36:31 AM, you wrote:

> Then again, maybe they have done this analysis and still determine it is
> best to have people shared amongst projects. You still can do Scrum but
> capacity and velocity will be impacted. Your Scrum teams will have to have
> some crucial conversations about priority among projects, capacity of team
> members for Sprints, and especially the inefficiency of task switching.

It seems to me to be clear on the face of things that sharing
resources "because we don't have enough" is always bad.

Queuing theory suggests that even sharing a resource which would
otherwise be idle can be bad. Sharing one where there's enough work
full-time on one project is [almost?] invariably an inferior
strategy.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Sometimes you just have to stop holding on with both hands, both
feet, and your tail, to get someplace better. Of course you might
plummet to the earth and die, but probably not:
You were made for this.

[Bob Sarni]

On 7/7/10 9:32 AM, "Ron Jeffries" <ronje...@acm.org> wrote:

Hello, Bob.  On Wednesday, July 7, 2010, at 8:36:31 AM, you wrote:

> Then again, maybe they have done this analysis and still determine it is
> best to have people shared amongst projects. You still can do Scrum but
> capacity and velocity will be impacted. Your Scrum teams will have to have
> some crucial conversations about priority among projects, capacity of team
> members for Sprints, and especially the inefficiency of task switching.

It seems to me to be clear on the face of things that sharing
resources "because we don't have enough" is always bad.

Queuing theory suggests that even sharing a resource which would
otherwise be idle can be bad. Sharing one where there's enough work
full-time on one project is [almost?] invariably an inferior
strategy.

If you read my first post in this thread you will see that I completely agree with you :) This post is in response to a “what if we have no choice” question – I would also say, there is always a choice :)

Bob Sarni

[Michael James]

One other piece I'll add: we want the person whose skills seem to be the bottleneck to start mentoring others. This is more likely to happen in a team environment. Rushing him from place to place to do task work just digs the rut deeper. The idea of "resource management" is part of the problem. Focus instead on learning teams, and eventually a learning organization.

--mj

[Sita Pun]

Thanks a lot for sharing your views.

If members are shared for multiple projects and if we implement scrum in all, does that mean team has to attend daily scrum separately? Can we make one daily scrum (eventhough it exceeds rule of 15 minutes)  for all since the team members will be almost same although they are shared among projects.

Is it bad idea to assign development task to product owner who also deals with clients too? And if we have no choice, then how do we make the scrum go smooth especially when client communication (for ongoing projects as well as for possible new projects) will always come first?

Regards,

Sita

[Ron Jeffries]

Hello, Sita. On Wednesday, July 7, 2010, at 8:32:39 PM, you wrote:

> If members are shared for multiple projects and if we implement scrum in
> all, does that mean team has to attend daily scrum separately? Can we make
> one daily scrum (eventhough it exceeds rule of 15 minutes) for all since
> the team members will be almost same although they are shared among
> projects.

Since the daily scrum wants to focus on the (individual) team's
commitments, I'd have multiple ones and people attend all the ones
for teams they are on.

Do you begin to see how wrong this is?

> Is it bad idea to assign development task to product owner who also deals
> with clients too? And if we have no choice, then how do we make the scrum go
> smooth especially when client communication (for ongoing projects as well as
> for possible new projects) will always come first?

If your PO, like your developers, has other priorities, nothing will
make your scrum go smoothly. You are throwing bumps in front of the
car as you go down the road.

Just do your best. You're so far from doing what Scrum says that it
might be better to name your process something else.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
To tolerate a problem is to insist on it. -- Software for Your Head

[Cory Foy]

Hi Sita,

Well, first, don't do multiple projects. Do what you have capacity for.

That said, I would make it visible. Make sure you have on the wall the
tasks the shared resource is working on, and only let them show in
active development when they are actively developing on them.

If them not working on a task is causing others to be blocked, that
should be raised as an impediment and measured. Every day. That will
give you the business case to justify changes down the line.

And yes, they should attend all of the stand-ups. Causing them to be
even more of a constrained resource.

--
Cory Foy
http://www.coryfoy.com
http://twitter.com/cory_foy

[Sita Pun]

In one of earlier postings, I had read that it is acceptable for the product owner to do the testing. What other roles are acceptable for product owner? and also what other roles are accceptable for scrummaster in addition to their basic role?

Regards,
Sita

[Michael James]

I think what a couple of us meant to say, or should have said, is that the PO's involvement *helping* with testing might be welcome in most cases. If only one person's testing we're in big trouble. In that other thread's case there were some power dynamics that would make me reluctant to prescribe one way or the other over email.

If your ScrumMaster's not busy, the full scope of the role probably isn't understood. A few years ago I got an email from one of those not-very-busy ScrumMasters in a place I had observed for a couple weeks. I realized the stuff I expected her to see automatically was not so obvious to her, so I wrote an example ScrumMaster's checklist about her particular organization. It's turned out to be useful to others (maybe you too), so I've been updating it and reposting it from time to time. Here's the latest version (with instructions on the back for anyone who wants to use it as a classroom exercise):

http://blogs.danube.com/wp-content/uploads/ScrumMasterChecklist_4_061710.pdf

--mj

[Ron Jeffries]

Hello, Sita. On Thursday, July 8, 2010, at 2:16:48 AM, you wrote:

> In one of earlier postings, I had read that it is acceptable for the product
> owner to do the testing. What other roles are acceptable for product owner?
> and also what other roles are accceptable for scrummaster in addition to
> their basic role?

Sita, with the greatest respect, you and your team are far from an
ideal Scrum situation. I would urge you not to try to run your
project "by the book" but to start looking at what is really
slowing you down and causing other problems, and adapt your process
to reality.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
If you don't have the courage to say what you think,
there isn't much use in thinking it, is there?
--Thomas Jay Peckish II

[Sita Pun]

Hello Ron, 

I would be grateful if you can explain ideal scrum situation.

Ya, I know there are problems. That's the reason I am seeking for guidance from you all.  And most important thing is there are limited resources( 'coz of financial constraints) and multiple projects. And some of the projects have same time line  ( so have to be run parallely) and some require urgent attention to client's unexpected request. So, there's no option except sharing resources. In such situation, how do I  adapt my process so that it becomes the best one?

Regards,

Sita

[Dan Rawsthorne]

Well, they're both part of the self-organizing team, so the team needs
to figure out how to optimize the use of both the PO and the SM in their
role as Team Members.

Dan Rawsthorne, PhD, CST
Senior Trainer/Coach, CollabNet
draws...@collab.net, 425-269-8628

> <mailto:scruma...@googlegroups.com>.

> To unsubscribe from this group, send email to
> scrumallianc...@googlegroups.com

> <mailto:scrumalliance%2Bunsu...@googlegroups.com>.

[andrej...@gmail.com]

Hi Sita,

we have same situation with UI designer and the only solution that
worked for us is to keep separate backlog alligned with other teams
backlogs for shared resources.
This "shared" backlog is reviewed together with all scum masters and
product owners.
Learn and adapt :)

hope this helps.

Andrej
www.agilemindstorm.com

> > scrumallianc...@googlegroups.com<scrumalliance%2Bunsubscribe@goog­legroups.com>
> > .

> > For more options, visit this group at

> >http://groups.google.com/group/scrumalliance?hl=en.- Slėpti cituojamą tekstą -
>
> - Rodyti cituojamą tekstą -

[Ron Jeffries]

Hello, Sita. On Thursday, July 8, 2010, at 11:07:04 AM, you wrote:

> I would be grateful if you can explain ideal scrum situation.

I'll do a bit here. Your reading in Scrum and perhaps some training
might do better.

The main topic I'm on is that Scrum requires that each project
should have a "cross-functional" team, including all the skills
necessary to complete each Sprint's increment of functionality.

With shared "resources" ... I assume you actually mean "people" ...
the team generally does not have all the skills necessary, all the
time, which is why you are having the scheduling difficulty.

Read on ...

> Ya, I know there are problems. That's the reason I am seeking for guidance
> from you all. And most important thing is there are limited resources( 'coz
> of financial constraints) and multiple projects.

Upon reflection, it may come to you that ALL projects have limited
resources and money. The world of people and money is finite. Scrum
/ Agile is a way of dealing with these limitations effectively, and
the way you do it is not, repeat not, share out the resources. As
you are discovering, that does not work very well. The thing to do
is to stop doing it.

> And some of the projects have same time line ( so have to be run
> parallely) and some require urgent attention to client's
> unexpected request.

Running in parallel using shared people and other resources
invariably, always, necessarily results in all the projects being
completed later than they otherwise would be. ALWAYS. This is really
and truly ALWAYS a bad idea.

Here's why. Suppose we have only two projects, X and Y. We want them
done in two months. They have equal priority and require the same
amount of work. It follows, as the night follows the day, that we
will therefore get at most one month's work on each. For this
picture, a month is ten X's or Y's.

One way to proceed is to work "in parallel". (We don't really work
in parallel. People can only do one thing at a time. What happens is
that we switch back and forth more or less rapidly. We do something
like this.

11111111112222222222 (month)
XYXYXYXYXYXYXYXYXYXY (work)

We think aha, wonderful we got everything done on time and we were
fair to everyone. This is incorrect. First of all, we could have
done this:

11111111112222222222 (month)
XXXXXXXXXXYYYYYYYYYY (work)

This strategy would get both projects done by the end of the two
months, which is what we desire. It also gets one project done one
month early. That is better!

Second, we cannot task switch with no overhead. Overhead comes in
the form of slowness picking up where we were, in the form of
defects, and in the form of bad design. Showing overhead as little
o's, the real results of the parallel project are like this:

11111111112222222222 (month)
XYoXYoXYoXYoXYoXYoXY (work (note only 70% as much done))

> So, there's no option except sharing resources. In such situation,
> how do I adapt my process so that it becomes the best one?

There is an option. It is: dedicate the resources needed to one
project, stop on its deadline, then do the other. That's the best
thing to do. That is what Scrum and Agile suggest.

If you want to do the second best thing, ask someone else. And
please don't call it Scrum or Agile.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Now -- Bring me that horizon. -- Captain Jack Sparrow

[Mark Levison]

Sita - I'm at client site so don't have the time to respond in detail. See: http://www.infoq.com/articles/multitasking-problems - basically multi-tasking will get everything done later. Pick one project and drive to done. Now focus your attention to the next one, etc.

Cheers

Mark Levison

		Mark Levison | Agile Pain Relief Consulting | Agile Editor @ InfoQ Blog | Twitter | Office: (613) 862-2538 Recent Entries: Self Inflicted Agile Injuries, Why use an Agile Coach

[Cory Foy]

Hi Ron,

Ron Jeffries wrote:
>> So, there's no option except sharing resources. In such situation,
>> how do I adapt my process so that it becomes the best one?
>
> There is an option. It is: dedicate the resources needed to one
> project, stop on its deadline, then do the other. That's the best
> thing to do. That is what Scrum and Agile suggest.

I'd agree with everything, and want to add a third option. It may be
that everything that is in the project is not necessary for it to be
shipped, or can be delayed. So we may be able to have a conversation
with the owners to find the most critical features and deliver those
first. So it would look (using your diagrams) like:

11111111112222222222 (month)
XXXXXYYYYYXXXXXYYYYY (work)

This isn't possible on all projects, but can be useful as a conversation
to have.

[Yavor Nikolov]

Hi Sita,

There are some videos by Johanna Rothman on Project Portfolio Management which you may find interesting (the very same problem is discussed: dealing with multiple projects). Here is the first of the series: http://vimeo.com/7638449
(In fact there is also a book on the same subject by the same author).

Cory Foy has already outlined my point of view:
 - shrink your projects (product releases) as much as feasible.
 - deliver the most important product release first.
 - your management should be engaged to estimate and re-estimate projects' value and make decisions which project makes sense to be delivered next.
 - take into account the overhead of switching between multiple projects.

Regards,
Yavor

--