AoAD2 Chapter 5: Invest in Agility

Book cover for “The Art of Agile Development, Second Edition.”

Second Edition cover

This is a pre-release excerpt of The Art of Agile Development, Second Edition, to be published by O’Reilly in 2021. Visit the Second Edition home page for information about the open development process, additional excerpts, and more.

Your feedback is appreciated! To share your thoughts, join the AoAD2 open review mailing list.

This excerpt is copyright 2007, 2020, 2021 by James Shore and Shane Warden. Although you are welcome to share this link, do not distribute or republish the content without James Shore’s express written permission.

Invest in Agility

As we saw in the previous chapter, in order for your teams to get the benefits of Agile, your organization has to buy in to 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.

Most of what holds teams back isn’t the processes they use; it’s the constraints they’re under.

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

1Excerpted from Fowler’s “Enterprise Rails” article at http://martinfowler.com/bliki/EnterpriseRails.html.

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 only included 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 [Fowler 2003], 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 “Agile Performance Over Time” illustrates. This is called “the J curve,” and it’s common to all significant changes. We’ll look at it closer in chapter “Invest in Change”.

A graph showing how an Agile team’s performance changes over time. It shows an Agile change starting out at the same performance level as the status quo, which is marked “Agile introduction; preparing for change.” Then the performance of the Agile change drops rapidly, a period marked “Introducing practices; some resistance to change.” Performance stays low for an unspecified period of time, which is marked “Initial learning; chaos of change.” Then it rises in the shape of an S-curve, which is marked “Gaining proficincy; becoming comfortable with change.” The S-curve crosses the status quo, showing the Agile change’s performance surpassing the status quo, then gradually levels off in a period marked “Reaching fluency; change established.” Finally, it continues improving at a gradual rate, which is marked “Continuous minor improvements.”

Figure 1. Agile performance over time

The time investment will typically pay for itself in the first year. The length of the initial dip depends on the fluency zones each teams is learning:2

2These time frames are ballpark figures based on my experience. Your experience may be different.

  • Focusing: one to four months

  • Delivering: two to six months

  • Optimizing: one to three 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 which learns Focusing skills first and moves to Delivering later will have two dips: a 1-4 month dip when they learn Focusing skills and another 2-6 month dip when they learn Delivering skills.

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 (or near-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.3 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.

3Martin Fowler says, “For a certification to be useful, it needs a correlation with competence in the thing that it certifies. So if Alice has a certification in, say, clojure programming; there should be a high probability that Alice is a competent clojure programmer.” [Fowler 2011] In private communication, he went on to say that usually isn’t the case. “I certainly don’t know of any in the agile world.”

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 them 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.

An Agile team is:

  • Cross-functional. The people on the team collectively have all the expertise needed for the team to fulfill its purpose.

  • Fully dedicated. Everybody on the team is assigned to the team 100%. 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. Over time, the team “jells” into a high-performance whole that’s greater than the sum of its individual contributors.

  • Long-lived. A highly-productive “jelled” team is worth its weight in gold. 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” on p.XX 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. They 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, they 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” on p.XX of the next chapter.

  1. Decide the purpose of each team. (See “Establish a Learning-Friendly Purpose for Each Team” on p.XX.)

  2. 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” on p.XX.

  3. Determine which skills each team needs.

  4. Choose people that 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 [Mamoli and Mole 2015] 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, it’s unlikely Agile will work for you.

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 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.

If a team has a history of interpersonal conflict, they might not be a good fit for Agile. If there’s just one person whose behavior causes conflicts, you might be able to solve the problem with individual mentoring or by moving them to a different team.

If you can’t get the business, customer, or user expertise you need...

Optimizing teams needs 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. It’s crucial, and often overlooked.

[Coffin 2006] describes an experience with two nearly identical teams: one that didn’t include users’ perspectives and one that did. The team with no users took 15 months to produce a product with mediocre value:

The total cost of the project exceeded initial expectations and the application under delivered on the user’s functional expectations for the system... real business value was not delivered until the second and third [releases] and even then the new system was not perceived as valuable by its users because it required them to change while providing no significant benefit.

A team composed of many of the same developers, at the same company, using the same Agile process, later produced a product with compelling value in one-fifth the time.

The first production release was ready after 9 weeks of development... it surpassed scheduling and functional expectations, while still coming in on-budget... The application development team continued to deliver new releases to production approximately every six weeks thereafter. Every release was an exciting opportunity for the team of developers and users to provide value to the company and to improve the user’s ability to accomplish their jobs.

One of the primary reasons for this success was user involvement.

Many of the shortcomings of the [first] system stemmed from a breakdown in the collaborative atmosphere that was initially established. Had users been more involved throughout the project, the end result would have been a system that much more closely aligned with their actual needs. They would have had a greater sense of ownership and communication between the various groups would have been less tense.

...

The success of the [second] system caused many people in the organization to take note and embrace the lessons learned in this project... other project teams restructured their physical arrangements into a shared project room as the [second] team had done.

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...

Delivering fluency depends on bringing a variety of development skills, such as testing and operations, into the team. If that isn’t possible, your teams won’t be able to achieve Delivering fluency. That said, Delivering practices are still worth learning even if teams can’t use all of them. Over time, they can use their experience to make the case for bringing in the people or training they need.

Delegate Authority and Responsibility to Teams

Respect for people’s ability is central to the Agile philosophy.

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. [Poppendieck and Poppendieck 2003]

Mary and Tom Poppendieck

As organizations become more Agile, they entrust more and more decisions to cross-functional teams. You can see it in the fluency zones:

  • Focusing teams are responsible for their process and task planning.

  • Delivering teams are responsible for testing, deployment, and operations.

  • Optimizing teams are responsible for business results.

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” on p.XX.

  • Teams decide their own processes. In particular, teams need to be free to use their own lightweight, tool-free approach to day-to-day planning and task tracking 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 purpose. Chapter “Scaling Agility” explains further.

  • 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” on p.XX.

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 teams to use a corporate tracking tool for their daily work will decrease their performance.

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. Every day, somebody on the team updates the corporate tool from the lightweight tracker.

You can reduce these costs by decreasing the amount of detail teams are required to put into the corporate tool. Ask if the tool really needs to be updated every day and for every task. Instead, see if teams can update it weekly or biweekly. “Roadmaps” on p.XX describes how.

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, you won’t see the benefits of 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 chapter “Ownership” 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 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.4

4Thanks to George Dinwiddie for making this point.

Managers often micromanage when they don’t 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.

Choose Agile Coaches

Each team needs a coach to help them learn how to be an effective Agile team. “Whole Team” on p.XX has the details (see “Coaching Skills” on p.XX), but briefly:

  • Every team needs someone who can help them 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.

Depending on which zones your teams are developing, you might need more than one coach for each team. 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 that 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 that are fully dedicated to a single team are your best choice.

Create Team Rooms

Agile teams are highly collaborative and communicate constantly. In order for that communication to be effective, they need a team room designed for their needs. For in-person teams, it will be a physical space. For remote teams, it will be virtual. “Team Room” on p.XX 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 the “Team Room” practice discusses, physical team rooms act as performance multipliers.

Teams new to Agile underestimate how much they’ll enjoy collaborating.

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 you can’t create a physical team room...

Remote teams can use virtual team rooms.

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.

Physical team rooms are expensive, but worth it. Do note that they don’t have to be literal rooms with walls. (See “Team Room” on p.XX for details.) If you’re not sure if the expense is justified, set up in a conference room for at least three months to evaluate.

Establish a Learning-Friendly Purpose for Each Team

Every team has a purpose: their place in the organization’s big-picture strategy. (See “Purpose” on p.XX.) When a team is learning Agile for the first time, it’s important to choose a purpose that will help them 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, they’ll 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 they’re 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 using Delivering practices.

If you have multiple teams, you’ll need to make sure their purposes align. See chapter “Scaling Agility” for details.

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

For Agile to work well, waterfall governance policies must be changed.

Governance is the way work is approved, tracked, and managed at a high level. Most organizations’ governance policies assume a waterfall development approach. For Agile to work well, those policies must be changed.

Early software development revolved around projects, which had clear start and end dates. When the software shipped, the project was over. When more work was needed, a new project would be started.

Modern software development doesn’t work that way, of course. Software today involves ongoing development, maintenance, and operations. Software is more like a product than a project. Some level of ongoing work is required until the product is retired. But many organizations still fund software development on a project-by-project basis.

Project-based accounting results in a whole series of complications. Projects typically require a fixed budget to be approved in advance. But if you need a budget in advance, you need to commit to a plan in advance. To commit to a plan in advance, you need to know your requirements in advance. To ensure you don’t exceed your budget, you need a way of monitoring conformance to the plan. In other words, you need a predictive process. But Agile is adaptive, not predictive.

Instead of using project-based governance, fund teams on an ongoing “business as usual” basis. Your biggest expense will be people (usually), so budget for a team of X people, where the cost of X is less than the value they’re expected to produce. Track progress through teams’ demos (see “Stakeholder Demos” on p.XX) and expect each team to ship early and often. Look for a steady stream of value, whether that’s revenue or something else. Manage the team at a strategic level: monitor the value they create and adjust their purpose, budget, and team size accordingly. When the team stops providing enough value, shut down their current purpose, or put it on the back burner, and give them a new purpose to fulfill.

This is simplified, but the point holds: for Agile teams, allocate an ongoing budget based on your estimate of value, not cost. Expect your Agile teams to deliver value early and often, measure the actual value they create relative to your estimates, and adjust your plans and costs to match.

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 use “Forecasting” on p.XX to dial in a high-quality roadmap.

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” on p.XX), 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.

If you’re a software development vendor...

If you provide outsourced software services, or other sorts of contract-based software development, you can still be Agile. Your approach will depend on the type of software contract you use.

Time and materials (T&M) contracts are the most compatible with Agile. In a T&M contract, the client simply pays the vendor for work performed. It’s similar to the "business as usual" funding Agile teams prefer.

Predictive T&M contracts put all the risk of incorrect predictions on the client, because if the work takes longer than expected, the client has to keep paying or be left with nothing. Agile T&M contracts can mitigate these risks by specifying regular demonstrations of work in progress, at least once per month delivery of working software, and the opportunity to change or cancel the work after every delivery. This allows the client to use Agile governance of the style described previously.

Fixed-price contracts, in contrast, puts the risk of incorrect predictions on the vendor. In a fixed-price contract, the project requirements are defined in advance. The vendor quotes a price based on those requirements, and if development takes longer than predicted, the vendor eats the extra cost. Vendors typically mitigate this risk by charging high change fees. They’ll often quote a low price in order to win the bid, then make their profit from the inevitable change requests.

Given the inevitability of changes in software development, fixed-price software contracts create an adversarial relationship between client and vendor that’s at odds with Agile’s philosophy of customer collaboration and responsiveness to change. That said, Agile teams can perform fixed-price work. Start with whatever estimating and bidding process you use currently, then use your Agile teams for the development and delivery portion of the work.

Contracts that depend on up-front requirements are incompatible with Optimizing fluency, but they’re fine for 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 only value 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.

Rewarding individuals instead of teams makes this worse. It sends a message that assisting others is less important than pursuing your own goals. At its worst, emphasis on individual work turns into hero culture, where talented individuals are rewarded for working long hours in isolation, often to the detriment of overall team performance.

Organizations can also develop blame culture, which responds to mistakes by punishing culprits. The Agile mind-set, 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 sharp 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 colocated teams who use practices such as “Pair Programming” on p.XX and “Mob Programming” on p.XX 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 is at the computer 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 VMs. 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.5

5Documented at https://git.wiki.kernel.org/index.php/CommitMessageConventions. Thanks to Jay Bazuzi for bringing this to my attention.

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 co-authors.

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.

If you’re required to have a separate code review step...

Code written by a pair or mob has already been peer reviewed, so teams can rubber-stamp reviews of that code. It adds friction, though, so it’s best to remove this requirement prior to spreading Agile widely.

Go Shopping

Whether they’re in-person or remote, your teams will need equipment, tools, and supplies to make collaboration more effective.

For in-person teams, provide following equipment and supplies. Although some of these can be replaced with electronic tools, invest in the physical equipment. It’s not very expensive and it will allow your team to take advantage of the strengths of face-to-face collaboration.

  • Two big magnetic whiteboards6 for planning purposes. I like to use a single double-sided, six-foot wide magnetic whiteboard on wheels. It makes it easy for the team to roll their plans into meeting rooms. It needs to be magnetic so you can stick cards to it easily.

  • Lots of additional whiteboard space, preferably magnetic, for discussions and charts.

  • A large plastic perpetual calendar (three months or more) for marking important dates.

  • Sound-damping partitions to define the team’s workspace and prevent noise pollution, or an enclosed team room.

  • Stools or other ways to easily sit with someone temporarily.

  • Notepads or handheld whiteboards for sketching ideas while seated.

  • Miscellaneous toys and conversation pieces to inspire discussion and interaction among team members.

  • Flip chart paper, one or two flip-chart easels, and a way to attach flip chart pages to walls (such as blue tape, poster tack, or T-pins).

  • Index cards in a variety of colors (at least 2,000 of each color). Make sure everyone on the team can distinguish the colors.7

  • Sticky notes in a variety of colors, sizes, and shapes.

  • Pencils, pens, and water-based felt-tip pens for writing on cards and sticky notes. Avoid permanent markers such as Sharpies; they have a strong odor and invariably get used on a whiteboard.8

  • Dry-erase markers for whiteboards, water-based flip-chart markers for flip-charts, and wet-erase markers for semi-permanent whiteboard notes and the perpetual calendar. Avoid scented markers.

  • Magnetic push-pins for attaching index cards and documents to whiteboards.

  • A copy of this book and any other useful reference material.

6Technically, a “magnetic whiteboard” isn’t actually magnetic, but has a steel backing so that magnets stick to it.

7One out of eight men have some form of color-blindness.

8Pro tip: you can remove permanent marker from whiteboards by writing over it with a whiteboard marker, then immediately erasing.

In-person teams using pair programming also need pairing stations (see “Pair Programming” on p.XX for details):

  • Wide desks suitable for side-by-side work. Some teams prefer a mix of standing and sitting desks, or adjustable-height desks.

  • One development-grade computer at each pairing station.

  • Two keyboards and mice at each station. Some people prefer to use their own keyboard and mouse; in that case, make sure each computer’s USB ports are easily accessible, because they’ll be moving between pairing stations multiple times per day.

  • At least two monitors at each station.

In-person teams using mob programming need a mobbing station (see “Mob Programming” on p.XX for details):

  • Desks with enough seats for every member of the team, plus a few guests, with room for people to easily switch seats.

  • A “driver’s seat,” easily accessible, with a mouse, keyboard, and development-grade computer.

  • A “navigator’s seat” at the same desk as the driver’s seat, or close enough for the driver and navigator to easily talk to each other.

  • At least one monitor, typically 60" diagonal or more, that’s large enough to be seen clearly from all seats. 4K TVs often work well for this purpose. Make sure to accommodate everyone’s vision needs.

Remote teams need an electronic version of the team workspace:

  • Videoconferencing software, such as Zoom, for real-time conversation.

  • Messaging software, such as Slack, for asynchronous conversation.

  • Collaborative workspace software, such as Miro or Mural, for free-form collaboration.

  • Collaborative versions of task-specific tools, where possible, such as Figma for UX and UI design.

  • Inexpensive tablets for collaborative whiteboard sketches.

  • An additional monitor or tablet for videoconferencing, so people can see each other and work at the same time.

  • For Delivering teams, collaborative programming tools, such as Tuple or Visual Studio Live Share, that support pairing or mobbing (see “Pair Programming” on p.XX and “Mob Programming” on p.XX for details).

In all cases, avoid purchasing new licenses for Agile Lifecycle Management software or other tracking software unless the team explicitly requests it. Even then, wait until the team has tried the lightweight planning practices described in Part II.

Share your feedback about this excerpt on the AoAD2 mailing list! Sign up here.

For more excerpts from the book, or to get a copy of the Early Release, see the Second Edition home page.

If you liked this entry, check out my best writing and presentations, and consider subscribing to updates by email or RSS.