Hi! I'm Dom Price, Atlassian's expert on team culture, agile and the future of work. AMA

[Anja Brkljacic]

What are your thoughts on pros and cons of using Portfolio? 

[Dominic Price]

Some of the pros of using Portfolio for Jira include the ability to: 

• Build a roadmap that's connected to your work in Jira Software.
• Get better visibility of work happening across teams and projects
• Get an overview of dependencies across teams and projects
• Add additional levels of hierarchy above epics. 
• Get a view on whether your team is above or under capacity in any given sprint. 

Some of the cons of using Portfolio for Jira include: 

• The tool requires a very systematic way of working that may require some changes in the way your team does things (e.g. relatively consistent estimation practices across teams, a well-groomed and up-to-date Jira backlog). 
• There's a steep learning curve to the tool that requires users to invest in it in order to reap its benefits. 

Don't take my word for it though. Check out these blogs to hear straight from customers why they use Portfolio for Jira:

https://www.atlassian.com/blog/portfolio-for-jira/factom-inc-portfolio-case-study
https://www.atlassian.com/blog/portfolio-for-jira/how-kodacloud-moved-off-excel-and-onto-portfolio-for-jira
https://www.atlassian.com/blog/portfolio-for-jira/kespry-portfolio-for-jira-case-study

[Kimberly Deal _Columbus ACE_]

So many serious questions, I feel like I need to throw something fun in to an AMA.  What is your favorite way to celebrate team success?  How to do you rally the teams, improving moral after a set back?  ... and, possibly the most important question, what's your favorite icecream flavor?

[Dominic Price]

Hey Kimberly! I think this is going to be my favorite question to answer 

As far as team celebrations go, I don't have a groundbreaking answer for you. My teams tend to want some free food and drink and a bit of time during work hours to consume it together to celebrate success. Sounds pretty basic, but that's what we all like. 

Setbacks happen. In fact, the time to start worrying is when there are no bumps in the road because that likely means you're not shipping. My advice is to find the silver lining (sounds corny, I know). What did you learn? How is that going to make life easier moving forward? How much better will your customer's experience be because of the lessons you learned? Trust me, there's an upside to every setback and as leaders we are responsible for helping the team always see the forest among the trees, even when a couple branches fall.

Lastly and most important, my favorite ice cream! Have you been to Sydney? I'm a HUGE fan of Gelato Messina...maybe too big of a fan. 

[Mike Solomon]

hi @Dominic Price! Thanks for doing this!

What have you discovered in your research about the future of work that you think would be most shocking or unobvious to those who don’t spend as much time contemplating the subject?

[Dominic Price]

https://www.atlassian.com/teamwork/artificial-intelligence

There were a few striking findings from our research.

1: despite lots of writing about technology and impact of tech skills, the challenges of today revolve around human to human, and trust.

2: Whilst we're anticipating impact to jobs and changes to roles, we don't seem to be doing much about it. It's as if we're equipped with the data, but struggling to take action. Should we retrain? What in? Where? Who pays? The disruption to jobs and employment needs more contemplation so that we prevent pain, rather than cure it. 

[Giuseppe Maggi]

Hello @Dominic Price!

Thanks for this great opportunity. We are using JIRA to plan our products in an agile way since a couple of time and we have some questions that occured during our JIRA Usage. 

Our questions refer to the following facts:

• We are still embedded in a classical, large enterprise hierarchy consisting of functional teams with a team leader who assignes tasks.
• As a result, we have people that may have multiple roles
  (e.g. being a product owner and a developer at the same time for different sub-projects)
• As a result, we have teams with multiple, independend goals and not one common goal (like teams developing a software product)

Therefore, we adapted the classical SCRUM process and defined the following work process:

We have one JIRA project that is representing a functional team with members that are functionally responsible for different sub-projects. We use "components" to define the different sub-projects and assign a component leader as responsible person. The component leader has the role of a product owner, that is responsible to define and maintain a product backlog for that component. Therefore, we created seperate boards for every component, which are filtered by the component's name. After that, each product owner defines elements of his component backlog that he wants to be handled in the next sprint. This way a "selected backlog" is created that is a collection of prefered issues of every component. This is the input for the sprint planning, where the team decides which issues may be realized in the sprint or not, so that the final sprint backlog is created. 

Questions:

• What is the best way in your oppinion to handle different teams with different goals that are in one funtional group? 
• What if people have to contribute to different projects at the same time?
• Do you recommend to use parallel sprints in one project?
• Do you have a suggestion how to guarantee that every team has the same understanding of story points? 
• Would you prefer to use "initiatives" as further issue type instead of components?
• How can we handle the dilemma of multiple roles without impacting the hierarchy?

We believe that in an classical, large enterprise this problematics are very common.
We would appreciate if you could give us some suggestions.

Thanks in advance, looking forward to your answers. 

[Dirk Henrichmöller]

+1 so am I ;-)

[Samuel Lago]

+1

[Dominic Price]

• What is the best way in your oppinion to handle different teams with different goals that are in one funtional group?
  • It's great to find something that can align the people in teams, maybe look at creating a common goal of sharing learning or a coaching program to cross-train people.

• What if people have to contribute to different projects at the same time?
  
  • If this is the way the work has to get done then limiting project/task switching is a good experiment to try. Help management slice the work small and complete those small pieces wherever possible rather than leaving them half done. This can speed things up, as long as you're not mostly waiting for others before you can start. It's worth measuring how long people are waiting on dependent work in this model as though all the projects may look like they're being worked on they're likely to all get finished very slowly.
• Do you recommend to use parallel sprints in one project?
  • If you have component teams that need to work together on a project then you're likely to have parallel sprints. If you have teams that depend on other teams for work then you could experiment by combining teams that have strong dependencies - it may well be faster and cost less to do this than manage the dependency. Also the more teams that depend on a team the shorter that teams sprint length should be if they're using Scrum or ideally they should be aiming to get ship quality continuously so that others are spending as short a time as possible waiting.
• Do you have a suggestion how to guarantee that every team has the same understanding of story points?
  • A common understanding could be achieved through training or coaching on what story points are.
  • If you're looking at normalising story points across teams so that you get better predictability across teams or can compare teams, I'd suggest experimenting with either using "team weeks" for early forecasting and product backlog item count (throughput) for finer grained forecasting, tracking. The law of big numbers makes both of these possible. With this approach, the teams can use their own flavour of story points locally and you'll have a common currency for tracking and forecasting.
• Would you prefer to use "initiatives" as further issue type instead of components?
  • It's great to experiment with aligning the people around the value they're generating in long-lived teams, this gives the team a closer link to the people who get value from the thing being delivered - driving better team engagement. It also means the team will have skin in the game on keeping the quality high - you built it, you run it.
  • Component teams are always in danger of locally optimizing at the cost of making their organisation faster or cheaper.
  • You can keep integrity across the components by keeping a community around a component that validates the integrity of all the initiative teams changes to the component
  • When your organisation gets to a certain size it's hard not to have some level of supplier / consumer component challenges - it's then about minimising them and getting them aligned from above so delays are minimized on getting what the organisation wants to be done first
• How can we handle the dilemma of multiple roles without impacting the hierarchy?
  • It would be great to understand this one better to give a useful answer.

[Nguyen Tran]

Hi @Dominic Price,

Aside from software development, I think that almost all of the other industry can utilize Agile methodology. So, when shouldn't you be Agile? I'm looking forward to hearing your thoughts on this.

Cheers!

Nguyen

[Dominic Price]

I mean... when you're dealing in matters of life and death (building a space shuttle, developing new medicines, etc) shipping early then iterating doesn't really seem like the thing to do... 

[Sakshi Mittal]

How should an organization working in a traditional way(waterfall) be transitioned to be agile? What is the path to be followed?

[Dominic Price]

This is a popular question! I'll quote what I wrote to answer Danny's question above. Feel free to let me know if there's any aspects of your question I haven't yet covered!

"Every organisation is different so there will be many ways for this to succeed. One way is to harness the energy and passion your people already have. Find those most passionate about being more agile and give them all the help you can to make them successful. Then you and they can showcase their success to encourage others to join the movement.

For those appearing resistant, maybe they feel forced to change and meeting them where they are will be more effective. Lose the A word and instead use the practices and behaviours that agile encourages to help solve the challenges they have today, Once this starts to work maybe they'll see the benefit; worst case they'll continue to improve and they'll become more agile regardless.

Also, before you talk frameworks (the solution), make sure to ask questions like "why?" and "what for", so you know the real problem you're solving. "

[Santhosh Kumar]

What is the best way to calculate forcast velocity for the current version.

In my Backlog i have user story for next version also.

[Dominic Price]

Hey Santhosh.

I'm not entirely sure what you're looking for.

Is it this: https://confluence.atlassian.com/jirasoftwarecloud/velocity-chart-777002731.html

Let me know and maybe we can re-ask the question in the Jira section of the community?

[Deleted user]

Thank you, Dom!! For your time and wealth of information... @Dominic Price

[Dominic Price]

Thank you taking part

[Carol Jones]

Yes, thank you! Do you plan to do this type of thing again in the near future? I would love to point our user communities to it in case they missed this one!

[brad dunn]

Hey Dom,

You talk a lot these days about remote work.

Do you think Atlassian would open its hiring up to a global candidate base for product/design and engineering roles?

[Andy - PTC Redundant]

Excellent discussion @Dominic Price ! That's a great slide show... was the key note also recorded?

Couldn't see a link. 

In the spirit of all topics "A" related... what about the question Agile vs agile!? So many companies say they're agile... but do they really practice being Agile? 

Do you think efficiency & effectiveness can be improved by understanding the difference and living by it better?

[Brian Rain]

@Dominic Price  In your Agile Alliance talk, you used the stat 

78% of people don’t trust team mates

I'm having trouble finding the source document.  Do you have it? 

[Dominic Price]

https://www.atlassian.com/teamwork/artificial-intelligence