Modernizing How You Build, Part 2—Taking the first step

In my previous post, I examined the modern application and highlighted the typical approach used to build modern applications:

1. Shrink the scope.
2. Choose the right tool for the job.
3. Offload the undifferentiated pieces.
4. Connect the building blocks.
5. Automate everything.

AWS continues to build services that make choosing the right tool for the job, offloading the undifferentiated pieces, connecting the building blocks, and automating everything easier. But while microservices and serverless offerings like AWS Lambda help, shrinking the scope requires change within your business to fully become a high-frequency organization.

Products, Not Projects

Many enterprises still approach software delivery by creating and executing projects. These projects assemble a purpose, team, timeline, budget, and scope when created. The projects begin and end on a date. Often, both knowledge and the team disperse upon completion, leaving the operations and upkeep to those relegated to long-term ownership of the project’s output.

Instead, a modern approach forms long-running “two-pizza teams” (a team small enough to be fed by two pizzas, typically 5–10 people), and gives that team full ownership over a product/service/feature/function. At Cox Automotive, these teams also executed on a fixed timeline: for example, two-week sprints. By organizing, planning, and delivering in this way, we accomplished A LOT. We removed several variables in the system and made them fixed: the size of the team, what they work on, how long they have to complete tasks, and, in many ways, the size of the tasks they can tackle in that timeframe (two weeks). When the definition of done means released to production, even if hidden behind a feature flag, we not only further constrain our work, we ensure value is delivered every sprint. Now, you may be thinking “He just constrained and shrunk everything. How is this a good thing and how does it lead to more value?” Well, let’s take it a step further.

In this largely fixed environment, we are left with two variables to manipulate to improve the pace and quantity of value delivery: the number of two-pizza teams we have and what we choose to work on. This model forces us to become good at prioritization, which in my experience is a difficult task for most enterprises. But I would argue that it is the single most important thing we can do for our business: increase the rate at which we weed out bad ideas so good ideas can flourish. When we focus on improving prioritization, we force ourselves to examine several important factors. We tend to ask ourselves:

1. How do we know this will be valuable to our customers?
2. Why is that more important than this?
3. How much is accomplishing this worth compared to that?
4. How will I know when this thing is good enough?

Data is your savior. The fixed variable environment I just outlined is well suited for experimentation. It becomes easy and relatively cheap to spend a sprint or two testing out an idea. If each idea is treated as a hypothesis, we then gather data to confirm or reject that hypothesis. The data should tell us if it is valuable to customers. If it is valuable, we should be able to ascertain its worth.

When data gathering becomes part of everyday practices, teams shift to focus on outcome-oriented development. Agile and iterative development practices are founded on the idea that scope and solutions emerge, they are not known or understood upfront. Outcome-oriented development allows you to focus on the problem you are trying to solve in terms of the desired outcomes.

Consider the problem statement: As a traveler with a family, I need a reliable, cost-effective, clean mode of transportation that feels safe and familiar. That problem statement makes me think of Uber or Lyft almost immediately. But, before they existed, the primary solution was to drive your own car, rent a car, or pay extra for a car service, because in my experience, taxis fall short in several areas.

The outcomes that teams could focus on might include: number/percentage of repeat users of the transportation service, number/percentage of users using the transportation service in multiple cities, user satisfaction with cleanliness, user satisfaction with the transportation service operator, and number/percentage of times users fail or wait long periods of time to obtain transportation. None of this implies scope or a solution, it simply takes the problem statement and sets measurements against key indicators that the problem has been solved. You will know you have sufficiently solved a problem when the outcomes you defined are satisfied and your customers see value in how you solved their problem.

Microservices

Now, consider that delivery environment paired with microservices: an independently scalable and deployable unit of functionality that can be owned and operated by a single small team. While you do not need microservices to achieve success with two-pizza teams, by evolving your architecture to create hardened contracts, APIs, between your data and data consumers or around your business logic, we can introduce further autonomy and agility. These microservices can change independent of their consumers, as long as they uphold their contract. Delivery can accelerate because change sets are now smaller, isolated, and you have created a smaller blast radius…the impact of failure has also shrunk. Microservices typically have their own code repository, delivery pipeline, and monitoring and operational support. This means teams can evolve and iterate on their microservice on their own timeline. Often, the need for coordination between teams also decreases. This allows teams to move more quickly, delivering value more often.

Taking the First Step

The approach I just outlined is a journey. No one goes straight from projects to outcome-oriented development…or if they have, I have yet to hear about it!

The first step is quite simple. Identify a product/feature/service/function that can be isolated and given to a small team to own. Form that team from your existing staff and work to fine tune your Agile development practice, which will be difficult. It takes time to figure out how to break down tasks such that they can be delivered (released to production) in a two-week period.

During this timeframe, you will also begin the difficult task of prioritizing work. You will soon have a fixed-size, two-pizza team that owns a product/feature/service/function, operating on a fixed timeline. Tasks are small, the number of tasks that can be delivered every two weeks is roughly fixed, and you are prioritizing work on a regular basis.

Congratulations! You have officially begun your journey. When I started this journey the first time at Dealer.com (we subsequently rolled out Scaled Agile Framework at Cox Automotive as well) back in 2012, I had an experienced Agile development transformation lead by my side helping me and my team become servant leaders. I’d encourage you to find someone to partner with who can help guide you on your journey.

Modern applications leverage modern approaches to people, process, and technology. AWS offers a breadth of services with APIs designed for automation, and AWS is innovating at a rapid pace. Implementing Agile development practices alongside your cloud journey helps you begin to tackle the people and process components that will allow you to build modern applications. Keep reminding yourself that this is a journey. While there is no end date there is a start date, start now!

Bryan Landerman
Enterprise Strategist & Evangelist @ AWS
@bryanlanderman
brylando@amazon.com