The Art of Agile Development

by James Shore

On the other hand, vertical scaling solves one of the major problems when scaling Agile: creating cross-functional teams. Agile teams need people with specialized skills, such as UX design, operations, and security. If your teams have only six or seven people each, it’s hard to justify including people with those skills on every team. But then you run into an allocation problem. How do you make sure each team has everyone it needs at the time it needs them?

The secret to successful horizontal scaling is how you allocate responsibilities to teams. The fewer cross-team dependencies, the better. It’s fundamentally a question of architecture, because the responsibilities of your teams need to mimic your desired system architecture. (This is also called the Inverse Conway Maneuver.)

After the demo, it’s time for your weekly team retrospective. It’s an opportunity for your team to look at your practices, team dynamics, and organizational roadblocks to experiment with possible improvements. Your monthly demo cadence was the result of one of those experiments.

Broadly speaking, these skills can be grouped into customer skills, development skills, and coaching skills.

In contrast to product management, which involves spending a lot of time with stakeholders, domain expertise requires spending time with the team. Most of that time is spent figuring out the details of upcoming work, creating examples of complicated rules, and answering questions about the domain.

The fast, iterative, feedback-oriented nature of Agile development leads to a different environment than UX designers may be used to. Rather than undertaking an up-front user research phase, UX design is performed iteratively, alongside the iterative refinement of the software itself. Agile teams produce software every week or two, which gives designers the opportunity to take real software to users, observe their usage patterns, and use that feedback to guide the team’s plans.

On a Delivering team, people with testing skills help the team produce quality results from the beginning. They apply their critical thinking skills to help customers consider all possibilities when envisioning the product. They also act as technical investigators for the team, helping the team identify its blind spots and providing information about nonfunctional characteristics such as performance and security.

Unlike most teams, testing on a Delivering team doesn’t involve exhaustively testing for bugs. Instead, the rest of the team is expected to produce nearly bug-free code on their own. When a bug does slip through, the team changes its habits to prevent those types of bugs from occurring in the future.

Operations skills also involve helping the team stay on top of production realities: planning for production needs such as security, performance, scalability, monitoring, and management; creating an equitable pager duty rotation (when needed); and helping to analyze and prevent production incidents.

People with coaching skills help teams learn how to be effective Agile teams. They teach practices, facilitate discussions, guide self-organization and team development, and show the team how to work with managers and other business stakeholders to get the investments it needs.

The job of these coaches is to help the team become independently fluent, so team members are able to perform the skills they need without the participation of a coach. That doesn’t mean the coach leaves the team, but it means that they could, and if they stick around, they gradually transform into a regular member of the team.

Even after a team becomes independently fluent, it’s helpful for an experienced coach to join the team once in a while—say, every year or so—to help the team try new things and remember forgotten practices.

Teams need coaching in up to four categories, depending on which fluency zones they’re pursuing. This might require more than one coach. Team development, self-organization, and facilitation (all teams) Focusing zone planning and teamwork practices Delivering zon...

Experienced facilitator-coaches can work with one or two teams simultaneously. One downside of facilitator-coaches is that they don’t contribute a lot to day-to-day development, which can lead organizations to see them as underutilized and assign them to too many teams. But then they’re not present to see and respond to team challenges. Coaches in this situation often end up as glorified meeting organizers, which isn’t a good use of their talents.

When choosing team members, be sure they’re willing to help out with tasks outside their specialty.

I consider most teams who I work with to be on a journey changing from “programmers” to “product developers.” Which means the team (whole team!) deeply understands the customer and customer domain rather than depending on someone to clarify for them and hand-off the result of that clarification. Yes, I love to have people with deep customer knowledge on my team, but mostly with the goal of helping the entire team to improve.

Teams that don’t use pairing or mobbing should have 3–5 programmers. As they grow larger, they’ll start to have trouble coordinating. Teams that pair program should have 4–10 programmers. Six is the sweet spot. Teams new to Delivering practices should avoid growing past 6–7 programmers until they have more experience. Teams that mob program should have 3–5 programmers. You can mob with much larger groups—it’s a great teaching technique—but you reach a point of diminishing returns.

But keep in mind that customers have a lot of work to do. They need to figure out what provides the most value, set the appropriate priorities for the work, identify all the details that developers will ask about, and fit in time for customer reviews and examples. They need to do all this while staying one step ahead of the programmers, who—especially on Delivering teams—are right behind them, crunching through work like a freight train. It’s a big job. Don’t underestimate it.

Team members aren’t necessarily equal—everyone has different skills and experience—but they are peers. It’s smart for junior team members to seek out more experienced team members for advice and mentoring. It’s also smart for senior team members to treat everyone with respect, to create collegial relationships, and to help junior members grow by stepping back so they can take the lead.

Many Agile organizations form “communities of practice” around functional specialties. These may be led by a manager, a centralized support team, or just interested volunteers. They’ll typically hold a variety of events to provide training, socializing, and other opportunities for developing those skills.

When you have a whole team: Your team is able to solve problems and fulfill its purpose without waiting for people outside the team. People on the team work outside their specialty to prevent bottlenecks from slowing the team down. Your team is able to make decisions smoothly and effectively. People on the team seamlessly switch leadership roles from task to task.

Further Reading The Wisdom of Teams: Creating the High Performance Organization [Katzenback2015] is a classic about high-performance teams. Agile Conversations [Squirrel2020] is an excellent resource for coaches who are helping their teams and organizations develop an Agile culture.

If you’re stuck on a problem and somebody on the team knows the answer, ask them to help. There’s no sense in banging your head against a wall. To support this, many teams have a working agreement: “We always help when a team member asks.”

The best way to prevent questions from being disruptive is to use pair programming or mob programming. With pairing, one person answers the question while the other keeps thinking about the problem at hand. When the interruption is over, a quick “Where were we?” gets things moving again. With mobbing, interruptions are even less of an issue; they tend not to happen in the first place, because everyone’s working together. When they do, the person being interrupted just steps away while the rest of the mob keeps working.

Similarly, if it turns out that the discussion isn’t relevant to you, you don’t have to stick around. You can go back to your work. It’s called the Law of Mobility: “At any time, if you are neither learning nor contributing, move yourself to a place where you are.”

Remote teams have the opposite problem: it’s too hard to overhear other people’s conversations. Once a conversation begins, it’s usually most effective to take it out of the group chat and into a videoconference. But then nobody can overhear what’s being discussed. So consider putting occasional updates in the group chat so people can decide whether they want to drop in.

One of my favorite ways of working simultaneously is simultaneous brainstorming. In simultaneous brainstorming, someone asks the group to come up with ideas relating to a topic, just like normal brainstorming. When somebody thinks of an idea, they say it out loud, write it on an index card, and put it where everyone can see. (One idea per card, for ease of sorting later.) Saying it out loud inspires other people to have new ideas, and writing the idea down yourself prevents the group from bottlenecking behind a note-taker.

Sometimes I’ll follow simultaneous brainstorming with affinity mapping. To make an affinity map, take all the cards your group brainstormed and spread them out randomly on a table or virtual whiteboard. Then move the cards around so the ideas that are most similar are closest together, and the ideas that are least similar are farthest apart. Everybody works at the same time, moving cards as they see fit. In the end, the cards should end up forming clusters that you can name.

Instead, use a consent vote. In a consent vote, somebody makes a proposal, then everybody votes “I agree” (thumbs up in person, “+1” in group chat), “I’ll go along with the group” (thumb sideways or “+0”), or “I disagree and want to explain why” (thumbs down or “–1”). To avoid accidentally pressuring people, you can optionally have everyone reveal their vote on a count of three.

When you notice a discussion drifting into speculation, propose a concrete experiment. For example, Extreme Programming includes the “ten-minute rule”: when a pair argues about a design direction for more than ten minutes, they split up, each write temporary code illustrating the design idea, and then compare results.

In a virtual environment, anything can be recorded. Establish clear guidelines about when it’s okay to record or share a conversation.

Create a “wall.” In an in-person team room, information that everyone needs to see or remember is posted on the wall. For your remote team, consider creating a small number of shared documents to store the same sort of information.

Team members need to share a set of core hours to collaborate effectively, even if they’re remote. If team members are so widely dispersed that shared hours aren’t possible, you actually have multiple teams, and you should design your work accordingly.

We share conflicting viewpoints without fear.

In 2012, Google launched Project Aristotle, an internal research effort intended to identify why some teams excelled and others did not. Google looked at a number of factors: team composition, socialization outside of work, educational background, extroversion versus introversion, colocation versus remote, seniority, team size, individual performance, and more. None of them made a significant difference to effectiveness. Not even seniority or individual performance. What mattered? Psychological safety.

One of the big benefits of safety is that it creates space for everyone’s voices. By feeling safe, team members speak up, disagree, suggest new ideas, bring up problems, and in general bring in options. It doesn’t mean all ideas are implemented; it means that your team has considered more options before making a decision—options you might not otherwise see.

Instead, if you notice people suppressing their opinions, ask them to share. If people seem to be indulging in false harmony, ask them about the downsides of an idea. If you see a problem that no one else mentions, bring it up, in a kind way.

The money for your team comes from somebody’s budget. They’re typically called the team’s executive sponsor. Although the sponsor technically has final say over the team’s purpose, it’s not always so cut and dry. They’re influenced by a variety of people, called key stakeholders, whose support is also necessary for your team to succeed.

Like the children’s game of telephone, every step between the product manager and the key stakeholders reduces their ability to maintain and promote the team’s purpose.

Product managers, as you talk with the sponsor and key stakeholders, refine their ideas into a draft purpose document. The goal of your conversations is to create alignment about what the team should work on, why it’s working on it, and what success looks like. Your purpose document is a living document that reflects that joint understanding. You’ll revise it regularly.

Some companies like to use Key Performance Indicators (KPIs) or Objectives and Key Results (OKRs).

Once the purpose is ratified, make it a constant touchstone. Use it to evangelize the team’s work to stakeholders. Refer to it when explaining your plans and priorities. Post a copy prominently in your team room, and refer back to it in planning sessions.

The team’s purpose will change over time. Indicators will age out and the team will learn new things about its stakeholders, customers, and market. Eventually, you’ll need to update the purpose. It’s a living document. Set a specific time to revisit and revise the purpose. Every three or six months is a good idea.

When you’re ready, ask participants to use simultaneous brainstorming to create a sticky note for each stakeholder group that your team needs to interact with. Think very broadly: everyone who affects or is affected by your team’s work, either positively or negatively. That includes software teams that your team interacts with, including teams that own systems that your software will communicate with; other groups within the company, such as Marketing, Sales, and Operations; groups outside the company, such as your customers, competitors, and suppliers; and even groups further afield, such as government regulatory bodies.

Agile teams avoid calling people “resources.” It’s dehumanizing. By resources, I mean things like time, money, goods, and services.

remember that sponsors have to make difficult trade-offs. They’re often stuck with a choice of two bad options. Sponsors own the team’s budget, yes, but their resources aren’t unlimited. Sometimes they have to make a tough choice between giving a team everything it asks for, and making a bet that the team will be resourceful enough to deliver even without it.

To create your team’s working agreements, start by sharing stories of other teams you’ve worked with. Describe how they worked together, either good or bad. You can do this in round-robin order, or just randomly, according to who wants to talk next.

As people share their experiences, pause to make a note of potential working agreements. They can be anything: behavioral standards, such as, “We don’t interrupt when people are talking;” specific practices, such as, “We use pair programming for all production code;” work habits, such as, “When we change tasks, we drop a note in the group chat;” and more. Include anything that will help your team work together better. Don’t critique the suggestions yet; just collect them.

The practices your team will use. I recommend starting with every practice in your team’s chosen zones. For remote teams, how you’ll communicate. (See “Designing remote collaboration”.) How you’ll make decisions. For in-person teams, how you’ll deal with distracting background noise. For teams that don’t use pairing or mobbing, how you’ll ask for help without being disruptive. (See “Always ask, always help”.) The core hours when you can expect people to be available.

To that end, use these two guidelines to define your standards: Create the minimal set of standards you can live with. Focus on consistency and consensus over perfection.