devopsy.kinsta.cloud

Tag: guilds

  • Swarms: Adapting Guilds To Scale Agility

    Swarms: Adapting Guilds To Scale Agility

    In my first article in this series, “Using Guilds to Combat Information Silos,” I reviewed the adoption of guilds at xMatters. As our company has grown, we’ve used guilds to keep critical information from languishing in silos—as often happens when an organization scales. Guilds have helped our engineers apply their creativity and critical problem-solving skills to other channels and contribute to areas outside their normal scope. It’s a win-win situation for everyone who participates—and especially for the company.

    Implementing guilds began as a grand experiment. We quickly learned a lot about what enhances or hinders a guild’s success, making adjustments and adding a necessary dash of protocol along the way. But, as is the case with any growing organization, new needs and pain points challenged us to adapt and tackle them. One attempt to solve a critical problem led to an entirely new team model: a body we call the Swarm.

    The Swarm arose as a result of key changes in our release protocol. We used to be very focused on getting new features out the door as fast as we could. As it turned out, many of our customers prefer a more predictable schedule. So we gave our customers  flexible options by maintaining continuous delivery of code to production, with flags to stage larger features or more visible changes. Now, customers who wanted more predictable updates could opt for a quarterly release model while others could continue to access features as they became available and were being iterated on.

    While the quarterly release model improved our rhythm for customers, it also created stricter deadlines. A project that just missed a quarterly release could get delayed by almost another full quarter before our customers could start using it. Throwing more engineers at a problem doesn’t necessarily solve it faster—but, being the engineers we are, we thought about ways to parallelize the problem.

    We knew that guilds were very good at collaborating around a shared problem, so we adopted temporary guilds, which “swarmed” around a shared problem, completed work at an accelerated pace and disbanded. Centered around a specific initiative with a definitive start and end, multiple teams from Dev to Ops collaborated to complete a defined project. For instance, we might form swarms to create new product features, and their lifetime would span a finite number of sprints across multiple teams until completion. Due to its nature of focusing on new product features, swarms differ fundamentally from Guilds in that they are typically not self-forming; each one is an entity intentionally designed for a specific purpose.

    We began our swarms experiment with a large architectural change to roll out a new format for our customer hostnames, which involved six Engineering and Ops teams. We realized immediately that this would be an incredibly challenging undertaking on our tight deadline. A slew of teams was working on different stacks in different programming languages, so there were many competing visions and different contextual understandings of the end goal. It became very apparent that the swarm could not be left to operate in a completely flat hierarchy, as a guild usually does. We needed a leader to help ensure there was no duplication of work, things weren’t falling through the cracks and necessary dependencies were completed in the scrum storywriting between teams.

    Having someone take care of all the logistical problems is one thing, but we realized that in-person communication between all the teams in the swarm is absolutely necessary. We tried staying in the loop with each other by defining a process of posting updates from each team in our swarm’s Slack channel, but this was not enough to keep the project on track. Mattius, one of our very talented operations leads, initiated regular in-person meetings across all the teams, which led to far greater clarity. It was absolutely crucial to have all of the teams together and face to face on a regular basis.

    In the end, swarming on this massive endeavor allowed us to get the project delivered a week before the deadline. It was a challenging and imperfect first run, but it absolutely paid off.

    I leave you with these three recommendations:

    1. Create each swarm with a clear purpose and deadline;
    2. Have a leader to enforce consistent communication; and
    3. Have regular face-to-face interactions.

    The lessons we learned were invaluable for refining (and continuing to refine) our approach to tackling projects for faster release, and we’re continually working to improve and enhance this model. Good luck with all your future swarms.

    About the Author / Nick Fletcher

    Nick Fletcher, Engineering Manager at xMatters, started designing and developing websites back in 1998, when the World Wide Web was the Next Big Thing. In the time since that first website, he’s mastered all the aspects involved in creating great products: design, development and strong leadership. Connect with him on LinkedIn.

  • Using Guilds to Combat Information Silos

    Using Guilds to Combat Information Silos

    At xMatters, our group of 100 or so talented engineers is subdivided into teams tackling everything from front-end work to release automation to user interface (UI) and user experience (UX). As is common in an agile-minded organization, our engineering team members are cross-functional, with knowledge and expertise that carries over into areas outside their main focus. The advantages of this cross-functionality are an enhanced, self-organized form of collaboration and a more contextual understanding of project needs and goals—all of which ultimately lead to faster innovation.

    When I joined the company seven years ago, we had three engineering teams. We were already utilizing agile methodologies to eliminate as many inefficiencies as possible and streamline the continuous delivery process. However, as we grew to six, seven and upwards of eight teams, we realized that agile principles weren’t enough to scale the benefits. There was still a tipping point at which critical information started to silo and communication hurdles began to creep up between teams.

    Despite the stellar performance and incredible strides we had achieved with our platform, there still was room for us to grow and become smarter, faster and more productive. We needed a solution for this problem at the team-level, and for this we found that another cultural transformation was necessary.

    Here’s how it started: We observed that many of our engineers had keen interests in areas outside their usual scope, and that we could harness their interests as a valuable resource. There was the possibility of another kind of team—less official and more fluid—that would allow us to capture new ideas and solutions to problems as well as give our engineers the opportunity to engage in their interests.

    Thus, we adopted the concept of “guilds,” originally pioneered by Spotify’s development team. While Spotify’s structure is more complex to account for its nearly 2,000 engineers (it utilizes squads, tribes, chapters and guilds), the premise is the same: Allow people from different teams to come together fluidly and collaborate on a shared purpose. Our teams already utilized Slack for internal communications, and so we also created relevant channels for guilds.

    For instance, the UX guild exists separately from our dedicated UX team to include members from the front-end and other teams. We also have a test guild, comprised mostly of QA team members, who meet in person or over videoconference on a monthly basis. Our architecture guild features people from across nearly every engineering team who are interested in discussing the way we build our platform and structure our code base. Whenever people have an architecture-related problem, they post it to the architecture guild, and its members devise, record and vet a solution.

    In one case, we needed a way to configure all our customer’s environments and also replicate those configurations globally across our data centers around the world. The conversation about this issue arose in the architecture guild channel, and through it we gathered all of the necessary information and expertise to work on a spike and write a complete architecture document.

    If you’re at an agile-minded organization and are thinking of implementing guilds, the most important thing is to create an open, welcoming environment. Don’t try to structure them or make them overly formal; in principle, they should be self-governing entities that are virtually hierarchy-less. One of the coolest things about guilds is that they will be self-vetted by your community of engineers, so as soon as one no longer serves a function or becomes redundant, it naturally will fizzle out. We saw this happen with an auto-testing guild (for automation testing vs. manual testing)—it was essentially absorbed into the testing guild.

    Remember, in addition to bringing together experts in different areas, you’re inviting newbies who are interested in learning. There are so many advantages to this approach: You not only benefit from free user testing—in the case of the UX guild—but you also can harness a diversity of skill sets and creative minds to solve problems. As Einstein once said, “We cannot solve our problems with the same thinking we used when we created them.” NASA has taken this idea to heart, and has long used public crowdsourcing to solve problems for humanity in space and create new, innovative projects.

    The people who ultimately create the solutions often don’t have any traditional experience or expertise in the same area as the problem itself. Sometimes, it takes the collaboration of those both near and far from an issue to overcome it.

    About the Author / Nick Fletcher

    Nick Fletcher, Engineering Manager at xMatters, started designing and developing websites back in 1998, when the World Wide Web was the Next Big Thing. In the time since that first website, he’s mastered all the aspects involved in creating great products: design, development and strong leadership. Connect with him on LinkedIn.