Why can only one Agile phase be placed in a Project?

[Uncle Rob]

Is there a particular reason why only one Agile phase can be placed in a project?  

Further, is there a reason why only one Team can execute it?   (also, if anyone has any insight, please see my thread on "teams vs work groups")

[anna_scheib]

I'll give it a shot but I'll have to defer to the Products team on anything that has to do with future plans. So the single Agile phase (as well as single Test phase) is a known limitation in Fuji as you pointed out. I do believe we are working towards relaxing this restriction and allowing for multiple Agile phases in a single project at some point. The 1-1 relationship of Agile phase and Team is related to the Team-centric architecture of the Agile/PPM integration. The mindset is that the IT Dev Team works across projects, executing potentially on multiple projects, in the same Sprint. There is also the assumption that the team works on multiple temporary projects and is not dedicated to a single product. As a consequence, Stories and Sprints created under the Agile module do not have a Product or Release attribute. The Agile phase is time boxed by a start and end Sprint. Sprints are created for a team. Consequently the Agile phase is "assigned" and can only be executed by a single team. Stories can be added using the Sprint Planning console, directly under the Sprint, or in the Project backlog from the Project Workbench.

In theory, if we allow for multiple agile phases, we could have multiple teams working the project stories.

Hope this is helpful.

[kellykaufmann]

If you create an 'Execution' phase within that project (marking it as Agile), shouldn't all your Agile activities fit in there? Picture this setup intended for Waterscrum, where you have a Waterfall phase w/certain standard waterfall activities to start off with (creating the charter, etc), then an Agile 'Execution' phase, then standard Waterfall activities after that as well.

The problem for your company seems to be with 'team'. We're thinking of not using the 'team' functionality (we'll have one dummy team behind-the-scenes that is auto-assigned to the phase, the sprint), because we're small and it really isn't needed for us. But we're still figuring this out. We still assign stories to people, so we don't see much need for this for us at this point. But I'm sure your org is larger & more complicated & that teams would make sense for you!

[Uncle Rob]

Kelly Kaufmann wrote:



If you create an 'Execution' phase within that project (marking it as Agile), shouldn't all your Agile activities fit in there? Picture this setup intended for Waterscrum, where you have a Waterfall phase w/certain standard waterfall activities to start off with (creating the charter, etc), then an Agile 'Execution' phase, then standard Waterfall activities after that as well.

What stops you from having multiple execute phases though?   What if my project is "roll out ServiceNow" and I have multiple execute phases (one for each major development initiative of the project)?

The problem for your company seems to be with 'team'. We're thinking of not using the 'team' functionality (we'll have one dummy team behind-the-scenes that is auto-assigned to the phase, the sprint), because we're small and it really isn't needed for us. But we're still figuring this out. We still assign stories to people, so we don't see much need for this for us at this point. But I'm sure your org is larger & more complicated & that teams would make sense for you!

I'm definitely struggling with Team because everywhere else on the platform work is given to Assignment Groups.   We even (usually) build list views around it so a group doesn't have to click as many lists as there are task types to scan their work.   I can see making team generic and just saying "Team = anyone who executes in this phase", but now I'm managing two different abstracts in my mind for essentially the same thing:   "who's working on this"? Additionally, there are times when dev teams run in parallel on existing efforts.   This happened to me multiple times in 2014 where bi-directional integrations required that two different dev teams each had work to deliver in the same project. What if our project is "Get a shuttle into space", we'll have all kinds of phases where multiple teams will be simultaneously working on development initiatives that necessarily happen in sequence or parallel.   The devs writing code to control thrust are going to need to work closely with devs grabbing positional information from ground control.   They might be totally different teams though.

Maybe this is why the concept of sub-projects exist though.   I just think it would be really hard to structure the project for those eventualities before hand.

[kellykaufmann]

Yeah for our SN execution project, we have each phase be it's own PRJ. Because we funded separately for each phase. I can see how if you want to have all the phases in 1 PRJ that you would need this.