One-on-Ones Don't Exist in the Scrum Guide - Why Do We Do Them?

Banner image for the article

This article will attempt to define some of the uses of a one-on-one. In sections that would require a large number of terms to define a concept I will use the terms defined in the Scrum Guide. Many organisations haven’t adopted Scrum completely and utilise different terms; if this is the case for your organisation then you will have to translate the terms for your use.

What is a one-on-one?

A one-on-one is a regular catch-up between a Developer and a Scrum Master. The format of the one-on-one varies for each combination of Developer and Scrum Master. As a Developer I have experienced one-on-ones that are done while going for a walk, while enjoying a coffee, while sitting in a meeting room, and even over a video call. The organisations I’ve worked at that have one-on-ones generally have them scheduled for once per week. If they are unable to occur for some reason it is generally accepted that one can be skipped with minimal impact, but it is very rare to skip two in a row (unless one party is on leave).

Why have a one-on-one?

Depending on the organisation structure and the Agile framework being used (or not used), a one-on-one can fulfil different purposes.

In all situations there are some common aspects to one-on-ones. A key aspect of the one-on-one is to build trust between a Developer and the Scrum Master, the reason for this will be slightly different depending on the organisation’s management and team framework. It is also a chance for the Developer to inform the Scrum Master of issues they may need assistance with outside of the team, or personal issues that may impact the organisation but are not suitable to inform the entire Development Team.

In many organisations there is a lack of clarity around who to talk to about specific issues. It may be possible to document each of these communication paths, but it would become difficult (and expensive) to maintain, and would be hard to navigate or search; thankfully the human mind seems to be good at doing this and through asking questions we can locate the correct individual or team to talk to about a specific issue.

An example of this would be when a Developer is pregnant; prior to telling the rest of the Development Team, the Developer will likely want to discuss the company’s parental leave policy with HR, they’ll likely seek advice from a trusted source about how to tell the team, especially in the case of a first pregnancy they will want advice about how the pregnancy will impact their work-life. These are items that don’t fit in with normal agile ceremonies. Through a one-on-one the Developer can be directed to appropriate people to talk to about each of these queries; ultimately, when the Developer chooses to inform the Development Team and the wider organisation they have a sense of safety and preparedness for announcement.

Another example would be when the Developer is having some family issues that are impacting their capacity to work. Although the initial discussions may take place outside of the one-on-one, the one-on-one can be used in the longer term to ensure work is not adding to their stress levels and to manage the on-going impacts of such an issue.

In both of these cases, having a regular one-on-one with each Development Team member means that the individual experiencing a life event or issue can maintain their privacy and avoid questions and assumptions about a sudden change in contact levels with the Scrum Master.

One-on-ones in Scrum

When an organisation has adopted Scrum a one-on-one should not be required. Some of the values of Scrum are courage, openness and respect; if all of these exist within the Development Team then a one-on-one will not be required. Unfortunately many people lack the courage to be truely open with their team, for this reason a one-on-one can provide a significant avenue for Developers to be open in an environment that gives them a sense of safety.

In a Scrum environment the Scrum Master serves as a servant leader, working to promote Scrum to the team, reducing unhelpful interactions with non-team members, and removing impediments for the development team. They also serve a significant number of other functions, but for the purpose of a one-on-one these aren’t particularly relevant. The nature of the Scrum Master role means that Developers not familiar with Scrum will see them as a manager, those familiar with Scrum will see them as a leader; in both cases the Scrum Master is viewed as a person who can inherently be trusted. The combination of leadership and Scrum Master responsibilities makes the Scrum Master the best positioned for a one-on-one.

The value of a one-on-one in Scrum centres around giving employees a safe place to vent, a safe place to discuss their individual performance, a safe place to talk about career goals, a safe place to talk about personal issues that may impact the team.

One-on-ones in other frameworks

Most organisations I’ve worked for do not implement Scrum; they implement something similar to Scrum, but it definitely isn’t Scrum. Many organisations implement SAFe, and Agile-Waterfall hybrid or one of the myriad of other agile and agile-ish frameworks. Due to my lack of familiarity with the implementation of all these different frameworks, and because many organisations have a version of agile that is unique to the organisation, I will focus on my experiences.

A common agile implementation seems to be the implementation of Scrum at the team level, but replacing the Scrum Master with a more traditional manager. In this situation individual contributions are still highly regarded; the manager leads the team to certain decisions; the manager undertakes a more traditional management approach (including performance management, leave management and approval, intra- and inter-team communication issues, sometimes even task distribution based on individual’s skillsets), but with some servant leadership functionality incorporated.

In this situation a one-on-one becomes more than just a trust building and enablement meeting. It becomes a necessary feedback point. My experience in organisations that adopt this style of team management is that the Developer is told they get to steer the one-on-one, but in reality over half of the one-on-one is run by the manager. In this situation this balance isn’t a bad thing, it is just not transparent to the Developer.

During this type of one-on-one the manager should provide feedback to the Developer about their performance, this should be done in an open and constructive way and can be used to avoid formal performance management in the future. The manager should also use the one-on-one to cover any issues within the organisation that may apply to the individual team member. The team member should use the one-on-one to seek feedback about their performance; to ask questions (and receive answers) to any questions that relate to them individually instead of to the team; and to discuss any issues they have within the team that they are not able to resolve themselves.

My use of one-on-ones

Personally, I use a one-on-one to talk to my manager about my desire to stop coding. I use it to check on my individual output and achievements to better myself and improve the output from the team. I use it to talk about my achievements outside of work. I use it to find out who I should talk to within the organisation about personal goals that don’t align to the team. I also use it to build trust and talk about non-work related topics.

I am generally a very private person, although this is slowly changing with the blogging activity I am currently undertaking. I hold myself accountable for my goals, and often I will not share my goals with others until I have completed them. Through one-on-ones I have built a level of trust with my manager/team lead and find I will often disclose more than I had intended to. An example of this was booking some leave to go to a conference; I had booked the leave and wasn’t intending to promote why I had booked it. The conference is for personal interest and doesn’t apply directly to my current role (or likely to my next role, maybe the one after that though), so I did not think it was a valid use of professional development. In a one-on-one the topic of conferences came up and I mentioned the reason I was taking the leave. To me this demonstrates the trust that has been built, at least partially, through one-on-ones. One of the outcomes of this discussion was a recommendation of who to talk to about some professional development I want to undertake; this is a great example of the one-on-one helping a Scrum Master to enable the team through guidance and ensuring external interactions are valuable.

Should one-on-ones be part of an Agile implementation?

Although I started this article by posing the question “Why do we need one-on-ones?”, I feel it is appropriate to finish it by asking if we need to have one-on-ones.

In the majority of cases I would say, “yes, we do need one-on-ones.” They provide an important avenue for trust building, for enabling individuals to seek information, and to provide confidential advice and guidance.

In the rare cases where a team is open, courageous and doesn’t judge, then they are not needed. If you find yourself in a team like this, then go ahead and cancel the one-on-one.