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

[Dominic Price]

UPDATE: It's a wrap for our first community AMA on Agile. Thanks to everyone for taking part and sharing. Feel free to keep the discussion going! 9th August 2018!

I'll be talking all things agile and healthy teams in the opening keynote at the Agile2018 conference, this coming Monday, 6 August. Let's keep the conversation going here!

Shoot me your questions, upvote others' questions and stay tuned as I'll be answering anything and everything that is on your mind about agile, team culture and the future of work.

Start submitting questions now below (yes, it says answers ;-)) and tune in Thursday, August 9th from 1 to 2 pm PDT when I'll be answering questions live.

P.S. If you’re keen to get my slides from this morning’s keynote, you can view it on SlideShare. We’ve tidied up the speaker notes – they’re under the “Notes” tab.”

[Leo Diaz DEISER · Accepted solution]

HI @Dominic Price!

After seventeen years of the Agile Manifesto... Is it time to think of something else?

:) Thanks!

[Scott Theus]

Best. Question. Ever.

I can't tell you how many times I've worked for a client that "did the agile" or was "agile-ish."  I have my own thoughts on it, but I'm looking forward to hearing @Dominic Price's take.

[Mike Solomon]

I am also looking forward to Dom's response to this!

In the meantime, @Leo Diaz DEISER , I figured I would share the link to the modern agile website:

http://modernagile.org

that community seems to be looking for something similar to your question :) 

[Dominic Price]

We believe the four founding principles of the Agile Manifesto are still relevant.

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

For Atlassian, we don't think of changing or deleting anything from the original manifesto, rather we are thinking about what principles we'd add as we apply agile in new contexts like Agile at Scale (taking agile into large and traditional organisations that have different levels of complexity) and Business Agility (adapting agile to non-tech teams). 

I still think we forget to go back and ask the questions WHY and WHAT FOR? Those are the ones that help know what our true purpose is.

[Leo Diaz DEISER]

Thank you @Dominic Price@!!! I agree with you...  Maybe is the moment to promote specific principles depending on the context but without forgetting the basis...

http://manifesto.softwarecraftsmanship.org

http://modernagile.org (Recommended by Mike Solomon) an others...

Thanks again!

[Chris Marsh]

This is interesting and why we came up with the term “WorkOps” - to describe how many of the principles of agile can be applied at scale across the spectrum of an organization’s workforce scenarios. WorkOps > TeamOps > SoloOps. 

[Nic Brough -Adaptavist-]

I often run into places yelling "let's go Agile" and then realising that they have no idea what it is.  Then when we've got past that (and checked that it is actually useful to them in their field, because it's not always right), the even more difficult task is working out how to get it implemented.

There's already questions about the quick-sell and different frameworks asked, but I'm looking for help and advice on the tools you can use to get whatever you want to implemented done in the face of misunderstanding and resistance to change. (e.g. would Team playbook be a good thing?)

[Jodi LeBlanc]

It's funny I once went up to someone at a tech event that had a t-shirt on that said "Ask me about Agile", so I did. The individual turned bright red and said the Tshirt was supposed to say ask me about UX. This term sometimes boggles peoples' minds when it shouldn't.

[Dominic Price]

Mate. People are going to think I paid you to plant that question :-) Because YES! The Team Playbook can serve as an excellent bridge into agile, and as a complement to established agile practices. You'll even find some standard agile practices in the Playbook (stand-ups, retrospectives, and demos) because pretty much any team can benefit from those practices regardless of the type of work they do. 

The key to overcoming misunderstandings and resistance to change is to weave the new thing into the fabric of the existing thing so it feels more "evolution" vs. "revolution". For example, next time your team is getting close to delivering a project, suggest the Premortem exercise in the Playbook. Or, suggest the 5 Whys play next time you need to do some root cause analysis. Neither are agile techniques per se, but they're effective. And they'll help build some muscle memory around trying new things. 

EG: https://www.atlassian.com/team-playbook/plays/pre-mortem

[Fadoua]

Hi @Dominic Price,

Can you please provide a brief and precise definition to Agile?There is lot of confusion. I feel Agile is being used out of context in some cases so that teams can feel like going with the flow.

Thank you!

[Dominic Price]

Thanks Fadoua. Brief is always a challenge for me ;-)

Agile is the ability to quickly and favourably adapt to your environment. The manifesto does a great job of sharing the spirit and philosophy in a succinct way.

I've also seen agile being used out-of-context, being that is doesn't represent the manifesto. Teams I've observed that go through all the rituals as if they are checking items off a to-do list aren't really working towards outcomes and therefore, to use your phrase, are using agile "out-of-context."

[Fadoua]

Thank you @Dominic Price for answering my question!

[miikhy]

Great call for questions, on a topic I'm very interested about!

Mine would be:

As an Agile practitioner and influencer, how do you feel about SAFe?

I've worked with some large companies here in Canada (banks, insurance companies etc..) and SAFe is a real topic where Agilists never share much more than a "feeling" that's it's great or not and should be considered as Agile or not. I did not find a lot of valuable and re-usable arguments in favor or against and I'd be curious to learn from your experience :)

Cheers and best luck for your presentation! 

[Darin Klein]

This ties into my workplace as well, great question! 

[Dominic Price]

Micky, hot topic and great question.

SAFe has many great ideas as do many of the other agile frameworks. There's no single one size fits all way of working however scaling agile does need some kind of structure, that includes:-

• shared ways of engaging other teams
• shared and agreed to language 
• congruence between the behaviours, practices and tools
• evolving customization of a framework

Whether it be SAFe or any other framework, make sure you have the foundation of WHY you are adapting a framework, what problem you are truly solving, and what trade off's are you willing to make. That will help either select the right framework, or build a hybrid that works for you in your environment. 

Let us know how you get on.

[miikhy]

Thanks @Dominic Price, much appreciated and clearly the kind of approach I was looking for!

[Deleted user]

I was a scrum master on a SAFe Agile team and participate on other framework teams.  They all focused on collaboration and empowered team members with a common short-term goal.  

[Deleted user]

Hello @Dominic Price,

Question;

How would you best address an organisation’s transition to an Agile framework? 

What options are there for teams within an organisation who are resistant to transitioning to an Agile framework?

Thanks Dominic 

[Meg Holbrook]

This is a great one! In a perfect world, every organization would see the proposed benefits, but some are 'stuck in the mud' for lack of a better term.

In my org, we started small with one agile team as a proof-of-concept, and are hoping to spread the agile bug elsewhere. Would be super interested to hear Dom speak on this. 

[Deleted user]

Thanks @Meg Holbrook, I have seen a lot of organisations run Agile transitions similar to a "POC"; implement an Agile framework for one team and report back on any benefits found.

The main problem I find is that most organisations are not looking to learn lessons, improve and roll-out the framework that the "POC team" has tailored to fit their needs, instead feedback is given and nothing changes. As if the "POC" was there as way of checking a box, a version of better-than-not-doing-it!

[Dominic Price]

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. 

Probably my favourite example right now is ANZ Bank in Australia who have gone through an Agile Transformation, and the outcome is New Ways of Working. The entire senior team are role modelling the behaviours that you'd expect, which is needed to get a 45,000+ person organisation to change. 

https://bluenotes.anz.com/posts/2018/06/q-a--elliott-on-the-healthy-chaos-of-agile

[Deleted user]

Cheers @Dominic Price

[Deleted user]

Heya @Dominic Price!

I know this is an old, tried dried and dusted question, but again, I would love to hear your take on this.

How can I pitch a move to agile to upper management in under 3 minutes, such that they would be intrigued beyond measure? 

Don 

[Dominic Price]

I want to be intrigued beyond measure! To intrigue here's what I'd say:

"Hey upper manager I've heard you're focused on (pick one of more of the following):

• Generating more value
• Controlling costs
• Engaging the people who work for you so they 

There's this thing called being agile, that if done well gets us more value for the same cost or the same value for less cost, helps us manage risk better and we'll also have happier people who produce better quality and save money by us not having to replace them. Can I get 30 minutes in your schedule to tell you how we could start doing this small to see how it can work here?"

Let me know how the intrigue goes. I'm intrigued.

[Kimberly Deal _Columbus ACE_]

I feel like continuous improvement is a really big part of the Agile methodology, but it seems like it is often brushed aside for getting from one sprint to the next as quick as possible.  I also often see it termed in ways that seem to apply only to the code or project. I see more and more businesses try to expand to using Agile in groups and teams outside of the development process, I see continuous improvement being shoved aside even more, as they don't see it as something that applies to them. 

So my question is, how do you get everyone to expand the items they think of when talking about continuous improvement, to include the process, workflow, team structure, knowledge and training of team members  and how do you bring that back into the sprint/project planning?

[C]

I like the question!   I think that is a culture issue!   I believe Continuous improvement is typically pushed out because people are uncomfortable with talking about their failures or challenges and identifying corrections steps or actions.    If your company culture does not support experimentation or accepts failure as a learning process, I think continuous improvements are not seen as a positive attribute. 

I recommend focusing on the "Why  continuous improvement is important to your organizations' success". ultimately, people typically do not do something that they do not see value in.   additionally, Unless someone teaches you the value continuous improvement can provide, they might not understand.

[LarryBrock]

+1 @Kimberly Deal - it's really important to stop with some frequency and have a retrospective on the process itself, not just the regular sprint retro's.  All too often, the focus gets too tight on making the things and how well we're making the things instead of stepping back and looking at how we approach the methodology we're using to define how we're making the things.  (Wow, that's a mouthful! :-) )  Cheers!

[Dominic Price]

That's pretty much what the Team Health Monitor is tailor-made to do. By asking questions like "Do we have the right balance of skills and experience on our team?", you're identifying the areas most in need of improvement. And by identifying follow-up actions and checking in regularly, you put the "continuous" in continuous improvement. 

Also worth noting is that the Health Monitor doesn't speak to code or specific deliverables. Like, not at all. It's all about assessing how you're working together as a team, and whether it's effective. So you're looking at whether your team is balanced, are you managing dependencies effectively, do you understand the value of what you're working on and how you'll measure success – things like that. 

We found a lot of teams focus their retro on their sprint, which is great. The health monitor complements that by coming up for air and looking broader at the team dynamic. They work really well together.

The trick to a retro or health monitor, isn't the exercise itself, but the action you take afterwards. 

[Kimberly Deal _Columbus ACE_]

Thanks! @Dominic Price

[Lauren Schroeder]

If you have a team that transitions to agile - how do you evaluate the effectiveness?

How long do you wait for results before deciding whether to keep new practices or revert back to old?

[LarryBrock]

Great question @Lauren Schroeder!  Having effective metrics showing positive results is a great way to build momentum and support.  I believe 3 sprints or at least a month should start to give some indication as to whether the change has been effective or not.  This can be greatly affected by the commitment the team has to change and the new methods.

[Lauren Schroeder]

Thanks @LarryBrock! I like that last caveat. 

[Dominic Price]

If I had to choose one, I'd say the simplest way to evaluate an agile team is their process efficiency. This is the number of valuable work items(one user story or ticket) divided by the number of calendar days it takes ship. So 1 user story per day is 100% efficiency, 1 user story every four days is 25% efficiency. You can quickly evaluate your transition to agile by charting the increase in process efficiency. Then, you need to drill deeper and find ways to increase the value of the stories you ship. 

My team does a monthly Team Health Monitor to check in on what practices are working for us on a regular basis. Try one out and let me know how it goes!

[Scott Theus]

Hi @Dominic Price,

In the (almost) true spirit of a Reddit AMA, I have an Agile/not Agile question for you...

I've been a project manager for 15+ years and as such many of the things I do at work bleed into my home life. For example, last weekend I was told that I do not need a Kanban board to clean out the garage! 

How does your work as an Agile practitioner help/hinder what you do during your non-working hours?

(On a side note...my wife also recently told me we should consider going back to Waterfall with full-on Stage-Gate approval meetings before I start any more projects.)

Thanks!

[SGD]

That's kind of hilarious. And I can relate! 

I'm constantly after my kids to finish one thing before starting another, and in my head, I picture a Kanban board every time! The WIP column is overflowing and the Done column is oh-so lonely. 

[Joe Tong]

Confluence confessions... I plan everything big at home using Trello.  If it isn't a card it doesn't exist.  

That said, my vacation planing boards are so awesome, I've got multiple friends that have asked for access so they can see where to go on various road trips I've taken.

[Kimberly Deal _Columbus ACE_]

@Joe Tong Now *I* want to see your vacation boards :D

[Dominic Price]

Hilarious and insightful!

My values in life very closely align to the Atlassian values, which makes for an easy life. But when it comes to me outside of work, I'm a very different proposition...you know they say never buy a house off a builder...never go to a dinner party with a chef...don't buy a car off a mechanic...don't let me plan anything! Ever.

The closest I've come to doing this, is using Trello boards to organise Christmas dinner (everyone brought a dish) and a spotify playlist.

I did try a health monitor in a relationship once...not so good.

If you want some inspiration, try this guy:

https://www.atlassian.com/blog/inside-atlassian/ran-kids-like-atlassian-team-month

[Monique vdB]

@Joe Tong if you don't write a community article about your vacation boards, I'm going to be very disappointed.

@Bridget ^^^

[Dominic Price]

Do It! Do It! Do It!

[Thomas Schlegel]

When we started with Agile, we got support from a well-respected consulting company. Their strongest advice was to not use electronical boards, just real boards with real paper issues. And we still have a lot of these, but also virtual boards in Jira. 

What do you think, is better? Would you say, issues should exist both in Jira and also on a real-life board?   

[Fabienne Gerhard]

Interesting question - we have big discussion about that right at the moment in our company. Looking forward to @Dominic Price answer!

[Carol Jones]

Based on this, is your team fully co-located?  None of the members of my team are co-located so this might be somewhat interesting for us :)

[Thomas Schlegel]

Yes, we are all working on the same place.  

[Dominic Price]

The right board for tracking work is the board that members of YOUR team will keep up-to-date. Some teams are really into physical boards where you move index cards from column to column. It's tangible, it's satisfying, it's easy. It's also completely unsuitable for distributed teams and it lacks a paper trail, so it's not a great fit for all teams. 

Whether you go physical or digital, show a bias for low overhead. Which means having ONE board. One source of truth. One place team members update their status. Don't create busy work for yourselves. 

In my experience, the best teams have the discipline of regular updates, openness and one source of truth.

[Daniel Wester]

How do you instill a sense of psychological safety at Atlassian?

[Dominic Price]

I love this question. THANK YOU for asking it. 

You can't run a top-down psychological safety initiative. It just doesn't work that way. Instead, we work to make sure individuals are contributing to a culture of safety in a few key ways.

First, we embrace honest failures as a learning experience. Nobody has ever been fired from Atlassian for taking a calculated risk that didn't pay off. And blameless post-mortems? You bet. In a failure-tolerant culture, it becomes far easier for people to admit when they've made a mistake. That admission, in turn, builds trust with the people around them and makes them feel like they can admit their mistakes, too – and the upward spiral continues. 

Second, we have an unofficial company value: "seek first to understand". In other words, start with the assumption that the person you're upset with is NOT an idiot. Ask them why they did what they did. Your desire to lash out will probably disappear immediately. 

Third, we focus a lot on belonging. So you'll find everything from informal mentoring circles for women on our technical teams to prayer and meditation rooms in our offices (and at events like Summit). We want every Atlassian to bring their true self to work. Fly that freak flag proudly. Because if you see the people around you being themselves, you'll feel like you have permission to do the same. 

I can't overstate how important psychological safety is for teams and companies that want to move fast and do big things. In today's fast-paced environment, a culture of fear is essentially a death sentence. 

[Matt Doar]

Great points there

[Monique vdB]

Wish I could click "Like" on this answer, @Dominic Price!!

[Thomas Deiler]

Dear @Dominic Price,

Which skills (and their levels) are obligatory for an agile coach to be successful in introducing agility to a team/company?

So long

Thomas

[Jodi LeBlanc]

Great question, and what skills and competencies do you most value for the future of work to stay ahead of the curve and not get left behind?

[carolyn french]

Interesting question and follow-up question!

[Dominic Price]

To nail the basics, an agile coaches should have a thorough understanding of agile practices, tools and processes. They should have experience in building, operating and improving agile teams and a deep understanding of agile methodologies. 

The best agile coaches I've seen guide teams through the why, what, when, and how they do what they do. They provide context in an ever-changing space by supporting, guiding, challenging, and ultimately enabling teams.

Above all, I believe an agile coach needs to be constantly learning. The higher your learning velocity, the better! Our coaches at Atlassian are constantly refining their practices and shipping them live to our Team Playbook. Check it out! Hopefully you find some good tips and tricks in there!

In the future of work context, I believe that as humans, we need to be more human. Find what makes us uniquely us, like empathy, compassion, creativity and curiosity, and utilise those skills.

[Danny Zuccaro]

Hi @Dominic Price

We are a large organization with many teams at different stages and with different Agile practices. There is also a number of groups that have not adopted Agile. Any tips or suggestions on how to best have all these groups work together on inter-dependent multi team projects. 

Thanks!

[Dominic Price]

My old mate Danny. Great question, and tough one to answer without knowing more. Maybe I need to come visit!

Some of the best insights and lessons I've learnt about inter-dependent multi team projects, is from the book Team of Teams, which is a great read. 

The way we've practiced that internally at Atlassian, is through having a strong and clear purpose that the teams align on (Shared understanding), and then having clear role and responsibilities in teams, and across teams, through an Engagement Model. It means our teams can remain semi-autonomous, avoids us building slow and monolithic teams, and keeps the communication, language and expectations between teams, clear and open.

[Danny Zuccaro]

Thanks @Dominic Price! And you know we've already rolled out the red carpet, just waiting for your arrival. 

Thanks for the tips and will certainly give Team of Teams a read. 

[Fadoua]

:)

[Davin Studer]

What are some good processes to prioritizing/triaging work to be done in a given sprint? Atlassian has a huge list of items in its product backlogs. How do y'all decide what gets worked on?

[Lindsay Czopur]

I second this question!  We have a lot of internal people who really dislike when we get urgent market feedback that needs planned and prioritized above current initiatives, but we have to get it done quickly, or else our users will not have a good experience and we could potentially lose revenue. In addition to prioritizing, how do you get buy-in from everyone and not disgruntled employees when something new and urgent emerges?

[Dominic Price]

Prioritizing work is a dark-arts melange of customer value, business value, and urgency. Atlassian starts by setting high-level objectives for a year that the whole company is going to work toward. From there, each department or team decomposes that into quarterly goals for themselves. And from there, we can prioritize the work on our backlogs from week to week. 

We actually just added a new play to the Team Playbook for prioritizing your team's work – check out the Relative Prioritization Matrix. 

The cold reality is that some things simply don't get done. Or, don't get done in a particular timeframe. There just aren't enough hours in the day. But by making sure our plans for each week ladder up to the big company-level objectives, we can be confident that we're working on the right things at (roughly :-) ) the right time.

[Tarun Sapra]

Hello @Dominic Price

The Agile topic I am most interested in right now is "Agile Metrics". Based on your experience, could you please share some key Agile metrics that validate whether or not the ongoing Agile transformation or Agile practice are delivering value or not.  Especially if you can share some Agile metrics which large enterprises would be interested in. 

[Dominic Price]

Some of us have found these useful:- 

• The trend of how long it takes an idea to go live 
• The trend of escaped bugs
• The trend of value delivered 

Use them together so that if teams focus too hard on one of them you'll see the impact on the others.

There's some great content at Focused Objective on agile metrics. For a deeper dive into metrics for agile teams, check out the research conducted by DORA. Leaders across Atlassian are obsessed with the book they wrote, Accelerate. 

[Kristian Walker _Adaptavist_]

Hi @Dominic Price,

My question is for an organisation that is just starting to use the Atlassian suite of tools for there agile practices, what would be the top 5 plugins that you recomend they look at using and why?

Thanks

Kristian

[Kira]

This is a good one! I'm wondering the same :) I know JSU for sure. Any others?

[Dominic Price]

We have an incredible Marketplace of apps (https://marketplace.atlassian.com/addons/app/jira), and the "best" app really depends on your needs. 

WIth that said, here are the apps that I have used and loved with Jira: Tempo timesheets, ScriptRunner for Jira, JSU - Suite Utilities for Jira, Jira Misc Workflow Extensions, and Zephyr for Jira (test management). But I encourage you to consider the gaps you currently have, and explore the Marketplace for the best app.

[Ignacio Pulgar]

What closed-ended questions help you determine whether or not an organization is Agile?

[Dominic Price]

Questions like:-

• Are you shipping value frequently?
• Is that frequency improving?
• Are you using frequent feedback loops to continually improve your product?
• Are you using frequent feedback loops to continually improve your process?
• Are your people becoming more cross-functional?
• Are your people engaged?
• Are your teams resilient? (pro tip: we use a health monitor to check in on our team's resilience monthly)

[Ignacio Pulgar]

Thanks so much, Dominic!

[Bryan Trummer - ReleaseTEAM]

What is your top piece of advice for a company moving to Agile? One of the pitfalls to avoid when trying to adapt to Agile?

[Dominic Price]

Thanks Bryan.

Meet the people where they are and help them solve the problems they have using agile behaviours and practices.

Accept that agile might be 'an' answer, but not 'the' answer, and that there may be other methods of working that make teams effective. 

One major pitfall I've seen, is that companies forget to unlearn old habits, rituals, or practices and just add in new ones, which is very confusing for people. Make sure you stop something, before you start a new thing :-)

[Michael Ellis]

Hey @Dominic Price!

When it comes to company culture, from your experience how much influence and impact can an individual have in changing or influencing culture? Or is this something that must be defined and modelled by founders / CEO?  Asking for a friend ;)

Mikey

[Tanja BB]

+1

[Dominic Price]

Mikey.

I think we can have as much impact as we believe we can have. Cheesy I know, but think about it as having two options. Option 1, you do nothing. It wont improve and you don't learn good habits. Option 2: You do something, and it might improve, and you'll definitely learn something.

I used to suggest that it was the CEO and leaders job, and then someone told me "you know you're a role model for many employees....right?". I remember being shocked, as I didn't have "leader" in my title, but culture isn't the org chart. We're all role models, whatever our position.

[Billy Poggi AUG NOVA_ DC]

Hi @Dominic Price 

You're all over crushing it in the world of spreading the news about all the ways the teams can collaborate and be awesome together.  The real question is, where do you get all of your cool tshirts and how can we get some...?

Cheers!

-Billy

[Dominic Price]

You really know how to make a bloke blush, Billy! As far as Atlassian swag goes, there's an app, well website, for that! https://atlassian-swag.mybrightsites.com/products?s%5Bf%5D%5Bc%5D%5B%5D=%2FApparel

[Billy Poggi AUG NOVA_ DC]

Woot!  Thanks for the link!  I'm going to see how much we can score for the AUG Members ;)

[Brittany Joiner]

Couple questions!

1) What are some common myths about agile that you think are holding back teams from moving into agile?

2) Not really agile related, but on the future of work... what do you think the state of remote work will be in five years? Will people still come into offices? What kind of obstacles will prevent a fully remote workforce?

Thanks! Looking forward to this!

[Dominic Price]

One myth holding people back is the idea that agile is only for software teams. Not only is this patently untrue (HR, Marketing, Design... all these disciplines can benefit from iterative planning and execution!), it's creating friction within organizations. If your software team wants to work in an agile way, but your design team doesn't think agile is for them, the two teams will be consistently out of sync, and massive headaches will ensue.

Regarding remote work, it's only going to be more prevalent. First, there's a war for talent going on. If you're limiting yourself to candidates to live in your area or are willing to move there, you will struggle to find the right people. Second, the tech that supports remote work and distributed teams is improving by the minute. We have loads of digital tools for sharing our work, and video is so easy these days, you can fire up a call with one click. Third, urban office space ain't getting any cheaper, even in relatively low-cost cities. 

I'm not sure anything exists to fully prevent an all-remote workforce. But I will say that relationships are extra-important in this context. In my experience it's best to spend time together in person once in a while, especially when the team is new or a new member joins. Kick-start those relationships in person, then maintain them remotely. 

[Brittany Joiner]

Love this! Thanks Dominic!

[Deleted user]

Sorry @Dominic Price, I have a follow-up question; 

Q: What predictions can you make for the changing models for work and work structure? 

[Dominic Price]

I believe that work will become more distributed, and there will be less of a focus on working hours/office, and more on energy, work anywhere, and contribution to outcomes.

I think the rate of change of roles and jobs will increase, and we'll need to re-skill more.

I believe we need to develop more discipline in being connected, and disconnecting, so that we actively manage mental wellbeing.

We need to focus on being effective, and efficient, when I think history has focused on just efficiency.

[Jobin Kuruvilla [Adaptavist]]

It is a common practice to blame it on the tool when things are not working in their favor. And we, as Atlassian experts, see that a lot while onboarding teams to the Atlassian stack or to new methodologies like Agile. Those who resist the change are quick to point out what the tool "cannot" do.

Having said that, I always favor tools that doesn't restrict much. One of the biggest advantages of tools like Jira is that it can be customized to do pretty much anything, to meet specific customer requirements. However, more and more restrictions are coming on to these tools these days.

For example, a popular request for Scrum boards is the ability to move a story between statuses in the same colum. Here is an interesting discussion on the same: https://community.atlassian.com/t5/Jira-questions/How-to-move-between-statuses-in-a-column/qaq-p/320156.

Whether I agree to it or not doesn't matter. My question is, shouldn't it be left to the customer to decide? Does it make sense to restrict/limit something in the tool because that is the "right" thing to do? Shouldn't the tool leave it to the user to decide what is the best option, in the context of their process? Maybe the tool should just make it configurable?

Or in other words, what is more important? The tool or the process?

PS: It is not a secret that I love Jira. Just picked an example that people can easily relate to ;)

[Dominic Price]

First, let's be crystal clear on one thing: the process is more important than the tool. Full stop. 

Now, are Atlassian opinionated about what good processes and good team practices look like? Hell yes. And do we bake those opinions into our tools? Absolutely. 

Jira is one of the most flexible, configurable tools on the market. That's a big part of what makes it so powerful. The flip-side, though, is that Jira gives you a lot of rope to hang yourself with :-) We don't want customers to use Jira to make life miserable for their teams, unintentional as it might be. So we build guardrails into our tools that nudge teams toward practices that are proven to be more effective, healthy, and sustainable over a long period of time. 

The magic happens when tools, practices, and people are all congruent. Just think about when it's not congruent... hire open, curious, autonomous people, give them strict practices/process, and a tool that requires lots of approvals. They'll be confused as hell.

Practically speaking, admins do get asked to configure our tools in ways that aren't aligned with agile or general collaboration best practices. It's ok to share that point of view with the person requesting the change as a bit of food for thought. They might persist with the request, but at least they're doing so with eyes open. 

[Jobin Kuruvilla [Adaptavist]]

Yeah, I hear you. And, more often than not, magic does happen!

But yeah, sometimes you are left with a fight that you can't win. Then we ask them to create a feature request with Atlassian :D

[C]

Before one decides to "go agile" how should they identify the pain points that they want to solve?

For example, there are three reasons people want to go agile:

1.  Improve personal resume to get a cool new job.

2.  Address an organizational or team pain point.

3. Chase shinny Objects

I think #1 and #3 are self explanatory, however, #2 is something that most people cannot articulate, and therefore, do not actually address when conducting and agile transformation.

What Tips and guidance would you provide for teams who want to change (Process, tool, technique, etc.)?  how do you identify the root cause of your current SDLC pain points or deficiencies?

[Dominic Price]

Identifying and articulating a team's pain points is exactly why we developed the Team Health Monitor. In a Health Monitor workshop, you'll walk through 8 attributes of healthy, high-performing team and assess where your team is at. 

Now, full disclosure: will the Heath Monitor reveal why your continuous delivery pipeline is clogged or what's lacking in your planning process? Not exactly. But it will prompt the kinds of discussions that will set you and your team on the path of figuring it out. 

I also recommend the "5 Whys" technique for root cause analysis. For example: "Why do our release dates consistently get pushed out?" If the answer is "We keep finding blocking bugs at the last minute,", then you follow with "Why do we keep finding blocking bugs as the last minute?" ...and so on. By the time you've asked "why" 5 times, you've probably zeroed in on the true root of the problem. There are full instructions (along with more examples) in the Team Playbook – atlassianteamplaybook.com 

[Brant Schroeder]

What are some techniques and processes that you use to change the culture of an organization to better align with agile methodology?

[Dominic Price]

Thanks Brant.

It's all about evolution instead of revolution. Here's yet another place where the Team Health Monitor can help. It gets teams into the habit of reflecting, assessing, and improving regularly. 

Making the mental shift from valuing perfection to valuing progress is massively important for teams transitioning to agile. The Health Monitor workshops are designed to create a safe space for admitting to ourselves that things aren't perfect right now... and that's ok. Because we're going to start making some progress on them. Continuous improvement for the win. 

[Laura Nicol]

What simple methods can a middle manager use to create an agile team? 

[Dominic Price]

Hey Laura!

What does an agile team mean to you and what is the problem you're trying to solve?

To quote from a previous question: 

"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. "

One of the most important ideas to keep in mind is that Agile is really a set of values and principles - you can start with aligning the team here. 

The last thing I'll say - also quoted from a question previously:

"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."