43911Re: [scrumdevelopment] Re: Developers on multiple projects
- Jan 3, 2010Hi bmwpapa,
> Thanks Elizabeth. If I read you correctly, you seem to describe a
> single backlog, managed by a single PO, with ONE team, across
> multiple projects.
Correct. We're looking at a situation where team members of ONE team might be working on a couple of different projects at a given time. Bob, Mary and Cindy may need to work on Project A during one Sprint and Tim, Meg, and Dan might work on Project B during that same Sprint. Next Sprint, Bob, Mary and Dan may need to work on Project A, etc. In the end, all members of the team are responsible for both projects.
> This appears to be more story/task-centric, rather than project/
> release-centric - i.e. work on stories/tasks in order of priority,
> regardless of which project/release it's for.
It is project/release-centric, though. Consider one point in time, there were two clients and the team was working on two projects, one for each of the two clients. If the team worked from two different backlogs, we would end up with competing priorities. Is Story A in product backlog A more important than Story A in product backlog B? Who decides? Toss in a request from the CEO for help with a proposal in the upcoming Sprint and it's easy for the team to be split in a lot of different directions without a clear understanding of what's most valuable/important. One backlog means the business is making a clear decision about what the priorities are and everyone can see the trade-offs. It's easier to see what happens to stories/progress for Project A or Project B when the CEO asks the team to take on a 40pt proposal for the next Sprint and their velocity is showing an average of 80 pts per Sprint. With multiple backlogs, it's not so obvious. (I've also witnessed separate backlogs for one team with a 40% velocity on Project A and 60% velocity on Project B sort of thing...I'm much, MUCH less excited about that actually...)
> But, then, how do you
> track your release burndown, velocity, and goals/progress for
> individual projects? Each project should be release-able after each
> sprint, but each sprint tracks multiple projects. Unless I'm missing
> something, this approach seems to cloud the bigger picture.
Yes, you're still looking at breaking down the work for each project into chunks that can be completed--done done done--at the end of each Sprint and is looking to deliver a releaseable product (for each project) at the end of each Sprint. No change there. Velocity is tracked for the whole team, everyone has a common understanding of relative sizes and what a "point" means. You're still tracking the amount of work remaining for each project in your release burndown charts, no change there. But, yes, you're associating the story with the project (in your spreadsheet, card or whatever tool) so that you can track. No clouding for us... crystal clear clarification, awareness of big-picturing impact across projects, understanding of where we are and where we're going.
> In response to other posts...
> Andre seems to suggest that developers on multiple projects is plain
> wrong. I understand it's not preferred, but I'm not convinced it's
> always avoidable.
I'm sure folks will cringe, but for the company I'm describing...working on multiple projects worked out very nicely for the company and for the team. Using Scrum in this way, clients were happy, the team aligned deliverables with the customers' expectations, quality was good and the team delivered value at the end of each Sprint, we reached a comfortable sustainable pace, etc.
> Maurice seems to think that I want "everything", but I'mwilling to
> pay "nothing". However, I'm really just stating the obviousI found was
> preference for cost-effectiveness. I want the biggest bang for the
> buck. Who doesn't?
> I'm still interested to hear more real-world experiences...
> --- In email@example.com, Elizabeth V Woodward
> <evwoodwa@...> wrote:
> > I was brought in to help a smaller company a while backâ€¦ What
> > that the teams were made up of some really amazingly talentedpeopleâ€¦ The
> > biggest problem was that they were constantly being interruptedwhen
> > working on one thing to work on something else. Along with themultiple
> > projects, there were multiple contacts who could shift the teamâ€™sside, project
> > attentionâ€¦project managers for each project on the client
> > managers for each project on the companyâ€™s side, the CEOof the company,
> > the CIO, etc. Not good.to one
> > Because it was a small company, having the entire team dedicated
> > project would not have worked. There were lulls in activitieswhere the
> > client was reviewing information with subject matter expertsor gathering
> > data for the project. During that time, the team had cycles towork on
> > other projects. Additionally, there really were time-sensitive,critical
> > work items (developing a time-sensitive proposal with some initialbe done in
> > modeling for a potential client, for example) that needed to
> > parallel with current project work. It wouldnâ€™t make senseto wait until
> > the end of one project to work on the proposal, for example.team,
> > What we did was set up a backlog of all of the work for the whole
> > owned and prioritized by one person. The CEO determined who wouldserve as
> > that Product Owner. That Product Owner took input from the differentof the projects,
> > project contacts, the Team, etc, andâ€"based on knowledge
> > technical constraints, business impact, the teamâ€™s capabilities/inputand
> > info they provided on the cost of context switchingâ€"thePO was ultimately
> > responsible for the order/prioritization of work items in thebacklog.
> > This helped to eliminate the thrashing we were seeing. It alsomade
> > visible problems with too many projects in play at a given time.Using
> > velocity and looking at the size of the work items, everyonehad a much
> > more realistic picture of what user stories and other work itemscould be
> > accomplished. Engaging clients for the reviews and planning ensuredthat
> > we stayed in alignment with clients' expectations.everyone
> > The whole team (7 people) participated in ONE Daily Scrum, so
> > knew what everyone else was working on. The team answered thethree
> > questions, focused on discussing dependencies they had on eachother, let
> > other people know when they needed help, discussed potentialblockers,
> > etc. We were able to much more quickly identify and address issues.We did
> > not have separate Daily Scrums depending on which people wereworking on
> > which projects during that Sprint. Everyone was on the same Sprintcycle.
> > We did not have a separate planning meeting for each projectwith user
> > stories that would be addressed that Sprint or separate retrospectivesfor
> > each project. The Team planned and reflected together. However,we did
> > have separate demos/reviews with the appropriate stakeholdersfor the
> > different projects.for your
> > -elizabeth
> > > Please respond to scrumdevelopment
> > >
> > >
> > > Here's an example scenario, based on real-world situations,
> > > feedback...reasons
> > >
> > > Company A is a small company with 5 projects, and 10 developers.
> > >
> > > Developers work on multiple projects. This is for various
> > > (senior developers contribute their advanced skills anddomain
> > > knowledge across multiple projects, other developers cross-trainfor
> > > interchangeability, small companies can't afford dedicatedteams on
> > > each project, etc.).3 of
> > >
> > > If Joe Developer works on 3 projects, he has to track/attend
> > > everything (sprints, stand-ups, planning, review, retrospective).He
> > > has to keep track of all his work across all 3 projects.Depending
> > > on the situation, he might work on projects in priorityorder (one
> > > project at a time), or he might work on his tasks in priorityorder
> > > (jumping from one project to another).to
> > >
> > > [Q:] What is your experience with this? I'm sure it's preferred
> > > have developers/teams dedicated to a single project, butI'm curious
> > > how common this scenario has been in your experience andhow you've
> > > handled it. Should the sprints be aligned or staggered?scenario?
> > >
> > > [Q:] What agile tools would you recommend overall for this
> > > I prefer tools that are free/cheap, simple/intuitive, fast/defect
> > > responsive, with potential integration with third-party
> > > tracking, wiki pages, etc.user story
> > >
> > > I've researched some nice agile tools that provide easy
> > > specification with drag-n-drop prioritization, easy drag-n-dropreporting,
> > > sprint planning, task breakdown, storyboard drag-n-drop,
> > > etc. BUT... tools that manage multiple projects, and enableseem to cost
> > > developers to see their tasks across multiple projects,
> > > more and have increased complexity.situation
> > >
> > > In summary, I want to learn the best way to manage this
> > > (developers on multiple projects), and I want to find cost-when
> > > effective, simple tools to help the team be most productive
> > > dedicated teams are not an option.
- << Previous post in topic Next post in topic >>