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

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

61 comments

Comments for this post are closed

Community moderators have prevented the ability to post new comments.

Post a new discussion

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!

Like • like this

This ties into my workplace as well, great question!

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.

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

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.

Hello Dom,

My question is

Why to go with Agile, if there is Holacracy? :)

Like • like this

Isn't Holacracy just a single consulting company that has invented a new term? I'm genuinely curious. At least "Agile" is not owned by anyone.

I've had a look at Holacracy website a few times, and I'm fascinated by some of the concepts, but I'll admit, I've never truly tried to follow it.

Based on the #retroonagile we ran in our booth this week, there is no doubt room for growth with Agile, but also an overwhelming amount of happy, devoted Agile adopters.

@Alexey Matveev: Probably best to say that Holacracy and Agile are equally similar as they are exceptionally different.... and same old answer, that fits all approaches to management of organisations, projects, process, change, etc.: "Choose the one that best suits your organisation" ;o)

@Kat Warner : You're not wrong there, although a company can still just pick up the book and be Holocratic without the getting accreditation. Not easy though: check out on any streaming service how Zappos has achieved Holacracy. Loads of videos on it.

Here's both in a nutshell from the almighty Wikipedia - I've taken the term Agile to mean 'Agile Software development' (i.e. the birth place of agile):

Agile software development describes an approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s). It advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages rapid and flexible response to change.

Holacracy is a method of decentralized management and organizational governance trademarked by HolacracyOne, in which authority and decision-making are distributed throughout a holarchy of self-organizing teams rather than being vested in a management hierarchy. Holacracy has been adopted by for-profit and non-profit organizations in several countries

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

Like • like this

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.

Like • _Fabian A. Lopez likes this

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!

Like • _Fabian A. Lopez likes this

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

Like • _Fabian A. Lopez likes this

Cheers @Dominic Price

Hi @Dominic Price,

in addition to Micky's question, what is your opinion on the LESS framework and what do you think where they have their strengths.

Thanks

Like • Stephanie Grice likes this

LESS' strength is that it’s lightweight on purpose. Typically teams may go from a single scrum team to a ‘scrum of scrums’ (maybe 3 teams) and then to LeSS. So it provides all the same rituals of scrum, just at scale, which is also good if those practices are already familiar to a team.

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

Like • like this

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

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.

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

Like • like this

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.

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?

Like • like this

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 :-)

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?)

Like • like this

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.

Like • Soumyadeep Mandal likes this

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

Like • like this

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!

Like • like this

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

Thank you @Dominic Price for answering my question!

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.

Like • like this

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.

When people talk about Agile, mostly they refer to Scrum which is the most popular methodology. Couple of questions from my side related to that..

Is Agile (Scrum) actually a good option for distributed teams? Comparing both, a team working in the same room and distributed. Would both have the same velocity? Would it change if they would switch sides?

If you have many remote teams and you want to make a switch inside a team... How does it work if you switch individuals across different teams that are working remotely? Are they adopting slower and being a bottle neck instead giving more value to the team?

What about timezones and meetings across the globe where you cannot have sometimes even 1 hour to go through the sprint planning or retrospective without rush? Is this effective Agile?

After few sprints and deliveries team notice that they are starting to receive more and more bugs. Suddenly they realize that do not have time to deliver something new to customer (spending time only on bugs). Very often then they want to estimate those bugs like stories. Is this goo approach even estimate is called a "Story Point" not "Bug Point" or something similar.. Do we even can estimate a bug (like stories) if this requires initial troubleshooting and might be hard to put it next to new features.. Maybe there should be a dedicated team that only resolves bugs using Kanban not Scrum and bugs should not land in backlog?

Do you feel that when using Scrum people do not take much attention to documenting things? Even Agile manifesto says: "Working Software over comprehensive documentation". Not having good documentation not always work if the project is bigger and people are switching across teams.. and later resolves bugs..

Thanks for replying! :)

Like • like this

According to a study of 10,000 teams performed by Larry Maccherone and his team at Rally, distributed teams are actually higher performing than co-located teams. Larry's study also shows that the benefit of being distributed is reversed when teammates are more than three timezones away....which is unnerving for me given my team is spread across Minneapolis, San Francisco and Sydney, but the reality is, that's the norm these days so we are forced to find ways to collaborate better and continuously improve our practices.

Adopting a tool that allows every team member to see exactly where work is in the workflow is a critical piece to making my distributed team function (we use a combination of Confluence, Jira and Trello). There are probably many tools that can do the job, but since I know most about Jira.... it allows teams to slice and dice work into the workflow stages that make sense for the team, which means everyone is on the same page and held accountable for their contribution to the project. Commenting and feedback can be done in real-time, in Jira, so potential bottlenecks or blockers don't have to wait until a formal meeting. It also keeps sprint planning and reviews with the team very focused (because my whole team has shiny object syndrome).

Check out the rest of Larry and team's study for more insights into comparing co-located and distributed teams velocity, quality and productivity.

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?

Like • like this

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?

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.

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?

Like • like this

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.

+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!

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.

Thanks! @Dominic Price

HI @Dominic Price!

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

:) Thanks!

Like • like this

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.

Like • Soumyadeep Mandal likes this

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 :)

Like • Soumyadeep Mandal likes this

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.

Like • like this

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!

Like • Soumyadeep Mandal likes this

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.

Like • Soumyadeep Mandal likes this

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

Like • like this

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.

What would be the real motivation factors for a team to keep agile "going"? Or how to avoid bumpy rides in an agile road.

I have seen some frustrated teams that wishes they got the real benefits every minute they spend within the agile environment.

Like • like this

I think the frustration is sometimes that you're following the rituals, but not seeing the results. In my experience, that is often caused by not realising the real outcome of the ritual. EG: I've seen teams religiously complete retro's, but get frustrated, that is because the same things are coming up every time. They aren't following through or management isn't helping to remove systemic blockers.

I also think many teams and organisation can do better at storytelling about what works and what doesn't, and being open and honest about the challenges they're facing. Also have customers and business people come in and share stories about how the software your teams are creating are helping improve the lives of people. Sadly agile teams can, over time get disconnected from the value they're creating, and working down a backlog can just feel like you're a backlog item processing machine.

When you read about Netflix and their culture deck (Patty McCord book "Powerful"), they were always very honest with the challenges the company was facing. No sugar coating.

There will be bumpy rides, so just make them less of a surprise.

Hi @Dominic Price

Has Agile outlived its usefulness? if it has, what will be next? maybe hybrid frameworks?...

Thanks!

Like • like this

A topic which has much debate Carlos.

Agile and agility are likely to remain useful for the foreseeable future, especially when you look at tech change, AI/Robotics, increased competition, innovation, war for talent, and borderless business.

As I mentioned in the question about the Agile Manifesto, what's next is for teams to use agile as a springboard for experimenting with practices and frameworks customized to suit their needs. For example, one of agile's core principles is cross-functional teams. Now, does that mean each person should belong to one, and only one, cross-functional team? No. Atlassian already has a number of "nuclear teams" (teams that report to the same manager) who work together in one capacity (say, design), but whose members are also on cross-functional project teams.

How can the tools an organization and their processes impact a culture? Can the implementation of your solutions and methodologies actually block your goal to improve your culture.

Like • like this

Yes! Tools can absolutely get in the way! I like to say that "a fool with a tool is still a fool... but now they're able to be foolish much more efficiently"

Look: tools aren't worth a damn unless they're supporting effective collaboration practices. If your planning and prioritization practices are crap, and you buy Jira, your practices will still be crap. The only difference is that now people will blame the tool. Which really sets you back because you're masking the true root of the problem.

So get the practices and people right first. Only then should you layer a tool on top of them.

Is X dead?

Is X dying?

where X is the name of really useful framework/methodology (after a while).

Like • like this

I think if you google most popular methodologies, you get that.

In truth, I think it's time for us to reframe Agile, and the variants of Agile, by going back and falling in LOVE with the problem we're solving.

We also need to stop looking for other teams alleged "best practice" and plugging it into our organisations, without realising that they other company is in a wholly difference environment to us.

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?

Like • like this

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

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!

Like • like this

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.

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.

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 ;)

Like • like this

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.

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

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

Like • like this

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)

Thanks so much, Dominic!

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

Like • like this

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?

Interesting question and follow-up question!

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.

The challenge I have run into w/ Agile is associated with the development of embedded solutions. That is, where a company is developing the hardware system and overlaying the software. Personally, I have not even considered inserting agile into the hardware piece but certainly have on the software deliverables. The challenge invariably comes in when trying to get the QA (system test team) working w/in the same sprint w/o unnecessarily bloating the sprint. What we end up with is a hardware development process (waterfall), a software agile process and then an odd QA process of incremental testing of sprints with a final QA once the last dev sprint is complete. This isn't ideal and I'm always interested in how others in similar product development environments leverage agile practices.

Like • like this

I'll be honest, mate: hardware or component development is not my area of expertise. However, have you looked into a practice called "concurrent engineering"? Again, I'm no expert, but it appears to be a framework for developing physical components in parallel with the software that controls them.

Curious to hear whether other participants in this thread have advice to lend here! #AlwaysLearning

@Jack Brickey

I work at a company that also develops embedded software solutions. We've migrated most development teams to Scrum (with JIRA project boards and BitBucket). The problems associated with relatively longer/delayed hardware, test, and manufacturing time boxes have been tacked a couple different ways with varying success:

A scrum of scrums to discuss any issues that need cross-functional attention Scrum of scrums was comprised of the technical leads of each functional area within that project
Slicing stories into small cross functional pieces of value that can be completed within the same time box

This is a work in progress for us and definitely falls under the #AlwaysLearning. I intend to incorporate some of this into a paper for Atlassian Summit '19? :)

Comments for this post are closed

Community moderators have prevented the ability to post new comments.

Post a new discussion

Recommended Learning For You

Level up your skills with Atlassian learning

Redesign your workweek

Configure your calendar to prioritize high-impact work and goals. You'll learn how to set daily priorities, prioritize essential meetings, and schedule focus time.

40m Beginner

Free

How to run effective meetings

Lead efficient meetings that have clear goals, keep your attendees actively engaged, and use the Atlassian Playbook to improve meeting success.

30m Beginner

Free

How to build strategic guidance

Build a high-performing, effective team by providing clarity, defining success, and making it clear who will benefit from your efforts — a technique we call strategic guidance.

30m Beginner

Free

Was this helpful?

Thanks!

Teamwork Lab

Forums

Product Q&A

Community resources

Support

Top groups

Community resources

Support

Learn

Community resources

Support

Events

Community resources

Support

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

61 comments

Comments for this post are closed

Comments for this post are closed

Was this helpful?

Thanks!

TAGS

Atlassian Community Events

Forums

Product Q&A

Community resources

Support

Top groups

Community resources

Support

Learn

Community resources

Support

Events

Community resources

Support

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

61 comments

Comments for this post are closed

Comments for this post are closed

Was this helpful?

Thanks!

TAGS

Atlassian Community Events

Welcome to the new Atlassian Community