This experience report tells how we started communities of practice (CoP) at Digital Globe as we grew from 4 agile teams to 12 teams over a period of 3 months. We found that developing communities of practice involved some coordination, but also the way they created alignment and continuous improvement across all the teams was truly amazing.

1.      INTRODUCTION

Before we begin this journey, let me talk about whom I am and my role at DigitalGlobe. Currently, I am an Agile Coach within our Information Line of Business that supports the Cloud Services release train. This release train is composed of 12 Agile Teams which include both a Systems and DevOps Team. We follow the Scaled Agile Framework (SAFe) as a guide to our Agile implementation while incorporating different processes and tools to complement the framework based on DigitalGlobe’s business needs. I was apart of the Cloud Services team prior to the Agile Transformation and was both the first Scrum Master and Agile Coach employed at DigitalGlobe.

DigitalGlobe is the leading provider of commercial high-resolution earth observation and advanced geospatial solutions that help decision makers better understand our changing planet in order to save lives, resources and time. Each day customers in defense and intelligence, public safety, civil agencies, map making and analysis, environmental monitoring, oil and gas exploration, infrastructure management, navigation technology, and providers of location-based services depend on DigitalGlobe data, information, technology and expertise to gain actionable insight. With our collection sources and comprehensive image library (containing over 4 billion square kilometers of earth imagery and imagery products) we offer a range of on- and offline products and services designed to enable customers to easily access and integrate our imagery into their business operations and applications.

2.      Background

After January 2013, our cloud services platform had just been awarded a new multi-million dollar program. This was the biggest award this platform has seen in its 3 years of existence. Furthermore, this was the 2nd biggest contract award in the history of DigitalGlobe. We were a platform that was doing Scrum well at the team level and was maturing into the program level and pioneering agile portfolio management in terms of our platform. For example, our teams were predictably delivering on commitments made at quarterly release planning, quarter after quarter, with minimal escaped defects. Additionally, we created Product Councils to help steer and prep work for the upcoming quarter but also would look at the current health of the release. We created the portfolio hierarchy structure for the platform for Initiatives/Programs and their Capabilities and Features that has now become the structure that the enterprise uses to manage the DigitalGlobe portfolio. We had great success at the team level and we were pushing to mature and be pioneers at the program and portfolio level.

When this program arrived, we had 4 agile teams, that followed the model of 7 +/- 2 which included a Scrum Master and Product Owner, across two time zones. However, the scope of this program was 3x the size of the largest program to date on this platform. One constraint was that we needed to deliver the features in this contract in only 9 months. The leadership team and I were thinking how on earth are we going to get this done? Orthogonal to the time constraints and the need to scale to deliver on the scope of this work, we were going through a combination with our largest competitor in the commercial satellite market, GeoEye. We knew at DigitalGlobe that GeoEye had a similar cloud services platform in which they delivered to the same customer of this program. This forced core delivery team members and leadership, from legacy DigitalGlobe and legacy GeoEye, to evaluate both platforms to commit to a platform for this program and the future. Would it be legacy DigitalGlobe’s Platform or would it be legacy GeoEye’s Platform? They are different technology stacks and this was an important decision to make. This was an exciting, but anxious time for everyone, new and old, that would have a part in delivering on this program and platform.

We needed to rapidly scale up your teams and quickly decide on a platform strategy. We had very intense sessions evaluating both platforms, which included core delivery team members and leadership to purposefully choose the best delivery platform for this program and the future. The decision to use and extend the legacy DigitalGlobe platform was made in February 2013. With that in rearview mirror, we now moved to focusing on building 8 new agile teams through two different avenues.

The first avenue, was hiring more staff in the our two current locations, Longmont, CO and Walnut Creek, CA, and the second was to assimilate the teams that came as a result of the combination with GeoEye in Herndon, VA. We hired 27 people in our current locations and gained 21 people and a new location in the 1st quarter of 2013. Gaining 21 more people from legacy GeoEye came at a cost in terms of working in a different technology stack, .NET to Java.

To help ramp up this many people in every way imaginable, we used a “grow and split” method in our two current locations. This method allowed us to put new hires on existing teams for a few iterations and then we would split the team into two agile teams, 7 +/-2 model, in which at least 1 senior engineer would be moved into the new team. This method also allowed us to keep the original 4 teams relatively the same without impacting the predictability these teams have built over the last 3 years. Furthermore, teams members felt more continuity because they did not have to split multiple times like in the “split and seed” method where teams are constantly being split and reformed before they get comfortable together. The other option was to hire more internal coaches and create teams of new hires. However, we decided it was more important to gain continuity from the “grow and split” method in terms of engineering than for process. Plus, we were hiring additional Scrum Masters. In the “grow and seed” method, my role was to train the new split agile teams on the Scrum process which lent itself to the creation of the “Implementing an Agile Team” concept that could be re-used for any newly created team. We felt the combination of the “grow and split” method and the “Implementing an Agile Team” concept would help us scale the fastest.

Unfortunately, we could not use this same “grow and split” method in our new location, Herndon, VA. We wanted to stay true to one of our core principles on the platform, which is co-location of teams. With that constraint, we used the “Implementing an Agile Team” method to ramp up these teams. We knew these teams did not operate anything like our other teams. They had a different process, technology stack, and culture that first needed to be understood and then led into their new process, technology, and culture. So, first, we formed new co-located cross-functional teams and training commenced from both a process and technology stack perspective. I launched three new agile teams through the “Implementing an Agile Team” concept in order to train all key roles in each team on the Scrum process. Additionally, we had a few senior engineers from both locations helping with the technical training on their new platform. This was an on-going process throughout early part of 2013. Essentially, we used the internal coach approach to on-boarding these teams with the help of senior engineers in the training of the technology stack.

Whether it was being involved in the hiring process or teaching and training others on the new process, the 1st quarter of 2013 was insane. I have never seen or been apart of rapid growth like that in my career nor has any of the leadership team and it posed many challenges on a personal and platform level. However, I knew, along with the Director of Engineering, that it was not going to get any easier over time with the scale of people we now have contributing to the platform. The “grow and split” method and the “Implementing an Agile Team” concept could only get us so far. We needed a way to continue to focus on aligning new teams and individuals around process, practices, and craftsmanship for the long haul of this program and our platform while still keeping the experimental and continuous improvement culture going that has been built over the last 3 plus years. So, in a car ride with the Director of Engineering to the Boulder Agile Meetup, we discussed different ways to solve that problem that led us to the idea of Communities of Practice. In that car ride, the Director of Engineering told me to create a experiment and run it to validate or invalidate the idea of Communities of Practice in helping solve the problems we were facing.  So, I did. In figure 1 below, outline the significant events throughout this experience report.

Figure 1: Timeline of Events

3.      Designing the Communities of Practice Experiment

It’s now April and all 12 teams are up and running and the new teams have either gone through the “Implementing an Agile Team” method or have been through the “grow and seed” method. New teams had a few sprints under their belts and have been learning through doing while building new relationships with teammates. In my mind, now was the perfect time to bring the idea of Communities of Practice to the table with the momentum and energy that has been created over the past few months.

However, if this experiment was ever going to gain momentum in its own right, I really needed people to buy into the idea of giving up their time for yet another meeting on their calendar. So I started to socialize this idea to the rest of the leadership team and key people across all three locations in very informal conversations both inside and outside the office. Through these conversations, some people would roll their eyes and say “this sounds just like another meeting that will take me away from my work.” Others would start thinking about some of their issues either from a team or individual perspective and started to envision themselves in a setting to talk with others if they were seeing the same things or how have they solved that issue. For instance, some Scrum Masters I talked with would say, “I wonder how others are running their retrospectives or planning sessions because the team feels like these are a drag.” So, through these informal conversations, I saw both sides of the coin. However, what resonated with me most was people just didn’t want someone to tell them that they must go to another meeting or try to tell them that this was the silver bullet to solving all of their issues. I needed to setup this experiment in a way that people could choose if they wanted to participate in a Community of Practice or not and these Communities of Practice needed to play an integral role in the day-to-day being of each individual on the Platform. My hope was that the people that I was socializing with about this idea would start to socialize it with their teams or other people in their office. After socializing this idea throughout April, I decided to do a brown-bag session with all invited from the platform to introduce the what and why on how we could use Communities of Practice to our advantage on the platform.

So in May, I held a brown bag session with whoever wanted to join from our platform. There was great turnout for this session and we easily had 75 people from the platform that included engineers, scrum masters, product owners, and managers in this brown bag session on Communities of Practice. I presented a PowerPoint deck that answered what I thought to be key questions that people would want to know about Communities of Practice alongside my thoughts on how we would get started if people wanted to go forward. So, these are the key questions that I answered in that brown bag session: 

What is a Community of Practice?

I quickly defined what a Community of Practice is so that we all understood before deep diving into the presentation. The definition that I used was, “Like minded or like skilled individuals who voluntarily come together because of their passion and commitment around technology, approach, or vision.” I told the group that Etienne Wenger invented the term “community of practice.”

What would Communities of Practice help solve?

We talked through how people in scrum teams become isolated or silo’d, speaking mostly to others on their individual teams. It’s hard for good ideas that come from inside of teams to propagate across the platform. Also, engineers have noticed similar functionality is implemented differently across teams. Basically, with the twelve teams we have coordination and communication was only going to get more difficult and the Scrum of Scrums could only go so far to reduce these types of issues.

How are Communities of Practice Organized?

In figure 2 below, you will see an example on how Communities of Practice could be organized to cut across development teams to create additional channels of communication. We also talked about that communities are project agnostic and don’t form around the pursuit of one single, specific goal. Instead, a community will generally have many related goals which means the practice can remain in existence indefinitely. However, communities can dissolve after achieving its goals or if members lose interest.

Figure 2: Example on How Communities of Practice cut across development teams

How do other companies use Communities of Practice?

I used an example from Salesforce, the Virtual Architecture Team (VAT), to show that other companies were using this as a tool for alignment and continuous improvement. The VAT is “virtual” as it is made up of developers from every Scrum team. Members work on the VAT in addition to being on a Scrum Team. The VAT owns maintaining and extending software architecture. They do this by defining the architectural roadmap, by reviewing architecturally significant changes to the code, and by defining standards to ensure consistent and maintainable code.

Should Communities of Practice be Formal or Informal?

I wanted to make sure I answered this one as passively as possible as the answer to this question could kill this idea right then and there. I said that Communities of Practice can be either formal or informal. Research that I have done showed that organizations with strong functional management in place prior to Scrum usually rely on those strong functional managers to support or even establish CoPs. However, it was up to us to decide if we want to go forward with this idea.

What are the 5 types of Communities of Practice?

In figure 3 below, I explained the different types of communities, their definitions, and typical challenges. I stressed that this table is not meant to be a hierarchy or the life cycle of a community and no one type of community is always superior to another. Rather, each has its unique strengths and weaknesses as seen in the chart. I indicated to the group that our communities would be somewhere between a “Bootlegged” and “Legitimized” community if we wanted to do this experiment.

Figure 3: Different Types of Communities of Practice

What are the 7 guiding principles to establish and help flourish a Community of Practice?

At this point in the presentation, I wanted to level set on the principles of a community since that would be the guiding light if we all choose to try this out. Those principles include: design for evolution; open a dialogue between inside and outside participants; invite different levels of participation; have both public and private events; focus on value; combine familiarity with excitement; create a cadence for the community. The ones that I stressed the most were design for evolution; open a dialogue between inside and outside participants; invite different levels of participation; focus on value; create a cadence for the community.

What is a Community Coordinator?

We also had a discussion on what a community coordinator was so that the group knew that this was not something organic and we need someone to facilitate the community. We talked about how this role was similar to being a Scrum Master in terms of not being the leader of the group but to facilitate the practice around which the practice has formed and help develop the community itself. They would need to convince members to attend, connect individuals with common interests, and schedule and participate in community gatherings or events. I knew folks would ask how much time does this coordinator activity take so I approached answering that question with a “it depends.” Currently, we don’t know and we would need to figure out. However, if I had to guess it would be a couple hours every few weeks.

Is this something you are interested in trying out?

At this point, I asked for reactions from the presentation. As expected, there were questions around this taking up valuable time but I did not even need to respond to those questions as others in the audience would tell them how this would be extremely valuable for them personally and their team to learn and gain alignment from others across the different locations. The other big elephant in the room was what type of Communities of Practice would we create, formal or informal. I knew that this was going to be a sticking point so I leaned in and suggested that we start out as informal and see where it goes. Everyone seemed to like that idea. There was definitely energy in the room and I didn’t even need to throw out to the session how I think we could get started as others prompted the room with the question “how do we get rolling on this?” We had a short conversation to answer that question and decided to set up another session to start brainstorming what types of Communities of Practice we would want to set up. After the session was over, a few engineers caught me after and told me how they have been thinking about how to do more knowledge sharing across teams and they just did not have a vehicle to do that but now it seem that this might be the ticket. One engineer was so excited that he created the Community of Practice WIKI page for the platform even before we had the brainstorming session. I was floored by the reaction and acceptance of this idea from the team. So I jumped right in on designing the next session on how we would brainstorm what our Communities of Practice should be on the platform.

3.1       The Brainstorming Session

The following week, I brought together all 3 locations into a meeting to decide on what Communities of Practice we wanted to create and decide on who would be the coordinator for that community. Again, we had great participation for this session as in the last with at least 75 people across all three locations. This session was a more difficult to execute on because of the nature of brainstorming with remote attendees. I designed the session to have everyone brainstorm items/topics that they felt passionate about around technology, approach, or vision. All attendees put their items/topics in a Google Document. Then we went through an affinity grouping exercise to group based on commonalities. After the grouping was complete, we then had to figure out titles for each group. That ended up being the names of the communities. This exercise yielded the creation of 15 different communities! Some of the communities that were created include the SAFe CoP, Scrum Mastery CoP, Test Automation CoP, DevOps CoP, Customer Experience CoP, Functional Programming CoP, Mobile Technologies CoP, and Big/Data Cloud Computing CoP. From my perspective, I saw some of the 15 communities being much needed for our platform, Scrum Mastery CoP, and others to be a great way for people to get together to talk about something that they are passionate and is not a core component of the platform, like Functional Programming. The output of this session is found in figure 4 below.

Figure 4: Communities of Practices created from the Brainstorming Session

Before we all left the room a few people signed up to create the 15 CoPs homepages on WIKI. We asked folks to sign-up if they were interested in the community on the WIKI page so that they would be apart of communication and meetings going forward. We allowed people a week to get signed up as communities would be meeting in the next few weeks to get started. I also made it clear to all the coordinators that if they needed any support to get these communities rolling to let me know. For example, if you needed me to be their for the 1st meeting or if you wanted to buy some books or lunch for your community or you just needed someone to bounce ideas off of, I was here for support. I had no idea that this many communities would have been created or seen so many people excited to be a coordinator. I knew, like with any new idea, you need to keep riding that wave of excitement or it will die on the vine. I came out of that meeting knowing I would not be a coordinator for any community so that others would have that opportunity but I could not wait to be involved in a few and help as many people as possible get their community off the ground. This was a huge stepping-stone to creating a sustainable method for alignment and continuous improvement over the long haul than the one time “Implementing an Agile Team” method or the “grow and seed” method.

3.2       Challenges Faced

It is now June/July 2013 and CoPs are getting up and running. I was asked by at least 10 CoPs to help get their practices started and I always gave the same advice to each community. I said invite everyone that signed up into a meeting room or offsite to kick things off. In that initial meeting, decide on who will be the coordinator and what type of cadence you would like to meet. Also, make visible to the community the 7 guiding principles and have a discussion about them and what they mean to your community. Then do a brainstorming session so that you can get a backlog of topics to discuss going forward and decide on the next meeting’s agenda based on the brainstorm. This seemed to be a nice pragmatic approach to start communities off on the right foot and all communities agreed. However, not all had success past the initial meeting.

 

I made a promise to myself to let communities take care of their own destiny and would only help or support when asked. However, for those communities that I was involved in, I would do my best to contribute as much as possible in anyway possible. With these two distinctive mindsets, I saw many different challenges in communities I was involved in and also observed on the periphery for communities I was not active in. The biggest challenge that I observed from all the CoPs was the time commitment. We all know that the tyranny of the urgent can take over anything and I saw this happen to multiple communities. These communities died and are no longer in existence. In the same vein as the tyranny of the urgent, some communities would try to take on too much and could never deliver back into their community. These communities would also die because they could not meet their commitments which in turn means no value was produced and community participants lost focus. Some communities would also have this issue but just not as severe. The community would get together but only a few people would show up for meetings. This type of involvement just was not sustainable because it was hard to come up with new topics and feel any value. These communities also died and are no longer in existence. Another example of communities dying involves coordinators leaving the company for another job. Two communities in particular had this issue and are no longer in existence. The challenges boil down to lack of participation and value perceived by participants. Although these were tough challenges, I still feel that communities dying were just part of the experiment and learning for all of us. Furthermore, we never expected for all communities to still be running at full steam as we knew more than 50% would not last beyond a few months and that was ok with us.

4.      Results and Learnings

So, 16 months after this experiment commenced what are the results? Successful or Unsuccessful? Well, I’m not sure this is a Boolean answer. However, I can confidently say that this experiment was well worth the effort. It aligned people and process across location and craft plus produced many improvements that would have been very difficult to get implemented without CoPs. For example, we still have 7 CoPs that continue to meet on regular cadence and produce value. Out of the 7 CoPs, 5 are from the original brainstorming session and 2 formed freely from a need in the Architecture and UX groups. Furthermore, the SAFe CoP has evolved into an Agile/Lean Center of Excellence for our platform. CoPs are just part of our nomenclature now on the platform and form freely when folks feel there is a need.

One thing that was difficult was to quantitatively measure the value of CoPs on the platform. However, it was easy to qualitatively measure value of these CoPs. All you had to do is go and sit in on one. The Director of Engineering and various other leaders on our platform would come to me and say “Wow, the energy and passion in that room is amazing!” and “I see new leaders emerging that I’ve would have never guessed without seeing them in this type of forum!” Contributors to the CoPs would say, “I feel like my voice is heard more now than ever before because I’m not silo’d in my team!” and “It’s nice to have forum like this. We get to have conversations that get all of us aligned and vent about pain points that we can improve upon inside and outside of my team!”

So, at the end of 2013, I started to look at all the individual CoPs WIKI pages and thought about a way that I could measure value, quantitatively. I decided to do something very simple. I looked through the each individual CoPs WIKI page, even if it was a dead CoP, and did a count of improvement items that have been implemented on the platform to my knowledge. The results of this exercise showed that these CoPs were giving back to the platform in big chunks. For example, our SAFe CoP led the charge in creating a Systems Team for our platform. The Test Automation CoP brought the idea of experimenting with BDD and now our teams are on a journey of a “whole team automation approach.” Our UX CoP has created and published many standards around UI creation that has brought improvement and alignment across teams and our UIs. Our Architecture CoP has contributed to creating an investment category around architectural runway/technical debt in which we now allocate at least 20% of the budget per release for these types of backlog items to be implemented. There have been numerous brown bag presentations and working agreements created throughout all the CoPs. For example, in the Product Owner CoP, Product Owners came up with working agreements around how to “pull” defects from the backlog so that we did not have to go through the infamous bug scrub. At my last count, there were 17 improvement items that I captured from the individual CoP WIKI pages. I’m sure that this is not the total number of improvements as it is very likely that many improvements were not documented because there was no requirement to do so. Leadership did not ask me to do this exercise; I thought this would be something that I could use both as a method of measurement and to quantify CoP value, if ever asked.

The successful results that we have gained from the CoPs have allowed us to experiment with the notion of a cross-functional manager. This role has individuals on cross-functional teams roll up to one manager. So, if you are a engineer, Scrum Master, or Product Owner on a team you will have the same manager. So we do not have functional managers on our platform anymore. Ideally, this cross-functional manager benefits from the CoPs in which the functions he or she manages have a CoP that preserves the craftsmanship, and creates alignment and improvement around technology or process. This is experiment is still in the early stages but would have never came about without the advent of CoPs.

As I introspect on this experience, I wish that I had worked closer with all the CoP coordinators to see how I could better serve them. I did not do regular check-ins with coordinators as I left it up to them to seek me out. I could have done a better job supporting them which may have resulted in CoPs not dying off or helping reform a dead CoP or getting the CoP the items they needed to be successful. Furthermore, I needed to create more space on my calendar to have sat in on more CoP meetings to understand how things were going and to help where I could. Another item, I could have done better with was to make the quantitative improvement measurements more visible to the people on the platform including leadership. I think this would have created a sense of urgency to be apart of this experiment for individuals plus gain even more support from leadership in terms of supporting CoP.

All in all, this experiment created value for our platform, helped us scale to deliver on our largest program to date, and extended our continuous improvement culture while knocking down team silos to gain alignment across craftsmanship and process. This experiment has also grown many new leaders on our platform.

5.      Acknowledgements

I could have not done this experiment without the help of Ben Buxton our Director of Engineering. His ability to setup an environment and give air cover to folks who want to experiment is second to none. Without his support and on going leadership CoPs would not be a reality at DigitalGlobe. I also want to thank all the Community Coordinators on the platform and contributors to the CoPs. This is your report and it would not have happened without your willingness to try something new and everyday leadership and participation. I also want to thank my shepherd Rebecca Wirfs-Brock. She helped guide me on this journey and gave meaningful and timely feedback throughout the process. I’m truly honored to have been able to work with Rebecca throughout this process. Thank You Rebecca! Lastly, I want to thank my wife Judy and daughter Lucy who had to endure countless nights and weekends of me not being around to participate in family activities. I could not have done any of this without your understanding and support through the writing of this experience report.

REFERENCES

Cohn, Mike, “Succeeding with Agile” Pearson Education, 7^th edition, 2013

Wegner, Etienne, “Communities of practice: learning, meaning, and identity”, Cambridge University Press, 1998