Re-imagining Agility Beyond Scrum

Transifex has the birthright to be called an agile company. From the very beginning, when a handful of developers pushed for building a modern localization platform, code was released in small and frequent increments using mainly Kanban as a means of delivering value to our customers.

A few years later, as the company grew and people started to organize and break into multiple teams, the word Scrum came into the game and gradually replaced Kanban. Value started to be delivered in sprints, with the cadence that the framework required. It worked for us and fulfilled its purpose.

Scrum is the most popular Agile framework out there, works when applied correctly, and is used by thousands of companies trying to make their businesses succeed in our connected, fast-changing, and highly competitive world. With Scrum becoming the norm, how can we strive to do better? Is there life after Scrum? 

This is a story about how Transifex broke away from Scrum in an effort to discover something new.

The Age of Scrum

Transifex is a backend-heavy team, meaning that the product requirements lean towards backend work, such as microservices development, database operations, data scalability, APIs, command-line tools and integrations, and less on frontend tasks.

This requirement made Transifex engineering structure around component-based Scrum teams and less on feature teams that would be able to manage end-to-end delivery of new product features. 

In the age of Scrum, Transifex worked within three major Scrum teams, with each team having its own Product Manager/Owner: one core backend team that could handle all the heavy backend tasks, a full-stack/feature team that was handling mainly frontend work with simple backend requirements, and an integrations team.

Each team had a dedicated Scrum Master who was also a developer, in a dual-role mode. At some point, the company introduced a Scrum Master Coaching Program, to help Scrum Masters develop their skills and be able to guide their teams more successfully in Scrum. It worked well and we felt proud of our efforts to improve agility and processes to make our customers happy.

However, we began to notice some disturbing flaws. The first observation was that Product Managers planned their work and roadmap based on the skill set and limitations of their teams. For example, the Product Manager of the core backend team was making plans based on features that backend developers could handle. Similarly, the integrations Product Manager was planning potential integrations that integration engineers could handle. Sometimes, this would not align very well with the top-level company goals, the customer requirements, or the market trends.

The second observation was around releasing features that nobody wanted. Quite often, the work of the Scrum teams ended as soon as the code was deployed in production, only to fly off to the next feature. Sometimes we were missing the KPIs or customer follow-ups that would describe whether a feature was successful and even the maturity or sunset of an existing feature, based on the needs of the actual customer.

The third observation was regarding bug management. Scrum does not recognize bugs in the process, but the reality is different. Every software has bugs. How can you define a clear sprint goal and commit to it, when your backlog is polluted or injected mid-sprint with urgent bugs that may take a significant amount of time to reproduce, investigate, and fix?

The last observation was our sense of guilt about admitting that we do not actually follow Scrum by the book, and therefore we are not playing 100% by the rules. This was never a problem for us as we adjusted a framework to our reality, but still, why did we feel like we had to apologize?

The Hackathon Paradox

Transifex Engineering hosts internal Hackathons twice a year. When this amazing event takes place, everybody writes down their exotic ideas in a shared Google Sheet, people vote for the best ones, and hackathon teams of 3 to 4 people are formed. 

Hackathons happen off-site and each team is given two full days of focused work to deliver something amazing and present their produced value to the whole company during a post-hackathon event. Guess what? It has been a success every single time.

Let’s take a step back and observe what really happens. People who might have never worked together before, align, self-organize, and collaborate towards a common goal, within specific time constraints. 

And they succeed every time, with many hackathon ideas finding their way to production, after being given some more time to polish the rough edges. Transifex editor dark mode is one great example of a hackathon idea that made its way into the final product.

And here comes the paradox. How is it possible for people who might collaborate for the first time to deliver amazing value in two days, while on regular sprints they might struggle to estimate and deliver value on time?

Rise of the Hexagon Trifecta

In late 2019, we decided to do something better, think outside of the box, re-evaluate what is important about how we work as a team, focus on how we can reduce waste in our processes, and work on making our product more impactful.

I really like relating Agile to cooking. When you start cooking, you follow some well-known recipes, that if executed well, can produce a good meal. However, as you grow your skills, your curiosity and experimentation come into play and you start to mix and match various ingredients, trying to discover new flavors and exploring new possibilities.

Scrum is a dependable, traditional recipe. It has been tried, it works, and if you follow it by the book, it can be a great entry point for your Agile transformation. When you have conquered that flavor and made it work for your team, it is time to go to the next level, the curiosity mode. It’s time to become a chef. A master of your craft.

At Transifex, we wanted to use the Hackathon paradox to transform our team’s experience. And we started by ditching Scrum all-together in favor of Squad based teams that would only live long enough to fulfill their purpose. 

We united all Product Managers into a strong core team, the Product Squad, focusing only on the outcomes we want to achieve as a company, regardless of our limitations. We introduced a lean product roadmap, with goals we want to achieve in the short term, within the year, and some long-shots. The Product Squad would focus exclusively on the why and the what of our product strategy, leaving the how to the engineers.

We dropped the component teams and united them under a common pool of engineering talent. Every engineer should have equal opportunities in every technical domain. We transformed team ownership to shared ownership.

We replaced sprints with cycles. In every cycle, the Product team would define a set of missions and pitch them in front of the whole engineering department. Then, each engineer would get to vote on the missions that they would like to participate in. After this process, teams would form around missions, called Hero Squads, with one sole purpose: Be given full uninterrupted focus and autonomy to deliver the objectives of their Mission. Autonomy would expand to self-organization, including using any digital or physical media to organize their work, with no specific roles on the team, and with equal opportunity. The mission would be over when all of the objectives had been fulfilled, including development of high-quality, bug-free software, deployment and monitoring, documentation, onboarding, communication with customers, and all the necessary components to make a feature successful.

But what about bugs or other urgent issues that would normally pop-up that had previously been handled by our Scrum teams? To maintain full focus on the Hero Squads, we decided that on each cycle there would be a special team called the Guardian Squad, with rotating members, having one sole purpose: Protect the Hero Squads from losing focus. This team would handle bugs, provide technical support to our Customer Success team, and onboard new members. They would also work on a Kanban-style workflow, as a maintenance and support team.

We called this workflow Agile Squads and built it around the core values that made our Hackathons successful: Purpose, Challenge, Focus, Safety, Collaboration, and Learning. Then, we visualized the entire effort in a chart called the Hexagon Trifecta.

The new framework has been a great success for our company and has completely transformed our motivation to come to work every day. The product roadmap and the company goals became more transparent, it was easier to pick our battles and prioritize more impactful projects instead of being spread too thin. 

People had the chance to work on projects that made them feel more challenged. They exposed themselves to unknown territories as a learning and growth opportunity. New exciting dynamics surfaced among our teams and our customers felt they were heard more. In general, it made our work feel more purposeful, exciting, and fulfilling.

We were so excited about this that we decided to make our Agile framework open source so that others can try our recipe, get inspired, and spice it up with their own ingredients. The framework is a constant work in progress and we keep working on it, making adjustments as we discover and learn more.

The framework is available at agilesquads.org and is built around a lightweight process, allowing anyone to fill in the details using add-ons. 

We welcome everybody to contribute and discover new Agile flavors together!

—

To learn more about the best localization practices that agile teams can employ to effectively go global, download our Complete 2020 Localization Guide for Agile Teams.