Kicking Off Ada’s Journey to Agility

In a world of acronyms and lexical borrowing, there’s a combination of letters for every process and project management style a team might need — Scrum, SAFe, Kanban, Gantt… you get it.

As Ada scaled rapidly, the pace of creating features and delivering continuous value to customers resulted in our Product, Engineering, and Design teams evolving organically, and in somewhat different directions. By the beginning of 2022, with 10 active teams, we had just about the whole process dictionary simultaneously in various stages of experimentation and adoption (even, admittedly, Waterfall).

Teams were struggling with basic task estimation to prevent working overtime to achieve seemingly random deadlines, and dependencies between teams started cropping up much faster.

We have lofty ambitions for Ada, and if we want to continue delivering features that automate VIP brand experiences, we need a high-functioning organization working in a supportive and nourishing environment. It became evident that we needed more consistent practices.

Then, someone said the magic word: “Agile

Look, we get it, Agile Transformations are cliche. Agile! It solves all your business’s problems, right? Certainly if you’ve been around software development organizations, you know it’s not quite as easy as that. For all the promise Agile Methodologies have, they are not a panacea.

Knowing that, we didn’t want to bulldoze processes indiscriminately and paint over them with a shiny coat of Agile to “fix things”. There were many areas within Ada’s Engineering org that were already working well and enabling people to do great things. 

The adage goes: “if it ain’t broke, don’t fix it.” What we wanted to do was bring in the important and relevant aspects of agile to help us do the successful things “on purpose” and reduce the painful parts of the journey as we mature as an organization.

Enter Conceptual Integrity.

Introducing Conceptual Integrity

To recap: we needed a solution that would…

  1. Ensure that teams operate similarly enough for clarity at the organizational level
  2. Ensure the flow of people between teams wouldn’t be a jarring experience
  3. Offer teams the flexibility to personalize their processes in ways that work best for them

We leaned into the concept of Conceptual Integrity, which is the “principle that anywhere you look in your system, you can tell that the design is part of the same overall design.”

Conceptual integrity is the principle that anywhere you look in your system, you can tell the design is part of the same overall design

To an outside observer, all teams will look generally the same, producing similar artifacts against a similar set of expectations and inputs. Upon closer inspection, you will start to see some variation and individualization. 

It was important that our teams execute in a frictionless environment to allow them to focus on software quality. The real trick would be creating this environment while enabling teams to do the experimentation needed to create world-class, differentiated software. 

That meant that our priority shouldn’t only be implementing consistent human processes and practices, but also fostering some of the great “DevOps” frameworks and behaviors that have grown organically around the organization.

Clearly, there are a lot of moving parts here. 

We knew from the very beginning that we weren't interested in adhering to anything wholesale, but we also didn't want to give up on structure. Agile, or some agile practices, are a good start. From there, we intended to find the meaningful constructs that work for us at any given time, given our unique context and capabilities, and build up the rigor and courage to inspect and adapt as we make progress together.

Simply put: we don’t want to do Agile, we want to be agile.  We want to emphasize agility over rote adherence to some prescribed framework. And we want this to be at the core of our culture and guide our behaviors versus checking boxes on a task list.

That’s why we’re calling this an agile evolution instead of Agile Transformation. A transformation implies that it will be done at some point — and at Ada, we will never be done honing our trade. The business landscape, the team members, the problem sets, the market, all of those things are going to constantly change. We want to be able to build a culture where we can adapt to those changes in stride and continue to improve.

join-ada-engineering-team

Identifying the principles

The first step was to write a set of principles to help guide our decisions. These are the principles we moved forward with:

We work hard, but work is fun

Fun, really? OK, maybe not fun in the traditional use of the word, but frictionless is probably closer to what we are looking to do. Work is work, but when work is low on friction and red tape, people are free to focus on problem-solving and honing their skills. This makes work more fun. We want that.

A Powerful Team is more effective than several Powerful Individuals

Individuals are great! They bring with them experience, creative thoughts, enthusiasm, and viewpoints that contribute to the products that we build. While we appreciate individual contribution, we absolutely cannot sustain a hero culture where knowledge silos develop and roadblocks get introduced. We also can’t sustain individuals who have to consistently work long hours per week to get work done because “they are the expert” in that area. Instead, we want to build an environment where the team executes as a unit, certainly developing specific skills and knowledge, but never so far from the rest of the team that an individual would not be able to take a planned vacation because it was during a push to release a feature where “they were the expert.”

Stop starting and start finishing

This is just another way of saying that we want to focus, we want to limit work in progress, and we want to finish current things before we take on new things.

We bring work to teams, we don’t form teams around work

We put a big emphasis on building out well functioning teams that work well together. When a team begins to execute together, they can execute on problem sets outside of their natural presumed areas of expertise, and they can do so because they know how to troubleshoot and work with one another. What we don’t want to do is to split up stable teams and loosely construct a new team because of perceived skills required to solve a new problem. Teams should remain stable and consistent as much as possible.

The Team is the base unit of measure for everything execution related

Hopefully you are seeing a theme here. Teams work together. Individuals contribute to the team’s work, but only the work produced by the team is consequential. We don’t want to fall into anti-patterns of measuring individual velocity or number of hours to perform a task by an individual. Those concepts are contrary to the philosophy of what we’re trying to put together.

OKRs help us assign our teams to our top priorities

At an organizational level, we want to make sure we assign as many teams to our top priorities as possible. This helps us focus our efforts on the most impactful work for the company, and reduces our inclination to prioritize work because it fits in a team’s wheelhouse. Just because we have a team that can do mobile doesn’t mean that the company requires work in the mobile arena right now.

Establishing the rollout plan

At this point, we’d started referring to our agile evolution as AdaOS or the Ada Operating System. It’s not just computers that have operating systems — organizations do as well, and this is ours. There is an agile component to it, but it’s not a prefabricated framework that we’re forcing our teams into like a square peg in a round hole. 

AdaOS Principles

To start evolving towards a more consistent approach across all of our teams, we decided to take inspiration from Aikido — a Japanese martial art form, also used by agilists the world over — that employs a technique known as Shu Ha Ri

Shu Ha Ri encourages incrementally mastering a technique or skill by going through three phases:

  1. The Shu, or follow phase, is where practices are followed more or less “to the book” 
  2. The Ha, or break away phase
  3. The Ri, or go beyond phase 

For now, we’re focusing on Shu, and to us this meant defining some base practices and prescribing how teams deploy them.

We identified basic Scrum rituals and techniques that we’ll employ according to best practices, and we’ll learn from those practices. The rituals we are deploying now include:

  • Sprint Planning — where the team casts ahead 2 weeks and identifies the package of work they will deliver in that time. The team also strategizes on ways to address that work during this ritual. This happens once per sprint at the beginning of the sprint.
  • Daily Standup — where the team gathers for a short period of time, 15 minutes or less, and individually answers the prompts, “what did I do since last time we talked,” “what I intend to do before the next time we talk,” and “do I need help with anything.” Standups occur daily.
  • Refinement — where the team meets with product management to discuss and size stories, break work into more executable units, and build out a backlog of work for the team to continue working against in the future. Refinement occurs at least once per sprint.
  • Demo — where the team demonstrates the work that they have completed during the sprint. Demos occur at the end of the sprint and can involve other teams and stakeholders, or even, customers!
  • Retrospective — perhaps the most important ritual in the Shu phase, retrospective is a ceremony where the team talks about how they work together and they take on initiatives to improve it. Retrospective is internal to the team and occurs once per sprint, typically at the end.

We’ve also standardized a common 2-week sprint length and sprint schedule — which goes from Thursday to Wednesday 2 weeks later. This gives teams consistency and predictability in their schedules as well as lines up potential dependencies to be executed more efficiently. We’ve also aligned on an estimation approach using Fibonacci story points.

For the duration of the Shu phase, the above rituals and approaches are considered “rigid,” meaning we are asking teams not to deviate from the defined approach until such a time as we have progressed to the Ha phase — which may happen at different times for different ceremonies and rituals. There is a natural tendency to want to change things too quickly, and we want to ensure that we are taking the time to really explore the benefits of the base set of approaches before we abandon it.

Next steps

This post marks the very beginning of this exciting evolution, and we intend to follow up on this topic soon with updates and further musings. 

When you hand good people Possibility (with a capital P), they do great things. At Ada, we are inspired to make our agile evolution a powerful opportunity to try something big, and to try it together. 

Stay tuned for additional posts where we will share our progress, our failures, what impacts AdaOS has had on our teams, and how we are learning from all of the above.

New call-to-action

Brandon Grady, Amy Boss, Janeé McConnell, Stephen Kawaguchi
Brandon Grady, Amy Boss, Janeé McConnell, Stephen Kawaguchi

——— Brandon Grady, Vice President, Engineering ——— Brandon Grady is a technology-focused development leader with a strong software engineering background and a head for Agile development practices. With 25 years of development and leadership experience, he has tackled challenges in a wide variety of domains in the enterprise software space. Brandon has consistently gravitated towards emerging technology challenges, from early projects in the then-new “web space” to more modern DevOps and Microservices efforts.  ——— Amy Boss, Sr. Director of Product Operations ——— Amy Boss focuses on the execution of innovative, strategic and operational initiatives through the product lifecycle, always keeping the voice of the customer in mind. She believes in outstanding digital experiences for everyone, no matter where they are or how they’re interacting. Amy sees all obstacles as opportunities for change, and ultimately, success.  ——— Janeé McConnell, Director, Agile Delivery ——— Janée McConnell is a modern agilist, coach, leader, and teacher at heart, drawing from her experience as an educator to build her agile career. She inspires positive change and surfaces the innate awesomeness of people and teams by helping to expand the application of agile principles and methodologies. Her weapons of choice are relationship building, honesty, creativity, and humor (with a healthy pinch of rebelliousness).  ——— Stephen Kawaguchi, Principal Engineer, Core Apps ——— Stephen Kawaguchi is a technologist with interests in programming, developer craft, and building high-performance development cultures using Lean, Agile, and DevOps practices. Throughout his career, he has been helping teams deliver high-quality software at speed, which has led him to explore many of the stages in the development value stream. You can usually find him wearing several different hats such as technical coach, mentor to all levels of software engineers, software architect, technical strategist, and time-permitting, writing mobile, browser, and back-end code.

Share This Post