Small Number

Agile or not, small teams have certain attributes that make them more conducive to high performance. Anyone who has tried to schedule a meeting with a large group of busy individuals knows that the simplest logistics become increasingly complex the bigger the group. While I’m a fan of big room planning, with representation from across the enterprise, these large gatherings often require weeks of groundwork just to get the group into the same room. In a high-pressure, high-expectation environment, we don’t have weeks to wait for the team to make a decision or allocate immediate tasks. Small teams can meet frequently and (relatively) easily, and can convene emergency sessions to address the unexpected situations that arise every day in an innovative product development environment.

Communication also becomes more challenging with larger teams . Two people have a direct link, three require multiple links, and six need a complex network of interactions just to ensure that everyone gets the message. Even in teams that small, the message often gets garbled, as each individual re-interprets and retransmits the narrative. A small team can gather in a room, and everyone can hear the issue and collaborate on the solution, while large, distributed teams require more channels of communication, often including e-mails, phone calls, web chats, and other communication avenues that are not suited for immediate action. These alternate channels reduce the team’s ability to interact, as anyone who has attended a web call can attest. The Agile Principles tell us that:

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

While today’s global, distributed teams can make face-to-face communication challenging, the ideal still stands. With the product owner in the room representing the client, and with a small, empowered, cross-skilled team, we can usually solve problems rapidly and come to consensus efficiently, without weeks of back-and-forth debate across multiple, impersonal mediums.

In a large group, it’s common that many of the attendees, even if they come from the same enterprise, don’t know each other, and are unfamiliar with the roles, responsibilities, and personalities of the people in the room. Many such sessions require a round-robin, in which we go around the room and describe our roles, often with the most cursory overview. In small teams, we incrementally gain intimate knowledge of our teammates’ skills, capabilities, and personal attributes. We progressively build trust, and migrate to openness and honesty as we work through challenges and triumphs together. We learn the habits and proclivities, the unique skills and deficiencies, and the human characteristics that define our teammates. After a while, especially in persistent teams, we can predict the responses to a particular situation around the room and adjust our communication to the various sensitivities of our comrades. By building this trust and openness, we can collaborate effectively to address challenges and obstacles without having to pussyfoot around each other or soften our messages to avoid offense. Avoiding offense, of course, is critical for trust, but in teams that know each other and have been through the fire together, we instinctively learn how to frame issues to encourage teamwork rather than set off emotions.

Once we’ve developed this level of trust and honesty, it becomes easier to determine if we have the right skills in the room, or if we need to reach out to other experts or specialists to help us deliver our commitments. We can openly state that Michele is not the database expert we need for a particular challenge without insulting her. We can come to the conclusion that our training commitments need augmentation from the Training Department without humiliating our teammate who “sort of” has training experience. More important, the individuals themselves can volunteer that their skills or experience are not at the level required, thus sparing us the tiptoeing that this conversation would require in a large team of virtual strangers.

In an agile context, in which we have a defined time box in which we commit to specific deliverables, honesty, openness, and trust are indispensable. We simply don’t have the luxury of dancing around delicate feelings when we’re striving to develop innovative, emergent products. We never purposefully offend, but neither can we avoid issues that are impeding our progress. Small teams, with cohesiveness, collaboration, and trust, can call them as they see them, and uncover the flaws in our thinking and our process. Without that open exchange we’ll never approach kaizen, let alone the perfection for which we ultimately strive.

Complementary Skills

In the typical enterprise, skills are clustered in functional silos. The developers sit, and work, together. The operations team has its own responsibilities, and reports to an operations manager. The same holds true for database experts, network teams, and quality assurance teams. Each functional, or component, team has its own chain of command, and its own goals and metrics. When a project is identified, temporary teams are pulled together across functions. They meet and collaborate on the project at hand, and then dissolve back into their respective silos until the next cross-functional project arises. This structure goes back to the industrial age, when individuals had very specific, repetitive tasks to perform, and, as long as each individual performed his task as expected, the final product rolled out the door. In fact, this separation of duties, along with interchangeable parts, is heralded as part of the industrial revolution that changed the world.

In the industrial enterprise , and in the administrative functions that grew to support it, this specialization made perfect sense. Specialist teams can be shared among multiple product lines, thus sparing the enterprise from hiring specialists for each product, increasing the expense and creating utilization problems. Specialists who work together can help each other, learn from and teach each other, and keep evolving efficiency within their speciality. As they enhance their capabilities, they can set standards of performance that lead to higher quality, easier handoffs, and more uniform practices and processes. All of these capabilities are focused on cost reduction. By carving out specialty, or functional, teams, we can keep the expertise in a controlled, closely managed team of shared resources that can be deployed as needed but kept together for ease of management, training, and cost control. We pay for this in the form of multiple handoffs, which decrease efficiency and increase the chances of miscommunication and error.

In the post-industrial age, cost control is still important but is trumped by innovation and customer responsiveness. Of course, costs need to be managed, but, as the management axiom goes, you can’t cost-cut your way to product leadership. From Apple to Tesla, customers will pay a premium price for distinctive and unique products. The current marketplace values products, even if they are centered on hardware, that have a broad ecosystem of services and applications associated with them. Building the best smartphone hardware is great, but it is useless without great services and apps on offer, and this trend will only accelerate as the Internet of Things takes off. When even the automobile becomes a platform for software, it’s clear that the pure hardware play is fading, to be replaced by physical products that are merely the platform for an array of additional, software-powered capabilities.

As hardware products become platforms, and as innovation and responsiveness become the differentiator, the industrial model of organization starts to show its age. The hierarchical, siloed structure is becoming obsolete as fast as the last generation of smartphones, and a more flexible, cross-functional, and self-managed workforce becomes the pathway to competitive advantage. Cross-functional teams, rather than silos of specialists, have been demonstrated to enhance the creativity and customer focus required in today’s marketplace. Lean manufacturing practices have proven that those closest to the actual work have the most insight into efficiency and innovation. As firms experiment with this new cross-functional structure, certain attributes become clear, as do certain challenges.

Cross-functional, or complementary-skilled crews, enable the enterprise to build high-performance teams that contain all the capabilities necessary to take product ideas or new features from inception to completion. A team that includes analysts, developers, testers, technical writers, and customer representatives can take a product from ideation through quality assurance, and deliver a running, tested feature set to the ultimate customer without having to beg for outside resources, wait for other specialties to become available, or accumulate stores of work-in-progress while waiting for testers or documentation writers to be borrowed from functional silos. This is the ideal, of course, as most agile teams don’t have every specialty required, and still have to wait or borrow, but teams that can take ownership of the product development cycle and avoid the serial, assembly-line practices of the industrial age have been shown to be more creative and invested than those in disconnected silos.

When we discuss complementary skills, many people think only of the technical or specialty diversity described earlier, but it’s also important to consider interpersonal and collaborative skills as well. Some team members are great problem-solvers and decision makers, while others are stumped and frustrated by the smallest obstacle. Some are talkative and participatory, while others are timid and reserved. Some are argumentative and blunt, while others are collaborative and discrete. The best teams have diversity of personality as well as technical specialty, as each of these personality types adds something useful to team dynamics. The opportunity to watch the diverse skills and attributes in action, to learn from those who see the problem at hand in a different light, is itself a key strength of agile teams, both in the technical and in the interpersonal realms. The agile consultant who advises the enterprise in the composition of agile teams does well to ensure that technical and interpersonal diversity is encouraged, and that the ultimate objective for each team member is to develop a broader range of skills through exposure to her peers, and through the daily interaction of solving problems together.

Of course, most teams will need to reach out to other functional specialists to deliver a complete solution. Not many teams will have the luxury of a full-time technical architect, writer, or training specialist. Agile teams need to develop practices around coordinating with other specialists, who are often still working in functional silos, in order to fill team gaps and satisfy the customer’s expectations. These interfaces can be fraught, as managers in silos attempt to ration their expertise or protect their positions. Agile leaders, such as scrummasters or product owners, often have to run interference in these situations, so team members can focus on their commitments without getting drawn into political disputes. Agile consultants should encourage teams to develop the required skills within the team when possible, and to reach out for expertise only when required. Teams that have grown up in functionally siloed organizations often stop forward progress as soon as they encounter an obstacle, before trying to design a creative solution within the team, a practice that only raises resistance and skepticism from functional managers. Agile teams are often surprised at their ability to figure their own way out of the box, and guiding them to success in this is a major triumph for the agile consultant. Agile consultants should aim to develop “generalizing specialists,” team members who have distinct areas of competence but also, through interaction with their fellows and insight into other specialties on the team, build increasingly deeper understanding of the capabilities required to become self-organizing and self-managing.

Common, Meaningful Purpose

We’ve devoted much space to discussing the importance of a guiding vision for the migration to agility, but each agile project we undertake must also have a clear and compelling vision of its own. Teams need a meaningful purpose bigger than themselves, bigger than the daily grind of paying the bills, to inspire them to persevere and collaborate. They need to feel that purpose in their hearts as well as their heads in order to achieve high performance. The Agile Opportunity vision we’ve discussed is an overarching, organizational vision, but teams need their own vision as well, one that suits their personalities both individually and as a group. As I illustrated above, roadmaps and backlogs derive from a consequential vision, particularly one that is developed and refined by the team itself. Visions that are handed down from on high, with no input or participation from the team, are interpreted as marching orders rather than inspiration. If the organization's objective is to “develop a new platform for processing insurance claims,” the team can then derive a vision that articulates its aspirations for its role in achieving that mission. A cross-functional agile team may aspire to deliver the most running, tested features in the least number of sprints possible, thus pushing itself to high performance while supporting the enterprise goal.

Words are slippery, with the possibility of each team member interpreting any vision statement differently and approaching the achievement of any objective in a different way. It’s important that the entire team creates and interprets the project or product vision the same way. It’s also important that the vision is concrete and measurable, with a binary outcome of achieved, or not. Vague visions, like “be the best team” or “create superior products,” don’t lend themselves to objective measurement or a clear outcome at the finish line. An agile consultant can help by coaching the team to develop a product vision that defines a SMART⁵ goal that also contains both a hint of inspiration and a bit of a stretch. Ideally, I hope to see an agile team develop a product vision that its members can articulate and defend with passion, that they can refer to as a guiding principle, and that can drive them to greater achievement in their personal and professional goals.

Common Set of Specific Performance Goals

In agile, the backlog is our version of the project plan, but, rather than reciting a list of tasks and activities, it defines a set of features that add value for the client and can be articulated and committed to by the team. This product backlog is our set of specific goals, and the roadmap and release plan is our visible articulation of what we’ve committed to deliver, and on what schedule. This granular set of goals is not only SMART but is also customer-focused and value-based. The goals are defined in such a way that they enable the team to demonstrate progress incrementally to both the customer and the broader organization, so the team can celebrate “small wins” and demonstrate that agility works.

To create a true product backlog, some team attributes are required. The team members must agree on the features or stories that comprise the product, and they must phrase them in a way that expresses the specific customer they’re delivering value for, or the role or persona they address. The team must also agree, with the help of its product owner or business representative, on the relative priority of the backlog items, and on the level of effort required to achieve them. The practices of writing user stories, assigning them relative priority, and estimating the effort required, are clearly described by Cohn, Schwaber, and other authors I’ve cited, and I won’t repeat them here. These basic mechanics of agile practice should be well understood by any agile coach or consultant, so reiterating them here is not our goal. We are, rather, focused on their importance from a team perspective. Skilled agile consultants know that the process of defining stories or features, coming to consensus on the roles, actions, and results that they represent, and deciding how to groom them to acceptable length and clarity is where the team dynamic is built and solidified. When a team looks at a large product vision, and collaboratively decomposes that into epics, stories, and priorities, it builds its understanding of each other’s skills, personal attributes , and points of view that then enables its members to work in increasing harmony toward a common objective. As often stated, the plan is nothing; planning is everything. While I think this is an overstatement in the agile context, where the backlog is a critical artifact of our work that guides everything we achieve, I do believe that the act of planning is the element that solidifies the team and creates the knowledge, intimacy, and sense of shared purpose that creates a high-performance environment.

Those consultants who have coached a planning poker exercise have seen first hand what I mean. The story point estimating process is significant in itself, as it sets the expectations for effort required and gives us a quantifiable metric by which we can measure progress. Equally important is the team interaction. When one team member estimates a story as 5 points, and another estimates it as 40, it opens a dialog that enhances team understanding of the story, surfaces issues and technical challenges that may not be explicit, and teaches the team how to reach a consensus without argument or drama. The agile consultant should be a role model for neutrality, and for managing the emotions and egos of the team. The consultant who can guide the team to a productive discussion that uncovers the risks while acknowledging the expertise of the players leaves behind a team that can work through its disagreements in a productive manner. Once the team has reached consensus on the backlog, including features, roles, estimates, and priorities, it has achieved the clear set of specific performance goals that were identified as a critical success factor by Katzenbach and Smith back in 1993.

Commonly Agreed Working Approach

For teams adopting scrum, or extreme programing (XP) , or test-driven development (TDD) , the commonly agreed working approach should be obvious; we follow the rules of the agile discipline we’ve chosen. This, as any experienced agilist can attest, is a fantasy. I’ve never encountered a team, or an enterprise, that doesn’t have unique circumstances, unique personalities, and unique constraints. I’ve also never encountered two teams, or two enterprises, that apply their selected agile discipline in exactly the same way. A team building smartphones may require longer iteration lengths to develop a valuable product, as I encountered in my consulting relationship with a major manufacturer. A team first learning agile methods may need to be eased into the process, by, for example, using t-shirt sizing before it evolves to story-point estimating. Enterprises with strong traditions of predictive, sequential project planning and estimation techniques will not automatically adopt relative estimating or backlog-based planning simply because we advocate it. While scrum, or the other approaches I’ve mentioned, have clear sets of rules and practices, the likelihood of those being adopted wholesale without training and evolution is nil. One of the critical areas of value that skilled agile consultants can add is their ability to observe and grasp the unique characteristics of the players and the environment, and figure out how to help teams adopt a version of their agile discipline that reflects the reality on the ground. I’ve followed up on too many failed agile transitions in which the sponsor told me that the previous coach was too rigid. “All he cared about was a set of rules; he had no sensitivity to our unique circumstances.” To me, that description typifies a rookie just out of scrum training. Consulting is an exercise in observation, sensitivity, and adaptability.

This is not to say that the rules are to be wantonly abandoned or applied in an ad hoc manner. Agile advisors should have a clear vision of where they expect to land, and should have a roadmap for getting the organization there. The practices must be respected; they’ve been refined, over the many years since Kent Beck first applied XP at Chrysler, because they work, and because they inculcate a healthy, high-performance culture. This being true, agile consultants need to determine the best way to get teams to accept these practices and internalize them. A book of rules, slavishly followed, is not an effective map for completing this journey. Teams must have input into the manner and speed with which these practices are shaped and adopted. They must own the process, it must reflect their opinions, personalities, and skills, and cannot be imposed.

This is an area in which I’m at odds with many agile experts, who advocate following the rules exactly before trying to introduce changes. My experience is that this rules-based approach often confounds the uninitiated, and discounts the enterprise history, culture, and business model. As I’ve noted, I’m an incrementalist, for many reasons. My overriding concern is that teams understand and own their version of agility, not that they get to agile adoption on the shortest possible timeline. By training on the meaning of the practices, their historical basis, and the successes they’ve achieved in other settings, the agile consultant can help teams develop the desire to adapt, rather than follow a “thou shalt be agile” dictum. I’ve consulted with teams that benefited from incrementally adopting the practices, migrating from task-based backlog items to user-centered stories, or initially thinking in hours and activities rather than relative points and value. While we respect the practices, we can allow teams to absorb at their own pace the meaning, rather than merely the methods, of agility. Most critically, they invest in the creation of their own version of agile, and own it. Incidentally, I’ve found that this approach actually shortcuts the dissemination of agility in the enterprise, as you avoid having teams and individuals blindly following practices that they don’t understand or invest in. Instead of questioning every technique and resisting the imposition of unfamiliar methods, they see for themselves how the practices they’ve devised help them achieve.

Shu Ha Ri,⁶ a martial arts philosophy that can be roughly translated as Imitate, Assimilate, and Innovate,⁷ is often cited as a central technique for training agilists. Shu Ha Ri was designed, however, for a physical discipline like karate, in which the development of “muscle memory” by imitation is a precursor to success. It is much beloved by many agile coaches, as it allows them to focus on rote repetition of a set of rules. Unfortunately, my experience is that teams coached in this manner never reach the assimilation or innovation stage, because they never understood or absorbed the underlying principles in the first place. Agility is a philosophy, not a physical practice; it requires understanding and acceptance, not muscle memory. As should be clear by now, I scoff at rote repetition; if that’s all that is required, new agile teams don’t need a consultant; they can learn the practices from a book. The consultant adds value through specificity; the ability to observe and absorb the unique circumstances at hand and guide the team to adoption of the practices in a manner and at a pace that fits their environment.

Make no mistake; the ultimate goal is a disciplined adoption of standard agile practices, with only the modifications that absolutely fit the enterprise’s, and the team’s, distinct requirements. I’m not advocating assembling a random collection of agile techniques, cobbling them together, and calling it good. “Fractional agile” is no agile at all. The agile practices that the team adopts cannot violate the spirit of lean, agile mind-set. It still must honor the basic tenets of the Agile Manifesto and the Agile Principles, as well as the kaizen nature of all lean enterprises. But Katzenbach and Smith use the language of “commonly agreed approach” for a reason. Agreement on a method that capitalizes on the team’s unique skills, requires measurable contribution by all participants, enables reality-based problem solving, and is unanimously accepted; these are the attributes that encourage team formation and results.

Mutual Accountability

When enterprises become agile , they abandon one thing that is precious in many cultures: the ability to hide. Many, perhaps most, organizations have a troubled relationship with truth. They tell themselves everything is fine when any outside observer can see massive dysfunction. They manipulate the numbers to misrepresent to the Wall Street analyst community, and to befuddle their own employees. They “work around” unproductive employees and broken processes to spare themselves the pain of decision, confrontation, and change. As we’ve seen, the speculators who caused the financial crisis through wild and self-dealing recklessness walk free. Management deals harshly with those who blow the whistle on unethical or dysfunctional behavior. In short, many enterprises lack accountability, transparency, and consequence.

In truly agile teams or enterprises, there’s nowhere to hide. Big, visible indicators show every interested party the precise state of affairs at any moment. Visible scrum or kanban boards enable both the team and the enterprise to see the progress, or lack thereof, that the team is making on a daily basis. Velocity metrics and burndown charts clearly illustrate the capacity for creating value that the team has achieved over time. Iteration-based demos and retrospectives enable the team to show the value they’ve added on a regular cadence, and to quickly correct suboptimal practices. Every practice or ceremony of agility is specifically designed to make progress visible, and to bring commitment and accountability to all team members, from the developer to the executive. Agility is a disruptive practice precisely because it eliminates hiding places and removes the ability to sweep broken processes under the rug.

Mutual accountability relies on more than simple visibility. It requires that the team embrace both individual and team ownership of the final outcome. Every team member must accept that they succeed or fail together as a unit, and that each individual has a specific role to play in order to deliver. The entire team must commit and own every element, from vision to roadmap to backlog, and every work product that makes up the whole. Rookie agile teams often struggle with the concept of collective and individual ownership. Agile consultants must define what commitment means, and help teams grasp the idea that they can’t passively accept roadblocks and challenges but instead must take action to achieve their goals, with the help of an active scrummaster. Teams accustomed to waterfall processes often simply send an e-mail and wait, versus picking up the phone or walking across the hall. Members who are used to being judged as individual contributors have difficulty adjusting their mind-set to the “whole team ownership” concept.

Unfortunately, we’ve all encountered those colleagues who have made a living by either hoarding their specialties or specializing in work avoidance. Agility will make these folks extremely uncomfortable, whether teammates or managers. That discomfort often spreads to their teammates as well; the “go along to get along” mentality is bred into many conflict-averse organizations. Agile teams tell the truth; that’s one of their defining features. If we don’t hold the non-producers, blockers, and hoarders accountable, kaizen is impossible. Helping teams change their accommodative behavior and start to expect higher performance from every member is one of the agile consultant’s most delicate jobs. Agile consultants need to role model honesty without encouraging confrontational behavior. As skilled facilitators, mature consultants understand how to avoid turning accountability into argument. By guiding teams to take the emotion out of the conversation, and to focus on work products rather than personalities, we can add value to the retrospective process without becoming a blame agent when teammates feel threatened or exposed. The delivery of running, tested features is binary; it’s either completed and demo-ready or it’s not. Coaches and consultants can often have problems with their own emotions as well. It’s easy to get frustrated with the team member who consistently misses targets or hands off a poor-quality product. Mutual accountability includes us as well. We need to remember that mutual accountability lies within the team, not at the scrummaster or consultant level. We’re there to guide, not enforce, and we guide through influence alone.

I’ve been an advocate of team rather than individual commitment long before agility, for a simple reason. I’ve observed, in my corporate career, that individual contributors quickly become immune to the scoldings or poor performance ratings of managers. If I’m not bad enough to fire, and I’m not particularly ambitious, what do I care if I have to endure a periodic chastening from some remote manager? On the other hand, if the team looks around the room and focuses on me and my inability to deliver, that cuts to the bone. The likelihood of influencing behavior rises exponentially when the team chastises me, even gently and indirectly, than if some manager whose opinion I scorn gives me a lecture. Teams that can get beyond the discomfort of holding their teammates (and friends) accountable, without triggering argument and emotion, master the art of kaizen and quality delivery quickly.