In our roles, we are frequently asked some common questions about Agile, teams, org structures, and leading change. Below are some common questions and our answers to them.

What is Agile? Is it a process? A methodology?

As we describe in more detail in the video below, Agile is a set of values and principles that were captured by 17 software developers in 2001.

The values are written as pairs, (we value this over that), and are a good description of what tradeoffs an organization would use to work effectively when the work is complex, meaning outcomes are not fully predictable and plannable, and there are many interdependencies in reaching good outcomes.

Since Agile is really a description of values and principles that are useful to make when working in complexity, it does not specify a single methodology. Agile organizations iteratively discover the right mix of practices, processes, and structures to effectively manage their own complex challenges. Each company has its own unique Agile process set.

What trade-offs are implied when working in an Agile way?

Agile organizations choose to make trade-offs that are appropriate for learning, cross-functional value delivery, and high engagement. For example, Agile organizations might list the following common trade-offs:

• To optimize for Adaptability, we are willing to get worse at Predictability
• To optimize for Cross-Functional Teams, we are willing to get worse at 100% Utilization of Resources
• To optimize for High Engagement, we are willing to get worse at Management Control & Oversight
• To optimize for Team and Individual Autonomy, we are willing to get worse at Standardization

Agile organizations do not trade off the ability to deliver high-quality products. In the software industry, Agile teams using the original Agile Software Development approach of eXtreme Programming (XP) have some of the highest quality products ever created.

Agile organizations do not trade off the ability to be highly productive. Cross-fuctional teams are highly productive, often outperforming traditionally structured teams by 2-5x.

Agile organizations do not trade off the ability to forecast a feature roadmap. However, they do trade-off the desire to have high-precision, high-granularity of plans that will inevitably change as we learn more, leading to a large amount of wasted planning effort.

What are the most common challenges organizations face when moving towards an Agile approach?

Agile organizations face three common challenges when adopting an Agile approach, what we call My People, Brute Force, and Train The Change.

My People: Org Structures and Power Dynamics

In a typical organization, the more people that are below an individual in the hierarchical org chart, the more perceived power that individual has. Additionally, most organizations are structured so that people with the same or similar skills roll up through the same management chain to a director or VP level. So, we have senior leaders with a large organization of people with the same skills, and the perceived power that comes with all of those people under the individual’s control.

Now, introduce the idea of Agile, with its cross-functional, highly autonomous teams into this previously stable power structure, and we need to figure out entirely different ways to understand who is in charge of what. While there are several different successful patterns for how to organize into cross-functional teams, and how to create management structures around those teams, the change from the original to the new is going to involve the discomfort of upending the career path of many executives. This can lead to strong resistance unless the executives are fully aligned on a critical problem an Agile approach is attempting to solve, aligned that an Agile approach based on cross-functional teams is the best solution to that problem, and aligned on how to move from one power structure to another. No matter the goodwill, clarity of why and how to change, the best intentions, and psychological maturity of the executives involved, this type of change represents a difficult and common challenge.

Brute Force: Change as if it is Predictable

This challenge is related to the most common way that large changes happen in an organization: with a top-down announcement, a detailed change management plan, and then everyone trying to figure out how to adopt the change in their part of the organization (or resisting said change). Just like new product development, change is complex and unpredictable. Change to an Agile approach should follow an Agile model in its roll-out: small, iterative changes in small teams, with feedback, sharing of learning along the way, and a continuously evolving and expanding adoption of an Agile approach. Beware of any consultant that claims to be able to “transform your organization” on any specific timeline.

Train The Change: Agile as Knowledge Transfer

This challenge happens when an organization believes that Agile is simply a set of processes and tools that can be “installed” in the organization, and they’ll be all set. Since successful Agile involves new habits, power structures, communication structures, beliefs, and skills, it is not something that can be delivered to an organization simply by providing some training and licensing Jira. While good training will give people a common language and help them align on what Agile is, how it is intended to work, and why, the actual habit changes and the larger systems in the organization take months or years to change. We’ve seen single teams make those changes in a matter of a few months, but the full adoption rarely takes less than a few years in an organization of any size. For this reason, it is important to supplement Agile training with good coaching whose goal is to embed the right skills within the organization over time, vs. remaining dependent on outside consultants.

How can an organization ensure the long-term success of an agile transformation?

Nearly every successful long-term adoption of Agile that we’ve seen has had three components:

1. Executive leadership Effective transformations we’ve been a part of have had a strong executive voice with sufficient political clout in the organization to help them get through the hard, frustrating, and sometimes slow parts of a cultural change like Agile adoption.
2. Small, strong successes Every successful large scale transformation we’re aware of started with one cross-functional team or group of related teams that adopted an Agile approach and saw significant benefits. Other teams in the organization noticed things were better, and Agile spread at the grassroots level. The adoption worked because individuals volunteered to adopt it, vs. being instructed to.
3. Internal Agile Champion In successful long-term adoptions, we’ve noticed that within the first year or so, an internal champion emerges as a trustworthy, capable evangelist and change-agent. Since they are “one of us”, and have experienced Agile working in our company, they have high credibility and are able to create the type of grass-roots adoption that an executive or consultant simply couldn’t do. Sometimes this person has a management or leadership role, but more frequently the person is an individual contributor that can tell the tale of how to make things work here.

To hear Peter’s own journey of change becoming the Agile Champion at Adobe, check out this episode of the Humanizing Work Show:

Agile Teams

What is a cross-functional team, and why is it important to agility?

We’ll start by clarifying how we define a team, which is a group of people that collaborate towards a shared goal. A football time works together (literally co-labors) to accomplish the shared goal of scoring more points than their opponents.

Historically, when work was more predictable, teams were assembled to do a single part of a bigger process. Imagine a factory that turns iron into steel creating one team that works together to keep the fires stoked to a consistent temperature, another team that gets iron ore from the yard into the factory, another that gets molds clean and ready, etc. Each team has a goal that is a single step in delivering value, and it works well enough because the process of turning iron into steel is largely predictable. If each team accomplishes their goal, the collective result will be valuable delivery of steel to their customers. This structure allowed each team to focus on technical excellence within their specialty because the transition from one step to the next was pretty clearly defined.

When the work of an organization is to create new things all the time, like software teams in the 1990s, this way of structuring teams didn’t work as well. When we’re developing new products and services, the important work is discovering what to make and how to make it, and it turns out that having hand-offs in that process doesn’t work well. See this Harvard Business Review article from 1986 that analyzes several companies and concludes that eliminating these hand-offs was a critical component in delivering new products to market.

So, a cross-functional team is a group of people that collaborate towards a shared goal, AND has all of the skills needed to take an idea from concept through to delivery to the customer (and beyond to providing support and services related to that delivery). This structure is critically important to an organization adopting an agile approach because cross-functional teams are the best structure to solve unpredictable, complex problems, the types of problems that Agile approaches emerged to solve. Instead of focusing on a single step in delivering value, a cross-functional team has the larger shared goal of delivering value to the customer. This focus on customer outcoomes leads to a stronger understanding of the impact of the work, which increases engagement, which leads to higher productivity and creativity.

Why might a business care about cross-functional teams?

Eliminating those hand-offs allows a cross-functional team to rapidly discover and deliver what customers actually want and how to deliver it to them. These types of teams tend to have people with diverse perspectives, which turns out to be important in any innovation efforts. If the business cares about decreasing time to market, creating more innovative products and services, and smoothing out revenue curves by moving from large, chunky deliveries to smooth streams of value, then creating cross-functional teams is one of the first few moves an organization needs to take.

How do Autonomy and Accountability work on an Agile team?

Decades of research have shown that humans have a high need for autonomy, mastery, and purpose in order to be engaged and creative. Agile organizations seek to create teams that have high autonomy for how to achieve a shared purpose because it creates a win-win combination of good business results and engaged workers.

Providing Autonomy to a team to make decisions means that we must hold the team Accountable for the outcomes of those decisions. Not only would a lack of accountability lead to a high likelihood of the team wasting the organization’s resources, but it turns out that autonomy without accountability limits our own growth. We need the feedback that comes from making a decision, sometimes the wrong one, and then suffering the consequences of that decision. Since the desire to grow and improve (mastery) is another core human need, Autonomy divorced of Accountability leads to low engagement. Finally, it would be foolish to make someone Accountable without given them the Autonomy for how to deliver on that Accountability.

So, we create teams with Autonomy to deliver on a specific outcome within a specified set of constraints (like budget and scope), then hold the team Accountable for how they use that Autonomy. Within the team, individuals hold each other accountable for delivering on commitments they’ve made to each other.

What are some standard roles people play on an Agile team?

Most standard agile role definitions come from Scrum, one of many agile frameworks. Different agile approaches define other roles, but not have proliferated the common vernacular as much as these have. Scrum defines three roles within a cross-functional team: a Product Owner, a ScrumMaster, and role they call “Developers”. We’ll provide a quick summary of each role and why that role might be helpful by describing the problem it solves.

Product Owner

What is this role?

The Product Owner (sometimes abbreviated to PO) is responsible for prioritizing what the team works on. Since a cross-functional team’s goal is to deliver value to the customer, the PO typically has deep expertise and connection to the customer. The PO is a team member, not an external role that delivers requirements to the team. Great Product Owners learn and communicate about what to build, for who, and why it matters in collaboration with their cross-functional team, as well as customers and other stakeholders, in order to maximize the flow of value through that team.

Why this role?

Since a cross-functional team is collaborating towards a shared goal, it is critical that their is alignment on what that shared goal is. The team needs both a big-picture understanding of “why” and a day to day understanding of what to do in order to accomplish that “why”. For many teams, the decision of what to do next is made by committees (too slow), by politics (focused on internal power vs. customer outcomes), or worst of all, the team doesn’t actually align on priority, so team members are pulled in all different direction by different stakeholders. The PO role emerged to make it 100% transparent to all stakeholders that there is a single decision-maker for what a cross-functional team works on.

ScrumMaster

What is this role?

The ScrumMaster creates the environment for the Scrum Team to deliver value. To do this well, they have a unique ability to focus through both a systems lens and a human one. The systems focus involves helping improve practices, processes, structures, and toolsets that help the team be more efficient, effective, and capable. They create structures that encourage continuous improvement at the individual, team, and organizational levels. The human focus creates the environment needed for teams to flourish, including psychological safety, trust, clarity, commitment, accountability, and a focus on results. This is a leadership role, but one where the leader recognizes that the goal is not to create followers, but to create the environment for others to succeed.

Why this role?

Creating value in complex, uncertain situations requires a different approach to work, one based on experimenting to learn over planning and controlling to the plan. That is an uncomfortable shift for humans since it requires embracing uncertainty. Additionally, today’s workers and challenges demand a high-engagement culture to effectively solve complex problems. Creating high engagement happens mostly at the team level, so the role of the Scrum Master is created to focus on what the team needs. While traditional roles like managers can have this influence at the team level, since Scrum Teams are cross-functional, they often do not all report to the same manager. The Scrum Master focuses on creating an engaging culture and effective processes at the team level.

Developers

What is this role?

The third role on the Scrum Team is made up of the people that actually make the product or service delivery, the product Developers. Each skill needed to develop the product or service is a member of this group. It is cross-functional, and works together to ensure high quality increments of the product are releasable at the end of each Sprint. The developers have high autonomy for how to do the work within the constraints of the priorities established by the Product Owner and the quality standards agreed to in the Definition of Done.

Why this role?

This role is different from traditional roles only inasmuch as it is cross-functional, stable, and self-organizing. The reason for those characteristics is already described above.

What is a Shared Services Team, and is it recommended in an Agile organization?

As software organizations grow, a common pattern has them splitting out some foundational pieces of the software stack into their own teams. A few common examples:

• Breaking out the skills needed to build, maintain, and improve the release and delivery pipeline
• Breaking out all work on legacy systems like mainframes (very common in financial industry teams)
• Breaking out e-commerce work for a web development organization

The shared services approach has the benefit of avoiding duplication of effort in a system and allows the team to focus on doing that type of work extremely well. The trade-off is that if other teams are dependent on the shared services team in order to deliver value, the shared services team becomes a constraint. For this reason, it is worth examining whether the organization would be better off taking the skills needed to do the work in the shared service area and distributing those team members on cross-functional teams. There are many reasons an organization might continue to choose the trade-off here, like not having enough skills in the shared technology to distribute some to each team. Often we can break this conflict by setting a long-term goal to begin training others in the skill so that after some period of time, we can distribute the capability across teams. See this article for more details on this approach.

Can a Shared Services Team be an Agile Team?

Shared services teams can behave exactly like a cross-functional agile team. They can have the three standard roles, priorities new capabilities desired in that shared service into a single, transparent, prioritized backlog, and execute the work in short Sprints with feedback and improvement after each one. In this scenario, the shared services team treats other teams in the organization as their customers.

Is Agile just for Software Development Teams?

While Agile was discovered by software developers, it is an effective approach to managing any work that has complexity and uncertainty. When outcomes are uncertain, the appropriate way to manage the work is in short, iterative pieces with fast feedback along the way. Software developers experienced this type of uncertainty more frequently than most other industries, and so were the first to begin to name the effective patterns, but those patterns have been used successfully in nearly every industry and by nearly every department in a standard organization.

For more on agile teams, check out the Humanizing Work Show Season 2, Episode 2