Beyond what makes a good team in general, what makes a good team for software development, specifically?

Two questions

By asking these two questions once per day, I believe that any well-functioning team can reach elite levels in software development. These two questions can trace their origin back to the DORA metrics which have a solid foundation in scientific data.

Did you deploy to production yesterday?

This simple question, asked every morning, cuts to the heart of the matter like no other. It is scientifically proven that teams that release code to production at least once per day are statistically better in most ways that actually matter: better business, happier customers, happier developers.

Do we have any bugs that we know about?

Known bugs in the system are like gravel in your engine. They slow you down and wear you out. A known bug has the following effects:

• An end user / salesperson is irritated with you.
• When developing, you need to take the bug into consideration whenever you touch any code that is even close to where the bug is.
• When testing, you cannot assume a working product and try to break it but have to tip-toe around the bug.

So when a bug is reported, finish your current task and then fix the bug as your next task. Whatever you do, do not put it on some list which you drag behind you like an anchor. See the blog post below for my inspiration on this topic.

Stop Managing Bugs, Start Focusing on Quality!

Background

Some background on how I came to this conclusion.

Dora Metrics

The DORA metrics are studied by an organization owned/funded by Google and their conclusions are based on the most comprehensive set of data that I am aware of.

The metrics they have found to best correlate to team performance are:

• Deployment frequency.
• Mean lead time for changes.
• Mean time to recover.
• Change failure rate.

I have simplified the two first into the question “Did you release to production yesterday?”. Because if you do at least one deployment per day, that puts a ceiling on both your frequency and your time to get a change into production.

The second two form the basis of the second question. All systems have bugs and both code changes and bit rot lead to new bugs being introduced. By having fixed all those bugs, we also have put a ceiling on the time it takes to fix a bug and the number of bugs we put into production. 

Other things that matter

In addition to the above, a healthy team is also statistically proven to improve both productivity and health metrics. 

Susan Whelan’s model for team group development is in my view the best tool to support in that journey: https://www.hyperisland.com/blog/creating-effective-teams-the-detailed-curation

An in a commercial setting, the role of the manager cannot be underestimated. See my thoughts on what a good manager should (And equally importantly should not) do here: https://daniel.armyr.se/2022/10/08/fundamentals-of-management/

During the spring of 2023, I found myself in a position of wanting to prepare two people I managed to become leaders. I set an exceptionally high bar for myself in these matters and I wanted to make sure that these two people met that bar, or at least knew where the bar was.

Now, by leader in this context, I specifically mean a person who is entrusted by their employer to take full responsibility of a group of employees and is prepared to handle the fact that those employees are humans who can get badly hurt if they are managed poorly.

The first part of this program deals with general leadership, while the latter part focuses on leadership of a group of development engineers.

Format

The program is based on a mentor/adept relationship where I acted as a mentor for my two adepts and tried to impart whatever wisdom I have acquired to them. But I also pointed out where I consider myself weak and where they should seek out others to get different perspectives so that they can surpass myself in those topics.

The program followed a simple format. There were 16 topics to be covered so that the entire program can be completed in half a year. Each topic contains one simple homework and then a 1 hour follow up between the adept(s) and the mentor.

The program is also based on the assumption that each adept is currently working in a team setting and can make observations or activities with their team to then reflect on the results.

Point of view

This program is based on a point of view developed over many years of experience in leadership in transformative projects combined with extensive formal training. 

It takes the view that much of what the popular view of leadership and management looks like is not useful and even destructive. 

It takes the view that there within the large field of “leadership” exists certain fundamental truths that have been scientifically validated and cut across all cultures and generations because we are all mostly the same at our cores.

It takes the view that to become an effective leader, most people need to look deep inside themselves and find a new relationship with themselves and their surroundings, and that this is a journey that is deeply uncomfortable at times. However, by being placed in these uncomfortable positions in a safe space the experience can become a positive transformation rather than a traumatic experience.

It takes the view that although some people have a natural talent for leading, any person who wants to can learn the skills needed to become good leaders.

It takes the view that both hands-on practice and reflection are critical to learning.

Fundamentals of Management

Homework:

Read https://daniel.armyr.se/2022/10/08/fundamentals-of-management/ 

At the session:

Explain the text above in detail, section by section (The section about Susan Whelans Integrated Mode of Group Development can be skipped). Which point in the text do you think is most important? Which point in the text do agree with least / think is least important?

Susan Whelan’s Integrated Model of Group Development

Homwework:

Read Creating Effective Teams – The Detailed Curation | Hyper Island 

Study your team for a week. Reflect on the following:

• Team dynamics
  • Which stage is the team in as a whole. Why?
  • Are there sub-teams, if so which are they?
  • At which stage are any sub-teams you are a member of?
  • Teams can also have relationships with each other. What stage are the relationships between your sub-team and the others?
• Leadership
  • Which leader positions (Formal and informal) exist in the team?
  • Which levels of leadership do they practice?
  • How well does that match where the team is?

At the session:

Present your findings above and discuss.

Feedback and difficult conversations

Homework:

Read How to Master Yourself and Win at Receiving Feedback | by Anthony Murphy | Ascent Publication and Feedback vs Advice — Tips on giving effective feedback | by Anthony Murphy

Write three pieces of advice feedback for each other person in the group. Two where you suggest they keep doing more of the same and one where you suggest they do something differently.

At the session:

• The positive chair: One person sits with their back turned. The remaining two talk about only positive things about the person who’s back is turned. Repeated for everybody in the room.
• Advice feedback: Taking turns, each person presents their feedback to the others in the group. As a suggestion, the mentor should start.
  • For each feedback you receive, actively choose where on the staircase you want to respond and respond.

Emptying your calendar / Interruptions vs Focus

Homework:

• The Importance of Scheduling Nothing 
• Interruptions – 10 Ways to Minimize Stops and Starts
• Keep an interruption log for 3 days.

At the session:

Show your calendar and discuss the good and bad about it. Present your interruption log and describe what it tells you about your working efficiency.

Presentation technique

Homework:

Prepare a 10 minute session about your home town (Or any other topic you know well so you do not need to do research).

At the session:

Hold the presentation and ask for feedback on what went well and how the rest of the group think you could make it better. Make sure that the presentation is recorded as a video so that you yourself can view it and give yourself advice.

Efficient Meetings

Homework:

Read the blog post Effective Meetings. Be the facilitator for all in-team meetings for an entire week.

At the session:

Discuss how facilitating meetings went. Are you following the pst practices? Discuss your reflections with the group.

Taking ownership

Homework:

Select two topics which you will take complete ownership of. One should be related to work, and the other to something in your private life. Track daily as a group if you have taken ownership of that topic during the last day.

Before you start, think about the following and then discuss.

As the session:

Discuss: Why did you select this topic to take ownership of?? What actions did you expect to need to take here. Did you have the time? Do you have the skill? If not, who can you ask for help. Who will be affected by you taking actions here? Did you talk to them?

Setting goals

Homework:

Read the following: https://daniel.armyr.se/2023/03/24/summary-of-a-little-book-on-goals/

Look at the current goals your team has. Describe each of these goals based on the theory presented in the article above.

At the session:

Discuss the above.

Vertical Slicing 

Homework:

Read the following article. Example 2 About Autodesk Advanced Steel and Revit I don’t understand. Feel free to skip it unless you understand what they are trying to say. http://www.scruminc.com/wp-content/uploads/2015/06/User-Stories-2.0.pdf

Take one single project from your team’s backlog (One that hasn’t been vertically sliced) and cut the smallest vertical slice from it that you can.

At the session:

Discuss the above.

Why relative estimations?

Homework:

Read the following article: https://drive.google.com/file/d/1CvhEC5ISwLPmsAb0paLXxBfJep67bsKK/view

Bring 3 different tasks that your team has completed. One should be small, one medium and one large. Give them relative estimation numbers.

Bring an additional 5 tasks in your backlog that you have rated against the three above.

At the session:

Discuss the above.

Get stuff out of the door / Zero bugs policy

The science is clear. The shorter the time between when you decide to make a change to your code and when you have deployed it, the better your code is. 

Spending a few days at the start of a project making deployment a 1-click / 5 minute task, the easier it is to write good code.

By limiting the work that is in progress and removing all bugs as they come in, the amount of unplanned work that builds up gets reduced.

Homework:

Watch the following two videos about continuous integration: https://youtu.be/FlaKS7EBsJc and https://youtu.be/v4Ijkq6Myfc

Watch this video about a practical way to implement a zero bugs policy: https://agilasverige.solidtango.com/video/dealing-with-bugs-by-deletion 

At the session:

Discuss the above. Some questions to think about:

• Can you think about a situation (Not necessarily work related) where you get immediate results from the actions you take (Hint: All the time)? How does this feel compared to when you do not?
• Discuss if you would work differently in a system that you knew had no bugs versus one that you knew had a few.

Evaluating performance / Salaries

Homework:

• Watch: How Does Salary Work?: a talk by Kevin Goldsmith 
• Write evaluations:
  • Select two people you work with, one junior and one senior (Not anybody among the group in the mentor program). It is easier if they have similar jobs. For their jobs, write down what you think should be the answer to each of the following questions:
    • Why do we have this job?
    • What is the simplest way to see that their job is done well?
    • What are 2-3 most important duties?
    • What should the user spend most of their time on?
    • What sort of traits/behaviors should a person have to be successful in this job?
    • For each person, write how well they match up against each of the answers you have given to question 2 – 5 above (Ignore question 1)
    • For each person, write down how much you think they should earn in relation to your salary (Half, equal, 50% more, etc).

At the session:

Present the above evaluations. Skip the salary figure you set. That is a mental exercise to be done in private.

After the meeting, delete all working material for this exercise. If this material leaks out, conflicts can arise.

The importance of 1-on-1s / Management by lunch

Homework:

Read the following: https://www.leapsome.com/blog/meeting-with-purpose-the-unique-benefits-of-1-on-1-meetings 

At the session:

Discuss:

• How long should a 1-on-1 be?
• What topics should be covered?
• What topics should not be covered?
• Should we occasionally have longer 1-on1s? If so, what should the agenda / format be?

Lots of people say “I have too many meetings” and “It’s impossible to book a meeting because everyone is already fully booked”. 

Every event in a calendar is not a meeting!

• After-Work and Friday Wins
• Recurring team events
• Workshops
• Focus time and group work
• 1-on-1s

TRY THIS: Color code the different event types in your calendar. Whatever you didn’t color code might be a meeting.

If it is, make sure it follows the upcoming best practices for meetings. If it doesn’t, consider cancelling it.

When should I call a meeting?

1. Call a meeting when there is confusion.
2. Especially if that confusion affects more than one team.

There are 3 ways to reduce confusion:

• Communicate information
• Take a decision
• Solve a problem

What do I need for an effective meeting?

• A Purpose: Mandatory for all meetings
• A Goal: Mandatory for all meetings
• Material: Send over material prior to the meeting to prepare the attendees
• Attendees: Think carefully before sending mandatory invites 
• Time: Start and end the meeting as scheduled

QUICK SUMMARY

• Every event is not a meeting – color code!
• Every meeting should resolve a named confusion, by either:
  • Giving information
  • Making decisions
  • Solving problems

Checklist before a meeting:

• A Purpose: What’s the topic?
• A Goal: Type of meeting?
• Material: What can you send ahead?
• Attendees: Who needs to attend?
• Time: Will you join and end on time?

Tech Lead is a solid title. It is something most engineers aspire to. But what does it really imply? If I am a Tech Lead, or aspire to become one, what are the expectations on me, and how will my work day look?

Less coding

As a programmer, you may spend up to 80% of your time coding. There is daily standup and a few weekly meetings. And every now and then you participate in a roadmap workshop or a strategy presentation.

Not so for the Tech Lead. As a Tech Lead, you still write code. But a LOT less of it. The rest of the article describes what you will be spending your time on instead.

Create specifications

As a programmer, you can hope to get a specification that tells you what to do and what is expected. As a tech lead, you are the person WRITING that specification. Together with your Product Owner and perhaps a Designer, you look at a business problem and you come up with a solution. 

A business problem can be of the form “Our customers are creating too few profiles”. Your job is to sit in the room from the very beginning helping to brainstorm solutions to the above problem. For each solution, your specific responsibility is to quickly estimate the cost in terms of time and complexity. Then it is your job to suggest something that is almost as good, but much simpler to implement. This cycle repeats until the group has a solution that the customer will love, creates good business value, and can be implemented in a REASONABLE TIMEFRAME. 

At this stage, there will still be many unknowns as there still isn’t a proper design, only some sketches and a shared understanding. Your next task is then to look at what parts of the proposed idea have the highest technical risk. You point to these and propose what needs to be done to reduce that risk. Are you worried that the UI will become very complex? Ask that work be started on a UI wireframe. Are you worried about whether the idea will fit into the current architecture? Initiate a POC to check the feasibility of the technical solution.

Once it is time to start writing the actual production code, whether you do it yourself or if you have a large team to help you, the questions that pop up should be small and should not affect the timelines significantly. 

Coaching

As a tech lead, you typically have more junior people in your team. Your job is to make them less junior. You do this by coaching them. 

The best coaching is pair programming. You work on the same piece of code. One types, and the other reads, thinks about the next step, and gives feedback. Pair programming is proven to over time give faster development with better quality. 

If pair programming is not an option, then solution and code review are alternatives. Before a developer starts a task, have them explain the task to you. They need to explain to you why the task matters and how they intend to solve it. You should only ask questions until you are confident that they know why they are doing the task and that their solution will be a good one. Once they have done the solution, you review their code to ensure that their solution is good enough. 

Driving architecture

As a Tech Lead, you are responsible for the architecture of the modules you are in charge of. You can ask for feedback from the solution architects or other senior developers, but they will not and should not provide you with a finished solution. 

So for each task, ensure that the code written will not degrade the architecture and quality of your module. And if you find that your module has degraded, talk to your Product Owner and propose a cleanup project to be added to the backlog. 

The book “A little book on goals” by Stefan Söderfjäll and Christoffer Svensson was suggested to me when I asked about some easy-to-read theory on how goals work. As a person, setting goals for me personally and in my after-work projects has always been easy. But I have found that the higher stakes in a commercial organisation, combined with the fear of delegation and the losing of control has made goal setting much harder. I wanted to understand if it really was harder, or if that was just a perception on my part.

I am glad to say that this book really kept its promise. It is very compact and quick and easy to read. There are a handful of chapters that each end with a summary that really hammers home the message. It chooses to take a slightly higher level approach, describing the theory and science more than being a step by step manual but at least for me, that theory was presented in a way that made it very easy to see how I could apply this in my day-to-day job.

As a part of a mentor program I am currently running, I wanted to condense the material even more into a summary of a few pages that can be handed out and then discussed in group. So here is that summary.

To be clear, my goal here is not to accurately summarize the book, but to write a summary on goal setting. So, I will add and change where I see room for improvement.

What is a goal?

A goal is simply a statement that describes a future state that is desirable (Or undesirable, in which case the goal is to just to avoid it). Different people have different need for goals with some people needing and wanting very detailed goals in their private life as well as professional life, while others can work more loosely. But if there is a complete lack of goals, then this results in some or all of chaos, passivity, or stress. For people to work well together, they should share the same goals, or clashes will occur.

The main benefit of goals is that they create motivation and help us make decisions on what to invest our time, effort, and money into.

Types of goals

Goals can be set at one of several layers. We can identify four layers that are useful.

Result-based goals

This is the highest level. A result-based goal relates to some fact in the outside world. The archetypal example is a sales-target or the placement of a team in a tournament. These are real-world results that show a real-world effect. When possible, these are the best types of goals because they allow complete freedom to take any action needed to achieve those goals. But they are also the hardest for several reasons:

• Results are always also based on actions that are not in our control. A sales target is affected by the economy and the competitors. Tournament results depend on the performance of the opposing teams.

• In addition, because of their high-level nature, those working to achieve the goals need to have a both broad and deep knowledge of the domain of the goal to be able to make smart decisions that will in fact work towards achieving the goal with high probability.

For this reason, it is advised that this goal type be used in less complex situations, where the outside effects do not muddle the picture too much, and for teams with a high degree of experience and knowledge within the field.

Performance-based goals

These goals take one step back and remove the effects of the outside world. So, the result on a goal like this should only be affected by internal actions. An example is the time it takes to run 100m, regardless of how fast others may run. These goals can be a good compromise as they still measure real-world effects but makes it possible to focus more internally. In addition, the messy outside world means that the relationship between actions and result is clearer, which in turn makes follow-up easier.

Knowledge goals

One step further down are the knowledge goals. Here we no longer measure effects, but simply that the knowledge that we believe that we need can be demonstrated. An example is learning a new language.

The benefit of a goal like this is that it is very much under control by the person doing it, but we are getting quite far from the real-world results. So, in a situation where there is great uncertainty, or the people trying to achieve the goal have very low knowledge about the domain of the goal, this can be a good thing. All involved can agree that this knowledge is needed before we can even know what type of performance or results-based goals are appropriate. So as a starting point a knowledge goal can be set.

Process goals

These are the goals furthest from the results. Here we are simply talking about behaviours that should be exhibited. An example can be how many sales calls a salesperson should make in a day. These goals should be used when the situation is completely unknown. The place where these goals can in fact be valuable over time is for culture and social goals. Here, effects are almost completely impossible to measure and instead agreeing on some habits is the best that can be done. An example would be that we agree that we say good morning to all when we come into the office.

Goals, methods, and psychological needs

Goals can feel either internal or external. Internal goals represent what we want to do. External goals represent what we think that we must do and are generally less powerful over time than the internal goals.

The way we set goals, and feel about them, can heavily influence the famous trio of psychological needs:

Competence

By setting difficult by achievable goals and seeing them to completion, we feel competent.

Autonomy

By having goals that we experience as internal, that are on a sufficiently high level, we have great freedom to choose our methods and we feel autonomous.

Relatedness

By sharing goals with others in a group, we can form a team with very powerful inter-personal bonds.

Criteria for effective goal setting

The most important feature of a good goal is clarity, meaning that it is easy to reach consensus about when a goal has been achieved and when it has not. Clarity is helped by keeping both the timeframe and the number of goals short, and making sure that the goals that exist are not contradictory.

Goals should also be difficult, meaning that they are not always achieved. For this to work in reality, it means that there should not be significant punishment for failing to reach a goal. Linking large rewards too tightly to goals can also be counterproductive.

A short feedback cycle allows those working towards the goal to see progress and be inspired to continue, but also to see warning signs when things are not going in the right direction so that corrections can be made early.

Finally, it is important that the goal is perceived as meaningful, or it will not have the ability to engage.

Pitfalls and risks

If a group of people are expected to work together, it is very important that they have a shared goal where everybody’s contribution benefits everybody.

If goals are set too narrowly, or are too easy to achieve, there is a great risk that important actions are missed. Either because they fall outside the narrowly defined goals or are not required to achieve the easy goal target. 

Or “The best managers just make coffee”

It is said that most meaningful things in life are easy to say and hard to do. So how would I apply that to leadership? Well, here is my view on leadership, reduced to its very bones.

In a single sentence, a leader presents a compelling vision and then acts as a proactive servant to the team as they work to make that vision a reality.

Breaking it down one step further, as a leader you should always confidently and clearly be able to answer the question “What is expected of me right now?”. 

Susan Wheelan’s integrated model of group development describes four phases of maturity for your team. Depending on where your team is on that scale, the type of answer you should provide to the above question changes. Your team should be at stage 3 or 4 as the first two stages are waste.

As a leader, you should think carefully what you spend your time on to make sure you create real value and eliminate waste for your team and not the other way around.

Do a daily check-in with your team, either with the whole group or individually. In this checkin, you should ask and not tell. The exception is to congratulate them on their progress. Make sure that these meetings promote the psychological safety of your team members so they openly share their honest ideas and opinions.

Be available to provide meaningful answers to any question your team may have and provide useful help with anything they ask you to help them with.

Work on the strategic plan and present the latest version when your team sets new concrete goals.

If your team has outside stakeholders (Including any higher level management), make sure that these stakeholders only interact with your team in ways that the team finds useful.

Anything else you spend your time on is almost certainly waste. You should understand the reasons for why you are doing it and remove those reasons.

We all know that it is true. People from India always say yes. People from Eastern Europe always say no. The French are arrogant and a Swede cannot make a simple decision even if their life depends on it.

But wait… our close friends and long-time colleagues born and raised in these countries are not like that at all! At least that is my personal experience and what many around me have said, time and time again. So how can this be?

In this article, I will argue that the reason for this apparent contradiction is all about team and relationship maturity. And I find that team maturity is best described by Susan Wheelan’s Integrated Model of Group Development. You may know it from the phrase “Forming, Storming, Norming, Performing”.

I will argue that cultural stereotypes are highly relevant in the Forming and Storming phases, but then have very little significance in the Norming phase and almost no significance in the Performing phase.

Forming

When we first meet and interact with new people, we are in the Forming stage. In the Forming stage, humans as a rule tend to look for clear instructions for what to do and how to act. In the Forming stage, traditional politeness is our guiding star. If we see anyone in the group act out any behaviour that deviates from what we consider to be traditional politeness it immediately makes us very uncomfortable. But what we consider to be traditional politeness is by its very nature very much dependent on what culture we have been raised in.

So in this early Forming stage, we really need an experienced guide who can navigate and translate the politeness cultures of all team members. Mixing people from different cultures without a guide of this kind will definitely cause friction.

But we don’t want our teams to stay in the Forming stage, cultural differences or not, because it is not a very efficient stage to be in. We want them to reach at least the Norming, or preferably the Performing stage where the teams really start producing high-quality work. And to get there, they go through the dreaded Storming phase.

Storming

What is the Storming phase really about? Ask someone on the street and they might say that all teams descend into bitter conflicts. And that usually happens. But it is not mandatory, and even when it happens, the conflict is just a symptom.

People experienced in working with teams know that the Storming phase really is about team members putting all cards on the table to be able to agree on what rules shall apply to the team. That can happen in a shouting match, or in a calm discussion.

What we do in that shouting match, or preferably discussion, is to begin replacing the traditional politeness we have been taught while growing up with a new set cultural rules. Once we have these new cultural rules, our previous traditional politeness suddenly matters a lot less. And this is the true purpose and meaning of the Storming phase and the team can now move into the Norming phase where we see the first real uptick in productivity.

Norming

At this stage, our new team culture is still in its infancy and as anyone with experience knows, old habits will still pop back. When this happens, the team typically moves back to the Storming phase for a bit. And this can and typically will happen more than once.

But in this Norming phase, with its occasional lapses back into Storming, this infant team culture gets polished and solidified until one day it is consistent and robust. And this is the day that the team moves into that Holy Grail of all teamwork, the Performing phase.

Conclusion

So if you hear complaints about cultural stereotypes getting in the way of work, or that idea pops into your head, then you can remind yourself that the cultural stereotypes are not the problem.

The problem is that your team is not in fact a cohesive team, but simply a group of people in the early Forming stage. But the good news is that your team has not yet reached its full potential, and have a lot more to give if given proper guidance and a bit of time.

The science is clear that empowered teams are more innovative and cost less than non-empowered teams when it comes to developing products. So naturally, all product companies want to have empowered teams for their development. 

But the vast majority fail. Why?

I claim that this is because empowered teams are completely counterintuitive in a corporate context. To make things even worse, the move to empowered teams typically takes a leap of faith, where you need to decide on a completely new way of working and then just hope that it will work out automatically. See my article on the Circle of Safety for a description of a transitional organisation that makes this leap a lot shorter and less risky.

I believe that a company leader must have seen an empowered team in action, to be able to make that leap. I first met empowered teams in the Scout movement, which unlike their own marketing is first and foremost in the business of teaching people how to form empowered teams. The whole nature-thing is just a means to that end. Without that Scouting experience, I don’t imagine that I would believe in the magic of the empowered team either.

But there is one situation in a run-of-the-mill company where I have seen many empowered teams. And that is in the planning and execution of an after-work or company party. Why do I believe that this situation allows empowered teams to emerge? Here is my list:

• Clear goal: We want a party and we want everyone to have fun. Any employee can understand the value proposition as well as the general scope limitations. The success criteria is typically not quantifiable, but still easy to agree on if it was achieved or not.
• Freedom: Management usually does not interfere with the details, but at best indicate a date and allocate a budget. As long as the party planning committee stays within the budget and does not break any laws, no questions will be asked.
• Engagement: Some party committees are drafted rather than volunteer, but often in a company there are some people who engage very passionately and the parties they arrange tend to live long in the collective memory.

The end result tends to be parties that are planned in a short time, use minimal budget, and are very appreciated by the intended audience. 

So the next time you tell a team what to do, mentally picture how you would approach the situation if you wanted them to arrange a company party. Because if you do, chances are that you will have cause to host a party soon enough. 

Background

In working to transition a traditional development organisation ot an empowered one, I have realised that most material widely available describe the end state. They describe, very clearly, what an organisation made up of empowered team looks like and the massive benefits they yield.

Unfortunately, we are all human, and simply describing an end state is very seldom enough for a large group of people to over-night change their way of working.

In this article, I propose a transitional organisation that allows teams to grow into fully empowered agile teams without too much frustration along the way.

What does this transition organisation look like?

In a traditional organisation the manager is the single formal point of contact between the rest of the organisation and the team.  This is not the case for agile empowered teams where there is no team manager and the individuals represent the team in a variety of contexts.

With all these different individuals representing the team, it is really important that they all act as ambassadors of the team as a whole, or else the communication and trust between the team and the rest of the organisation will disintegrate rapidly. This means that the team has to have matured to at least the third level of Susan Whelan’s integrated model of group development. A team which has not reached that level of maturity simply does not have the capacity to present the necessary unified front.

To start with, most things will work like in traditional Scrum. Below, I list differences between, or clarifications to, the proposed transition organisation and a textbook Scrum organisation.

The Product Owner

The first difference is that the Product Owner becomes the single formal point of contact for the rest of the organisation and has the overarching responsibility for the entire team. The Product owner has these specific tasks that are not strictly articulated in traditional Scrum:

The first task is to ensure that the team gets the proper input it needs, mainly consisting of the goals that the team shall achieve. However, this also includes providing access to stakeholders and end users in order to be able to get nuanced enough information to be able to achieve those goals.

The second task is to ensure that the discovery phase happens completely inside the team, as opposed to having a list of pre-scoped tasks that the team shall compete. If the discovery work is not happening fully inside the team, then the team has no choice but to remain a feature factory.

The third task is to ensure that deliveries created by the team are properly delivered to end users and results are properly communicated to stakeholders.

These three tasks shield the team from outside disturbances and confusion, allowing the team to mature in a safe space. This safe space is what we call “The Circle of Safety”. By giving the Product owner control of the entire interface between the group and the outside world, the Product Owners are in a position to be fairly held accountable for the work done by the team.

To be clear, I am not saying that the Circle of Safety shall become some form of a no-go-zone. Any team member may still communicate with any other person in the organisation. And anyone else in the organisation may talk to anyone in the team. However, there shall exist absolute and total clarity in that the team members can redirect any requests that they feel disturb their work to the product owner. In addition, the product owner shall be aware of all major communication between team members and the outside world to ensure that this communication is for the benefit of both the team and the organisation as a whole.

All said, this role looks very similar to that of a manager in a traditional organisation when seen from outside the team. This is intentional, as the rest of the organisation can interact with the product owner just like they would with a traditional manager.

In this model, the product owner is also responsible for the team happiness, something that otherwise typically falls on the Scrum Master. Since the product owner is given very large power over the team, including handling all input and output, this makes sense.

The Scrum Master

Since the product owner takes on such a large role, one might wonder if the Scrum Masters are needed at all in this organisation. They are. They are the ones that ensure that this transition organisation actually transitions to empowered agile teams and rather than just remain as a traditional teams but with different titles.

The Scrum masters role is to work inside this circle of safety and ensure the team matures in both productivity and in-team interactions.

Their first task is to ensure that each individual rapidly improves in all of the skills needed to shoulder the full responsibilities of a high performance agile team (e.g. Automation of tests and delivery, Architecture, Clean Code, and Innovative Discovery)

Their second task is to work actively with the team and the Product Owner to ensure the team maturity increases. This involves building trust and resolving conflicts between all team members including the Product Owner. To start with, this will require a lot of workshop sessions and detailed instructions, as the team members will not used to the new way of working and the team generally having a lower maturity in the internal interactions.

The third task is to work to become redundant. A Scrum Master shall look at every activity they do with a critical eye. They shall think about how increasing the teams maturity can make the activity in question redundant. The parent of a friend once told me that “The best Scrum Masters just make coffee”.

The team members

The team members also work inside the Circle of Safety. Their job is to get the necessary skills and interaction maturity so that they can step out of this Circle of Safety as soon as possible.

Their first task is to get good at doing realistic and thorough analysis of work to be started. This will allow them to give realistic estimates on when they can deliver. By committing and then delivering on those commitments, the team builds trust with the rest of the organisation.

The second task is to never deliver a product that does not conform to the minimum standards set by the company, both from an architecture, coding, design, and usability perspective. In this task, we also include mastering the hands-on skills needed to be productive, e.g. Architecture, Automation of tests and delivery, and Clean Code.

The third task is to take an active interest in the discovery of new solutions. This means being a driving participant already from the early stages of an idea, long before any concrete features are even defined. Even at this early stage, the team members shall provide rough cost estimates and provide creative ideas that provide similar value but at a fraction of the cost.

The fourth task is to actively work with the other team members to form robust relationships. The end goal is that a third party coordinator and conflict resolver (i.e. the Scrum Master) shall no longer necessary in daily work.

The fifth task is to creatively and critically evaluate their own work and proposing actionable changes that will have a real impact on the team’s effectiveness.

The Manager

The manager has the overarching responsibility for the individual team member.

The managers job is to ensure that the individual team members in fact perform their tasks as stated above and that any impediments they or the Scrum master raise are removed.

What do I hope to achieve with this organisation?

This organisation allows for a completely fresh team with no experience of working in an empowered agile way to start delivering value immediately. The rest of the organisation can also treat this team as a traditional team for almost all intents and purposes. The Product Owner and Scrum Master together forming the role of a traditional manager building up the team.

If each part of the team takes responsibility for the tasks articulated here, my experience says that it will put the team on a well-defined path to grow into an empowered team. Once the team has proven to itself and the rest of the organisation that they are mature enough, then the Circle of Safety can be removed and the team can interact with the rest of the organisation as a cohesive and effective unit. 

It is said that “For many reasons, Agile seems to work best when a [line manager] does not assume either the Product Owner or Scrum Master role.” But if so, then who should be that line manager?

The above quote comes from SAFe, and although the latest version of the official Scrum Guide has nothing to say about the topic, it is an often-repeated truth when talking about Scrum. But that obvious follow-up question is not discussed nearly as often. 

In this article, I want to present a thought model that clarifies the responsibilities of the line manager and helps decide who should hold that title. I will present the model, present how we use this model at Nextory today, and finally share and discuss some quotes by great Scrum thinkers on the topic

The Spotify Model

A very well-known answer to the above question is the Spotify Model. In Scrum, there are two leader-type roles, the Product Owner and the Scrum Master. Spotify has extended this model by introducing Chapters. A Chapter is a set of people with similar skills but who may be part of different agile teams. Each Chapter has a Chapter Lead who is the line manager for all members of that Chapter. This means that within a team, not everyone has the same line manager.

To repeat, in the Spotify Model, there are now three leader type roles defined:

• The Product Owner
• The Agile Coach / Scrum Master.
• The Chapter Lead, who is the line manager for all members of their chapter. 

The Spotify Model, if implemented as presented, places the agile coach and the product owners at the same level as the rest of the team, which is in line with Scrum. In addition, the role of the Chapter Lead becomes a natural promotion for an expert within an area who wants to get into management. Who better to be a line manager for a group of experts than a senior expert within the same area?

Challenges with the Spotify Model

T-shaped skill profiles

“The concept of T-shaped skills [is used] to describe the abilities of persons in the workforce. The vertical bar on the letter T represents the depth of related skills and expertise in a single field, whereas the horizontal bar is the ability to collaborate across disciplines with experts in other areas and to apply knowledge in areas of expertise other than one’s own.”

Software development requires people with deep knowledge of the topics worked on. But agile development works much better if the team members are also generalists. With generalist knowledge, any team member can step in to support in any activity making the team more flexible.

But cultivating this generalist skill set can become challenging when placing a group of specialists within the same field under a line manager who is typically also a specialist within that same field. Within this group, there will be a pride in being a specialist and learning new skills from other areas will not come naturally. For individuals who want to develop in a new direction with a new specialization, they also need to change their line manager which is a big deal.

The Peter Principle

Although it is not explicitly stated, the Spotify Model encourages the idea that specialists shall be promoted to line managers. But the duties of a specialist and that of a line manager are very, very different. So there is a large risk that the Peter principle will result in line managers who are not particularly good at their job..

The four coaches model

The Four Coaches model has similarities with the Spotify Model, but takes it one step further. In this model, four separate leader/coaching roles surround any given individual employee.

These leader/coach roles are:

• The Product Owner
• The Agile Coach / Scrum Master
• The Senior Specialist
• The People Manager

The difference between this model and the Spotify Model is that the Chapter Lead has been split into the Senior Specialist and the People Manager.

For completeness, here is a more in-depth description of each of these four roles in the context of this model:

The Product Owner

The Product Owner is responsible for the direction to build products that solve customers’ real problems and generate business value. Simply: What is important?

The Product Owner shall have a clear and deep understanding of how changes to the product will be received by the end user. This means that they can typically come from a customer-near background, like sales or customer support, extended with an understanding of how the product is developed.

The Agile Coach

The Agile Coach is responsible for the team and the process. Do the actions taken by the team lead to a valuable product materializing predictably and often?

The Agile Coach shall be an expert in which methods actually work to develop the product. This means that experience in development methodologies in particular is useful. They need to be experts in how to collaborate effectively, ways to have meaningful meetings, and the agile methodologies that their teams make use of. They should also have an understanding of group dynamics to help form solid teams.

The Senior Specialist

The Senior Specialist is a person who is exceptional at a skill that is critical for the organisation as a whole. Typical examples include development, testing, design, and architecture.

They are responsible for coaching and developing the organisation within their speciality. This means deepening the skill of less senior specialists within their own field, and broadening people with another speciality to help them achieve the T-shaped skill sets. The Senior Specialist may also be a team member in a Scrum Team. 

The Senior Specialist typically also has the authority to set minimum standards or define best practices within their area of expertise.

The People Manager

The people manager is responsible for the individual within the organisation. Individuals need to be welcomed when they join and given a path along which to grow. They will be part of a team, but may swap teams as the needs of the organisation changes. They may have one specialty when they join, but will need to grow both vertically and horizontally. Sometimes they want to develop a new specialty and focus on that as their primary job. They will succeed and expect recognition, be demotivated and need support, and sometimes the company will need to let them go. 

All of this is the role of the People Manager.  This person would typically be an expert in motivation, psychology and group dynamics. The natural place to look for people who are good at this is within HR. 

To make this role even more concrete, this role is responsible for:

• Recruiting new members to the teams.
• Removing impediments that the individual or the team they belong to cannot remove themselves.
• Evaluating the performance of the individual and driving the subsequent promotions, compensation adjustments, or removals.
• Holding regular informal follow-ups with the individual, e.g. a recurring 1-on-1.
• Plan and scheduling training for the individuals.

How are we doing this at Nextory today?

So have we implemented this fully and as presented at Nextory? Does each person have a total of 4 coaches/leaders? No, we have not.

So if we have not implemented it, why talk about it? Well, this mental model allows us to clearly communicate how responsibility for each individual within the company is shared. 

We use it to check that every individual has access to each of these roles to coach and lead them.

When we want to make an organisational change, which we as a growing company do almost continuously, we can use this mode to reform a new organisation depending on the coaching/leading skill sets available and needs of any given part of the organisation. 

For some individuals and parts of the business, like our design department, the Spotify model makes perfect sense. So we merge the Senior Specialist and the people Manager into one role. In this case, our Senior Specialist in design is also the People Panager for our designers.

For many other individuals, we actually go directly against the opening quote of this article, in that they have their Scrum Master as their People Manager. Even if this goes against the well-known best practice,it has great support among those team members. They feel that the Agile Coachwho is very present in their day-to-day activities is in fact the best person to judge their performance and support them in their career growth. But the Four Coaches alerts us to the specific challenges this might pose and allows us to compensate for this.

And for many small or newly started teams, there is simply one manager who takes all of the above four roles. This is of course a very traditional hierarchy, but such a team can still fulfill all of the famous agile principles and be a great and empowered agile team. 

What does the literature say?

The model of the Four Coaches is still a very new idea, even at Nextory, and still very much based on speculation at this point. But can we find any support for this way of thinking in the writings of seasoned Agile and Scrum experts?

The conclusion is that there in fact exist some references that encourage this line of thinking. So here are three quotes from three respected sources on the topic.

SAFe

In the article “The Evolving role of managers” SAFe states the following: 

“[A]ll employees still need someone to assist them with career development. A manager still has to set and supervise expectations and compensation as well as provide the active coaching needed to advance individual skills and career goals. In other words, managers are ultimately responsible for ‘growing their people’”

I state that the manager described in this quote is very closely aligned to the People Manager role outlined above. This quote in particular, and others like it I have read formed the core inspiration when developing the four coaches model.

LeSS

LeSS has the following to say on the role of middle management: 

“They should help the team and the Scrum Master with removing obstacles and making improvements. 

This is in line with The Four Coaches model, where the People Manager has the greatest mandate to make broader changes in the organisation. 

“They should teach the team how to improve and solve problems.”

At the team level, I claim that this is the job of the Scrum Master. But at the individual level, the responsibility of this falls on the People Manager. But they should in turn enlist the help of an appropriate Senior Specialists or potentially even external training depending on exact improvement needed. 

“They should Go See to understand what is really going on in the place of work and see how they can best help the team improve their work.”

This would be the largest challenge for a purely non-technical People Manager. But I claim that by being at the place of work, meaning sitting next to a developer or even better next to two developers doing pair programming, can be very enlightening. No engineering skill is needed to understand the body language of frustration, and open coaching questions can quickly help articulate the exact cause. And these are the two main skills that qualify a person for taking the role of a People Manager.

Pete Deemer

Pete Deemer, famous senior development manager and “Scrum Guru” lists the following manager activities in his article “Manager 2.0: The Role of the Manager in Scrum”. I find his list to be a bit of a mash-up, but once split into three groups, some themes became apparent that are in line with the Four Coaches model. So the headings are my addition to his list.

The People Manager should:

• Help remove blocks that the Team is not able to resolve by themselves
• Do regular 1:1 meetings with Team-members, to provide coaching and mentoring.
• Plan training and other skills development for Team-members
• Plan and manage budgets and financials
• Do performance evaluations and provide feedback to Team-members.
• Do career-development and career planning with Team-members
• Recruit, interview and hire new Team-members
• Remove Team-members who are not able to perform well within the Team

The Senior Specialist should:

• Provide advice and input to the Team on technical difficulties that come up
• Stay abreast of developments in tools, technologies, and techniques the Team is using
• Anticipate tools, skills and other future needs

The Product Owner should

• Stay up to date on industry news and developments
• Give input on what features / functionality the Team should build