Forums

Within my group, we use Agile methods. We work within 3-week sprints, and for the most part it's a workable system. However, there is one ongoing problem: A small proportion (~5%) of our tasks are really not contained with our group. These intergroup tasks are performed both by people with my group, and people within another group. An intergroup task is hard to break into smaller tasks. And the other group in question does NOT use Agile methods. So coordinating who-works-on-what-and-when is problematic.

 

Does anyone have any suggestions for dealing with this? It's quite vexing, and I haven't found any good solution yet...

davfive's picture

Our division recently switched to agile/scrum. We have upwards of 10 teams and things are going quite well. Having said that, the problem you describe is one that we are still trying to get our heads around as well.

I am the Product Owner for one of the first agile teams that we spun up, so we've had to address this with others who have and have not been on other scrum teams.

What we have found is that it works best when we treat the person we need help from as a consultant or contractor. We explain what we need, when we need it and then schedule them to work on it during a particular sprint. We invite them to join our team for the time they are working on that part of the project. Sometimes it has been only for a couple days, sometimes a couple of sprints. They don't generally attend the daily standups, but they could. We definitely have them attend the planning and review meetings though.

scm2423's picture

It doesn't matter that you are using agile/scrum the problem relates to Who does What and by When.  The fact that your team is working in three week sprints does not matter to others.  This is just an issue of coordination, you've imposed tight deadlines so you need to work with the external groups to ensure you can meet them.  How is your relationship with these other groups?  Do you have a good relationship where they will want to work with you in meeting your goals or do you have to revert to role power, or escalate things up the ladder to get support? 

mrstevegross's picture

I think the issue in many ways is just the change request system itself. Here's the deal:

 

* We have a change request system.

* In this system, we can create "issues" (aka ticket / request / work-item / task / etc.)

* Each issue can have multiple engineers assigned to it

* If an issue is assigned to only people within my Agile group, we use additional fields to track whether it's on the backlog or on the current sprint.

* If an issue is assigned to a mix of people (within the Agile group and from other non-Agile groups), we do NOT use additional fields to track its Agile-related status.

 

So the problem is this: When we've got an issue whose assigned engineers include people in and out of my group, we can't really track the issue as a part of any particular Sprint. As a result, it's really hard to figure out prioritization of the issue.

 

Any ideas?