CHAPTER FOUR
Invest in Agility
As we saw in the previous chapter, for your teams to get the benefits of Agile, your organization has to buy into the underlying Agile philosophy. Not just spending money—that’s comparatively easy—but making real, meaningful changes to organizational structures, systems, and behaviors.
If that sounds like a lot of work…well, that’s because it is. Are these investments really so important?
Yes. They really are.
Investing in Agile is important because you’re investing in changing your constraints. Most of what holds teams back isn’t the processes they use; it’s the constraints they’re under. Make the investments and ignore the practices, and your teams are still likely to improve. Perform the practices and ignore the investments? They’ll struggle.
As Martin Fowler said:1
I see a startling parallel between DHH [David Heinemeier Hansson, creator of Ruby on Rails] and Kent Beck [creator of Extreme Programming]. For either of them, if you present them with a constrained world, they’ll look at constraints we take for granted, consider them to be unessential, and create a world without them…they just stick some intellectual dynamite under them and move on. That’s why they can create things like Extreme Programming and Rails, which really give the industry a jolt.
Martin Fowler
Make the investments. They’re the secret to Agile success.
The following sections describe the investments your teams need from your organization. You may not be able to get all of them, so I’ve provided alternatives. But the alternatives come at the cost of reduced effectiveness, so work hard to get as many as you can. I’ve included only the ones that are important.
Make Time for Learning
Changes are disruptive, and new ideas take time to learn. Learning Agile will slow your teams down at first.
How much will they slow down? There’s no objective measure of software productivity [Fowler2003], but from experience, I’d estimate a 10%–20% performance dip at first. As they become proficient with Agile skills, their performance will increase. It will continue to increase until they achieve fluency, and then the increase will gradually level off, as Figure 4-1 illustrates. This is called the J-curve, and it’s common to all significant changes. We’ll take a closer look at change in Chapter 5.
The time investment will typically pay for itself in the first year. The length of the initial dip depends on the fluency zones each team is pursuing, as described in the previous chapter. To recap:
-
Focusing: 1–4 months
-
Delivering: 2–6 months
-
Optimizing: 1–3 months
These periods overlap, so a team learning Focusing and Delivering skills together will have a performance dip that lasts about 2–6 months. In contrast, a team that learns Focusing skills first and moves to Delivering later will have two dips: a 1–4 month dip when it learns Focusing skills and another 2–6 month dip when it learns Delivering skills.
Figure 4-1. Agile performance over time
Agile teams’ performance changes in other ways, too. Agile teams focus on getting features completely done before moving on to the next feature. This is particularly true for Delivering teams, which build quality in from the beginning rather than fixing bugs at the end. This improves throughput and performance, but—ironically—it feels like a slow-down to people who are used to seeing multiple features in progress at once.
The net result is that stakeholders can be frustrated by the pace of Agile development, particularly in the first year, when they’re dealing with three hits all at once: a real delay from learning, a perceived delay from a focus on getting things done, and the cost of finishing pre-Agile work that was declared “done” without actually being done.
This frustration can lead to teams being redirected away from learning Agile, and solely focused on delivering software, before they’ve finished learning. This is counterproductive for everyone: teams will feel yanked around and frustrated, and the organization will have wasted the investments they’ve made so far. Before teams begin their Agile journey, make sure managers and stakeholders are on board with the first-year performance dip.
Your organization can trade money for time by hiring people to help your teams. This won’t eliminate the performance dip, but it will make it shorter and shallower. There’s a wide variety of help available: occasional mentoring, training, help with process design and implementation, and full-time coaching. The most effective help you can get is to hire experienced practitioners to coach each team full-time.
As you consider who to hire, ignore the myriad Agile certification schemes. Too many are money grabs. Most demonstrate nothing more than the ability to connect butt to chair for a few days. Some are associated with excellent training courses, but that’s due to the trainer, not the certification, so evaluate training courses independently of the certifications they tout. The same goes when hiring consultants and coaches. Ask your network for recommendations, sample publicly available materials, and check references.
As you apply this book’s practices, you’re likely to run into problems and challenges specific to your situation. Be sure you have a mentor you can reach out to for questions. This doesn’t have to cost money; a respected colleague at a company who’s done it before, a local user group, or an online forum are all good options.
If there’s no time for learning…
You can make the performance dip less noticeable, at the cost of larger overall expense, by starting with just the Focusing zone and easing into Agile’s focus on getting things done.
If your organization won’t accept any perfomance dip at all, now isn’t a good time to invest in change. If there never seems to be a good time, that’s a big red flag. You’ll need to convince management to make time for change before you continue.
If there’s no budget for help…
With this book, the many free resources available online, and a dedication to learning, your teams can teach themselves everything they need to know. Outside help is, well, helpful, but it’s not required.
Choose or Create Agile Teams
I can’t overstate how important teams are in an Agile organization. Most organizations consider people their fundamental work-producing “resource.” In Agile, teams are the resource.
Your organization needs to invest in teams that are:
-
Cross-functional. The people on the team collectively have all the expertise needed for the team to fulfill its purpose.
-
Fully dedicated. Specialists can come help from time to time, but core team members are solely dedicated to their team.
-
Collaborative. Team members have friendly, collegial relationships and work closely together.
-
Long-lived. It can take months for team members to figure out how to work most effectively together, so keep teams together for as long as possible.
The size and composition of each team depends on which fluency zones you’re pursuing. “Whole Team” has the details, but briefly:
-
Focusing teams focus on achieving business results. They need people with the ability to put themselves in users’ and customers’ shoes to determine exactly what the software will do. If the team’s purpose is user-centric, that includes people with UI/UX skills. Teams also need a way to determine what to work on next. Although it’s best if the team includes people with the skill and authority to do this themselves, team members can also work with someone from outside the team.
-
Delivering teams take responsibility for end-to-end delivery of their software. They need all skills required to build and deploy their product. Responsibilities that were previously handed off to other teams need to be brought into the team. This includes build management, data architecture and administration, testing, and operations.
-
Optimizing teams take responsibility for the broad business success of their product. They also take responsibility for coordinating with stakeholders and deciding product priorities. They need team members who have business, market, and product expertise.
You may already have teams that fit the bill. If you’re creating new Agile teams, use the following steps. Either way, remember to get teams’ buy-in, as described in “Get Team Buy-In”.
-
Decide the purpose of each team. (See “Purpose”.)
-
Decide how many people will be on each team, based on how valuable the team’s purpose is, subject to the size limits described in “Whole Team”.
-
Determine which skills each team needs.
-
Choose people who have the skills each team needs, are likely to work well together, and are willing to try Agile.
If you’re creating or reorganizing a lot of teams, consider using team self-selection. It’s surprisingly effective at creating highly productive teams that are excited to work together. The book Creating Great Teams: How Self-Selection Lets People Excel [Mamoli2015] describes how it works.
If you can’t dedicate people to their teams…
Agile depends on close collaboration, and that doesn’t work well if people aren’t available. Occasional outside responsibilities are fine, but if you can’t get dedicated team members, Agile probably won’t work.
If team members don’t get along…
It’s normal for new teams to go through a rough patch while they figure out how to work together, so don’t worry if a team struggles at first. The team’s coach and manager can help mediate conflicts. See “Team Dynamics” for more.
If you can’t create long-lived teams…
It’s wasteful to break up high-performing teams, but it won’t stop your teams from being Agile.
If you can’t get the business, customer, or user expertise you need…
Optimizing teams need at least one team member with product management skills, but they don’t necessarily need a traditional product manager. Sometimes developers with a lot of company history know their product and its market better than anyone else. If that’s the case, you’re good to go.
If your teams aren’t pursuing Optimizing fluency, you don’t need a product manager directly on the team, but you still need someone with those skills to work closely with the team, and you still need team members who can represent customer and user perspectives.
Business involvement makes a huge difference to team success. It’s one of the things that sets Agile apart from its predecessors. Make an extra effort to include business, customer, and user perspectives in your teams. If you don’t, the software they deliver is likely to disappoint.
If you can’t get all the developer skills you need…
You may not be able to achieve Delivering fluency, but the Delivering practices are still worth learning and using.
Choose Agile Coaches
Each team needs a coach to help team members learn how to be an effective Agile team. “Coaching Skills” has the details, but briefly:
-
Every team needs someone who can help team members learn how to be an effective, jelled team.
-
Focusing teams need someone who can teach them the planning practices described in Part II.
-
Delivering teams need someone who can teach them the technical practices described in Part III.
-
Optimizing teams need someone who can teach them the business development practices described in Part IV.
Some coaches can cover multiple categories. Each coach can work with one or two teams.
If you can’t hire the coaches you need…
You can grow your own Agile coaches. Choose senior practitioners who team members respect and trust—if they’re not immediately obvious, ask your teams for recommendations—and ask them to take on the challenge. This book has everything they need to get started. Player-coaches who are fully dedicated to a single team are your best choice.
Delegate Authority and Responsibility to Teams
Respect for people’s ability is central to the Agile philosophy, and nowhere is this more apparent than in Agile’s approach to authority and responsibility.
Top-notch execution lies in getting the details right, and no one understands the details better than the people who actually do the work…When equipped with necessary expertise and guided by a leader, they will make better technical decisions and better process decisions than anyone can make for them. [Poppendieck2003]
Mary and Tom Poppendieck
From an organizational investment perspective, this means:
-
Work is assigned to teams, not individuals. Teams decide for themselves how to break their work down into tasks, and who on the team will perform those tasks. You may need to change ticketing systems and other workflow processes to fit this approach. Doing so has implications for performance evaluations, which ties into “Change Harmful HR Policies”.
-
Teams decide their own processes. In particular, teams need to be free to use their own lightweight, tool-free approach to planning rather than being tied to a corporate tool. Management can put constraints on teams’ processes, but they must ensure each constraint has a clearly articulated reason.
-
Focusing teams work with stakeholders to understand business needs and priorities. The organization needs to make sure teams have easy access to stakeholders or their representatives.
-
Delivering teams control their development, build, test, and release processes. Again, management can put constraints on those processes, such as mandating the use of a corporate release pipeline, but make sure teams have the ability to develop and release on their own without waiting for other teams.
-
Optimizing teams control their own budget and product plans. Management defines each team’s purpose, determines overall strategy, and sets the teams’ budgets. They also provide oversight in the form of reviewing business indicators. Within that framework, the organization needs to allow individual teams to decide for themselves how to achieve their purpose and spend their budget.
If work must be assigned to individuals…
If your organization isn’t comfortable with teams making their own task assignment decisions, your organization lacks the trust that Agile requires. You might be able to convince people to change their thinking by trying team-based work with a pilot Agile team, but proceed with caution. Command-and-control management styles are generally incompatible with Agile.
If it’s not a widespread issue, but just a few individual managers that have trouble letting go, see “Change Team Management Style”.
If tools don’t support team-based work…
If your company has existing work assignment systems that are difficult to change, a short-term solution is to create a “phantom” person for each team who receives the team assignments. Alternatively, team members can choose to treat individual assignments as team assignments.
Long-term, it’s better to fix the tools.
If teams have to use a corporate tracking tool…
One of Agile teams’ biggest sources of leverage is the ability to improve and streamline their process. Corporate tracking tools, including so-called Agile Lifecycle Management tools, limit teams’ leverage. Like so many of the products jostling for space on the Agile bandwagon, these tools tend to miss the point of Agile so badly that they actually decrease teams’ agility.
Forcing Agile teams to use a corporate tracking tool for their daily work will decrease their performance. If you don’t have a choice in the matter, a common solution is to maintain two tracking systems: a lightweight Agile approach and the corporate tool. See “Corporate Tracking Tools” for details.
If teams don’t have access to stakeholders…
Unlike waterfall processes, which use an up-front requirements and business analysis phase, Agile teams work with stakeholders throughout development to refine plans and gather feedback. Without access to stakeholders, they won’t build the right thing.
If a team can’t work with one or more stakeholder groups, make sure the team has access to someone who represents those groups’ interests. Choose this person carefully: the quality of the team’s product will depend on that person’s availability and ability to accurately represent stakeholders’ needs.
If Delivering teams don’t have control over their release processes…
You won’t see the full benefit of Delivering fluency until your teams have control over their release processes. That said, there’s enough value to Delivering practices that the zone is still worth pursuing. You can chip away at the problem over time.
If Optimizing teams don’t have control over their product plans and spending…
Optimizing teams need the ability to conduct experiments and adapt their plans, and that requires them to control their plans and spending. Without it, they won’t reach Optimizing fluency.
Change Team Management Style
With teams deciding their own process, making their own task assignments, and coordinating with stakeholders, team-level managers could think there’s no place for them in Agile. But that’s not remotely true. The job of the Agile team manager changes, but it’s no less important than in a pre-Agile team. See “Management” for details.
Talk with managers about their new role and provide training as needed. Make sure their managers’ expectations have changed to match.
If managers have trouble letting go…
Micromanagement is annoying, but it isn’t a deal-breaker in the short term. It does inhibit learning, though, by taking decisions out of team members’ hands. Micromanagers will increase the time and cost required to reach fluency.2
Managers often micromanage when they don’t know what else to do, or when they fear that there won’t be a place for them in an Agile environment. Reassure managers that they still have a role by showing them what that role looks like. Training or a good Agile coach can help.
Create Team Rooms
Agile teams are highly collaborative and communicate constantly. For that communication to be effective, they need a team room designed for their needs. It can be physical or virtual. “Team Room” has the details.
For in-person teams, creating physical team rooms can be one of the most expensive investments you’ll make. It’s also one of the most valuable; as “Team Room” discusses, physical team rooms act as performance multipliers.
When your teams are just getting started, though, you may not yet know what sort of team rooms they need, or even if Agile is a good choice long-term. Your teams probably won’t either. Teams new to Agile underestimate how much they’ll enjoy collaborating and overestimate their desire for privacy.
So it’s okay to hedge your bets on physical workspaces. Set aside the budget for it—you’ll need good team rooms eventually, if you stick with Agile—but in the short term, you can commandeer a large conference room or part of an open-plan office for each team.
Whatever you decide to do, start working on it early. Physical team rooms take a long time to arrange.
If a team is remote…
You can create a virtual team room. “Virtual Team Rooms” describes how.
If you can’t create a physical team room for an in-person team…
In-person teams can use virtual team rooms, too, but I strongly recommend against this. They will experience the worst of both worlds: the inflexibility and commute of in-person work, combined with the communication challenges of remote work.
Establish a Learning-Friendly Purpose for Each Team
Every team has a purpose: its place in the organization’s big-picture strategy. (See “Purpose”.) When a team is learning Agile for the first time, it’s important to choose a purpose that will help team members learn. Practically speaking, this means three things:
-
A purpose that’s valuable, but not time-sensitive. If the team’s under a lot of time pressure, team members will have trouble learning. They’ll default to what’s worked for them in the past rather than taking time to learn new ideas.
-
A purpose that’s self-contained. The more the team depends on other teams, the more coordination challenges it’s likely to face. Some coordination challenges are to be expected, but too many will distract the team from learning.
-
A green-field (brand-new) codebase. Teams learning Delivering practices have a lot to learn, and it’s easier to do so with green-field code. That said, they’ll need to learn how to work with existing code eventually. Teams that have an experienced Delivering coach can ignore this requirement, if the coach agrees. So can teams that aren’t learning Delivering practices.
If there’s an important deadline…
Each team needs plenty of time to learn. If the deadline leaves lots of room to maneuver, you’re okay. If not, it’s usually better to delay trying Agile until after the deadline is met, or to choose different teams.
If there’s no valuable green-field work to do…
It’s more important for teams to do valuable work than to have a green-field codebase. Without an experienced coach, though, teams learning Delivering practices for the first time are likely to have difficulty with pre-existing code. Expect a longer performance dip, more time needed to reach fluency, and more frustration from programmers on the team.
Replace Waterfall Governance Assumptions
Governance is the way work is approved, tracked, and managed at a high level. Most organizations’ governance policies assume a waterfall development approach. Sometimes this requires up-front documentation or phase gates. It often requires a predictive approach to planning.
For best results, governance policies need to be changed to match the Agile approach. That means removing phase gates and using an adaptive approach to planning. See “Agile Governance” for details.
If waterfall governance is required…
It’s wasteful, and will detract from your teams’ agility, but you can adhere to waterfall governance policies if you need to. It’s okay for a few pilot teams, but switch to Agile governance before spreading Agile further.
The most common governance demand is to produce a fixed plan and budget in advance. The simplest way to meet this demand is to use whatever approach you use now, then start the Agile part of the process after you’ve gone through project approval. Alternatively, for teams that are fluent in both the Focusing and Delivering zones, you can allocate 4–8 weeks for “planning,” start working normally, and dial in a high-quality roadmap. (See “Roadmaps”.)
Other up-front documentation, such as a requirements analysis document or design document, can also be done using existing approaches prior to starting the Agile part of your work. Remaining compliance work can usually be scheduled alongside your Agile work, with stories (see “Stories”), like any other request.
Waterfall governance is incompatible with Optimizing fluency, which relies on adaptive planning. If you’re required to adhere to waterfall governance policies, limit your aspirations to the Focusing and Delivering zones.
Change Harmful HR Policies
Agile is a team sport, and despite paying lip service to teamwork, many companies have policies that unintentionally discourage it. Any policy that puts people in competition with each other is going to make Agile more difficult. A particularly destructive example is stack ranking, in which team members are evaluated relative to each other, with the top of the stack getting promotions and the bottom getting fired, regardless of their actual performance.
A related issue is managers who value only tangible output. On an Agile team, there are many ways to contribute to success, such as the person who doesn’t write a lot of code, but spends a lot of time reproducing bugs, or the person who works in the background to improve communication.
Organizations can also develop blame culture, which responds to mistakes by punishing culprits. The Agile mindset, in contrast, treats mistakes as a learning opportunity. For example, a non-Agile organization might fire a programmer for accidentally deleting a crucial production database. An Agile organization would instead ask, “What checks and balances can we put in place to prevent accidental database deletion, and how can we make it easier to recover from these sorts of mistakes?”
These sorts of cultural issues are often reflected in HR policies about promotion and rewards. If people’s careers depend on making themselves look good, regardless of their actual effect on team performance, your teams are likely to have trouble with Agile’s emphasis on collaborative work.
You won’t be able to change your organization’s culture overnight, but you can work on changing HR policies, and managers can change the way they treat their teams. This will take time, so start working on it early. You’re likely to need the backing of senior management.
It helps to look for creative ways to apply existing policies, rather than removing policies altogether, which can be more difficult. Remember, too, that managers often have discretion in how they apply policies, so if you hear that something “can’t be done,” it may be a manager that you need to convince, not HR.
If HR policies are set in stone…
If you can’t change bad HR policies, managers will have to shield their teams from them. Make sure they’re on board with Agile and are savvy about navigating corporate bureaucracy.
If you have a lot of teams, limit your Agile pilot to teams with savvy managers. Use their experiences to motivate the policy changes you need.
Address Security Concerns
This investment usually isn’t an issue, but when it is a problem, it will stop you cold. So check into it, especially if you’re in a security-sensitive industry.
The issue is that in-person teams who use practices such as “Pair Programming” and “Mob Programming” work together at the same computer. This can be worrying from a security perspective, because the person who logged in to the computer isn’t always the one who’s at the keyboard. In fact, the person who logged in might even step away for a moment to go to the bathroom or have a side conversation. Because people switch who’s typing frequently—as often as every few minutes—logging out and back in again every time a new person is at the keyboard isn’t feasible.
If your teams will use those practices, run them by your company’s security team and work with them to resolve their concerns. You can usually find a creative way to support Agile work while also remaining secure. One common approach is to create a locked-down, shared development account. Some companies combine this with dedicated development workstations or shared server-based virtual machines. Email and other individual work takes place on individually assigned laptops.
A related issue is traceability. Some companies require that every commit be traceable to its original authors. You can meet this requirement by adding the authors’ initials or email addresses to the commit comment. Git has a convention of adding Co-authored-by lines to the end of the commit message.3
Some companies require that all code be reviewed prior to release. Pairing and mobbing meet this requirement, but you may need to modify tooling to allow code to be released without a separate review phase. If removing the requirement entirely isn’t an option, you might be able to modify the tool to skip commits that have coauthors.
If there’s no flexibility around security requirements…
You can require that the person who logged in stays at their computer. If they need to step away for a moment, either they switch logins, or work stops until they’re back. This introduces more friction than you might expect, so prefer solutions that allow work to continue.
Teams can also use tools designed for collaborative remote work rather than working at the same computer. This introduces a lot more friction than the other options, even when team members are sitting side-by-side, so I don’t recommend it unless your team is already remote.
1 Excerpted from Fowler’s “Enterprise Rails” article.
2 Thanks to George Dinwiddie for making this point.
3 Thanks to Jay Bazuzi for bringing these commit message conventions to my attention.
Get The Art of Agile Development, 2nd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
