Seeking Advice: Project/Team/Workflow models

[Josh McManus]

Hi Atlassian Admin family!

My organization has been using Jira since 2010 and while there has been some general governance in the past, it hasn't been comprehensive or rigidly applied. I convinced my company that putting someone into the "Product Owner" role for our internal tools so that we treat our users like customers and work to ensure our tools are meeting the needs of our teams...and that person is me! Now comes the hard part...moving their cheese.

Projects

Currently there's not great consistency in how my org decides when a new Jira project is needed. Some parts have one project per team irrespective to the product they're supporting, some parts have one project per product that multiple teams work out of, while some parts spin up a new project for every new scope of work they decide to take on. I know that factors which play into this decision should consider permission schemas/access, Release versions (I'd love for this nomenclature to be cleaned up), Components, and screen/field configurations. Based on these factors, it *seems* to me that building the projects around the products they support is the best match...but we are relatively immature in our cloud service products and shared services/components between products seems to mess that model up a bit. What are your experiences with project structure and do you have to fit both desktop applications and cloud service SaaS products in that model? Because I'm working to obtain funding for Salto, a requirement for me is to keep our project count as low as reasonable.

Teams

We used to use Groups to assign work items to teams/boards, however this became burdensome since only Site admins can modify groups and any time there was a restructure and a team needed to be created/removed it forced the Site Admin to engage. To remove this requirement (and to better integrate with Portfolio/Advanced Roadmaps) we decided to move to the new(ish) Team field. While the benefits are definitely valuable in how it ties Teams to home pages and allows teams to manage their own membership, there have been complications as the field still has some support issues. We have worked around some of them (like Two-Dimensional Filter Statistics and Pie Charts not working...we bought the Reports - Charts and Graphs add-on to supplement), however now we have the complication that we are trying to aggregate useful data to this assignment but the fact that *anyone* can create a team makes that data less reliable. What's your experience with building boards that may span projects but centered around some team identifier?

Work Items and Workflows

My organization has purchased licenses to Jellyfish to derive more useful data analytics from our engineering group, and since it uses Jira as a data source for it's metrics it is forcing our hand in aligning the way our engineering group operates. Historically we were primarily a desktop/installed application software company, and that led us to models that were based around builds that generate installation bundles. However as we mature into SaaS products this is forcing us to development patterns that include deploying services to intermediate environments, test environments, and production environments. What does this look like for you in regards to your ticket structure and statuses? Do you leverage subtasks for tracking these deployments or do you have a serial flow of statuses mapped to the activities? Or do you generate Deployment tickets and only track the story or bug fix to the posting of the service to the artifactory? It seems to me that subtasks might be the best fit for tracking these activities since some of them could be operating in parallel (functional testing in a QA environment while load testing is running) and you could block the Deploy to Production subtask with the other activities...however this seems like an administratively heavy load and I can picture teams complaining about the overhead.

Thank you for any advice or feedback you might have!

[David Foote]

We also had an environment where we had great inconsistency in the structure of projects, the workflows associated with the projects and the amount of teams working in each project.

With the introduction of a new head of our IT PMO, we finally had the support needed to clean up this side of our house (at least for our IT users; non-IT service teams are a whole other bag!). The PMO's need for clear reporting was a huge deciding factor in getting the organizational will behind standardizing!

This is the approach we took:

Standardized issue types, workflows, and screens across all IT development project

This was crucial in allowing us to provide the metrics the PMO needed along with preserving our sanity as Jira admins; it's no fun rolling out updated field requirements across 20 workflows! We introduced an integrated change process between software and service last year - it literally would not have been possible without this standardization.

We tried as hard as possible to build flexible workflows though; some teams have different QA and UAT requirements for deployment so our flow changes depending on how some fields are set.  If you set 'UAT Required' to 'Yes', you get a set of UAT statuses after development being done for example, where 'No' allows you to go straight to the deployment statuses.

Cons: Our workflow diagram is a huge mess, thanks to the multiple transition paths we need to have available. And standards are really standard - if the PMO says this new date field is needed, everyone will now be filling that out, no one off exceptions to make the Networking team (or whoever) happy.

Objective Projects vs Team Projects

Our first approach for project design was to have a generic "Initiatives" project that held parent cards with the children Epics living in separate projects. But after some reporting headaches, the take-two for us on how we define out projects was to split out projects related to big objectives that multiple teams work on and projects that are specific to one team and contain that team's keep-the-lights-on work along with a board that shows cards across all projects for that team. 

Initially, we weren't so strict on the split and we found it very difficult to report on, say, time spent on a particular objective when the child Epics for an objective lived in many different projects. So we created Objective projects that make reporting dead simple; if you want to know what cards were finished in so far this year for an initiative, you just look at project = X and resolution >= startOfYear(). Objective projects also make it easy for a project manager/product owner - they create the cards they need in the project, assign the right team and don't worry about where that team likes to "work".  Boards on Objective projects are also very simple (and close to the Jira default) - just show the cards in this project to get an overview of where everything stands (although we really try to stress that these work best as Kanban; Scrum can muddy the waters a bit).

Team projects are really a combo of two things:

1. A board (Kanban or Scrum) that is built to pull in cards from across the system wherever the team is assigned (we use a field called "Teams" for this)
2. The expectation that only KTLO work is created directly in this project.

The board, in particular, gives a team one location to go to see what work is on their plate; regardless if they are cards coming out of projects, ops-type work they may need to do, or even service tickets that have been escalated to them. Going this route was mostly due to teams being confused that they had work as part of a project but not knowing this because they had never been to that project's board before.

The KTLO expectation fits with our reporting needs - while we need that for estimating workload, it's not something our PMO needs a lot of data on. So having it in the team project gives the Scrum Master a place for it to live (and for their reporting) without muddying objective reporting.

Cons: It can take awhile before people internalize what the two different projects are for; there still needs to be some level of communication when creating cards for teams because new cards that are just dropped on a backlog can be lost; because the queries on the team boards are so broad it pulls in statuses that aren't really relevant - this can cause confusion for scrum masters who are configuring the board's columns. 

Team vs Teams

We were using a field called "Teams" before Atlassian forced introduced the 'Team' field. We explored switching, but the lack of any sort of controls around who can create and update a 'Team' really made it unusable for us. 'Teams' is baked into our required fields for our workflows on both the Software and Service side of Jira for us - but we don't do a lot of actually defining who is a member of which team.

On the service side, we do use special Jira groups that will automatically update the 'Teams' value based on the assignee, but on the software side we don't enforce that the assignee be linked to a team or anything. Weird to be missing that team membership linkage, but it works surprisingly well!

Cons: We will likely switch to 'Team' when it becomes a more mature feature, which will be a lot of work; we sometimes get zombie team values and aren't informed of updates (but generally the PMs/SMs are very aligned and are able to get work to the right teams).


Sorry for the wall of text but hopefully it can provide you with some benefit!

[Josh McManus]

Definitely useful information! Thank you for sharing. For ITSM I can understand how this model could work...I think my concern is that the number of products we make and the number of "initiatives" that come up around those projects would lead to a lot of new projects and it wouldn't be very clear where the KTLO work would need to get assigned. I'll give this some consideration though, perhaps there's a way we could make it work!

[David Foote]

So we have around 60 projects on our dev standard, with about a quarter of those being objective projects. Because everything is standardized, it's been a manageable amount so far.

The teams themselves are the one who create/manage their KTLO work, so this approach works for them. But if that work is managed more centrally I definitely see it being hard to replicate.

[Crystelle S]

We do a variation on David's comment :)

Projects

We align our projects to releasable concepts - software stacks/codebases or devices - with the exception of our portfolio level projects (2). All the other projects are considered "engineering", the portfolio projects contain our programs and projects (which can cut across our products or align to one) using ticket types (we use a data model that focuses on scope at the ticket level and decorates those levels with standardized fields which capture additional data so we can report on different aspects of the scope and its delivery). Engineering projects house all the work that is KTLO as well as the Feature work, Feature work is laddered up to a Feature in the portfolio project. Boards are pulled to show all the work regardless of parentage. Advanced Roadmaps (AR) can be used to pull a delivery view.

Teams

We use the Teams field from AR. We haven't had a lot of the issues with Teams that others have, but our engineering org tends to be arranged into component teams and our Jira projects follow the technical systems pattern so we're not as beholden, we have team = tech system = jproject  a lot of the time.

Work Items and Workflows

This one, we don't do well. We do all of the things you mentioned except for the environments as subtasks. You may get frustration with the subtasks since their parents are standardissuetypes and you tend to have a lot of those. If you do go subtask I would look at some automation to help ease the pain. If you're using automation, I'd look into the fix version field - you can have multiple values in this field so it can be an "add to existing" and generally speaking environments tend to indicate what type so they don't get crossed but some folks get prickly if anything but the prod designation is in there.