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!
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.”
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.
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.
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?)
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.
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.
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."
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!
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:-
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.
Hello @Dominic Price,
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?
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.
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!
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.
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):
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.
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?
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.
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.
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?
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.
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.)
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.
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.
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:
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?
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.
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!
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.
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.
Some of us have found these useful:-
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.
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?
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.
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.
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.
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.
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 :-)
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.
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?
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
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 ;)
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
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.
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!
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.
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...?
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
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 ;)
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.
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.
Let's face it, work can be challenging but fulfilling, especially when you enjoy the challenges thrown at you. However for me, nothing compares to going on vacation (or holiday as some of you m...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events