Mauna Kea – Work

Mauna Kea in Hawaii is probably less popular and touristy than Mount Fuji and it’s already 4000 meters high, so we’ll start feeling the lack of oxygen. When a self-organized team climbs up here we can expect they’ll have to deal with work-related decisions, so we call this one this the “work mountain”.

Execution decisions

While in Mount Fuji we saw how a team could decide among them who would do what, in this step we find how a team performs their tasks, meaning what solution to choose and apply to a given problem. Our experience is limited to software development teams but we believe this step is generic enough that the main idea can be applied to teams in different industries. So if we’re talking about a software development team this would be deciding the architectural and implementation details, maybe the technical solution they’ll use and so on. This is usually easy to delegate for a manager and very positive for the team as it makes them feel more engaged and helps them find a solution that takes into account the vision of every team member.

Vacation and time

Vacation approval and working times are some low added value tasks which are pretty easy to delegate, and yet some of those we still find a lot of managers handling. Delegating part or all of these to teams can be very beneficial for both teams and their managers, whose main task will be to let go of the doubts they may have that the team takes advantage of this.

Most of the teams we have worked with have reached this level, meaning they don’t need to submit their vacation request to any manager approval. Instead, they need the ability to see who in their team is on holiday and when, so that they can ask the group for a convenient time for vacation days and the group can safely agree, based on an internal working agreement about team availability.

Within these teams, working times have more or less the same rules as holidays. What is important for these teams is that the job they committed to do gets done. Some of this job will require close collaboration, for which being together in the office will be key. Other parts won’t require close collaboration and can be done by individuals at the time they prefer, in the office or at home. This is especially clear to teams working in software development but can be easily applied to other teams in different industries.

Decaf feedback

A constant flow of feedback is obviously something extremely important in the agile world and we are fond of finding many alternative ways to keep this flow alive. We took all these possible practices for fostering feedback inside teams and classified them as coffee, because good coffee needs to wake you up, right? We believe good feedback has to have the same effects as coffee, so this feedback that wakes you up is what we call strong feedback. A decaf feedback, on the other hand, is feedback that is just okay but is not waking you up. What makes feedback stronger or softer in this scale is the emotional investment in the exercise, so how hard is to give or to receive feedback, emotionally speaking, for the individuals involved.

At this point in the climbing teams usually start to use decaf feedback. An example of decaf feedback could be an anonymous online survey, in which nobody’s looking at your face while you give feedback, nobody knows who you are and you can just say anything you want. This is pretty easy to do for the giver, even if it could be hard for the receiver, therefore it’s not equally enriching for both, and even inexperienced teams who are new to feedback can use these practices.

How are you doing with oxygen breathe? Should we keep climbing? You’re ready for the next level. We’ll be close to almost 5000 meters soon visiting Monte Bianco.

Mount Fuji – Coordination

The first peak in this model is Mount Fuji, with its 3776 meters. If you’ve been there you may have noticed that it’s a pretty touristy place. In fact you can find experienced climbers but also totally inexperienced people who get there by bus.

We associate this mount with coordination, the first stage of self organisation in this model. This is when a team starts to self organize, which usually in our experience comes in the following forms.

Task distribution

Teams that are new to self organization usually follow Scrum or Kanban rules and visualize their work on physical boards where they can easily see who’s responsible for each task. In this phase team members love using magnets or other fancy sticky labels to see who’s doing what after discussing among themselves how to best divide the work and how to best leverage individuals’ skills in the team. Sounds familiar?

Space distribution

Where should teams sit? Who gets the brightest spots? Who gets the noisiest? Answering these questions may seem of little importance (if you’re lucky to be in a place with some self management in place already) but you’d be surprised by how many companies whose teams have managers making decisions for them struggle with this problem every time they form teams or change their members. Solving this puzzle can be an extremely painful process, with competing managers, back and forth consultations, half decisions,  long meetings, layouts that result from exhaustion rather than consent and ultimately, unhappy people.

A few years ago our office had this same problem to solve after reshuffling teams but we were in a favorable situation where we could decide as a group instead of having managers do that.

As scrum masters we were asked to come up with a process to solve the puzzle collectively, and we took the opportunity to be creative and add some level of self organization in the process. We tried to simplify it as much as we could and came up with a funny way to it.

We took all the teams involved to a session and asked them to elect a spokesperson on the spot to represent each team. Then, we gathered all the spokespersons around a map of the office and gave them as many little post it paper balls as team members in their team, each team a different colour, and asked them to place those paper balls on the layout together, discussing among themselves and bringing the voice of the teams they represented. We timeboxed it to 30 minutes and asked to come up with a viable layout in that time.

We were a bit scared at the beginning but interestingly there was no tension or argument, and people actually were very happy to take part into that because they felt like they had a voice in the decision. Simple, quick, sweet.

Team identity

Team identity can mean many different things to different people. In our experience team identity starts from very basic things like a name and logo, and part of our job back when we formed new teams a couple of years ago was to help them figure those out. One of the first things we did with them was to encourage them to call themselves something more meaningful than just “Service X Team” or “Component Y Team” (yes, that’s also you “API Team no. 2237” out there).

Another great way to let teams find their identity is by helping them find their values, which we usually do by facilitating that discovery process with them. Values are what’s important for them, what makes them angry, sad or proud of what they do. Interestingly, different teams in our experience found very different values which represent them quite well.

By helping them find their identity we helped them finding what makes them unique, so in way we could say we helped them like Sherpas would do (okay, considering this was Mount Fuji maybe we did more like bus drivers than Sherpas).

Start with Fuji

These are just a few examples of things that managers can start to delegate to teams. We consider these in our first level because they can do no harm to the business but they can mean a lot to a team building their confidence in making decisions.

Stay tuned and climb the next mountains with us!