Agile for Everybody

Chapter 4. Agile Means That We Collaborate Early and Often

The idea of working in small, cross-functional teams is central to several Agile methodologies. But, as with many other Agile practices, it is much easier to approach this as an operational change than as a cultural change. In far too many cases, organizations simply add a few dotted lines to the org chart or implement an open-office plan without really thinking through why cross-functional collaboration is valuable to the organization and its customers, and what has impeded it in the past.

And therein lies the greatest challenge of this guiding principle: just because people are on a team together or in a meeting together does not necessarily mean that they are collaborating. True collaboration requires openness, vulnerability, and the willingness to share ownership over ideas. It requires asking a question before you know the answer and being prepared to receive an answer you did not expect. It is something that does not come easily for most organizations, no matter how much time people spend in meetings.

This is why our second guiding principle is to collaborate early and often, both within and beyond our teams. Collaborating early means that we collaborate during upfront strategic conversations as well as downstream tactical ones, opening up the possibility of discovering new and unseen solutions. Collaborating often means that we continue these conversations throughout the process of creating and delivering, ensuring that strategy and tactics remain aligned and giving us more opportunities to adjust course as needed.

For organizations in which collaboration between particular groups is a well-understood problem, describing the specific silos across which we need to work more closely is one way to specialize this principle for your particular needs. You might want to say, for example, “We collaborate across functional roles,” or “We collaborate across product teams.” For some organizations and teams, it might also be worth explicitly denoting what we mean by collaboration. For example, “We collaborate early and often by sharing works-in-progress and asking questions before we know the answer.” Again, it is important for you to find the framing that speaks most directly to your own organization’s needs and goals.

Escaping the Second Law of Organizational Gravity

At times, the lack of connection and collaboration in even the most well-intentioned organizations can seem bewildering. Even when collaboration is codified in a company’s mission statement or operating principles, people still tend to default to working only with the people in their immediate orbit.

I call this the Second Law of Organizational Gravity (Figure 4-1): individuals in an organization will prioritize the work that they can complete most easily within the comfort of their own team or silo. As with all our laws of organizational gravity, this is a force that is rarely named or seen in the open, but one that has an enormous impact on the way that modern organizations work.

Figure 4-1. The Second Law of Organizational Gravity: Individuals in an organization will prioritize the work that they can complete most easily within the comfort of their own team or silo. Note how the gravitational field at the lower right pulls members of a single team closer to each other and farther away from their colleagues elsewhere in the organization.

The reasons why individuals might choose to prioritize the work that requires the least support from outside their team or silo are not terribly difficult to grasp. Imagine that you are on the hook for delivering something that your boss has demanded be completely finished by a certain date at a certain time. You know that your deliverable would be stronger if you got input from different teams—but you also know that the people on those teams likely have their own priorities, their own objectives, and their own deadlines to worry about. Even worse, they might undermine your work—or take credit for your work if it succeeds! Simply put, venturing outside of your own team or silo is risky, and minimizing risk is a successful strategy in most modern organizations.

In many ways, Agile is designed to harness the power of this gravitational force by creating empowered, autonomous, and cross-functional teams.  If your immediate team consists of everybody whose work is required to create a successful customer experience, the work that is most important to your customers is more likely to be prioritized. In practice, however, it is rarely either possible or advisable for a team to actually include every single person whose work touches a given product or project. And so the need to create a culture of collaboration across teams and silos persists even when an organization has formally reorganized itself into small, cross-functional teams.

It is often when organizations facilitate collaboration across their most disconnected and far-flung teams that they are able to achieve the most impressive results. Jodi Leo, an experienced UX practitioner and educator who has worked with organizations like Nava PBC, Apple, Google, and the New York Times, described to me how a financial services company was able to meet an impossible-seeming deadline by connecting its product and compliance teams:

In November of 2014, we had the opportunity to create one of the first apps for the Apple Watch, which would be featured in Tim Cook’s keynote. That’s not the kind of opportunity you can pass up. But this seemed like a nearly impossible task—we had 120 days to create something for a brand-new platform, and we didn’t even have an app for the iPhone yet. The message from executives was clear: we don’t care what mountains you need to move, we want you to make this happen.

Miraculously, we got it done on time—and, beyond that, it was a great bonding experience for everybody involved. One main reason for this is that we were able to move a mountain that has not been moved before or since: we had compliance officers actually sitting on the floor with us. In the past, compliance had always been seen as the rarified team who said “no” and made our jobs more difficult at the last minute. But our relationship with them was very different when they were actually part of the team. They were there with us reviewing designs before we sent them to code, and about 50% of the time they would be able to find a workaround that maintained the integrity of the user experience. Having them there with us made such a big difference, and made such a clear case for the importance of collaboration.

This example illustrates just how critical it is that we collaborate early and often across even the most entrenched and calcified silos in our organization. When we engage people such as lawyers and compliance officers early enough, we have the opportunity to explore multiple solutions before we have finalized something to which they can only say “yes” or “no.” This allows us to better understand and internalize the underlying rules and regulations that guide their decisions, which in turn minimizes both the time needed for costly regulatory review and the time needed to rework anything that fails such review. This is one example of how time invested in collaboration across functions and teams can yield tremendous long-term returns.

Moving from a Report and Critique Culture to a Collaborative Culture

In far too many cases, people interested in bringing Agile to their teams or organizations feel that increasing collaboration is not possible without a formal reorganization, whether it is the reshuffling of individuals from functional teams into cross-functional teams, or the establishment of a multitiered cross-functional system that operates on the “squad,” “tribe,” “chapter,” and “guild” level (often called the “Spotify model”). Mayur Gupta, VP of growth and marketing at Spotify, described to me how even the Spotify model is less a question of org charts, and more a question of culture:

When people refer to the Spotify model, they’re usually talking about guilds, tribes, and chapters. But those are just rituals. I don’t believe that you break down barriers by changing reporting lines. When you have a truly cross-functional team, reporting lines become irrelevant. The way you run the business, and the way you solve problems, inherently has to be done cross-functionally.

As you keep going through your life and career, you realize that what truly drives these changes is the culture. That to me is paramount—the culture of your organization. The culture of how you grow individuals, how you inspire your employee base, how you recognize your employee base. That culture becomes truly cross-functional when you are agnostic of where you sit, and when you start to recognize collaboration as opposed to individual heroism. At the end of the day we all want to be recognized for the work we do. If recognition operates in silos, or is only given to individuals, then that’s how individuals will seek recognition. We need to recognize teamwork and we need to acknowledge teamwork.

Even for Spotify itself, a successful implementation of the Spotify model has less to do with the specifics of the frameworks and reporting structures the company has adopted, and more to do with the culture that it has cultivated. For many organizations, there is a fundamental—if often unspoken—belief that working together is simply a waste of time and efficiency. Even when these organizations adopt Agile practices, they have a difficult time imagining what a more collaborative culture might look like beyond “more meetings.” For these organizations, a fundamental cultural shift must take place: the shift from a report-and-critique culture to a collaborative culture.

A report-and-critique culture is one in which teams and functions do their own work and then hold meetings to tell other teams about that work. Those teams, in turn, are only able to offer inputs on something that has already been completed, resulting in contributions that feel more like critique than collaboration. For many organizations, this is the sum total of what “meetings” across teams and functions represent. Table 4-1 demonstrates how a report-and-critique culture is very different from a truly collaborative, Agile culture.

Table 4-1. Report-and-critique culture versus collaborative Agile culture

Report-and-critique culture	Collaborative Agile culture
Meetings are a chance to present work that has already been completed	Meetings are a chance to share ideas and make decisions about works in progress
Interaction with people from other teams or functions is inefficient and to be avoided unless there is an immediate tactical dependency to be resolved	Interaction with people from other teams or functions is seen as a way to get out ahead of potential future dependencies and conflicts
Each team has distinct—and at times conflicting—goals	Each team’s goals are aligned under overall company and customer goals
Team divisions and chains of command are absolute and unchanging	Team divisions and chains of command can be reorganized temporarily around project needs

Some organizations develop a report-and-critique culture as a reaction to misaligned goals and incentives between teams. For example, one team might be held accountable for the number of new customers acquired through marketing efforts, while another team is held accountable for the average revenue earned per customer. As the first team casts a wide net and brings in low-value customers, the second team’s success metric suffers. The resulting mistrust stifles collaboration and makes it all too easy for either team to blame the other if they fail to reach their respective goals.

More commonly, a report-and-critique culture emerges when individuals only reach out across teams and silos when there is an immediate, tactical dependency to be resolved. This perpetuates the belief that other teams exist only to derail or complicate your own team’s work, leaving ample room for misunderstanding and little room for true collaboration.

Finally, a report-and-critique culture is often a simple product of the fact that people will generally prefer to share things that are finished, polished, and impressive—especially when sharing with people who might not be immediately familiar with the quality of their day-to-day work.

Shifting from a report-and-critique culture to a collaborative culture is no easy feat and, as with the adoption of Agile principles in general, more of an ongoing journey than a finite transformation. But at its heart, this shift involves giving people the opportunity to experience collaboration as something that will help them achieve their goals, not something that will delay or derail them in achieving those goals. Often, the best way to accelerate this shift is simply to begin reaching out to people from other parts of your organization and learning more about their particular goals and objectives—before you need something from them or have something finished and polished to share with them. Alan Bunce, a consultant and former marketing leader at organizations like IBM and Salesforce.com, described to me how he was able to create a more collaborative culture by encouraging one-on-one relationships between individuals across functions and silos:

At one company where I worked, we had these weekly or biweekly product marketing and product management meetings. All 10 of our product managers, and all six of our product marketers, attended every meeting. There was always an agenda, and it was always useless. These meetings were torture, and you never really got anything out of them.

I try to avoid having those big meetings where there’s an agenda and somebody presents. At the next company where I worked, I agreed with my counterpart, the head of product management, that what we really needed was to develop strong one-on-one relationships between product marketers and product managers. You shouldn’t need to wait for the next meeting. You’re talking to each other informally all the time.

Note that many practitioners I have spoken to have a very different perspective about meetings without formal agendas. This, again, illustrates how different teams and organizations will need to take different steps to move toward a truly collaborative culture. If, for example, your team is struggling with disorganized meetings that don’t offer any clear value, using formalized agendas to structure space for collaborative decision making might be an important step forward. If you are working in an organization in which formal agendas are reinforcing the perception that something must be finished and polished before it can be shared, you might take a very different approach.

In either case, there are always opportunities to look beyond transactional and structured meetings and create more space for informal communication. It is often through these conversations that individuals from different teams discover opportunities to work together toward a shared set of goals.

The Room Where It Happens

Many organizations seek to instill the Agile value of collaboration by creating open and flexible floorplans, sometimes called Agile zones or, in some cases, Agile cities. As a rule, you need not spend too much time in one of these zones to determine whether its energy matches its title. Some Agile zones buzz with interaction, creativity, and collaboration. Others are tense, stifled, and permeated by the palpable discomfort of individuals desperately vying for any crumbs of personal space.

The difference has less to do with the spaces themselves, and more to do with the teams that inhabit them. For teams that are used to working in a synchronous, face-to-face way, an open Agile zone can be an ideal working environment. But if a team communicates primarily via asynchronous email threads, Google Docs comments, and PowerPoint presentations, an open Agile zone is at best irrelevant and at worst enormously distracting.

These asynchronous methods of communication have become the default for many teams, including teams that are entirely colocated. In many cases, working this way just seems easier; shooting off a quick email or tagging someone in a Google Docs thread doesn’t take much time at all, and it certainly feels like a less onerous task than throwing yet another meeting on people’s already-packed calendars. And yet, each of these actions incurs a cascading cost of time and attention that is often difficult to see and measure. Sure, it does not take long to add a few more people to an email thread or to pop a few comments in a document to show that you’re paying attention. But for the people receiving those emails and comments, this can add up to a mountain of ambiguously prioritized busywork detached from clear goals and outcomes.

This dynamic often results in a lot of time being lost without a lot of decisions being made. And when you’re on an email thread with 20 other people, it can be difficult to know what a “decision” even is. Does everybody need to agree? Is the lack of feedback an implicit sign of approval? This lack of clarity often makes it particularly difficult for a team to move forward with any kind of work that requires input from multiple people.

When I started researching this book, I was bowled over by a brief case study in Scott Brinker’s Chief Marketing Technologist blog about Coca-Cola applying Agile principles to its 2006 FIFA World Cup campaign (and refining and extending their approach in subsequent World Cup campaigns). To summarize, Coca-Cola was developing the campaign with two different agencies, one for design and one for technical implementation. These two agencies had once been part of the same agency and did not enjoy a particularly harmonious working relationship. To get things moving, the folks at Coca-Cola invited representatives from these agencies to sit in a room together and develop a plan collaboratively. The conversations themselves were not always easy, but the outcome was fairly miraculous: a giant global ad campaign finished just ahead of schedule. As they refined their Agile approach for 2010 and 2014, they were able to deliver increasingly sophisticated campaigns well ahead of schedule.

I had the chance to chat with Thomas Stubbs, who led Coca-Cola through that particular Agile initiative and continues to push the organization toward embracing more Agile ways of working. He described to me how taking this “hothouse” approach has helped his teams collaborate more closely and hit their deadlines:

We’ve operated under the very simple principle that we’re not going to communicate over email and PowerPoint presentation; we’re going to put the designers and the technical folks into a room with the business owners and let them do their work. I’ve always called it a “hothouse” approach, and I’ve been using it since before I knew anything about Agile. Putting the right people together, we are able to make decisions and make progress really fast.

It’s also much harder to create negative working relationships when you sit in the room with someone and figure something out. There are boundaries of civility that generally apply to how you will interact with the person who is sitting across from you. Email, meanwhile, can become a passive-aggressive medium when misused—making it possibly the worst tool for Agile ever invented. The wrong people can be copied, and people who don’t need to be copied are sometimes copied. And even the people who should be copied get a lot of things they don’t need to see. Beyond that, people’s ability to perceive and deliver content and context is challenged over email. In situations where we need to make decisions and move fast, PowerPoint and email slow progress.

I don’t think there’s a neat formula for who should be in the room. Decision makers should be there, and team leaders trusted by the people who aren’t in the room, for sure. There’s also certainly a number at which gathering people in the same room becomes unwieldy and doesn’t work so much anymore. I don’t know what that number is, but when you start getting north of 10, you’ve got enough conversations and chaos in a small place to make things difficult. We did have it north of 10 for the Brazil World Cup campaign—which, in retrospect, was probably too many. But we still made it work. And we still managed to get 18 months of work done in six months’ time.

As this example illustrates, sometimes just putting people in a room together—even if it’s too many people and even if it isn’t exactly the right people—is enough to make significant progress. Here are a few steps you can take to get in the habit of making decisions “in the room”:

Decide what you are going to decide

To make sure that the time people spend together is impactful, get out ahead of thinking through what decisions you’re actually hoping to make in each synchronous meeting. Resist the urge to punt on these decisions and send things around for asynchronous feedback when the meeting is over, which often becomes a huge time-suck and, as Thomas Stubbs suggested, opens up lots of room for miscommunication and hurt feelings. If the group gets stuck trying to reach a “perfect” decision, try asking the question, “Would our current decision leave us in a better position than the one we are in right now?” If the answer is yes, commit to your decision in its current form, and commit to reevaluating that decision at an agreed-upon time in the future.

Practice time-boxing

One idea that informs multiple Agile practices is that of time-boxing, or establishing an absolute upper bound to the amount of time allotted for a given meeting. The first couple of times a team actually enforces a time box, it usually does not go that well. Critical decisions are left unmade, the most talkative people in the room go off on tangents, and everybody leaves feeling defeated and confused. But by the third or fourth time-boxed meeting, there is usually an appreciable change. Once people actually believe that a meeting will end within a given timeframe, they are much more inclined to prioritize the conversations that will help that meeting achieve its intended purpose. They are also much less likely to resist synchronous meetings out of fear that such meetings will go on forever and produce no tangible result.

Set expectations clearly

Regardless of whether you have a formalized agenda for a meeting, it is always helpful for people to know why you are asking for their time in the first place. Beyond being clear about the decisions you seek to make, it is helpful to tell the individual people you are inviting why their particular perspective is important and valuable to you. This makes it clear that you are actively looking for their input and collaboration rather than simply checking a box that corresponds to their role or team.

Don’t call it a meeting!

For many modern organizations, “meeting” is nothing short of a dirty word. Though it might seem trivial, using a term like “hothouse” or “summit” can constitute an appreciable step toward helping people overcome the self-fulfilling belief that anything called a meeting will be a waste of time.

Disentangle “synchronous” from “colocated”

For remote and distributed teams, finding ways to work together “in the room” can be particularly challenging. But it is helpful to approach this challenge by clearly differentiating synchronous work from colocated work. Once this distinction has been made, it is much easier to ask questions like, “What kinds of decisions should we be making synchronously?” and, “How will we use asynchronous channels like email and document comments in a way that helps us achieve our goals?”

For teams of all kinds, drawing attention to the differences between synchronous and asynchronous modes of communication can open up space for more people to participate meaningfully in the process of making decisions, which in turn fosters a greater sense of shared accountability. Even though sending a PowerPoint deck around to 50 people and asking for feedback might feel like the easiest way to get something done, it is definitely not the most collaborative—or the most efficient.

Making Connections to “Scout and Scale”

Knowledge management can be a huge challenge for large and small organizations alike. As priorities shift and personnel turns over, there is a substantial risk of lessons that have already been learned going unheeded, and work that has already been done being redone. Embracing the guiding principle of collaborating early and often gives us one important step that we can take to reduce these risks: asking our colleagues what has already been done and by whom before we rush to executing new work within our particular team.

Embracing this approach allows us to take a broader view of our overall goals and shine a bigger and brighter light on the things that are already helping us to meet those goals. Shift7 CEO and former United States CTO Megan Smith described to me the scout-and-scale approach that she used successfully to address big, challenging problems in the public sector:

In my work with the government and my work with Shift7, I have cultivated a scout-and-scale approach, which is to say, I don’t build stuff, I find the people who are building it and connect them. The way to get to the future is solution making through inclusion, and the first step is often just asking, “What have you already got? Who already solved this problem?” It’s usually multiple people, and we can connect these people to resources and to one another to scale these solutions. It’s a systems-level intervention, very much in line with Agile principles.

Smith explained that her approach was inspired largely by venture capital firms, who she observed take two critical steps to catalyze their investments: “finding and supporting what works (or is promising)” early and often, and “networking their networks” to accelerate that positive momentum. In a blog post titled “Try this at Home: Scouting local solutions and scaling what’s working” published by the Obama White House, Smith and her former White House colleagues Thomas Kalil and Aden van Noppen describe how Smith’s scout-and-scale approach was used to address issues ranging from smart cities to police data access to Science, Technology, Engineering, and Mathematics (STEM) education:

Creative, committed, passionate people are solving challenges in their local communities. We can accelerate progress in more places by scouting to find these creative solutions or solutions-in-progress to tough problems that already exist. To scale, find, and share solutions with others working on the same challenges, use the Internet, and bring teams together.

Just as individual cities might have already made significant progress on a problem that is vexing a national government, individual teams often have firsthand knowledge of important business problems and opportunities that can be of great value to the organization at large. Connecting these teams with a scout-and-scale approach speaks directly to the value of visibility and collaboration between teams, and reinforces the idea that these teams are working together toward the same goals. It also provides organizational leaders with an opportunity to give credit and recognition to folks who might be outside of their immediate orbit.

Here are a few steps that every organization can take to implement a scout-and-scale approach to their work:

Get in the habit of asking what work has already been done and who is doing it.

In every organization, there is some degree of “tribal knowledge” that people share informally but is not captured in a permanent or easily retrievable way. One of the best ways to capture this knowledge is to dispel the assumption that if we haven’t heard about something, it doesn’t exist. Get in the habit of asking what’s already been done and by whom. Questions like, “Have we tried this before?” or, “Who else in the organization is thinking about this same issue?” and even, “Are others outside our organization doing something relevant?” are great places to start.

Let your customer be the bridge between silos, products, or projects.

When scouting solutions from across the organization, don’t forget who you’re solving for. Keep customer goals and needs front and center, and you might discover unexpected opportunities to better serve your customers by making connections across functional or project-based teams. Ask teams and individuals to share the customer insights that led them to their particular solutions, and let those insights lead the way as you look for opportunities to connect and scale the work that has already been done.

Network your networks!

One powerful way to put scout-and-scale into practice is to provide your colleagues with multiple forums to share knowledge across teams. Drawing from the Spotify model, this might involve creating guilds in which people from across functions can share knowledge about common interests ranging from coffee to proprietary data analysis tools. Or, drawing from the Scrum framework, this might involve regular meetings in which “ambassadors” from each project team share their progress.

Have a shared language like “scout-and-scale” that speaks to the power of collaboration beyond squishy and easy-to-dismiss terms.

Simply saying, “We should all collaborate with each other more” is often not enough to drive action. As we discussed in Chapter 2, it is critical that you frame the idea of collaboration in language that your organization will understand and accept. Scout-and-scale provides a great template (and, if you are so inclined, some off-the-shelf language) for how you can use more specific and catchy language to generate interest in collaboration.

When we begin by asking what is already working, we give ourselves the opportunity to put more resources behind the solutions that are meeting the goals and needs of our customers. Adopting a scout-and-scale approach is one way that collaboration can break us out of the company-centric assumption that our first step should be to pitch a big project, secure a budget, or build something that will impress our colleagues and managers.

Agile Practice Deep Dive: The Daily Stand-Up

The daily stand-up, or daily scrum, is the first step that many teams take toward adopting Agile practices, and with good reason. This daily meeting provides a regularly scheduled opportunity for members of a team to align around their respective progress and their shared goals. And because it clocks in at under 15 minutes, the daily stand-up can usually be fitted into a team’s existing schedule without feeling like an unreasonably large or disruptive ask.

The rules of the daily stand-up are fairly straightforward: every day, each member of the team stands up and shares information about the work they’re doing as it relates to the team’s goals. The entire meeting is to take no more than 15 minutes—a strict constraint that is reinforced by the fact that nobody is sitting down! Within the Scrum framework, each member of a team is tasked with answering these three specific questions:

• What did I do yesterday that helped the Development Team meet the Sprint Goal?

• What will I do today to help the Development Team meet the Sprint Goal?

• Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

For teams that are neither developing software nor working in sprints, these questions are often abstracted to the following:

• What did I do yesterday that helped the team meet its goals?

• What will I do today to help the team meet its goals?

• Do I see any impediments that prevent me or the team from meeting our goals?

Many teams abstract this even further, simply asking its members, “What did you do yesterday, what will you do today, and do you have any blockers?”

The daily stand-up can seem almost trivially simple, but it provides a hands-on introduction to some very powerful Agile ideas. First, it provides a relatively low-stakes way to introduce the practice of time-boxing. For many teams, it is unheard of for a 15-minute meeting to actually take 15 minutes. Once teams are accustomed to holding properly time-boxed daily stand-ups, they are often more comfortable applying the practice of time-boxing to longer meetings and meetings that involve people from outside of their immediate team.

Additionally, the daily stand-up introduces the idea of creating and protecting a regular cadence for communication. For many teams, synchronous team-wide meetings only occur when there is an immediate and transactional need for one. Holding space for your entire team to interact with one another every day, even if there is no proverbial fire to put out, helps create a true sense of shared purpose and accountability around both day-to-day tasks and broader team goals.

Of course, there are also plenty of ways for a daily stand-up meeting to go awry. In companies with a report-and-critique culture, the question of “What are you doing toward the team’s goals” can feel like an accusation. One product manager I worked with described the daily stand-up as the “What have you done for the company lately” meeting, a rote and fruitless exercise in which team members defensively spit out as much as they possibly can about their own individual work without listening to or interacting with their colleagues.

Indeed, the simple fact of holding a daily stand-up will in no way guarantee that you are actually building a collaborative culture. As IBM CMO Michelle Peluso told me:

You can’t check the box of “oh, we’re doing stand-ups” and really understand what it means to be Agile. When you are truly practicing Agile, you’re learning, starting to create your own things. It becomes reflexive. You keep going, you iterate, and you continue moving forward and living it. And once you get to that stage you never go back.

In other words, the daily stand-up is at its most impactful and sustainable when your team feels a sense of collective ownership over this practice. Here are a few steps that you can take to make sure that your daily stand-up meetings are actually adding value and encouraging collaboration:

Be clear about why you are holding the stand-up

As with any Agile practice, the daily stand-up is only useful if you and your team have a clear understanding of why you’re doing it in the first place. Take the time to discuss with your team what the purpose of this Agile practice might be, and be sure to tie it back to your guiding Agile principles and your organization or team’s specific needs. For example, “We know that our organization is struggling to keep pace with our customers, and we have committed to the principle of collaborating early and often as a way to maximize the immediate impact of our customer research. So, we are going to have a daily stand-up meeting to stay focused on our customer-facing goals.”

Treat the stand-up as a diagnostic

Because it is so simple and straightforward, the daily stand-up often becomes a powerful tool for diagnosing whether your team is stuck in report-and-critique mode or is building a truly collaborative culture. If people on your team roll their eyes or miss meetings, don’t castigate them for not “doing Agile”—understand what isn’t working for them and talk about how you can address this together. (As we discuss in Chapter 5, holding a retrospective is one way practice to group reflection on what is and is not working.)

Change the questions

The three canonical questions of the daily stand-up meeting were designed to keep teams tactically synchronized and focused on their overall goals. But the needs of every team are different, and nearly every Agile practitioner I know has at some point changed these questions to better reflect the needs of their team. Some have changed them to more explicitly encourage collaboration, like “What opportunities are there for your colleagues to help you today?” Some have gone so far as to ask much more personal questions like, “How much energy do you have today?” to address disconnects between team members’ energy and capacity.

As we discussed in Chapter 2, making changes to any Agile practices, including the daily stand-up, should be done in the name of living up to your Agile principles and achieving your team or organization’s specific goals. If you and your team are having trouble finding value in the daily stand-up, treat it as a learning opportunity rather than a procedural failure. Have a conversation with your team to find out what value people would like to get out of this practice and why they feel that they are not currently getting that value. Agree upon small changes you can make, one at a time, and reflect openly on whether they are helping you achieve your goals. Because the daily stand-up occurs every day, and because it is so often the first step that a team takes toward adopting Agile practices, it makes for a great opportunity to model a collaborative and principles-first approach to Agile in general.

Quick Wins to Put This Principle into Practice

Here are some steps that different teams can take to begin putting our Agile guiding principle of collaboration into practice:

For marketing teams, you might try…

…bringing together planners, agency partners, and creatives for regular synchronous meetings to guide campaigns from ideation through execution.

…responding to requests for asynchronous feedback (“Hey, can you take a quick look at the attached presentation?”) by scheduling short time-boxed meetings to talk things through and make decisions.

For sales teams, you might try…

…sending a representative to product and marketing meetings to better understand the future of the product.

For executives, you might try…

…asking what has already been done toward addressing a given customer need or meeting a particular company goal before signing off on any new, big projects.

For product and engineering teams, you might try…

…inviting people from across the organization  to attend a daily stand-up meeting so that they can learn more about this practice.

For an entire Agile organization, you might try…

…time-boxing meetings to facilitate decisive outcomes and minimize wasted time.

You Might Be on the Right Track If:

People from different teams and functions are spending time together outside of formally scheduled, transactional meetings

As we have discussed throughout this chapter, actually following our guiding principle of collaboration is much more a question of culture than it is a question of org charts or calendar invites. A lot of important things can happen when people from across teams and functions are spending time together informally during meals, coffee breaks, and after-work activities. This does not mean that everybody should be, or should feel pressure to be, best friends. But the comfort and rapport that people develop through these informal interactions can have a tremendously positive effect on both an organization’s culture and the quality of its work.

To keep the momentum going around this, you might want to:

• Make sure that organizational and team leaders are present during informal events like company lunches to avoid the implicit suggestion that people should be focused on “more important work.”

• Utilize “Lunch Roulette” or another mechanism for making informal connections across far-flung parts of your organization.

• Hold open “lunch-and-learn” meetings during which people can share interests outside of their day-to-day work (such as how to make great coffee at the office or how to research an awesome vacation).

Collaboration is taking place around upstream strategy as well as downstream tactics

In too many cases, “collaboration” happens only when the high-level strategic decisions for a project have already been made. For example, a broad group might be consulted on a specific wording choice for an advertising campaign or the specific shade of red to be used in an interface design, but the overall shape and objectives of the campaign or product are already set in stone. This is a classic symptom of an organization that is going through the motions of collaboration but still getting tied down by the Second Law of Organizational Gravity. When a broad and open conversation about a new idea is seen as an opportunity to make that idea better, not a threat to that idea’s success or survival, an organization is well on its way to becoming more truly collaborative.

To keep the momentum going around this, you might want to:

• Hold open “demo days” during which teams can show off works in progress before they are finished and polished.

• Ask project leads to co-create a plan for how their respective projects will work together to meet customer needs and goals before any projects are approved or budgeted.

• Start each new project with a cross-functional work plan that explicitly includes inflection points for getting feedback from across the organization.

Nobody can really remember whose idea that was in the first place

When your organization has embraced the spirit and practice of collaboration, everybody feels invested in the ideas that are being developed and executed. Po.et CEO and former VP of Innovation at the Washington Post Jarrod Dicker pointed out to me that the most successful ideas are often the ones for which nobody can even remember whose idea it was in the first place. This creates a self-reinforcing loop of collaboration and success because the ideas that have been influenced, shaped, and reshaped by the broadest set of people and perspectives in the organizations are those receiving the most attention and resources. This is, in Dicker’s words, a sure sign that an organization has transitioned from a “don’t step on my toes” culture to a “please stomp all over my feet” culture.

To keep the momentum going around this, you might want to:

• Run ideas past individuals from across the organization when they are still in a relatively early form to incorporate diverse perspectives and create a shared sense of ownership.

• Recognize and incentivize collaborative efforts, and/or give employees ways to acknowledge and bring attention to one another’s contributions.

• Conduct regular meetings during which people from different teams and functions can share works-in-progress, to incorporate perspectives and expertise from across the organization.

Anybody on your team can take a sick day without work grinding to a halt

One classic sign of a high-performing Agile team is that the team can continue to function in the absence of any of its individual members. This is not to say that multiple members of a team need to be experts in the same skill; I have worked with many Agile product teams, for example, that include only one engineer capable of writing a particular kind of code. But when a team is in the practice of collaborating early and often, the members of that team are able to regroup, adapt, and keep things moving forward. (Thanks to Andrew Stellman for this suggestion!)

To keep the momentum going around this, you might want to:

• Hold a daily stand-up meeting at the beginning of each day, giving your team the opportunity to regroup and adapt as needed.

• Provide opportunities for members of your team to share their skills and knowledge with one another. This could involve pairing team members with different skills to work on the same thing, or hosting informal gatherings during which team members can share their skills with the group at large.

• “Trade” a member of your team with a member of another team for a day or a week to expand your team’s skills and knowledge beyond its immediate boundaries.

You Might Be Going Astray If:

Your meetings feel like elementary school book reports

For organizations that have not evolved past a report-and-critique culture, meetings can feel more like elementary school book reports than opportunities to collaboratively make important decisions. If your meetings involve taking turns spouting off the most defensible thing you can conjure while everybody else dozes off or dreads their turn in front of the room, you’ve got some work to do.

If this is happening, you might want to:

• Acknowledge that the way you are currently holding meetings is not working and ask for the help and support of your colleagues in making your meetings better. Sometimes, just opening up this conversation is enough to begin steering things in the right direction and create a shared sense of accountability around meetings instead of treating them like something that is being forced on everybody.

• Impose strict time limits on your meetings, and enforce them ruthlessly. When people realize that their time is truly limited, they are more likely to make the most of it. Note that it generally takes at least three to four meetings for people to get used to this and actually begin managing their time differently.

• Try making your meetings optional and see who shows up. This will help you to understand who is currently getting value from a given meeting. Work with those people to understand why they find the meeting valuable and what you can do collectively to extend that value to others.

Everything shared between teams is finished and polished

Everybody wants to do a good job, and presenting something that is finished, polished, and impressive often feels like a surefire way to boost your status in an organization. But finished and polished things often send the wrong message: “I want you to be impressed by this, but I don’t really want you to participate.” Even worse, when feedback is given on something that is polished and finished, it is often met with heavy sighs and huffs of, “Well, this is already pretty much finished,” or, “My boss already signed off on this, I can’t really change anything.”

If this is happening, you might want to:

• Have a “no PowerPoints” rule when new ideas and initiatives are being discussed, an idea popularized by Jeff Bezos at Amazon. The time that goes into finishing and polishing a PowerPoint presentation often has nothing to do with the quality of the ideas being presented, and it certainly offers no value to the customer or end user.

• Conduct short, high-energy structured brainstorming sessions with people from multiple teams and functions to think about how a particular customer need or goal might be addressed. The tools and practices commonly associated with Design Thinking can be particularly valuable here.

• Put new ideas and works-in-progress in a public and highly visible space to invite serendipitous feedback from anybody who happens to be present.

Your inbox is full of requests for asynchronous feedback

Talking through works-in-progress synchronously can be awkward, uncomfortable, and challenging. It is much easier to simply send an email and say, “Please send me your feedback.” Your bases are covered in that you technically asked for feedback, and you can add as many people as you want to the distribution with minimal additional time expenditure on your part. But for each person you chose to copy in the thread, there is now a new task on their desk that they must process, prioritize, and find time to address.

If this is happening, you might want to:

• Be clear about who you will ask for feedback, and why. You can use a formalized framework such as a RACI (Responsible, Accountable, Consulted, Informed) Matrix, or just keep an informal list and make sure each person on that list knows what you expect from them and why.

• Reply to requests for asynchronous feedback with an offer to meet up for 10 minutes and provide your feedback in person. If the person who emailed you doesn’t have the time to spare, they likely were not all that interested in your feedback in the first place.

• Get in the habit of including the kind of feedback you need and the timeframe in which you need it in your email subject lines. For example, “Newest Version of Campaign Plan [Approval Needed by Friday],” or, “Latest Product Mockups [FYI, No Feedback Needed].”

Summary: Building a Culture of Collaboration

For people whose calendars are already packed with tedious and seemingly unnecessary meetings, the idea of more collaboration can seem wasteful and counterproductive. But truly building a culture of collaboration is about much more than sitting in a room while somebody tells you about the work they just finished. Making the choice to err on the side of openness—to share things before they are finished and polished, and to ask for input while that input can still inform a project’s overall shape and direction—can contribute to a truly collaborative culture. When we work toward developing such a culture, the value we deliver to our customers is not bounded by the gaps and silos in our org chart.