That's a wrap! AMA on the psychology of high-performing agile teams

[Mary Raleigh]

UPDATE: That's a wrap on our AMA. Thanks for taking part and asking such interesting questions!

Have you ever wondered why some teams excel (hello 96' Chicago Bulls!), while other teams, with seemingly similar qualities, struggle? At Atlassian, we’re hyper-focused on helping teams unleash their potential, and know first-hand there’s no silver bullet to becoming a high-performing team. It takes strong metrics (team performance) and happy, trusting team members (team psychology) – and both measures affect each other.

So what actions can you take to help your team improve in both happiness and performance? How can you become/remain a high-performing team even amid a global pandemic, when teams are facing more obstacles than ever before?

Megan Cook, a former agile coach, has been at Atlassian for over 7 years and currently serves as the Head of Product for Jira Software. As someone who eats, sleeps, and breathes agile teams (when her newborn daughter isn’t keeping her up), Megan is excited to share her experience helping agile teams big and small unleash their potential through a people + products + practices equation.

Dr. Mahreen Khan has a PhD in Organizational Psychology, and has spent the past few years researching topics like creative performance, productivity, and emotional intelligence development. She recently joined Atlassian’s research team to lead a program to understand the science of high performing teams. She is thrilled to be able to share her insight into the connection between team happiness and team performance.

Join our AMA on Tuesday, June 23rd to ask Megan and Mahreen any questions you have about agile team psychology and team improvement. They can’t wait to engage with y’all, and hope to help alleviate your teams' most pressing challenges.

Start submitting and upvoting questions now below (yes, it says “answer” 😉), then tune in on June 23rd from 2-3pm PST / 7-8am AEST when Megan and Mahreen will be answering all submitted questions LIVE!

Need some inspiration on what to ask? Here are some ideas:

• What are some tangible things my team can do to become more agile?

• Should I be measuring my team’s happiness? If so, why?

• What successes and failures have you seen as teams try to adapt their agile ways of working to a 100% remote environment?

• My team takes too long to make decisions. Why is it so hard to get on the same page? What can we do to unblock ourselves?

[Chad Wight]

Any recommendations on ensuring what is delivered to customers (in our case, software automations/enhancements delivered to internal operational resources), gains awareness, on new capabilities, with maximized adoption?  Favorite tools/methodologies/constructs, or formulation of messaging?  Thanks

[shannyshan]

Hey Chad! Great question. Jumping in to help as a Marketing Manager who has definitely struggled with this in the past! Communicating changes to customers is a crucial step of the overall development process that is easy to overlook (especially when you’re focused on shipping quality stuff out as quickly as possible).

One way to get ahead of this early on is to embed Product Marketing within the development process. Instead of a typical triad made of up development, product, and design (where marketing is usually downstream and only hears about new stuff they need to announce once its already shipped), try a “quad” model that includes marketing, too. This is a fantastic article from one my teammates that explains the benefits of including marketing early on, and gives tips for breaking down silos and building empathy among dev, product, design, marketing, etc. It also includes some suggested Atlassian Playbook plays to help clarify roles & responsibilities, define and guide work, and make better, faster decisions as a group.

A few other methodologies/templates/tools that might help:

• In terms of messaging, I strongly recommend developing a “message house” that you send out to every team involved in the launch (writers, designers, sales and events teams, etc.) to ensure everything you’re putting out clearly presents the customer value, competitive differentiation, etc. Here’s a message house Confluence template to get you started!

• Intercom has a great e-book on Marketing that includes a helpful framework you can use to determine if something is worth announcing and how to go about announcing it to ensure the most awareness, adoption, etc. (pages 77-82 of the e-book)

• LaunchNotes helps keep your internal teams and external users ahead of upcoming product changes with features like an internal change feed, a public release stream, release articles, and end-user subscriptions/notifications.

• Appcues and Pendo are tools that let you publish in-product annoucement, tooltips, tutorials, etc.

Hope this is helpful for your teams - let us know how it goes!

[Chad Wight]

This is brilliant, thank you so much!

[Marianne Miller]

How do you support the team when you have a strong PO who attends stand-ups and expects status updates and drives the team away from established agile practices?  The PO has close relationships with 2 devs, which impacts communications with others on the team and creates knowledge vacuums.  We've addressed it as a process issue, and agree as a team to correct, but quickly fall into the old patterns.

[M]

I can relate to this challenge, Marianne! There’s always going to be people who resist new ways of working. Depending on the trust level within the team, I’d pursue one of two paths. Path 1 is if you feel your team can be vulnerable and open about sharing the pains in front of the PO. If that’s the case I’d try a Health Monitor. It’ll give you a great structure to compare your team to the 8 qualities of high performing teams and hopefully illicit conversation among the team that helps the PO see how their behavior is affecting the team. Path 2 is if you feel your team will not be comfortable openly discussing their pains. You could try a Rules of Engagement play. I like this option because it’s a way to openly discuss and improve the pains of your team’s processes without forcing an uncomfortable conversation about the interpersonal dynamics that the team might not be ready for.

With either option 1 or 2, make sure that at the end of the session you commit to only one action item. I find teams tend to feel overly ambitious and take on too many changes at once. Teams who try making one change at a time and commit to making it stick are most successful in improving their teams' ways of working.

[Alex R.]

MIght be a basic, but it's on the top of my head.

In a remote team setting, how do I make young(mid 20's) developers more accountable and like using JIRA?

They keep missing deadlines, struggle to organise (add, move, complete) tasks on the board.

I don't micromanage them and provide freedom of how they want to accomplish the task as long it reflects goals of the task and delivers the result. So, they defo don't stress or hate working on the project. Nobody holds them either, they are free to walk out anytime. They are good developers. It's just everything gets in their way, family stuff, pets, friends you name it.

And the second part of the question is they don't like log in JIRA and I don't feel like I want or can force them. It could be pa my fault as well. It's not like I hired them with the main requirement to love JIRA in the first place. I hired them for their skills.

Anyways, I am looking for some psychological patterns that I could help me understand the reason behind of all it and sort this mess out.

Thank you

[Gizem KILINÇ]

Can't we vote this question a million times? :) 

I have some questions for this question. I would be very happy if you could answer. 

• Are stakeholders involved in events as required?
• What do you mean by "they keep missing deadlines". ? Are they just missing upgrade JIRA or are they missing both the upgrade JIRA and work to be done?

[Mahreen Khan]

Very interesting question Alex! I believe the heart of your question goes well beyond using Jira and reflects a core question that the field of psychology has been trying to answer for decades: how do you change someone’s behaviour? Why do I sometimes stop going to the gym when I am trying to lose weight? Why do students sometimes watch TV instead of studying right before an exam? Why do smokers sometimes have a cigarette on a night out when they are trying to quit? Why do developers not use Jira when it is so important for collaboration? 

One of the most influential theories in trying to understand human behaviour is the Theory of Planned Behaviour (1985, 1991). This theory proposes that behaviour are predicted by intentions. Intentions are predicted by attitudes (do I feel positively or negatively about the behaviour?), subjective norms (is everyone else doing it?) and perceived behavioural control (do I find the behaviour easy or hard?).

For Jira, developers are more likely to use Jira if they intend on using Jira. They are more likely to intend on using Jira if they have positive attitudes towards it, it is the norm to use Jira and they find it easy to use. Accordingly, to influence your team to use Jira, you can use the following steps: 

1. Enhance positive attitudes towards using it: Attitudes are predicted by beliefs. Do the developers believe that using Jira is worthwhile? If they do, they will be more motivated to use it. By simply communicating the benefits of using Jira, and how important tracking progress is for goal attainment, positive attitudes towards the product are likely to improve. 

2. Make it the norm to use Jira: By leading by example, and using Jira yourself and communicating that you are using it frequently, you are more likely to inspire someone else on your team to use it more regularly. This, in turn, is likely to have a domino effect where more people start using it. A child who is in a school where every student studies really hard for exams is more likely to do so compared to a child in a school where students study more half-heartedly. 

3. Figure out if everyone finds it easy to use Jira: Perhaps there are some members in your team that find it difficult to use Jira for some reason? If they do, or are relatively unfamiliar with the product, it would be worthwhile teaching them how to use it. If everyone finds it easy to use, they will be more likely to want to use it. 

Good luck with the above steps, and hopefully this will help inspire some positive change.

[Carmina Lange]

What are the top 3 metrics to look at as a lagging indicator on how the team is performing at their peak?

[M]

Hey Carmina! Thanks for raising this interesting question. It seems like you’re trying to retrospectively understand how the team has been performing in the past and whether it was over or under their baseline. 

While the definition of a high performing team might vary depending on your industry or company culture, we highly recommend that you take a holistic approach. This means the team shouldn’t be judged solely in one vector. Like what you suggest, a few metrics need to be in place, where each looks at a specific aspect of the team. Moreover, this should be a team exercise to agree on a set of metrics so there is an alignment when reviewing them retrospectively. 

Firstly, you can start from the team’s mission or goals. What is the team out to accomplish and how would you measure the outcomes? This will not only give you a way to measure a team's performance retrospectively, but keep the team focused and motivated. At Atlassian, we use OKR (objectives and key results) to set up goals for the company as well as for the teams, so everyone is aligned on the mission.

Secondly, there are some good engineering metrics that can highlight areas of improvement for your team. Now, there isn’t one metric to rule them all because a lot will vary based on your team’s process, tooling, and workflow. The goal here is to understand how your team’s workflow can be optimised to meet the team’s goals, like an OKR, as mentioned above. Discuss where most of their time is spent (and where it should be spent), where they get unnecessarily stuck in the pipeline, and then come up with metrics that can best measure improvements in those areas. For example, this can be about how long a piece of work takes to get into the hands of customers (cycle time), or how often you’re shipping value to customers (deployment frequency). A good starting point is the DORA metrics.

Last but not least, high performing teams are also fulfilled, motivated, and healthy. While this isn’t easy to accurately measure, it is important to keep the pulse of the team's health in check. At Atlassian, we regularly get together as a team to run health monitors for this. Whether it’s run in the beginning, middle, or at the end of the project, this gives us a good idea of how the team is performing; the peak performing team will be seeing many green lights. 

Once you agree on these metrics upfront, they will be helpful to the teams when reviewing the performance retrospectively. As you closely involve your team in this exercise, it will become clear what your team’s baseline and target should be. 

So I know that isn't just limited to three metrics but teams are complex and the context in which they're working plays a massive part in how to measure their success. Generally I look towards three areas:

1. Is the team getting the right outcomes for the business?
2. Are they able to deliver high quality work on a predictable schedule?
3. Are the team cohesive and happy working together?

[CI]

How do you approach the politics?

In many companies there is a power play between the devs/delivery side and the product side...and most times they use a Scrum Master or an Agile Coach as scape goat for their shortcomings...either in the product side or on the delivery side - instead of discussing the elephant in the room.

[M]

This is a fantastic question. That tension between developers and product doesn’t have to be a bad part of politics. It’s necessary and healthy to have it in place. It sounds like there may be a few issues you’re facing:

1. The scope and/or timeframes are not balanced for the time it takes to deliver

2. The team have become divided and are blaming each other instead of working together to solve issue #1

The first step would be to make sure both product and developers have been brought together as one team with the same goal.

For issue # 1, I’m guessing this is a classic case of developers only being able to deliver so much. However product keeps adding more scope than the developers can deliver within the agreed timeframe. Generally there’s some flexibility in how much developers can deliver but it usually comes at the cost of the quality or the product or burnout for the team. The product manager can also cut scope to meet the team’s deadlines but they need to ensure their customer’s needs will be met, and will push to get as much into the product as possible. The team can agree to push out the deadline but that may come at the cost of other external factors, such as if an announcement to the market has been made on when a new product will ship. It’s good to have two different groups of people advocating for these two different sides of the problem. When a team is operating well together this tension can result in problems being surfaced early, a lean well prioritised roadmap, and a team with a strong bond from working through these challenges together.
Agile can help teams surface where this tension will cause issues. A kanban board can be used to show the amount of work the team has taken on, whether they have too much in flight at one time, if work is getting stuck in a particular stage, and give an idea of how long it takes the team to get through work. This visibility helps the developers communicate how much work they can get through and push back on too much scope. Without visibility of the issues and a shared understanding of the problems, it’s hard to tackle issue #2

For issue #2, when the team have become divided I recommend starting by building empathy for each other and the problems they face. A retrospective can be a great way to reflect as a team on the good and the bad. One of my favourite retrospective techniques is the 4 Ls. It helps the team frame their problems for constructive conversation. The team keep blame out of it and accept that everyone did the best they could with the information they had at hand. They then work together to solve the problems surfaced by the retrospective. One other exercise that could be useful is trying a rules of engagement play. This helps set the team culture and can be a good reminder on how the team should work together as tough challenges come up. Sharing their issues openly and working together to solve them is crucial to building trust in the team and stopping the blame cycle that can cause toxic politics.

[hdario]

How would you measure a team whose priorities are always changing, resulting in having to pivot and not finishing work?

[M]

That’s an interesting question and a tough situation for the team. The key part to solving this is understanding what is driving the changing priorities. Is it the team itself? Or are the priorities being changed by leadership?

It’s important to come together with the leadership from your area to understand what success looks like. Running a Goals, signals, and measures exercise can help tease out what the purpose of the team is and how it should be measured. By doing this with your leadership you can ensure there is a shared understanding of the team’s situation and what that means for how they can be measured. This will help both the team and leadership on the desired business outcome, which will help drive focus and might help stop the shifting priorities.

However, it may be that the organisation is going through a tumultuous time and shifting priorities are something the team have to deal with. In that case, the measures could be limited to what the team can control. So something as simple as velocity or quality measures. Ideally only until the team’s priorities can be solidified. In this way the team can still aim to improve how they work.

[Deleted user]

How much do you focus on measuring the team's performance vs. the organization's performance?

[M]

I prefer to focus on measuring what is within my scope of control. Mike, Scott and our executive team do a great job of measuring our organisation’s performance, but I’m only responsible for a team, not the whole organisation, so I focus on measuring my team’s performance and typically do that by running the Goals, Signals, Measures play with my team. We stay on top of how the organisation is performing, but it’s not our focus.

It can be a bit of a chicken and egg process to set team or organisational goals first. Ideally your organisation sets their goals, or at least your strategy first. That will give you a North Star by which to draft your goals.

If all else fails, know that you’re doing the right thing for your team by tracking progress towards any goal (organisational or team). There is extensive evidence that tracking progress at any level (individual, team or organisational) is crucial for goal attainment.

[Daniel Roberts]

I am the Scrum Master of a team which is highly dependent on other Agile teams, some of which seemingly practice Agile on their own "island". What can I do (as an individual contributor) to help drive the organization to a truly Agile mindset, working across team boundaries?

[M]

Thanks Daniel, this is such a good topic. In the past agile has come into an organisation team by team slowly spreading effective ways of working. Having different ways of practicing agile may not be a bad thing. For example an infrastructure team may have different needs to a team which incorporates hardware who may have different needs to a growth team.

This can cause problems for your team if it impacts the way your team wants to work.

It’s helpful to remember that two of the key underpinning principles of agile are communication and relationships. Individual contributors should feel empowered to reach out across team boundaries as needed to share knowledge and build those relationships.

A good first step to is to run a session with the other teams to map out the dependencies between your teams and agree on commitments. The teams can also agree on how to communicate with each other and what the frequency should be.

As a Scrum Master you have a wealth of knowledge on agile and have worked through many pitfalls. I suggest starting a mentoring ring with other scrum masters or anyone who is interested in bettering their agile knowledge. It gives everyone a forum to share learnings and help each other find solutions to the problems they’re facing. It’s also a chance to build great relationships across the organisation.

All the best!

[Brant Schroeder]

How do you deal with conflict without impacting team morale?  

[Mahreen Khan]

Great question, thank you Brant! They key thing is that conflict is not necessarily a bad thing for team morale - in fact, it can even be a good thing!

Within teams, there are two main types of conflict that may occur: task conflict and relationship conflict. Task conflict occurs when there is disagreement related to the actual tasks the team is working on; for e.g., the team may have differences of opinion regarding ideas for a project, or the best way to implement a particular project. Relationship conflict occurs when team members do not like each other, and involves annoyance, tension and animosity. 

Relationship conflict is detrimental for team morale, whereas task conflict can lead to better decision-making which leads to better performance. However, sometimes there is a spillover effect whereby task conflict leads to relationship conflict. For e.g., two team members may disagree about the best way to implement a project and this may lead to frustration and resentment between the team members.

In order to maintain team morale, it is imperative to ensure that task conflict does not spillover into relationship conflict. How does one do this? Teams that have greater trust between team members experience less of a spillover effect. In addition, teams that use constructive conflict resolution strategies focused on problem-solving and compromise also experience less of a spillover effect. These conflict resolution strategies ensure that the team members are focused simply on the disagreement relating to the task, without attributing it the other individual.

In sum, when conflict occurs within teams - if team members communicate with each other in a constructive manner, trust one another, and remain focused on solving the actual problem (and reminding oneself that the disagreement is about the task not the team members), conflict can beneficial for teams. 

[Deleted user]

What are some of the non-negotiables on a successful team, besides soft stuff like empathy and respect?

[Mahreen Khan]

Thank you for the question Brian! Whilst the soft stuff like empathy and respect is undoubtedly very important, there are of course other factors that contribute to a high performing team. The most important (aside from the soft stuff) is that each individual needs to have the requisite knowledge, skills and abilities to perform the relevant team tasks.

Ideally you’ll determine this prior to the formation of the team when selecting individuals. If you’re already deep into your project, I’d recommend taking a step back and looking at your teams knowledge, skill and abilities and assessing where there are gaps or unneeded skills. While it may be inconvenient to consider these factors mid-project, the required knowledge, skills and abilities needed on the team can change throughout the journey. Accordingly, we advise setting yourself checkpoints to periodically assess your team’s dynamics and competencies.

[BMac]

How do you deal with team dynamics where there is a tendency to be quiet, withdrawn and lacking in leadership? 

[M]

This is a tough question, BMac. If I were able to spend time with your team I’d try to better understand why the team is quiet.

• Are the team members introverted by nature?

• Was there a past event that eroded trust on the team?

If your team is naturally introverted a good course of action may be trying the Inclusive Meetings play. This is a great way to be more intentional about hearing all the voices in your team’s meetings. This blog by my teammate, Season, who is a self-identified introvert has some great tips for working with introverts.

If your team experienced a past event that eroded trust, it’ll be important to rebuild that trust. The best way to build trust is 1:1. I’d recommend setting up a series of 1:1’s for all team members to spend time getting to know each other and rebuilding trust. If you’re looking for a template to help guide discussions in these 1:1’s try the My User Manual play.

The team “lacking in leadership” may be a different challenge to the introvert/extrovert balance. There could be a couple of causes here:

• Team or organisational culture. Do individuals feel empowered to take ownership of their work (along with the risks that entails)? If people don’t think they are allowed to lead or challenge the team direction they won’t step up to do so. Addressing this should start with establishing trust in the team (which I talked about above). To encourage people to take ownership it helps to put some basic structure around owning parts of the team’s work. For example, having a software developer work as feature lead to help shape a feature and move it through the development process. Junior team members can be mentored through this process to help build confidence.

• Individual confidence. Do you have a team of relatively junior people who don’t yet have the experience to confidently take ownership of the team direction? This can be addressed by mentoring from more experienced colleagues.

[Jeff C]

Here are a few from a software services organization that is entirely project-based (with some ongoing support by client):

1) Each newly formed team currently only has a Project Manager and a few devs.  Can the PM realistically act as a PO (since they are currently prioritizing work and acting as the voice of the customer) and the SM (since they are trying to support the team to get work delivered)?  Or should we push Dev leads on each team to take on SM duties?

2) What are some ways to handle work that is dev complete within a week sprint but will not be deployed until the following week?  I.e., how to give the team credit within Jira for completing X points of work within that sprint even though the issues isn't "Done"?

3) Is there a way to have tickets from a Support project (tied to Jira Service Desk) pulled into a sprint in a Scrum Project so the team has better visibility into their project work and support work at the same time (and to have it reflected in the sprint metrics like velocity)?

4) How can I configure Jira to email a client's Account Manager when someone at that company creates a Jira Service Desk ticket?  Adding an internal email address to the customer organization and using the "Organization added" email doesn't seem to work (at least with editing an existing issue to add the Organization to it).

[M]

Thanks Jeff! Feel free to keep these questions coming.

1. I recommend separating out these roles. There’s a healthy tension between pushing the boundaries for the best possible product for the customer and pushing back on scope so that the developers can deliver within the estimated timeframe. It’s very hard for one person to argue both positions. They have to argue with themselves and usually one side suffers. The Product Owner will be thinking about what’s best for the customer where the Scrum Master should be thinking about what’s best for the team. If you can have different people with that focus, I think you’ll get a better outcome.

2. There are a few details that would change my recommendation here. I’m keen to understand why the team has chosen 1 week sprints. I’d also like to know whether the deployments are handled by a seperate team? If the deployments are handled by the team doing the coding: It sounds like you have a constraint in your deployment process that pushes the team to have sprints of two weeks. So one way is that your sprint would be two weeks long and the bottleneck of the deployment process would be very visible as work piled up in that column. This could be a great incentive to figure out how to get to shorter deployments. If the deployment is handled by another team then the team could claim the entire # of points as they’ve completed their work.

3. Yes! You can create a cross project board that can include Jira Service Desk issues as well as Jira Software issues. This community post on cross project boards is the best place to start.

4. The organisation should work for new issues but not for existing ones. The requester would also need to select ' share with organisation' when the ticket gets created. Here's some more information on organisations which may help. The other option is to create an automation rule that matches requesters and uses the 'send email' action. 

[Bill Sheboy]

I liked the response to item (2), until...

Perhaps this is just semantics; I find troubling the phrase "claim the entire # of points as they’ve completed their work".  Yes, given the way the team appears to support this value stream, they have finished some steps...and some steps remain to release to production.  So the customer doesn't have the delivered value yet. 

Points are not the goal; they are usually a tool to uncover complexity and aid understanding of a request.  Sometimes they can be used for forecasting.  Please take care not to incentivize points for the sake of points.

[Richard West]

You'll probably cover this anyway, but what is the base research and principles behind all this? eg Deming, .... ?

[Mahreen Khan]

Although we consult a wide variety of sources (e.g., from the software industry), a lot of our research is informed by the vast and extensive literature on teams from the field of organisational psychology. Teams in organisational psychology has a very long history - decades of research, and thousands of scientific studies. When sifting through all this information, we focused on the most findings that have the most solid scientific underpinnings (e.g., the methodology was both reliable and valid). Whilst Deming conducted some very influential research, we focused on scholars that concentrate more fully on teams (as teams are a core part of Atlassian’s mission) - some examples include John Mathieu, Stephen Zaccaro and Daniel Ilgen.

[Amir Ansari]

Can you please share your definition of 'high performance', so we are all on the same page?

[Mahreen Khan]

Thanks for the question Amir! We define performance as consisting of performance output (which is measured by any objective measure of a team’s output - for e.g., one way of measuring output for a team is the extent to which they have attained their goals). Another characteristic of high-performing teams is that they are more satisfied with their team, but also are more committed to staying in their team in the long-term.

[Amir Ansari]

Many thanks @Mahreen Khan I would like to ask a follow up question to that. How do we ensure that the 'performance output' of the team is aligned with the organizational bottom-line? In my mind, a crude measure for that is to go back to the final users of the team's output, and ask them if their requirements have been met. But as soon as you do that, you are also measuring the efficacy of the Product Owner as a requirements provider. So it seems to imply that 'team' should include 'Product Owner' when defining 'performance output'. I would like your views on this, and would be really interested if any research has been done on the topic.

[Mahreen Khan]

Thank you for the follow-up question Amir. It is not always easy to ensure that a team's performance is always aligned to an organisation's bottom line. Every performance measure on its own is limited in some way, and only really captures one aspect of performance. Ideally, there is a higher chance of a team performance being aligned with the organisation's bottom line if the data on performance is being obtained from multiple sources (e.g., combining measures of a team's goal attainment with customer feedback). The more sources of data, the closer you will get to a holistic picture of teams' performance. 

In addition, the advantage of combining multiple sources of data is that the limitations of each individual measure of performance is mitigated. I hope that answers your question!

[Amir Ansari]

Definitely, that is extremely useful. You addressed the customer feedback part. Should the PO be considered part of the team when using customer feedback as one of the measures of high performance? Also, is there any framework out there that guides us on what metrics to use? We have already discussed customer feedback, I am guessing we need to look at things like individual ownership, cohesion within the team etc? Can you give us guidelines on what we should be measuring? I can see others have asked something along these lines. It would be nice if you could provide concrete examples from research, or what you guys are measuring at Atlassian.

[Mahreen Khan]

Glad you found it useful Amir. I don't think there is a hard and fast answer regarding the product owner - their input could be simply considered as an extra data point (rather the be all and end all). There is definitely frameworks that we use when considering the various aspects of performance. A general framework of performance involves objective output (e.g., sales, quality, quantity, efficiency, innovation outcomes etc.) along with commitment to the team. For cross-functional software teams, metrics such as cycle time, change failure rate etc. could be considered aspects of performance. 

Factors that predict performance include many if the psychological variables that we mentioned such as team cohesion, psychological safety, team confidence, team processes etc. In terms of psychological factors, our current focus is on team processes (the ways in which teams interact with each other), team cohesion (the way in which the team is united and committed to the task) and support for innovation (the extent to which the team believes that their is a culture of innovation).

[Deleted user]

How do you determine which parts of high performance are most important? My thought is that there are some behaviors (eg. psychological safety, autonomy etc.) that apply broadly, but there are other behaviors that may be more or less relevant depending on what your organization's goals are. How do you differentiate or determine where to focus when building a high performance culture?

[Mahreen Khan]

Great question Madeline! As part of our work on understanding teams within Atlassian, we really delved into the scientific research on teamwork and team effectiveness. One of the most well-established frameworks for understanding team effectiveness is the Input-Mediator-Outcome model (Ilgen, Hollenbeck, Johnson, & 2005).

In their model, inputs are who are the individuals on the team, what type of team it is, and what type of organisation does the team belong to. Mediators are the processes the team engages in, and the way they think and feel about the team. Mediators are broad variables which include team processes, team confidence, team cohesion, psychological safety, team trust etc. Outcomes relates to performance of the team.

Very intriguingly, meta-analyses (which synthesise evidence across numerous scientific studies) repeatedly show that mediators have a stronger relationship with performance (across various organisations and occupations) compared to inputs. This means that the broad variables are more important for building a high performance team culture compared to more narrow and contextual factors (such as the organisation’s specific goals). Hope this answers your question!

[Gizem KILINÇ]

Hi! I have 2 questions. ( Actually, lots of questions but here 2 of them.)

1. How do we decide whether the team is showing its real working performance? 
   • In this question, it may be good to consider that the team has been working together for 1 year and most of them are junior engineers. I believe we should trust teams on this, but I'm not sure if they can find out if they've reached the optimum speed. 
2. What values ​​should be focused on to form high performance teams?

[Mahreen Khan]

Thank you for the questions, you are welcome to ask as many as you wish! 

1. Very thought-provoking question. Whilst it is possible to track a team’s performance, and to improve performance, I don’t believe it is possible to determine whether a team has reached its optimal level of performance. Even in elite teams, I believe that there is the capacity for improvement. Given this, the focus should be always on improving team performance as opposed to determining whether a team has reached its optimal level. 

2. Again great question! Values are useful in creating a team climate that facilitates high performance. One of the foremost frameworks of team climate (Anderson & West, 1996) considers four key aspects:

• Psychological safety: Team members should feel psychologically safe in voicing their opinions and when proposing new ways of doing things. 

• Support for innovation: There should be support for innovative ideas. This support should not simply be vocal - there should also be practical support for innovation (for example, actually investing in innovative ideas). 

• Vision: The team’s short and long-term objectives and vision should be clear, shared and well-defined.

• Task orientation: There should be a commitment amongst the team to achieve the highest standards of performance and excellence. 

By focusing on the above four categories, you are building an atmosphere which will definitely help facilitate high performance in your teams!

[Carley]

How do I tune into this talk or register? Thanks

[shannyshan]

Hi @Carley! Thanks for reaching out. No registration necessary. Megan and Mahreen will be answering questions on this post live on June 23 at 2pm PST, but you can start submitting questions right now :) 

[Nicole Rowe]

You mentioned measuring team happiness, but there's also thought out there that measuring team morale is preferable. Do you have a view? And how would you measure team morale beyond a survey?

[Mahreen Khan]

Thank you for the question Nicole! Ideally, when measuring psychological factors, you would not simply choose one variable, you would choose many. Team happiness is more of an umbrella term, but ideally a team would measure things like team confidence (or morale), team cohesion, team climate amongst many others. By combining multiple aspects of team psychology, you are more likely to get an accurate picture of your team's health. 

For psychological factors, such as the way a team thinks or feels, a survey is actually the best way. This is because you can quantify the way in which a team's health is changing. Team leads should also have regular check ins with each team member and ask them directly about their thoughts and feelings regarding team dynamics. This can be helpful in capturing the root cause of problems and issues that may arise. Hope this helps!

[Craig Payne]

Thanks for the opportunity to ask questions!

We have a SCRUM team which has been split into 2 parts due to its size (12 developers + PO + a project manager, each team is 6 devs).

Our team is absolutely bogged down in meetings and discussions for every little point rather than planning the tasks in a smaller leadership group.  Meetings take around 40% of our time, and we aren't getting much done even though all devs are highly experienced.  The PO is giving us clearly defined stories, but because we have no technical leadership we wash around like shipwrecked sailors in a storm.  Is this really the way SCRUM is supposed to work?

I come from a background with an architect planning the basic bones of an implementation, then the lead developer taking over and assigning tasks among his/her team as skills and availability allow.  This worked really well, because the basic planning was done by the leaders and the developers could just get on with it.  Could a similar approach be implemented on a sprint basis using SCRUM?

[BMac]

HI Craig, I'm not from Atlassian or involved in this Q&A, other than posting a question myself, but your question stuck out to me. I'm a scrum master so my perspective is facilitating effective scrum teams, which often means planning. 

Where do you think the issues lie with making decisions and agreeing on a solution to the user stories? Do you have a scrum master across the two teams and do the teams have their Definition of Ready in mind when planning? That's where regular refinement and effective sprint planning can help. 

The best book for understanding scrum IMO is "Scrum: a Pocket guide" by Gunther Verheyen. It's only 120 pages so you can read it in a few hours and you get it on Google books for around $12. If you only read one agile/scrum book this is the one. 

[Wonky Andy]

I work at a company that employs various agile frameworks.

However, like Atlassian (I checked and saw the 3% PoC employees from your diversity report), we have struggled with hiring of people of color. Since it's self-evident that companies which spotlight "agile, high-performing teams" struggle to translate into hiring more employees of color, my question is for Dr. Khan:

how does she recommend that younger, non-manager employees, who are a part of "agile teams," broach this issue to our managers and high-ups without being perceived as "difficult" or "not a team player."

I want to be clear that the structural manifestations of racism are not the issue here. My question pertains to the communication around this pretty, egregious gap between values and reality and how can a junior member of a team be a force for a change, employ the "right communications" and still be considered a "team player" even if I (and some fellow junior colleagues) feel that it is time to "rock the boat" (ie, engage our companies more directly).

Thanks and I welcome any recommendations or feedback from Dr. Khan.

[Mahreen Khan]

Thank you for the fantastic question Wonky Andy. Diversity is something that is personally very important for me, so I am glad you raised the question. We have so much room for improvement and we are a long way from where we should do. And change is a long, slow and arduous process.

With topics like diversity, some people shy away from having difficult conversations - but it is more important for our voices to be heard and be advocates of diversity. When I was younger, I also found it difficult to broach topics like diversity (I didn’t want to be seen as difficult), but over time I began voicing my opinions more frequently.

It is important to note that even though someone is voicing their opinion, this does not make them “difficult” or not a “team player.” Having an opinion, and feeling psychologically safe enough to voice your perspective, is actually a fundamental ingredient of a successful team.

But when having these discussions, I would recommend a few key things. I would start by laying out the facts (as you have, by citing the 3% figure), and by using this as evidence that we have a long way to go. And then I would recommend having a conversation that is open, honest, vulnerable and empathetic. If someone is not in favour of pro-diversity strategies, one conversation will not change their minds - so it is important to be aware that by broaching the conversation, you may not initially receive the outcome that you wish. It is more likely that sustained conversations over time will start causing a shift in mindset, which in turn, will start to create the sense that things need to start changing.

It will not be an easy process, but I am inspired by your enthusiasm in wanting to create change. I wish you the best of luck when engaging in these conversations with your managers. 

[Akalpit]

What are some of the steps you have taken/would suggest coaches/managers take to create an appetite for contentious improvement within teams? The pose the message such that the effect would be team 'striving for process improvement' vs perception of 'needing people improvement'?

[Mahreen Khan]

I love this question, Akalpit. My team is responsible for enabling teams across Atlassian to continuously improve so I’d love to share our experiences thus far.

In principle, our teams are all about continuous improvement but it wasn’t until we gave them a feedback loop that they turned their good intentions into actions. The feedback loop gave them a tangible tracker of their progress and benchmarks for what success looks like using examples from similar teams. For our R+D teams, we are tracking Cycle Time to understand velocity along with a bi-weekly 20 question survey to understand the teams' psychology (team processes, team cohesion and support for innovation). By providing these data sets in an automated dashboard our internal teams have the feedback they need to stay motivated on their never-ending journey of continuous improvement.

[Piyal Nanayakkara]

Hi

I am located in Sri Lanka  (Time Zone : Indian Standard Time - IST), due to the scheduled time, it is not practical to attend to the event. So, would like to know whether:

1. Can we get the recording of the session after its done?

2. Is there a plan to schedule another round of session targeting day time of Asian time zone?

Thanks and Regards

Piyal

[Mary Raleigh]

Hi Piyal! We're so glad you're keen to join the AMA. All the questions and answers will live on this page indefinitely. We are not recording a video.

Please do submit your questions any time before June 23rd (PST). There's no need to be online at 9 am (PST) Tuesday, we'll be answering all questions that are submitted before the scheduled time. 

(JINX @shannyshan !)

[shannyshan]

Hi @Piyal Nanayakkara! No problem - it's actually just a Q&A on this community page (no webinar recording). Megan and Mahreen will be answering questions live right here on June 23 at 2pm PDT, but you can start submitting questions right now, then can check back for the answers next Wednesday. :)