AoAD2 Chapter 4: Investing 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 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.

Investing in Agility

One of the recurring themes in this book is that, in order to be 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.

Investing in Agile is important because it changes your constraints. Most of what’s holding teams back today 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.

1. 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 the “Agile Performance Over Time” figure illustrates.

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 the teams are learning:

  • Focusing: one to four months

  • Delivering: two to six months

  • Optimizing: one to three months

These periods overlap, so a team that’s learning Focusing and Delivering skills together will have a productivity 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 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 3-12 months, when they’re dealing with three hits all at once: a real delay from learning, a perceived delay from focusing on getting things done, and the cost of finishing work on pre-Agile features that were declared “done” without actually being done.

This frustration can lead to teams being redirected away from learning how to be 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 cost of learning, but it will shift the cost towards the faster end of the range. 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. They’re money grabs. Most demonstrate nothing more than the ability to connect butt to chair for a few days. Some are connected to 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 mailing list 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 productivity dip at all, now isn’t a good time to invest in change. If there’s never 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.

2. 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 complete its work.

  • Full-time. Everybody on the team is assigned to the team 100%. Specialists can come help from time to time, but core team members are dedicated solely 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. The “Whole Team” practice has the details, but briefly:

  • Every team needs programming skills. The specific programming skills depend on the team’s purpose.

  • Every team needs a way to determine what the team will work on next. Although it’s best if the team has the skill to do this themselves, Focusing and Delivering teams can work with a business representative who’s outside the team. The representative needs to be readily available to answer questions and attend planning meetings.

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

  • 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, database 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, follow these steps. Either way, remember to get teams’ buy-in, as described in the “Get Team Buy-In” section.

  1. Decide the purpose of each team.

  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 the “Whole Team” practice.

  3. Determine which skills each team needs.

  4. Choose people and coaches 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 allocate people full-time...

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

[Coffin 2006] describes an experience with two nearly identical teams: one that didn’t include users’ perspective 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... In the first two months of live production usage over 25,000 citations were entered using the new system. 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.

Customer involvement makes a huge difference to product 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 products they deliver are likely to disappoint.

If you can’t get the Delivering skills you need...

Delivering practices have a lot of benefits, so they’re still worth learning even if teams can’t be responsible for every aspect of their products’ delivery. They won’t reach fluency until they can, but, over time, they can use their experience to make the case for bringing in the people or training they need.

If you can’t get the Optimizing skills you need...

An Optimizing team needs business expertise, but they don’t necessarily need a traditional product manager. Sometimes technical team members 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 a team doesn’t have anybody with business expertise, though, the Optimizing zone is a mistake. Stick with the Focusing and Delivering zones.

3. Choose Agile Coaches

Agile relies on self-organizing teams. A self-organizing team doesn’t have a predefined leader; instead, the team decides for itself who is in charge of what. They seamlessly defer leadership responsibilities from one person to the next, moment to moment, depending on the task at hand and the expertise of those involved.

When a team first forms, though, people won’t work together so easily. In addition, when teams are new to Agile, they have a lot to learn about how Agile works. Somebody needs to help team members learn.

This person is the Agile coach. Their job is twofold: first, to help the team learn how to use their Agile method; second, to help the team learn how to work together as an effective self-organizing team, which includes working together to remove organizational roadblocks. Ultimately, the job of the Agile coach is to make themselves unnecessary, so they can move on to another team.2

2As Andrew Stellman points out on Twitter (https://twitter.com/AndrewStellman/status/1316114014322274304), companies need to ensure that this sort of lateral movement enhances, rather than harms, their coaches’ careers.

Coaching ability typically falls into three categories:

  • coaching self-organization, team development, and Focusing zone practices

  • coaching Delivering zone technical practices

  • coaching Optimizing zone business development practices

It’s rare to find one person who can coach teams in all three categories, although experienced Delivering and Optimizing zone coaches can often handle the first category as well. Teams need coaching in all the skills they’re developing, so you might need more than one coach per team if your teams are developing fluency in multiple zones simultaneously.

Choose your teams’ coaches when you form the teams. For pre-existing teams, if no one on the team is qualified to be the coach, you’ll need to add a coach to the team. Make sure the team accepts their coach. The most effective coaches lead from a position of earned respect, not organizational fiat. Similarly, don’t put coaches in a position of authority over the teams they’re on. It’s easier for people to learn if they’re not afraid of being judged.

My preferred type of Agile coach is the player-coach: a full-time member of the team who has genuine expertise and leads by example. Another popular approach is the facilitator-coach, often called a Scrum Master,3 who leads from the sidelines by facilitating conversations and resolving organizational roadblocks.

3The name “Scrum Master” originated in the popular “Scrum” method. The name is misleading; it‘s supposed to mean someone who has reached mastery in their understanding of Scrum, not someone who has authority or control over the team.

One of the reasons I prefer player-coaches is that there usually isn’t enough work to justify a full-time Scrum Master on each team.4 A single Scrum Master typically ends up serving multiple teams, which reduces the effectiveness of their coaching, as they’re not present to see and respond to team challenges. Scrum Masters often end up as glorified meeting organizers, which isn’t a good use of their talents.

4If you make the investments in this chapter, that is. If you don’t make the investments, there will be plenty of roadblocks for your Scrum Masters to beat their heads against. Think of it as a jobs program.

If you can’t hire any coaches...

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. Player-coaches that are dedicated full-time to their teams are your best choice.

This book has everything your coaches need to learn Agile practices, including lots of references to further reading. There’s less about how to coach self-organization and team development; for books about those topics, as well as coaching in general, see the “Investing in Agility Further Reading” section.

4. Create Team Workspaces

Agile teams are highly collaborative and communicate constantly. In order for that communication to be effective, not distracting, they need a team workspace designed for their needs. For most teams, it needs to be a physical work space. For teams that use remote work, it will be virtual. The “Team Room” practice has the details.

For in-person teams, creating a physical workspace is 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 productivity 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 floorplan for each team. If you set up any of your teams in an open floorplan, be aware that Agile teams have a lot of conversations and can be exuberant about successes. This could disturb their neighbors.

Whatever you decide to do, start working on it now. Physical team spaces take a long time to arrange.

If you can’t colocate your teams...

Agile works fine with fully remote teams. I address how to make Agile practices work for remote teams throughout this book. However, I do assume that your company and teams already know how to support remote work. Doing remote work well takes dedicated effort and additional organizational investment that’s beyond the scope of this book. REMOTE: Office Not Required [Fried and Hansson 2013] is a good resource to learn more.

What doesn’t work is partially-remote teams. The people off-site will miss out on the ad-hoc conversations that take place in the office. They won’t be able to keep up. It’s okay for people to work from home once in a while, but it doesn’t work to have a few people who are in a different location entirely. Everybody needs to be together, or everybody needs to be remote.

If you have a partially-remote team, you can work around the issue by requiring that the people in the office act as if they are remote, too. That means that all conversations need to happen in the team’s virtual team room (their online tools), even if they’d be easier and faster face-to-face. Otherwise, it’s too easy to leave out the people who are remote.

It also doesn’t work to have people with wildly different work hours. Everyone on a team should have at least a five or six hour overlap in their core hours. If there are people on your teams who can’t do that—for example, if they’re in very different time zones—either rearrange your teams or choose different teams to be Agile.

5. Establish a Learning-Friendly Purpose for Each Team

Every team has a purpose: their place in the organization’s big-picture strategy. Most software teams’ purpose involves building a product, or part of a large product, or serving a specific market segment. Sometimes a team’s purpose will be to promote some organizational initiative, such as moving software to the cloud, or improving uptime.

Teams’ purposes change over time. When a team is learning Agile for the first time, it’s best 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 their purpose isn’t valuable, the team will have trouble engaging stakeholders. 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 planning and scheduling challenges they’ll face.

  • A green-field (brand-new) codebase. This is only necessary for teams learning Delivering practices. Delivering teams do a lot to make their code easy to modify and maintain, and it’s more difficult to learn how to do that when working with existing code.

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 green-field work to do...

Fluent Delivering teams can work on pre-existing code, of course, but it requires advanced techniques. Teams learning Delivering practices for the first time are likely to have difficulty with pre-existing code. Expect a longer productivity dip, more time needed to reach fluency, and more frustration from programmers on the team.

You can reduce (but not eliminate) these added costs by hiring a coach that has deep experience using Delivering practices with existing code. In particular, they need experience with test-driven development, refactoring, and evolutionary design. (For details about these practices, see Part III.)

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

Mary and Tom Poppendieck

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

  • Focusing teams take responsibility for their process and task planning.

  • Delivering teams take responsibility for testing, deployment, and operations.

  • Optimizing teams take responsibility for product planning and 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 the “Change Harmful HR Policies” section.

  • Teams decide their own processes. In particular, teams should be free to use their own approach to day-to-day planning and task tracking rather being tied to a corporate tool. Management can put constraints on teams’ processes, but make sure that there’s a thoughtful reason for those mandates, not just foolish consistency.5

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

5Ralph Waldo Emerson: “A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines... Speak what you think now in hard words, and to-morrow speak what to-morrow thinks in hard words again, though it contradict everything you said to-day.”

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 demonstrating success 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 the “Change Team Management Style” section.

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. 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 in 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 semi-monthly, and find out the smallest item that managers really need to track. Minimum marketable features are a good choice. If that’s not enough detail, user stories also work. (See the “Planning” chapter for more about these terms.) Further detail is counterproductive.

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

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

Agile team managers manage the work system rather than individual work.6 Their job is to guide their team’s context so that the team makes correct choices without explicit management involvement.

6Thanks to Diana Larsen for her contributions to this section.

In practice, this means team managers:

  • Make sure the right people are on the team, so that the team has all the skills needed for its work. This includes coordinating hiring and promotions.

  • Make sure the team includes the coaches it needs, and act as a backup coach, particularly around interpersonal issues.

  • Mediate interpersonal conflicts, help team members navigate the chaos of change, and help team members jell as a team.

  • Help individual team members develop their careers. Mentor individuals to become future leaders and encourage team members to cross-train so that the team is resilient to the loss of any one person.

  • Monitor the team’s progress towards fluency—the beginnings of Parts II-IV describe how—and coordinate with the team’s coaches to procure training and other resources the team needs to reach fluency.

  • Procure the tools, equipment, and other resources the team needs to be productive.

  • Ensure that the team understands how their work fits into to big picture of the organization, that they have a charter (the Purpose, Context, and Alignment practices in the “Teamwork” chapter), and that the charter is updated regularly.

  • Provide insights about how well the team is fulfilling their charter and how their work is perceived by stakeholders, particularly management and business stakeholders.

  • Maintain awareness of the relationships between the team and its stakeholders. Help the team understand when and why those relationships aren’t working well.

  • Advocate for the team within the rest of the organization, and coordinate with peer managers to advocate for each others’ teams. Help the team navigate organizational bureaucracy and remove impediments to their success.

Managers’ managers also need to change their expectations to match.

If managers have trouble letting go...

Micromanagement is annoying, but isn’t a deal-breaker in the short term. 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.

8. Replace Waterfall Governance Assumptions

Governance is the way work is approved, tracked, and managed. Not using waterfall governance for Agile teams may seem obvious, but waterfall assumptions can be subtle and widespread. They often stem from outdated views of software development.

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 a product, not a project, and 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. And, oops, Agile is adaptive, not predictive.

Agile governance is simpler. Fund products 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 product’s value. Track progress by expecting the 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 product stops providing enough value, shut it down, or put it on the back burner, and give the team a new product to work on.

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

You can adhere to waterfall governance policies if you need to. It’s okay for a few pilot teams, but it’s wasteful, so switch to Agile governance before spreading Agile more widely. Even for a pilot team, waterfall governance is like sand in the gears: a little bit is wasteful and annoying, and a lot will grind you to a halt.

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 have both Focusing and Delivering fluency, you can allocate one or two months for “planning,” conduct 4-8 real development iterations, and use the practices in the “Planning” chapter and the “Forecasting” chapter 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 user stories (see the “Stories” practice), like any other request.

Waterfall governance is incompatible with Optimizing fluency, which relies on a flexible product-based approach. If you’re required to adhere to a waterfall governance policy, limit your aspirations to the Focusing and Delivering zones.

If you’re a software development provider...

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

Fixed-price contracts, in contrast, puts the risk of incorrect predictions on the provider. In a fixed-price contract, the project requirements are defined in advance. The provider quotes a price based on those requirements, and if development takes longer than predicted, the provider eats the extra cost. Providers 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 provider 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.

Cost-plus contracts inhabit a middle ground between T&M contracts and fixed-price contracts. Risk is shared between client and provider. They’re still based on an up-front definition of requirements, though, so the Agile approach is the same as for fixed-price contracts.

Contracts that depend on up-front requirements are incompatible with Optimizing fluency, but they’re fine for the Focusing and Delivering zones.

9. 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 people 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 that 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 smooth over interpersonal conflicts.

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?”

It takes time to change HR policies, so start on them 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 your organization has a cultural problem, there’s probably not much you can do about it in the short term. That’s okay. Focus on changing the way managers treat your Agile teams rather than trying to change the whole organization.

If HR policies are set in stone...

Individual managers can often work around or mitigate harmful HR policies, so bad policies aren’t a deal breaker, so long as your teams’ managers are on board with Agile and are savvy about navigating corporate bureaucracy.

If you have a lot of Agile teams, you won’t be able to get a savvy manager for every team, so you’ll need to change the policies first. If you can’t change HR policies, limit your Agile aspirations to a few pilot teams—with sharp managers—and use their experiences to motivate the changes you need.

10. Address Security Concerns

This investment only applies to colocated Delivering teams, which use techniques such as the “Pair Programming” practice or the “Mob Programming” practice to work together at the same computer. This can be worrying from a security perspective, because the person who logged in to the computer might not be the one who is actively using the computer. In fact, the person who logged in might even step away 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.

Work with your company’s security team 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 emails to the commit comment. Git has a convention of adding Co-authored-by lines to the end of the commit.7

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

11. Go Shopping

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

For colocated 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. The “Ownership” chapter has more details.

  • Two big magnetic whiteboards8 for planning purposes. I like to use a two-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.

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

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

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

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

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

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

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

Colocated Delivering teams using pair programming also need pairing stations (see the “Pair Programming” practice 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.

Colocated Delivering teams using mob programming need a mobbing station (see the “Mob Programming” practice 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.

  • For Delivering teams, collaborative programming tools that support pairing or mobbing (see the “Pair Programming” practice and the “Mob Programming” practice 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.

Further Reading

TBD

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.