What are the pros and cons of implementing structure a vs b in jira align?

[sachin gangam]

Hello,

I want to know which structure among these two will be the recommended and what are some of the pros and cons..(how would reporting look and how will way we work change)

In first setup we have typical structure 

• Portfolio
  • Solution
    • Program AB
      • Team A
      • Team B
    • Program 12
      • Team 1
      • Team 2

However, we have few teams which do not fall under any program. So, we were thinking about second structure

• Portfolio
  • Solution
    • Program AB12
      • Team A
      • Team B
      • Team 1
      • Team 2

Note: All the programs follow same cadence..

Thanks,
Sachin.

[Peter Jessen · Accepted solution]

Hi @sachin gangam ,

You are posing an interesting question that requires more information to provide a meaningful answer that would best serve your organization. So let's start with some basics on what you shared.

1. Why are you turning on the solution level? That potentially adds a significant amount of complexity that might not serve your organization.
   • In six years of implementing AgileCraft/Jira Align I've seen less than a handful of clients who needed or gained value from the additional level.
   • I would always recommend erring on the side of keeping things simple.
2. Now to your question:
   • Align is designed to model and track the flow of value through the system. The programs are best aligned with value streams to provide this visibility.
     • How do you define a program? Is it in alignment with SAFe's Agile Release Train (ART)? or is it more of a waterfall project? or is it a collection of a series of applications?
       • All of these things influence the best way to model Align to reflect your organization.
   • Programs typically consist of teams that are doing related work and interdependencies between teams.
     • That doesn't appear to be the case here.
     • Are your teams effectively a Shared Services program where they do work across multiple programs?
3. Mechanical impacts in Align:
   • For your first setup the four teams will appear on two Program Boards of two teams each, in two Program Rooms, and all data will roll up at the feature and epic level as two programs.
   • For your second setup the four teams appear on one Program Board, in one Program Room, and all data will roll up at the feature and epic level as one program. 
     • Assuming the program itself has no meaning to your organization, then you would provide meaningful views by filtering on some field on the feature or epic level.

As I stated upfront, to answer your question in any meaningful way requires more information about what you are trying to model.

• Align is not a project management tool (focused on utilization and task completion), it is an agile at scale platform designed to measure the flow of value through the system. 
  • So what value are you trying to measure?

Regards,

Peter

[sachin gangam]

Hello @Peter Jessen  , all this is very helpful information. 

1. We are turning on solution level just for teams to get that visibility on their top tier filter. But, I agree we can totally ignore solution layer as we are not using capabilities. 

2. We are trying to push our users across enterprise to work in SAFe and that ART structure, but in all honestly it is currently a mix of both. Few work in ART, few don't. Teams works across multiple programs.

3. This is mainly I was trying to understand as an Admin. But, I think you have provided great info from process standpoint. Thanks again.

[Peter Jessen]

Hi @sachin gangam ,

Glad I could be of service.

Process modeling is a huge part of a successful Align implementation.

• Proper modeling of the company's flow of value is critical.
• Many organizations make the mistake of trying to model their management structure in Align instead of the actual agile teams and trains that deliver value.
• Keeping the structure as simple as possible (hence, not using solution layer if at all possible) improves the probability of a successful implementation and adoption.

I am a bit concerned by your first point without having more context - "We are turning on solution level just for teams to get that visibility on their top tier filter."

• There are many ways (better than enabling the solution level) to get the right level of visibility. 
• This might be a sign of structuring align to model the management hierarchy vs the value delivery structure, but I am only speculating based on 6 years of implementing Align in large organizations. 

Regarding your second point, I hope your company has some sort of organizational change management in place for the implementation of Align and the transformation it seems to be supporting.

• A major success anti-pattern is assuming Align will magically work and give the right insights without the company leadership first asking and answering the right questions - such as what insights are they trying to glean from Align?
• Implementing Align, when done properly (IMHO) is a matter of working with the art of the possible combined with an incremental approach to change. 
  • What's your starting state, what's your perfect (and possibly unattainable) end state, and what incrementation steps will you take to get there balancing the amount of change with the company's (aka people) ability to handle change.
• Align can be modeled to support multiple starting points and be changed over time to get to the desired future state.

Regards,
Peter