This experience report revolves around this question: How do we, as Agilists, work well together? It reflects on how Agile Coaches and similar roles might be unique in terms of constraints and potentials for self-organized competency building. And it describes how a group of a dozen coaches continuously sought answers and what they found.
1. INTRODUCTION
Six years ago, I started my first Scrum Master job at German telephony provider sipgate. Together with two other colleagues, we started forming their first full-time Scrum Master team. We worked with our respective Scrum teams, while we also collaborated on cross-team and organizational issues. Like every other team, we needed to figure out how to do this. Little did I realize how many times I would come back to this question: How do we, as Agilists, work well together?
It might seem like an easy question, especially given that we are all working jobs in which we help others figure this out. I am convinced, though, that the nature of our work and role asks for solutions that might differ greatly from what we advise other teams to do.
First of all, as a coach, you are often acting alone with the people you coach, be it an individual, a team, or something larger. And of course, you want to know how you are doing and where you can improve. While it is always helpful to get feedback from the people you work with and for, a peer will likely be able to go much deeper. Having a heightened awareness for anything coaching-related means that peers will be able to pick up on and verbalize things others can’t.
Secondly, when you cooperate with multiple coaches, you do not necessarily have the same conditions as, say, a development team. You are likely scattered throughout the organization, focused on working on your individual assignments. That means that the conditions are most likely very different from those of regular teams. So you need to approach cooperation in different ways.
1.1 My current coaching context
Fast forward to today: I now work at idealo, one of the largest price comparison platforms in Europe. It is my fourth job coaching Agile. And again, I am working with other Agilists in one organization. This report will reflect on my experiences with my current colleagues. My views have, to some degree, emerged from my discussions with co-workers. In the end, they are still my personal views and interpretations. I think there are valuable questions, lessons, and solutions arising from this group of a dozen coaches. Of course, this is all specific to the given context; however, I do hope and believe that it can serve others. Perhaps there is also something useful here for people outside the coaching domain.
In the following section, I am going to provide some background on idealo to set the scene. I will then lay out some ideas about the transition we went through and reflect on them. Next, I will describe some of our learnings on competency building and practice sharing. I will conclude with an outlook and final remarks.
2. Background
idealo was founded 18 years ago as a product price comparison website for the German market. Today the Berlin-based company provides one of Europe’s largest price comparison platforms. And it has grown to 750 people, 280 of whom work in the Product & Technology department.
In 2012, idealo hired its first Scrum Master. The organization quickly saw the growth of a small team of Scrum Masters. They each worked with a handful of teams while closely collaborating on ‘anything Agile’. Over time the size and structure of the organization changed, and so did its needs.
I joined idealo in March 2017. The Product & Technology department had just undergone some fundamental structural changes. To allow for more autonomy and focus, it was split into 10 units, each focused on one aspect of the product and user journey. There is e.g. a unit focused on anything that happens once a product is bought by a user. A unit consists of 1-7 teams and two unit heads. Depending on the size of the unit, there are one or two dedicated coaches.
This change and other developments also brought about change for the Scrum Master team. Two things happened:
- A role transition from Scrum Master to Agile Coach
- A structural transition from (Scrum Master) team to (Agile Coach) collective
2.1 From Scrum Master to Agile Coach
The focus of the role changed from Scrum Master for one or two teams to being the coach for a whole unit. While a coach might act as a Scrum Master for a team to a certain extent, the focus is on making the unit as a whole function well. This means focusing on leadership and the organization in order to create a leadership team that sustains an Agile mindset. In contrast to the former Scrum Master role, the Agile Coach will spend more time working with the unit heads, the team leads, group of product owners, and other units and departments. Hence, when I speak of the Scrum Master role, I am referring to the team-based approach, and coach or Agile Coach, when I refer to our current setup.
2.2 From Team to Collective
The autonomy (and different needs) of the units also meant that the conditions for the collaboration between coaches had changed. It goes without saying that growing from five to twelve coaches also pushes the boundaries of a manageable team size. Growth also implies that new people come in, and sometimes others leave.
In short, this meant going from a Scrum Master team focusing on development teams to a collective of Agile Coaches working on improving the units and overall organization. The challenge was and is to figure out what our current needs for cooperation are, and how to address them appropriately.
3. Our transition
As explained above, our collective of coaches grew and its focus changed. My idea of that transition time is that we needed – and to some extent still need – to challenge some core beliefs of our cooperation.
3.1 Cooperation ≠ Collaboration
I am going to differentiate between cooperation and collaboration here. While they might be used interchangeably in other contexts, the difference is, in my opinion, quite important. I am going to use the terms as follows: Cooperation is a form of working together on a collective output based on individual contributions that are being coordinated. Collaboration, on the other hand, is a much deeper form of interaction. It means you will not only share the goal, but also make (most of) the individual steps jointly to achieve it.
Establishing a work culture that is based on collaboration is an awesome accomplishment. A change of goals and growth might make it hard though to keep it up. ‘Reverting’ to cooperation might feel like a setback, but it might also be the better modus operandi for the new environment. This is what happened for us.
Next, I will describe three assumptions of the ‘collaboration mindset’ and explain how they can become a burden when changing (back) to cooperation, creating the need for a mind-shift.
3.2 Assumption 1: Everyone needs to be informed on every topic
Hitting the sweet spot between too much and too little information is hard. Missing this spot means that you either don’t have what you need, or you have a hard time finding it in all the noise. In a collaborative working environment, there is a need to share a lot of information, because you are doing all steps as a team. When this is no longer necessary, disseminating information as if you were collaborating can easily lead to information overload.
3.3 Assumption 2: Everyone needs to be involved in all topics
Working on a shared goal as a team likely means that everyone is involved in all topics to a certain extent. You feel a collective ownership and act accordingly. The larger a group gets, the harder it is to involve everyone. It can also make things quite inefficient and, in the end, ineffective. We got to a point where we needed to start making decisions on what to be involved in. This meant, to a certain extent, finding our own focus and area for specialization. It also meant being okay with things happening without us. This seems to be especially hard for people who have a great deal of professional curiosity.
3.4 Assumption 3: Everyone needs to build strong relationships with everyone
Building strong professional relationships takes time, and there are only so many of them one can maintain at a time. With a small group of people that closely collaborate on a goal, building and maintaining such relationships is both possible and necessary.
Having achieved a state of collaboration might make it especially hard to ‘revert back’ to a state where cooperation is the norm, and where it is harder to maintain strong relationships. With the growth of the team, it seemed less feasible to keep up the depth of the relationships with so many more people. Next to a growing number of new coaches, there are also people within the unit, a range of stakeholders, and often colleagues from other departments that one needs to build a working relationship with.
The less collaborative and more cooperative working mode doesn’t require all coaches to know one another to such a large extent. You will need to build working relationships with most of your colleagues. But the needed depth of those relationships in order to successfully cooperate is not as great.
3.5 The need for a mind-shift
These presumed beliefs probably emerged in an environment where a ‘collaboration mindset’ was – from my point of view – both needed and possible. However, the corresponding actions and activities did not scale to a dozen coaches in a changed environment.
In other words: the constraints (and the goals) changed, and we needed to change our ways of working accordingly, i.e. from a collaborating team to a cooperating collective.
3.6 How the change to a collective practically played out
Up until summer 2017, the Agile Coaches met e.g. for a weekly ‘Agile in our units’ meeting to discuss what was happening in our respective units. The idea was both to have a broad overview, and to identify topics to collaborate on. With 12 coaches in the room it was next to impossible to provide a detailed enough report while not spending too much time. There were also debates on what would qualify as a relevant topic. We experimented with the format, e.g. only focused on one theme at a time (e.g. management within the units). The decreasing attendance at these meetings did not suggest that we were getting anywhere with it.
Through various rounds of inspection we discovered that we had very different needs and expectations – somewhat surprising given that we all had the same job in the same company. This was one of the triggers to experiment with the ‘Communities of Practice’ idea within the Agile Coach group. I will elaborate on this in the respective section of this paper.
Today, we have, generally speaking, four types of interaction:
- Informal exchange between a few coaches
- Assignments that are worked on by a few coaches
- Communities of practice[1] as an established format to collaborate on a defined topic (see section below)
- A formal frame for everyone, that has a particular focus and that we experiment with frequently
3.7 Some measurable results of this mind-shift so far
About two years ago, the time spent in fixed meetings with the whole team was at a respectable 8.25 hours a week, spread over 6 formats. The latest iteration on this is, as I am writing this, 45 minutes per week, plus a four-hour multi-purpose meeting every 2-4 weeks.
While we keep iterating on these things, we still have a few important yet unanswered questions: How do we measure the success of these changes besides our own qualitative assessment of them? And more specifically, how do we know if we are still optimizing the whole while adapting to a diverse set of needs?
3.8 Why are we doing this anyways?
The attentive reader will have noticed that I was writing about our structure before discussing our goal(s). And this is actually the chronological order of how the problems emerged. We first noticed that the how felt weird, and only then did we get into our why. I assume that an explicit why had been diluted along the way, and it was only when the motions felt weird that we took a step back.
In a way, we fell into the cargo cult trap[2]: we were still going through the motions, but lost sight of the actual goal(s). I find it very humbling and grounding that even a group of coaches isn’t safe from finding itself in such a situation. After a few rounds of discussion we were able to paint a clearer, more up-to-date picture of why we are there. In short, the mission for us as coaches is to
- Make sure our respective units are functioning well
- As a group, do the same for the Product & Technology department as a whole
Both of course mean that we will at times work with other parts of the company as well. From all this we can derive different needs, e.g. the need to have appropriate support and to further develop the skills needed for our tasks at hand. Which takes us to the topic of this paper: Self-organizing competency building and practice sharing.
In the next sections I will describe three ideas we tried, refined, and found to be of great value. The first two are ways of collaboration [sic!] for a smaller number of coaches. The third one is a way to make the most of the time we spend together as a whole group.
4. Communities of Practice (dealing with diverse needs in a large group)
As one might expect, there is a great deal of diversity amongst the coaches at idealo regarding e.g. work experience, professional background, and individual strengths. As pointed out above, there is also a large difference in the work we do – based upon the context of our unit.
All this means that we have very different needs in terms of what and how much we need from the other coaches. Working as a team meant spending a lot of effort on the same things. While this ensures that everyone is on the same page, it is not optimal for supporting each individual in their work and growth. And this might ultimately lead to a sub-optimal performance of the whole group.
In the process of realizing this, we came up with the idea of trying Communities of Practice to provide a frame to match topics with people. To kick things off, we had a ‘marketplace’ to share what topics we wanted to cover or skills we wanted to develop. This provided transparency of supply and demand. It also provided a chance to discuss priorities, so that we could make sure that we stayed focused as well.
4.1 Example 1: A place for closer cooperation
Given the individual needs, there were and are different needs regarding the closeness of the cooperation. Three of us set out to form a circle that would meet more often and provide time and space to get deeper into the topics that we were individually concerned with. We also worked on things that concerned all three of us. So we started to actively pursue collaboration in specific contexts.
We kicked this off with writing specific working agreements and making our expectations (needs) explicit. It did in a way feel odd to do this for a subsection of the coaches, and one might describe this as an anti-pattern for teams. But then again we realized we weren’t a (regular) team and experimentation was in order.
We start every week with a breakfast meeting on Monday in our canteen. While there is food and small-talk, the purpose is to identify work during the week where we a) need help b) seek reflection or c) want practical tips. We also share information that might be of use for the others. It is through these interactions that we discovered the resources we actually have to help us do a better job.
We also have a slot reserved on Wednesdays to dive deeper into a topic, e.g. through peer consultation. This is a process to seek consultation with colleagues on real issues that you are dealing with[3].
Perhaps not by coincidence, two of the three members are the only coach in their unit, and all of them had been with the organization for less than a year. So the need for closer cooperation and exchange seems to be greater given these factors. Two more members joined along the way and their situations harden this pattern.
4.2 Example 2: Collectively learning about the Theory of Constraints
One of the first communities was on the Theory of Constraints. Our goal was to – collaboratively – learn more about it so that we could apply it in our respective units. One of our colleagues was already rather experienced in its application. He worked with us through the basics, building on Eliyahu Goldratt’s The Goal and a few more tools and case studies. Participation was voluntary and over time a core of people emerged who stuck with it.
The community went on for over 6 months. Given the endurance of the members, I would claim that it proved our idea of focused, voluntary collaboration to be of great value. Today, we have a number of units that have kicked off working with the Theory of Constraints. When one needs help with a related issue, there is a large enough knowledge base within the collective to advise and provide opportunities for reflection.
4.3 Learnings
Experimenting with the communities of practice allowed us to significantly decrease the time we all spend in meeting with the whole group. At the same time, we were able to provide platforms for exchanges based on individual interests and demand.
5. Pairing for coaches
Some of us already work as a pair in our unit, simply because of its size. It was a bit of a happy accident that others got to experience this working mode as well.
We had two departments who asked for some (Agile) coaching support. We do listen to such requests, and then offer help depending on the potential value this would create and our capacity. In these two cases, none of us had the time to take on the full assignment, but the need was evident to us. We ended up finding two coaches for each assignment. So both departments got some time from two of us, who ended up doing those assignments mostly in pairs.
There was a bit of ramp-up time for the pairs to interlock. When they did, it was perceived as a very fruitful collaboration that provided lots of learning opportunities for the coaches:
- Seeing other coaches role modeling their approach to their job
- Having someone to deeply reflect on observations, dynamics, and hypotheses
- Having intense exchanges of ideas while e.g. designing workshops
While not every step requires two coaches, there were numerous occasions where this appeared to be of value:
- Meeting facilitation: Especially for larger groups it is good to have two people who can facilitate the discussions, suggest ideas on how to proceed, and pick up on what is happening in the room; when it is not necessary to have two facilitators, one could still join as an observer to either play something back to the group or use those observations for later
- Coaching: For coaching two or more people, it can be valuable to have more than one coach, as it broadens the available techniques (two coaches for one coachee can still work, but might be a bit much)
- Mediation: When helping to resolve conflicts, it can be very helpful to have more than one facilitator / mediator, and if it is just to avoid the possibility of one party perceiving the facilitator as taking a side
5.1 Learnings
What we did notice is that it would have been an advantage to have some outside party (e.g. a third coach) to facilitate the reflection on our work as a pair. This would have likely accelerated finding a smooth flow for the pair.
It is also important to avoid confusion based on different treatments of the same issue. While it is a great benefit to have multiple professional opinions on a topic, it is important to highlight them as being just that and help people draw their conclusions from them.
6. The huddle (our perfect format for operational topics)
With a few coaches it is easy to sync and get everyone involved. With a dozen people it is not possible to keep up this degree of exchange and involvement. Still, there is a need for regular face-to-face communication. Through a number of iterations our ‘huddle’ developed into an easy and elegant way to do just that.
As mentioned above, we did a lot of iterations on our meetings as a team / collective. The huddle has been the only one that was able to stick for a considerable amount of time. And while it has lately become more of a playing field for experimentation, I believe it can be of great value for others.
There are often many topics where it seems appropriate to discuss them with everyone, e.g.
- Everyone should hear them and be able to ask questions
- Everyone should be able to take part in a decision
- It is unclear who would be the right people to work on a given topic
In order to provide a space for this, we meet with all coaches once a week for our ‘huddle’. Before the huddle, we can propose topics including a suggested timebox on a wiki page. Everyone can vote up front in order to prioritize the topics. This list – backlog if you will – then serves as the core of our agenda for the meeting.
There are usually two of us who will take care of facilitation, timeboxing, and note taking. The meeting starts with a review of actions that were agreed at the last meeting. It is followed by an update from our two Agile Leads on topics from the department management meeting that might be of interest.
We then go through the topics that we collected beforehand. We discuss them until the timebox is over, and move on unless a majority is in favor of spending additional time on it (50% of the original timebox). The outcomes of the discussions are documented on the agenda page, often in the form of actions to be reviewed at the next meeting.
If we need to have a vote on a topic, we try to get to consent through a majority vote (with nobody having any objections). If this fails, one person will be tasked with making a decision at a later stage after consulting with peers.
There were times when we frequently didn’t get to certain topics because we had too little time. We highlighted those topics. And if they failed to make it three times in a row (because there were always topics that were more important) we dropped them.
Something that proved to be of great value for some time was to use the meeting as a way for the company to interact with the whole group of coaches. Anyone could put a topic on our list, and regardless of the voting we would address them first in our meeting to allow guests to leave early. The guests showed up mainly for two reasons:
- They felt the need of limited coaching support but didn’t have a coach in their department
- They wanted to have our feedback on something, e.g. on an HR project
How does all this relate to competency building and practice sharing? The huddle provides a good platform for anything that is small enough to fit into a small timebox (max 20 minutes) and might involve the majority of us. So it is a great way of sharing / discussing topics that fall into some of these areas:
- I went to a conference / seminar that was really great, and I want to share some takeaways
- I am planning on doing XYZ for my development (e.g. a training) and would like to hear from other’s experiences and potentially get some recommendations for training providers
- I am stuck with a particular issue and would like to know whom of you would be available to help me figure this out
6.1 Learnings
The fuller the room and the agenda, the more important it is to show some discipline and have an attentive facilitator (while this probably goes for many other meetings, it is important to point out that also Agile Coaches are often in need of facilitation).
Because the agenda / topics backlog is easily accessible to everyone, we can actually clarify a lot of things before the meeting, making it unnecessary to discuss them with everyone. Also, we are able to ask questions up front which help the topic owner to come better prepared.
Providing the opportunity for everyone in the company to add topics to the agenda was in a way very helpful, because it was an easily accessible touchpoint to address all of us. However, we did note over time that we usually asked the same questions to clarify the intentions, and we weren’t all going to take on a single support request anyways. This is why we drafted a small list of questions that we send out to whomever inquires our support. Based on this list, we decide if and who will provide such support.
But even without this measure, we already saw a decrease in the number of topics on the agenda. There are a few things that might have been the drivers here:
- We have become better at deciding which topics actually merit a discussion with the whole group
- A lot of topics are related to HR, e.g. hiring (decisions), feedback talks, etc., which probably peaked at some point last year
- Focusing more on our respective units means that there is less time to think about and work on other topics
7. Conclusion
In the previous chapters I laid out some of the learnings I observed around working with my Agile Coach colleagues at idealo. I covered the transition process we went through from Scrum Master team to Agile Coach collective. And I explained a few lessons in detail. Next, I want to distill some general lessons that we took from all of this.
7.1 Agile Coaches aren’t immune to the effects that we help others work through
Just as with any other person and group of people, you need to spend some time and effort on making things work. Thinking that this is not necessary may sooner or later lead to the realization that coaches are people too, and as such not infallible.
7.2 Be very context sensitive with your solutions
As laid out in the introduction, we as Agilists have contexts that can vary greatly from that of ‘regular’ teams. So we need to be especially sensitive to the context that we are dealing with. I have heard numerous times that Agilists felt the need to ‘eat your own dog food’, the dog food being specific Agile processes or practices. I am convinced that we need to put even more emphasis on the Agile values and principles when we seek to introduce Agile in an area where your complex problems aren’t products (but, say, Agile Coaches working together). Also, don’t seek to standardize too much. Just like with development teams, you want to provide a degree of freedom that allows for the best solutions to arise, and provide the specific support needed.
7.3 Open your activities up to others
Everything I mentioned so far was about working with other Agile Coaches. We did however have quite good experiences with opening our formats up to others. Some time ago we initiated a Community of Practice on Leadership for the whole Product & Technology department. As the first two projects we launched
- A Coaching Dojo (not only for Agile Coaches)
- A book club on how to master crucial conversations[4]
We realized that learning with other people and roles provided more value for everyone, as we had a great level of diversity (people, roles). And it turns out that these formats are also a great platform for us Agile Coaches to engage with others to collaboratively shape the work and the culture of the organization.
8. Outlook
It has been 6 years since the first Scrum Master joined idealo. A lot has been done to improve competency building and practice sharing amongst Scrum Masters / Agile Coaches. That being said, we are dealing with a complex system that continues to evolve, so we will never be quite done.
While I still don’t possess a crystal ball, there are a few questions that we will have to answer at some point. For instance, right now we are measuring the success of our experiments based on a) attendance and b) individual assessment of how well something addresses our needs. We don’t have good measurements for how much impact this has on the overall organization.
Additionally, we still need to find a better way to use our observations to decide which things we want to address on a department / organizational level. And it will be interesting to see how our coaching and cooperation practices will change over time.
9. Acknowledgements
I’d like to mention a few people that made these lessons and this paper possible. While it is about my experiences at idealo, it was definitely influenced by a lot of people I have had the pleasure of working with before as well. I was very lucky to have Tim Mois and Olaf Lewitz as early mentors, and too many great colleagues to mention all of them here. And there are of course my Agile Coach colleagues at idealo. Thank you for your inspiration, your efforts to create a better place for development and growth, and your feedback on this paper. And thank you idealo for making all of this possible. Thank you Mark Kilby for guiding me through the writing of this paper. Your positive way of challenging drafts and making suggestions was always very helpful.
And thank you, dear reader, for getting all the way to here. I hope you found a few helpful ideas and questions to improve skill development amongst your peers. And I’d very much like to hear your thoughts and experiences – just drop me an email at gerrit.lutter[at]gmail[dot]com.
[1] ‘A community of practice (CoP) is a group of people who share a craft or a profession. […] A CoP can evolve naturally because of the members’ common interest in a particular domain or area, or it can be created deliberately with the goal of gaining knowledge related to a specific field. It is through the process of sharing information and experiences with the group that members learn from each other, and have an opportunity to develop personally and professionally’ (https://en.wikipedia.org/wiki/Community_of_practice).
[2] The term cargo cult is originally used to describe ‘a […] movement first described in Melanesia which encompasses a range of practices and occurs in the wake of contact with more technologically advanced societies. […] the belief […] that various ritualistic acts such as the building of an airplane runway will result in the appearance of material wealth, particularly highly desirable Western goods (i.e., “cargo”), via Western airplanes.’ (https://en.wikipedia.org/wiki/Cargo_cult)
In the context of Agile, it is used to describe a state in which a team goes through the motions of an Agile process, without actually understanding the underlying principles. It is hence not able to cash in the benefits of Agile.
[3] There are many formats for this, e.g. http://www.liberatingstructures.com/8-troika-consulting/
[4] Based on the book https://www.vitalsmarts.com/resource/crucial-conversations-book
