Focus and the meeting culture

Today I would like to talk about one of the biggest threats to focus and productivity in the free world: Meetings!

Don’t get me wrong, having a meeting is not a bad thing by definition. Working together is a great thing, so meetings could actually be fantastic. And sometimes they are, but very often they are disastrous to morale, focus and the general well-being of the employees.

Now why is that, and am I not exaggerating a bit? I believe that meetings are often bad because they disrupt the team’s focus in a severe way. Imagine a workday where we have two one-hour meetings scheduled for the team. Let’s assume the team members work 08:30 AM - 5 PM and go for lunch between noon and 1 PM. Also let’s assume that daily scrum is held 9:00 - 9:15 AM. Now, if the two meetings are scheduled to 10 - 11 AM and 2 - 3 PM, my experience is that most of the workday is wasted. The team doesn’t have time enough to enter a state of high-focus collaboration, except for maybe after the last meeting. In order to work effectively, my experience is that either the entire morning or the entire afternoon must be free of meetings.

I once listened to a TED talk where the speaker said that working and sleeping are similar in that you can’t get quality work or quality sleep if you’re interrupted all the time. As a father of two, I can relate to this. If your sleep is disturbed ten times during the night, you are destined be an unshaved sleepwalker at the office the next day. If you are a programmer and get interrupted all the time, you will never enter the zone of total focus. As a consequence, the quality of your work will be much lower.

The lack of great outcome from the team adds a lot of stress to its members. A stressed-out team will be even less productive. They will also start questioning the scrum ceremonies. The team will start feeling that retrospectives are time wasted. A vicious circle has been formed.

The only exception to this rule is when the meeting creates more value than what all the wasted focus time costs. And there are a few tricks you can use to minimize the negative impact of a meeting:

• Make it as short as possible. Try cutting the standard duration of your meetings in half - if you usually schedule one-hour meetings, try to cut them to 30 minutes! 
• Create a crisp agenda. Personally I am sick of all those two-hour meetings without an agenda you’re invited to. If you know the agenda well in advance, you will have the chance to prepare for the meeting. You will also have the chance of responding with an informed decline, as you will be able to assess whether your participation will actually create value. 
• Only invite a skeleton crew. The fewer that are disrupted from their work, the better. 
• Make the invitations optional to the highest degree possible. Don’t insist on attendance if it is not absolutely necessary! 
• Place the meetings in time so that the negative impact on focus is as small as possible. Right after daily scrum and lunch are great choices. 

It is always hard to practice what you preach, but I have been playing around a lot with cutting down meeting duration. I often separate room bookings from meeting bookings, so that a meeting can overshoot its alotted time if that is really needed. And if we are done after fifteen minutes at a thirty-minute meeting, we cut it short!

Last but not least, trying to change your organization's meeting culture too fast might turn into a conflict. In that case, I suggest meeting halfway!

How big is a team?

When I first started out with scrum in the mid noughties, the Scrum guide’s recommended team size was five to nine people. Since then, this has been changed into three to nine. Now, there is a huge difference between a team of three and a team of nine. So when should you be three and when should you be nine? Maybe it’s better to play safe and always stick to eight?!

Well, that depends!

The more people on the team, the harder it gets to maintain a single focus. A big team may easily become fragmented; suddenly you spend half of the fifteen minutes of daily scrum zoning out from the meeting, since you’re totally disconnected from what five people in the team are doing. Because you’re in a sub team that is doing something completely different!

Setting a crisp sprint goal for a team of nine is very hard. Usually, you end up with three goals at every sprint planning, which means that the team won’t have a clear guiding north star for the next sprint. 

So obviously, big is not always better.

I firmly believe that team size should reflect the number of people that need to work together in order to focus on one major initiative at a time. If your organization deals with a lot of complex and big initiatives, a bigger team size probably does makes sense. This may also be true if your deliverables are huge legacy applications. However, if the majority of your initiatives are quite small, it makes sense to have smaller teams. Especially so if you have begun transitioning to a micro-service architecture.

But if some initiatives are tiny and others huge beyond comprehension? Does this mean that team size will have to vary over time? And wouldn't that mean that we will be stuck in some sort of perpetual "Tuckman loop" jumping between group development stages every time someone is added to or removed from the team.  (N B: By ”Tuckman loop” I mean constantly transitioning between the Tuckman stages of group development.)

My bold proposal is to have your cake and eat it too! Build teams big enough to solve your smaller initiatives. Make sure that the team members work well together and complement each other professionally. Let's assume you do this in your organization and that you then end up with six four-people teams. That covers small initiatives. For big initiatives, build together eight-people teams from the four-people ”atom” teams. You will end up with teams where you know that the majority of team members work well together. This is a big difference from the old-fashioned way of forming project teams from a pool of people (or even worse: resources), where you will never know what to expect!

I am not saying this is a silver bullet, but the joint-team setup has been successfully used for one of my teams over the past two sprints. "My" three-person team is teaming up with a team of roughly equal size in another location for a limited time. With great result! I have also seen other successful examples of the joint-team setup, so it's not a one-hit wonder. 

When putting together two teams in this fashion, my observation has been that they function much like two sub teams do in a larger team. The two micro teams do the sprint planning and sprint review together. Daily scrum and retrospectives can be done separately or jointly, depending on what is best - in the initiative I mentioned above, we have kept having our separate standups and added a full-team standup on top of that, two times a week.

We call this setup Micro teams. Most people who have worked in this kind of micro team love it and don't want to go back ever again to big teams. They love the short, relevant standups. They love the feeling of all team members working on the same thing. And they love the focus.

This is the kind of team that can deliver fantastic value!

Outsourcing kills the feedback loop!

It is human to optimize locally. In this blog post I would like to shed some light on one specific local optimization: Outsourcing your maintenance.

It all sounds very logical: Instead of slowing down the teams by having them fix the bugs that their software causes in production, let’s form a specialized team that will take care of that boring chore! So that our best people can focus on creating value! And better yet, let’s outsource maintenance altogether! We don’t have time for bugs, let’s focus on the customers! Let’s be customer-centric!

This looks neat from an accounting perspective too, with separate teams for CAPEX (new investments, i e new products and features) and OPEX (operational costs, such as correcting bugs).

However, when you put on your Agile glasses, you start seeing that this is really bad. The first thing that strikes you, is that the feedback loop from production back to the development team has been severed. In an organization that outsources maintenance to a separate team, there was probably not much of a DevOps setup to begin with. But the team was at least informed about the bugs that were found in production, since they had to fix them. So this was the feedback loop. And now it has been cut.

Without a feedback loop, learnings from production will never reach the development team. Let’s say the team forgot to close database connections in their code. After an incident in production, the maintenance team creates a hotfix to correct this. But the development team isn’t in the loop, so they never learn of the problem. So, in the next release there is yet again a problem with the database connections. And so it continues.

The second problem is the amount of waste this creates. The development and maintenance teams need to do constant handovers if this setup is to work at all. Handover is a Lean waste. Wasted time and energy. Since the maintenance team has to fix bugs in software that they don't fully understand, there is a high risk of overprocessing, which is also a Lean waste.  

The third problem is the organizational culture that might be the root cause of the local optimization. Somehow, the organization thinks it is most efficient and best that specialized teams do specialized task. This degenerates fast into a sequential waterfall which rids the organization of the dynamics of crossteam knowledge sharing. Put simply, the Organizational intelligence will not reach its fullest potential, since people will work separately instead of together.

Instead of insisting on local optimization, be Lean and Optimize the whole! Instead of outsourcing, insource! Keep maintenance within the team and also insource operations! Don’t just fix the bugs, find them before the customers even notice them - by insourcing monitoring!

This approach is also a great way to switch the focus of the organization from delivering as much functionality as possible to delivering as much value as possible. And that's being customer-centric for real! 

Seriously, do celebrate your failures!

Celebrate your failures! is a ubiquitous Agile mantra. But what does that actually mean - and why on earth should you celebrate your failures? It is your successes that should be celebrated, right?!

It is true that team successes should indeed be celebrated. Celebrate these often. This is a positive feedback loop to the team that enhances good practices! But do make sure the entire team get to celebrate - we don’t want any heroes or favorites in the team, as that will damage the team spirit - ”hero personas” within the team will surely decrease collaboration. 

But what I want to talk about in this post is not how to celebrate successes. I want talk about failures. Of course, there are different types of failures. I am not talking about failing to come in to the office in time for the daily standup. An example of a failure that does fall within this post is:

"We decided to skip writing unit tests for one of the features we delivered last sprint. The team had committed to it in the sprint backlog and the Product Owner really wanted that feature to be deployed at the customer’s site by the end of the sprint. As a consequence, we have spent this entire sprint trying to fix the chaos that resulted from deploying the release."

In this case we can identify a few obvious learnings: Lower quality (no unit tests) does not mean higher speed or faster delivery - on the contrary it means lower speed and late delivery. Also, the team may be overcommitting, which might be the root cause of the incident. And on further analysis, maybe the old-style habit of committing to a sprint backlog is a local optimization in this case; perhaps it would have been easier to optimize the whole if the team had committed to a sprint goal instead? 

Ergo, a failure is actually a bunch of valuable learnings in disguise!

The Retrospective is the ceremony at which the team extracts learnings from their failures (and of course from their successes too). There should be no blame and no punishment. Instead, strive for an open and positive ceremony where everyone feels at ease. Focus on finding the root cause of failures and discuss how problems can be solved. Create (a limited number of) actions/experiments and commit to these. And then celebrate the failures! I suggest bringing Swedish "fika" such as cinnamon rolls to the retrospective.

For continuous improvement to work, the feedback loop from the retrospectives is essential. Now, imagine we are in an organization where failures are hidden and never talked of, due to a culture where they are unacceptable and therefore punished. In a such an organization, the improvement feedback loop will run dry. This means that the organization will cease to learn, stop improving and probably get behind its competitors, eventually going out of business.

Therefore, celebrating your failures is the antithesis to going out of business. And that is my point: Celebrate your failures, or you might eventually go out of business!

Continuously Inspect and Adapt!

In this short post I would like to share an experiment that I have been doing over the past year - the concept of Continuous retrospective.

Usually, a team's retrospective appointments are booked well in advance. For example, in my teams we try to have our recurring team retrospectives once every four weeks. The meeting is timeboxed to between 45 minutes and an hour, depending on team size.

But sometimes it feels much too rigid having to wait for many weeks between retrospectives - you ideally want that feedback loop start flowing with learnings right away! Therefore, some of my teams have started to do ad-hoc retrospectives when we feel the need for it, for example after a chaotic deployment or if there is a conflict within the team.

As the retrospectives are ad-hoc, we just go find a room and get started. Keep it swift, go around the table and discuss what went well and what didn’t. Try to find root causes for problems - 5 Whys is an excellent tool for that. Make immediate adjustments or commit to experiments (Not too many, preferably just a single one!) that might solve the problems. Then get back to work. 

The implementation of Continuous retrospective makes the team-process feedback loop run continuously instead of delivering learnings in big batches. Also, problems get addressed faster which means that they won’t have as much time to grow!

Inspect and adapt, continuously!

Trading Persona for Trust

One thing that has been on my mind lately is how to coach a team in order to help it reach the Performing stage in Tuckman’s group development model. Even if a team does incorporate all competences that are required to fulfill the team’s mission, I find it common that the team gets stuck in a stage where everyone stays in his or her comfort zone. Cooperation within the team is realized through handover between competences (or even worse: roles), which is of course a local optimization. Ergo, this is a team with a lot of I:s - contrary to the well-known saying.

My experience is that this type of environment is not a fertile ground for collaboration. To me, collaboration is a high-energy state where the team acts as one and where the whole is greater than the sum of its parts. When this type of team is iterating over a new design or hunting down a performancy issue, you often don’t know which of its members that came up with an ingenious breakthrough. This is because the team can somehow collaborate to the extent of becoming one mind. Therefore, who came up with an idea is both impossible to know and irrelevant to ask. This type of team is an example of the Lean principle Optimize the whole.

Teams that have reached this nirvana-ish stage consist of people who are comfortable both with themselves and with each other. And I’m not saying that they are complacent. I am not saying that they always agree and that there are no conflicts. Because there are always conflicts and that is actually a good thing - this would be material for a blog post on Agile and Hegelian dialectics. What I am saying is that the comfort zone has grown to incorporate the entire team.

As of late I have become interested in Jungian psychology and its theories on personality. Now, I might inadvertently prove the Dunning-Kruger effect by posting this, but please bear with me. As a layman, what really caught my eye in my first introduction to Jungian psychology was the concept of the Persona. The persona is essentially a mask we wear in order to be able to function socially. The persona makes sure that we follow social rules and don’t generally misbehave. Anyhow, I believe that in order to function as a collaborative team, the team members need to - at least partially - lay down their personas and instead cultivate their true selves. Why is that? Because this builds honesty and trust. This rids the team of competitiveness and alienation. And a team with honesty and trust is a team where collaboration techniques will work extremely well, very easily!

From my personal experience, this type of team is usually the outcome of a small group of very competent people that have had to work very hard closely together in order to reach a goal. If the group is too large, it is much harder to reach this stage. (This is one of the reasons for my being a proponent of micro teams.) The same thing applies for a team that is not forced to work closely together in order to reach a goal.  

So back to the original question: How do I coach a team in order to help it reach this stage? I believe that I should stop trying to control the team. Instead I should take a step back and hold space. I should open my heart and let go of judgement. I should walk alongside the team and provide support. This will rid the team of fear and build trust. Without fear and full of trust, the team members will start shaving off their personas. And right there, might we not have found a shortcut to Performing?

A passion for Agile

This is my first blog post ever. Not that the concept of blogging hasn’t interested me ever since it became popular in the early noughties. But I always figured that in order for me to spend my precious time and energy on writing blog posts, I would need an audience. And in order to get an audience I would have to write blog posts interesting enough for people to read them. So I quickly gave up on that dream.

But now that has finally changed. 

Since two years, I’m a full time agile coach at Telia Company’s TV & Media department in Gothenburg, Sweden. Even though I seriously have no clue as to what an agile coach is supposed to be doing all day, this position has given me the luxurious opportunity to spend time pondering upon what agile really is, how teams can go from cooperating to collaborating, what factors that drive motivation and what the ideal size of a scrum team is. For example.

Last summer I co-wrote a a blog post on Telia TV’s agile transformation, together with Michael Göthe at Crisp. The response from that post has lead to many interesting discussions and insights, which has in turned made me grow professionally. And it has been great fun.

I want this to continue. I want to spread my thoughts on agile and start a discussion with you, my readers!

So today I start blogging - and may this not be my very last post! :-)