Agile Book Club: What Is Agile?

Fridays from 8:00 – 8:45am Pacific, I host an online discussion inspired by the new edition of my book, The Art of Agile Development. Each session uses a chapter from the book as a jumping-off point for a wide-ranging discussion about Agile ideas and practices.

On October 22nd, we kicked off the book club with a foundational topic: What Is Agile?

Discussion topics:

  • What does “Agile” mean to you?

  • What does “Agile” mean to your organization? How is that different?

  • When you’ve seen Agile at its best, what was it like?

  • If you could wave a magic wand and change one misconception about Agile, what would it be?

Visit the event page for more information, including an archive of past sessions. For more about the book, visit the Art of Agile Development home page.

AoAD2 Chapter: Choose Your Agility

This is an excerpt from The Art of Agile Development, Second Edition. Visit the Second Edition home page for additional excerpts and more!

This excerpt is copyright 2007, 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.

📖 The full text of this chapter is available below, courtesy of the Art of Agile Development book club! Join us on Fridays from 8-8:45am Pacific for wide-ranging discussions about Agile. Details here.

Choose Your Agility

There’s no point in Agile for the sake of Agile. Instead, ask yourself two questions:

  1. Will Agile help us be more successful?

  2. What will it take to achieve that success?

When you can answer these questions, you’ll know whether Agile is right for you.

The Agile Fluency Model

In 2014, I partnered with Diana Larsen to analyze why companies see such different results from their Agile teams. We had both worked with Agile teams from the beginning. Over the years, we noticed that they tended to see dramatically different types of results, and those results tended to cluster in different “zones.” We captured these observations in the Agile Fluency Model. A simplified view is shown in the “Agile Fluency Model” figure. [Shore2018b]

A picture of the Agile Fluency Model. It shows a path from “Pre-Agile” through a shift in team culture to “Focusing,” followed by a shift in team skills to “Delivering,” then a shift in organizational structure to “Optimizing,” and finally a shift in organizational culture to “Strengthening.” The path continues and fades away, as if there are additional zones yet to be discovered.

Figure 1. A simplified view of the Agile Fluency Model

Each zone is associated with a set of benefits. To reap those benefits, a team needs fluency in that zone. A team has fluency when they’re able to apply all the skills associated with the zone without conscious effort.

Although the figure shows a straightforward path from one zone to the next, reality is messier. Teams can achieve fluency in any zone, in any order, although the progression in the figure is typical.

The skills needed for fluency are listed in the introductions to Parts II through IV. But fluency isn’t something a team can achieve on its own. Your organization also has to invest in your teams’ fluency. That means more than paying lip service to Agile ideas. It has to make actual, meaningful changes that cost time, money, and political capital.

The results you get from your Agile teams depend on how well your company buys into Agile ideas. When a company fails to achieve the results they want from Agile, it’s usually because they didn’t make the required investments. Often, they don’t even realize what was needed.

Make a conscious choice to invest in agility.

Make a conscious choice to invest in agility. Consider each zone carefully. Each has costs; each has benefits. Choose the ones that have the right cost-benefit trade-offs for your situation.

You probably won’t be able to convince your company to invest in every zone. That’s okay. In contrast to maturity models such as the Capability Maturity Model Integration (CMMI), the fluency model doesn’t show a progression from low skill to high skill. Instead, it shows multiple investment/benefit choices. Although the diagram shows the most common progression, each zone may be chosen independently. Each has value on its own.

Focusing Zone

The Focusing zone is about Agile fundamentals: focusing on business results; working as a team; taking ownership. Teams that are fluent in this zone focus development on their team’s core purpose, release their most valuable features first, and change direction in response to changing business needs. They’re constantly Focusing on their organization’s most valuable priority.

For most teams and organizations, this requires a shift in how they think about teams. Pre-Agile organizations make plans in advance, ask teams for estimates, and expect reports about how work is progressing relative to those estimates. Focusing teams revise their plans frequently—at least every month—and demonstrate progress by showing what they’ve completed.

Pre-Agile organizations break their plans into tasks, assign those tasks to individuals on the team, and judge individuals based on how well they complete their tasks. Focusing teams do their own task breakdowns, decide for themselves who will work on each task, and expect to be judged on their ability to create value as a team.

For a team to succeed, your organization will need to support these changes with concrete investments in the form of changes to team structure, management, and work environment. (I’ll go into detail in the next chapter.) It’s a “good news, bad news” situation: the bad news is that, when the rubber meets the road, some organizations won’t be willing to invest. The good news is that, if they refuse, you’ve discovered early on that they’re not really on board with the Agile philosophy. You just saved yourself years of frustration and heartache chasing Cargo Cult Agile.

If you are able to get buy-in, Focusing fluency will take each team about 2–6 months of dedicated effort to achieve. With proper support, they’ll exceed their prior levels of performance within 1–4 months.1 Part II has the practices they’ll need.

1The time frames in this chapter are all ballpark figures based on my experience. Your experience may be different.

Delivering Zone

Agile teams may change their plans at any time. For most teams, this slowly degrades the quality of their code. They gradually lose their ability to make cost-effective changes. Eventually, they say they need to throw away the software and rewrite—an expensive and wasteful proposition.

Delivering teams prevent this problem through technical excellence. They design their code to respond to frequent changes. They keep code quality high, so they don’t waste time hunting bugs. They refine their production lifecycle so releases are painless and operations are manageable. They’re capable of Delivering reliable, low-defect software whenever it makes the most business sense.

Achieving these results requires a substantial investment in team members’ development skills, as well as structural changes to integrate people with skills such as testing and operations into each team.

If your company makes these investments, Delivering fluency will take each team 3–24 months to develop, and you’ll see improved performance within 2–6 months. The exact amount of time each team needs will depends on the quality of its existing code and how much coaching team members receive. Part III has the practices.

Optimizing Zone

Most companies would be satisfied with Focusing and Delivering fluency. But Agile imagines more. In its full glory, Agile is a world in which teams twirl and dance in response to changing market conditions. They experiment and learn; develop new markets; outmaneuver the competition.

Optimizing teams achieve this level of agility. They understand what their market wants, what your business needs, and how to bridge the two. Or, as in a startup environment, they know what they need to learn and how to go about learning it. They’re constantly Optimizing their product plans to achieve the most value possible.

This requires a shift in organizational structure. Creating optimal plans requires constant attention by people with deep business and product expertise, and that means having product and market experts join development teams full-time. It also means giving those teams full responsibility for their product budgets and plans.

These structural changes require high-level permission in the organization. It can be difficult to obtain. Teams typically need to spend at least a year building trust via Delivering fluency before they get permission for these investments. Once that happens, Optimizing fluency takes another 3–9 months to develop, although you’ll see improvements within 1–3 months. But even then, Optimizing is a never-ending process of experimentation, learning, and discovery. Part IV describes how to begin.

Strengthening Zone

There’s one final zone in the Agile Fluency Model. It’s largely speculative: a possible future for Agile. It’s also only appropriate for organizations on the bleeding edge of management theory and practice. That puts it out of scope for this book. Briefly, the Strengthening zone involves distilling teams’ collective insights and channeling them into organizational improvements. If you’d like to learn more, see the “Into the Future” chapter.

Choose Your Zones

Which fluency zones should your teams pursue? It depends on which zones your organization can support. In a vacuum, Focusing, Delivering, and Optimizing, all together, are your best choice. The combination of all three provides the best results and purest realization of Agile ideas.

But choosing all three zones also takes the most investment. If you can’t justify those investments, you’re likely to have trouble getting the support you need. And without sufficient investment, your teams will have trouble reaching fluency. You’ll incur the costs of learning without getting all the benefits. You might even see worse results than now.

In other words, choose only the zones your company both needs and is willing to pay for.

So, which zones should you choose?

  • Every Agile team needs Focusing fluency. It’s fundamental. If your company can’t at least invest in Focusing fluency, Agile probably isn’t a good fit, although you may be able to work your way up to it by starting with Delivering fluency instead.

  • Delivering fluency decreases costs and increases development speed. Without it, your code will eventually succumb to technical debt. That makes the Delivering zone a no-brainer for most teams. That said, some organizations aren’t ready to make the big investments in learning and code quality that the Delivering zone requires. It’s okay to start with Focusing fluency first, demonstrate success, and then use that to make the case for further investment.

  • Optimizing fluency is where Agile shines brightest. It’s also a lot to ask. For most organizations, it’s best to build trust by demonstrating fluency in the Focusing and Delivering zones first, then gradually take on more responsibility. But if your organization already has a culture of delegating decision-making authority to cross-functional teams, as is often seen in startups, Optimizing fluency will give you great results.

For details about each zone and their benefits, see the introductions to Part II, Part III, and Part IV. For a detailed summary of the investments required, see the “Summary of Investments” sidebar. If you aren’t sure which zones to choose, start with Focusing and Delivering.

Whichever zones you choose, invest in learning all their practices simultaneously. The practices in the later zones make the earlier zones work better, so you’re better off adopting them together rather than one at a time. But if you can’t invest in every zone you want, that’s okay. It takes longer, but you can build up to the other zones over time.

Once you know which zones you want, it’s time to consider your organization’s investments in more detail. We’ll study them in the next chapter.

Share your thoughts about this excerpt on the AoAD2 mailing list or Discord server. Or come to the weekly book club!

For more excerpts from the book, see the Second Edition home page.

AoAD2 Chapter: How to Be Agile

This is an excerpt from The Art of Agile Development, Second Edition. Visit the Second Edition home page for additional excerpts and more!

This excerpt is copyright 2007, 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.

📖 The full text of this chapter is available below, courtesy of the Art of Agile Development book club! Join us on Fridays from 8-8:45am Pacific for wide-ranging discussions about Agile. Details here.

How to Be Agile

How do you get from Agile’s conglomeration of ideas to actual, functioning Agile teams?

Practice. Lots and lots of practice.

Practicing Agile

Every team has a way of working—a process, or method—that it follows, even if it isn’t formally written down. The method reflects an underlying philosophy of software development, although that philosophy is rarely articulated and isn’t necessarily self-consistent.

To be Agile, you need to change your process to reflect the Agile philosophy.

To be Agile, you need to change your process to reflect the Agile philosophy. This is both easier and harder than it sounds. It’s easy because, in most cases, you can start with one of the many off-the-shelf Agile methods, such as the one in this book. It’s hard because you need to change your way of working, and that involves changing a lot of habits.

The Agile community calls those habits practices. Most of this book is dedicated to them. They’re things like planning sessions, automated builds, and stakeholder demos. Most have been around for decades. Agile methods combine them in unique ways, accentuating those parts that support the Agile philosophy, discarding the rest, and mixing in a few new ideas. The result is a lean, powerful, self-reinforcing package.

Agile practices often perform double- and triple-duty, solving multiple problems simultaneously and supporting each other in clever and surprising ways. You won’t truly understand how an Agile method works until you’ve seen it in action for a while.

As a result, although it’s tempting to customize your Agile method from the beginning, it’s best to start with a by-the-book approach. The practices that are the least familiar are the ones that are most tempting to cut, but they’re the ones you need most, if you’re really going to be Agile. They’re the ones that involve the biggest change in philosophy.

The Road to Mastery

Mastering the art of Agile development requires real-world experience using a specific, well-defined Agile method. Start with a by-the-book approach. Put it into practice—the whole thing—and spend several months refining your usage and understanding why it works. Then customize. Choose one of the rough edges, make an educated guess about what happens, and repeat.

This book is dedicated to that purpose. It’s a curated set of Agile practices that have been proven in the real world. To use it to master the art of Agile development—or simply to use Agile practices to be more successful—follow these steps:

  1. Choose a subset of Agile ideas to master. The “Choose Your Agility” chapter will help you decide.

  2. Use as many of the corresponding practices as you can. They’re described in Parts II through IV. Agile practices are self-reinforcing, so it works best when you use them all together.

  3. Apply the practices rigorously and consistently. If a practice doesn’t work, try following the method more closely. Teams new to Agile often underapply the practices. Expect to take two or three months to start feeling comfortable with the practices and another two to six months for them to become second nature.

  4. As you become confident you’re applying the practices correctly—again, give it several months—start experimenting with changes. The practices in this book each include a discussion of why the practice works and how it can be changed. Every time you make a change, observe what happens and make further improvements.

  5. There is no last step. Agile software development is an ongoing process of learning and improvement. Never stop practicing, experimenting, and evolving.

The “Road to Mastery” figure illustrates the process. First, follow the rules; then break the rules; and finally, leave the rules behind.1

1This progression was inspired by Alistair Cockburn’s discussions of Shu-Ha-Ri.

How to Begin

Your first steps depend on what you want to accomplish. Are you joining an existing Agile team, introducing Agile to one or more teams, or improving the Agile teams you already have?

Joining an Agile Team

If you’re planning to join an existing Agile team, or just want to know more about how Agile works in practice, you can skip ahead to Parts II through IV. Each part starts with a “day in the life” story that describes what Agile can look like. Every Agile team is different, so the team you join won’t be exactly the same, but the stories will give you an idea of what to expect.

After reading the stories, skip around to the practices that interest you. Each is written to be a standalone reference. If your team uses a practice that isn’t in the table of contents, check the index—it may be under a different name.

A diagram with three sections, labelled “Follow the Rules (Apprentice),” “Break the Rules (Journeyman),” and “Ignore the Rules (Master).” Each section has double-headed arrows indicated that it’s possible to travel between each section. In the “Follow the Rules” section, a small flow chart starts by saying “Pick a method,” then shows an endless loop from “Follow it thoughtfully and rigorously” to “Reflect on your experiences” to “Study the method further” (and then back to “Follow it thoughtfully and rigorously”). In the “Break the Rules” section, a flow chart shows an endless loop from “Observe results. What could be better?” to “Make a change” to “Follow it thoughtfully and rigorously.” Finally, in the “Ignore the Rules” section, a flow chart shows an endless loop alternating between “Do what feels right” and “Observe results.”

Figure 1. The road to mastery

Introducing Agile

If you’re helping your organization create Agile teams, or you want to convince it to do so, the remaining chapters in Part I will help you get started. Use the following checklists to stay organized.

First, make sure Agile is a good fit for your company:

  • Choose an approach to Agile that your organization can support. (See the “Choose Your Agility” chapter.)

  • Determine what your organization needs to do for Agile to be successful. (See the “Invest in Agility” chapter.)

  • Get buy-in to trying Agile. (See the “Invest in Change” chapter.)

  • If you have multiple teams, decide how you’re going to scale. (See the “Scaling Agility” chapter.)

In the weeks leading up to a team trying Agile:

  • Determine who the team’s coach or coaches will be, and identify at least one person who will act as the team’s product manager. (See the “Whole Team” practice.)

  • Have the team’s product manager meet with the team’s executive sponsor and key stakeholders to create a draft purpose. (See the “Purpose” practice.)

  • Ensure the team has a physical or virtual team room. (See the “Team Room” practice.)

  • Schedule and conduct the team’s chartering session. (See the “Planning Your Chartering Session” sidebar.)

  • Ask the team to review its new practices. Provide copies of this book for people to study on their own, suggest that they try some practices in their current work, and consider providing training for practices that seem challenging. (The practices are described in Parts II through IV.)

When a team is ready to begin, take a deep breath and:

  • Have team members plan their first week. (See the “Your First Week” section.)

Improving Existing Agile Teams

If you already have Agile teams and you want them to be better, your approach depends on what kinds of improvements you want to make.

If you’re interested in fine-tuning your team’s existing process, skip ahead to Parts II through IV and read the practices that interest you. If you want to make bigger improvements, the process is the same as introducing Agile to a team, except you can focus just on the things you want to change. Use the “Introducing Agile” checklists as a guide.

If Agile isn’t working for your organization, check out the “Troubleshooting Guide” sidebar.

Applying Individual Agile Practices

Agile works best when you go all in, but if that’s not an option, you may be able to add some Agile practices to your existing process. These are good places to start:

  • Daily planning. If you struggle with frequent interruptions, try adopting day-long iterations (see the “Task Planning” practice). Use the planning game (see the “The Planning Game” practice) and your team’s measured capacity (see the “Capacity” practice) to conduct a joint planning session at the beginning of each day, then defer all interruptions until the next day’s planning meeting. Be sure to have people estimate their own tasks.

  • Iterations. If you aren’t interrupted frequently, but you still want to improve your planning, try using weekly iterations (see the “Task Planning” practice). In this case, you may also benefit from daily stand-up meetings (see the “Stand-Up Meetings” practice) and regular stakeholder demos (see the “Stakeholder Demos” practice). As time goes on, consider using index cards for planning and a big chart to show upcoming work, as described in the “Visual Planning” practice.

  • Retrospectives. Frequent retrospectives (see the “Retrospectives” practice) are an excellent way for your team to adapt and improve its process. The other practices in the “Improvement” chapter may be helpful, too.

  • Fast feedback. A fast, automated build will make a big difference to your quality of life, and it will open up opportunities for other improvements as well. See the “Zero Friction” practice for more.

  • Continuous integration. Continuous integration—the practice, not the tool—not only decreases integration problems, it also drives improvements to your build and tests. See the “Continuous Integration” practice for details.

  • Test-driven development. Although test-driven development (see the “Test-Driven Development” practice) isn’t as easy to adopt as the other practices, it’s very powerful. Test-driven development is the basis for reducing bugs, increasing development speed, improving your ability to refactor, and decreasing technical debt. It can take some time to master, so be patient.

Other practices in Parts II through IV could be useful, too. Agile practices have a lot of dependencies on each other, so be sure to pay attention to the “Allies” blocks and the “Prerequisites” section of each practice.

Don’t be disappointed if you have trouble applying individual practices. It’s faster and easier to choose a coherent subset and go all in. That’s what we’ll look at next.

Share your thoughts about this excerpt on the AoAD2 mailing list or Discord server. Or come to the weekly book club!

For more excerpts from the book, see the Second Edition home page.

Art of Agile Development Book Club

Announcing The Art of Agile Development book club!

Fridays from 8:00 – 8:45am Pacific, I host an online discussion inspired by the new edition of my book, The Art of Agile Development. Each session uses a chapter from the book as a jumping-off point for a wide-ranging discussion about Agile ideas and practices.

Attendance is free! Join us for a great discussion and a chance to win a free copy of my book.1

1Attendance is limited to 100 people on a first-come, first-served basis.

To learn more about The Art of Agile Development, see the book home page. You can buy a copy from Amazon or your favorite purveyor of software development books.

October 29th: Choose Your Agility

There are many ways to be Agile, and no one way is right for everyone. Which ones should you choose? We’ll discuss it in our October 29th book club session.

WhenOctober 29th, 8-8:45am Pacific (calendar invite)
WhereZoom link
Reading 📖 How to Be Agile
📖 Choose Your Agility

Discussion topics:

  • Which Agile ideas and fluency zones are important for your teams, and why?

  • Which aspects of Agile has your organization chosen to embrace, and how did it make that choice?

  • What does your organization want from Agile? How do its investments in agility reflect those goals?

  • If you could change anything, what would you improve about your team or organization’s approach to Agile?

Share your thoughts on the AoAD2 mailing list or Discord server, then bring your experiences and stories to the book club this Friday!

Past Sessions

Note: The Art of Agile Development Book Club sessions are recorded. By appearing on the show, you consent to be recorded and for your appearance to be edited, broadcast, and distributed in any format and for any purpose without limitation, including promotional purposes. You agree Titanium I.T. LLC owns the copyright to the entire recording, including your contribution, and has no financial obligations to you as the result of your appearance. You acknowledge that your attendance at the book club is reasonable and fair consideration for this agreement.

If you don’t want to be recorded, that’s fine—just keep your camera and microphone muted. You’re still welcome to attend!

Art of Agile Development Discord Server

I’ve set up a Discord server for discussing The Art of Agile Development. Join the conversation here.

Also, big news: the book has been sent to the printer! That means the eBook edition should be out sometime in the next week or so, and the print edition should be out in 3-4 weeks. You can pre-order it here.

For excerpts and more information, see the second edition home page. And don’t miss the Art of Agile Development Book Club coming up on October 22nd!

AoAD2 Chapter: What is Agile?

This is an excerpt from The Art of Agile Development, Second Edition. Visit the Second Edition home page for additional excerpts and more!

This excerpt is copyright 2007, 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.

📖 The full text of this chapter is available below, courtesy of the Art of Agile Development book club! Join us on Fridays from 8-8:45am Pacific for wide-ranging discussions about Agile. Details here.

What Is Agile?

Agile is everywhere. And paradoxically, nowhere.

In the 20 years after the Agile freight train roared into software developers’ consciousness, the number of companies calling themselves “Agile” increased by orders of magnitude. The number of teams actually taking an agile approach to their work? Not so much. “Agile,” the easily repeated name, is enormously successful. The ideas behind Agile—well, most of them are ignored.

Let’s fix that.

Agile’s Genesis

In the 1990s, software development was believed to be in crisis. They actually called it that: “The Software Crisis.” Software projects were overbudget, late, didn’t meet requirements, and—according to the oft-quoted and ominously named “CHAOS Report”—nearly one-third of them were cancelled outright. [Standish1994]

Agile wasn’t a response to this crisis. Far from it. Agile was a response to the response.

To bring software development under control, big organizations had created highly detailed processes that defined exactly how software was to be created. Everything was tightly controlled so that no mistakes could be made. (In theory, anyway.)

First, business analysts would interview stakeholders and document the system requirements. Next, software architects would read the requirements documents and create detailed design documents specifying every component of the system and how they related to one another. Then programmers would convert the design documents to code. In some organizations, this was considered low-skill work—just a mechanical translation exercise.

Meanwhile, test leads would use the same documents to generate test plans, and when coding was done, armies of QA personnel would manually follow those test plans and report variances as defects. After each phase, everything would be carefully documented, reviewed, and signed off.

These phase-based approaches came to be called “waterfall development,” or “phase-gate development.”1 If they sound like a ridiculous straw man, well, consider yourself fortunate. Not every company used a document-heavy, phase-based process in the ’90s, but it was widely recognized as a logical and sensible way to work. Of course you needed to define requirements, then design, then implement, then test. Of course you needed to document every phase. This was discipline. This was engineering. How else could you possibly succeed?

1Waterfall is often mistakenly attributed to a 1970 paper by Winston Royce. But phase-based approaches date back to the 1950s, and Royce’s paper was largely ignored until the late 1980s, when it was used to describe what people were already doing. [Bossavit2013] (ch. 7).

Born Out of Crisis

Big companies defined their processes in excruciating detail. Roles, responsibilities, document templates, modeling languages, change control boards...every aspect of development was strictly defined and controlled. If a project didn’t succeed—and, according to the "CHAOS Report," less than one-sixth of them did—it was because the process needed more detail, more documents, more sign-offs. This resulted in a massive amount of documentation. Martin Fowler called it “The Almighty Thud.” [Fowler1997]

This wasn’t a great way to work. It was bureaucratic and dehumanizing. Skill didn’t seem to matter as much as adherence to process. Programmers felt they were interchangeable cogs in an impersonal machine. It didn’t even work all that well.

So several people created simpler, slimmer, and less prescriptive methods for developing software. They were called “lightweight methods” in contrast to the heavyweight methods used by big companies. These new methods had names like “Adaptive Software Development,” “Crystal,” “Feature-Driven Development,” “Dynamic Systems Development Method,” “Extreme Programming,” and “Scrum.”

By the late ’90s, these methods were attracting serious attention. Extreme Programming, in particular, saw an explosion of grassroots interest among programmers. In 2001, 17 of the lightweight methodology proponents met at a ski resort in Utah to discuss unifying their efforts.

The Agile Manifesto

“I personally didn’t expect this particular group of [people] to ever agree on anything substantive,” Alistair Cockburn said later.

And, in fact, after two days, they accomplished only two things: the name “Agile,” and a statement of four values (see the “Agile Values” figure). During the following months, over email, they hashed out 12 accompanying principles (see the “Agile Principles” figure). [Beck2001]

This was the Agile Manifesto. It changed the world. So, as Alistair went on to say, they did agree on something substantive after all.2

2Alistair Cockburn, quoted by Jim Highsmith in [Highsmith2001]. The full quote is, “I personally didn’t expect...this particular group of agilites to ever agree on anything substantive...Speaking for myself, I am delighted by the final phrasing [of the Manifesto]. I was surprised that the others appeared equally delighted by the final phrasing. So we did agree on something substantive.”

A picture of text with the header “Manifesto for Agile Software Development”. The body of the text reads, “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools; Working software over comprehensive documentation; Customer collaboration over contract negotiation; Responding to change over following a plan. That is, while there is value in the items on the right, we value the items on the left more.” It’s followed by the names of 17 people and a copyright notice.

Figure 1. Agile values

If your teams embody the Agile philosophy, then they’re Agile. If they don’t, they’re not.

But there was no unified Agile method. There never has been, and never will be. Agile is three things: the name, the values, and the principles. That’s it. It’s not something you can do. It’s a philosophy. A way of thinking about software development. You can’t “use” Agile or “do” Agile...you can only be Agile. Or not. If your teams embody the Agile philosophy, then they’re Agile. If they don’t, they’re not.

The Essence of Agile

Martin Fowler has made a career out of turning complicated software topics into well-considered, even-handed explanations. His explanation of “The Essence of Agile Software Development” is one of the best:

Agile Development is adaptive rather than predictive; people-oriented rather than process-oriented.3

3Fowler has expressed this idea in many ways over the years. It originated in [Fowler2000a].

Martin Fowler

A picture of text with the header “Principles behind the Agile Manifesto”. The body of the text lists 12 principles. They read: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” “Business people and developers must work together daily throughout the project.” “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” “Working software is the primary measure of progress.” “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” “Continuous attention to technical excellence and good design enhances agility.” “Simplicity, the art of maximizing the amount of work not done, is essential.” “The best architectures, requirements, and designs emerge from self-organizing teams.” “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

Figure 2. Agile principles

Adaptive rather than predictive

Remember the "CHAOS Report," which said that only one-sixth of software projects were successful? It had a very specific definition of success:

Success
The project is completed on-time and on-budget, with all features and functions as originally specified.
Challenged
The project is completed and operational but over-budget, over the time estimate, and offers fewer features and functions than originally specified.
Impaired
The project is canceled at some point during the development cycle.

These definitions illustrate the predictive mindset perfectly. They’re all about conformance to plan. If you did what you said you were going to do, you were successful. If you didn’t, you weren’t! Easy.

It makes sense at first. But look closer. There’s something missing. As Ryan Nelson wrote in CIO Magazine [Nelson2006]:

Projects that were found to meet all of the traditional criteria for success—time, budget, and specifications—may still be failures in the end because they fail to appeal to the intended users or because they ultimately fail to add much value to the business...Similarly, projects considered failures according to traditional IT metrics may wind up being successes because despite cost, time or specification problems, the system is loved by its target audience or provides unexpected value.

Agile teams define success as delivering value, not conforming to a plan.

Agile teams define success as delivering value, not conforming to a plan. In fact, truly Agile teams actively look for opportunities to increase value by changing their plans.

Look back at the Manifesto (see Figures “Agile Values” and “Agile Principles”). Take a moment to really study the Agile values and principles. How many relate to delivering valuable software and adapting to feedback?

People-oriented rather than process-oriented

Heavyweight processes tried to prevent errors by carefully defining every aspect of software development. By putting the “smarts” in the process, individual skill became less important. In theory, you could apply the same process over and over, with different people, and get the same results. (Come to think of it, they kind of did. Just not the results they wanted.)

Agile says people are the most important factor in software development success.

Agile says people are the most important factor in software development success. Not just their skills, but all aspects of their humanity. How well team members work together. How many distractions they encounter. How safe they are to speak up, and whether they’re motivated by their work.

Agile teams have a process—every team does, even if it’s implicit—but the process is in service of the humans, not the other way around. And Agile teams are in charge of their own process. When they think of a better way of working, they change it.

Look at the Manifesto again (see Figures “Agile Values” and “Agile Principles”). Which values and principles relate to putting people first?

Why Agile Won

In the first 10 years after the Manifesto, Agile faced enormous criticism. It was “undisciplined,” critics said. “It could never work.” Another 10 years after that, the critics were silent. Agile was everywhere, at least in name. Heavyweight waterfall methods were effectively dead. Some younger programmers have trouble believing anybody ever could have worked that way.

It’s not that phase-based processes are inherently broken. They have their flaws, sure, but if you keep them slim and operate in a well-understood domain, waterfall-style methods can work. The problem was the heavyweight approaches big companies used. Ironically, the processes designed to prevent problems actually caused many of the problems organizations were seeing.

Learning and responding to change are at the heart of what Agile is all about.

It’s very difficult to imagine how software will work before you actually use it, and it’s even harder to think of absolutely everything your software needs to do. This is doubly true for people who aren’t actively involved with software development. As a result, it’s critically important to get working software in front of people as soon as possible. You need to get feedback about what’s missing or wrong, then change your plans based on what you learn. As the Manifesto says, “Working software is the primary measure of progress.” Learning and responding to change are at the heart of what Agile is all about.

Those heavyweight processes put so much emphasis on process controls and documentation and sign-offs, they incurred a huge amount of delay and overhead. They took years to produce working software, and they had nothing concrete to show until near the end. Instead of welcoming change, they actively worked to prevent change. They actually had a dedicated part of the process, the Change Control Board, whose primary purpose was to say “no” to change requests. (Or, more accurately, “Yes, but it will cost you.”)

All of this added up to projects that spent years in development before they had anything to show. When they did, it was too late and too expensive to make changes. They ultimately shipped software that didn’t do what customers needed.

Agile teams show progress with working software, not documents.

Although there are a variety of approaches to Agile—and some of them are more about co-opting a popular name than following the actual philosophy—one thing they all have in common is a focus on making progress visible and allowing stakeholders to make course corrections as they go. This seems like a small thing, but it’s incredibly powerful. It’s why we no longer hear about the Software Crisis. Software is still late. It’s still over-budget. But Agile teams show progress with working software, not documents. Right from the beginning. And that’s huge.

There’s more to Agile than just providing visibility. But this one thing? This was enough. It’s why everybody wanted Agile.

Why Agile Works

Agile’s first break-out success was Extreme Programming (XP), a method with the slogan “Embrace Change.” XP mixed a healthy dose of philosophizing about software development with a pragmatic emphasis on making a difference. As the preface to the first XP book states:

In short, XP promises to reduce project risk, improve responsiveness to business changes, improve productivity throughout the life of a system, and add fun to building software in teams—all at the same time. Really. Quit laughing. [Beck2000a]

Extreme Programming Explained, First Edition

Some people did laugh. But others tried it, and they found that—contrary to common wisdom about how software development was supposed to work—XP really did everything it promised. And so, despite the laughter, XP thrived, and Agile along with it.

XP was the original poster child of Agile, donating a backbone of ideas and terminology that are still in use today. But the strength of the Agile community is that it has always been a big tent. Agile isn’t limited to any one method. It’s constantly expanding to include new people and ideas. Lean Software Development, Scrum, Kanban, Lean Startup, DevOps, and many, many more, have all contributed to what people think of as “Agile” today.

If you take their ideas and group them into categories, five core concepts appear.

  • Rely on People. Build processes that understand and work with people’s essential humanity. Put decisions in the hands of those who are most qualified to make those decisions. Base your work on healthy, collaborative relationships.

  • Deliver Value. Seek feedback, experiment, and adapt your plans. Focus on producing valuable results. Consider partially done work a cost, not a benefit. Deliver frequently.

  • Eliminate Waste. Work in small, reversible steps. Embrace the possibility of failure and design your plans to fail fast. Maximize work not done. Pursue throughput rather than efficiency.

  • Seek Technical Excellence. Enable agility via technical quality. Design for what is known, not what is speculated. Start simple and add complexity only in response to actual needs. Create systems that are easy to evolve, even—or especially—in unanticipated directions.

  • Improve Your Process. Experiment with new ideas. Tune and adapt what works. Never assume the established, popular way is the way that’s best for you.

Agile works because people make it work.

Agile is defined by the Manifesto, but the Manifesto is just the starting point. Agile works because people make it work. They take Agile’s ideas, adapt them to their situation, and never stop improving.

Why Agile Fails

Agile started as a grassroots movement. Its initial success was largely driven by programmers seeking better results and better quality of life. As that success grew, Agile’s momentum shifted from the underlying ideas to hype. Rather than saying, “Let’s get better results by adapting our plans and putting people first,” organization leaders started saying, “Everybody’s talking about Agile. Get me some Agile.”

The thing is, there is no “Agile” to go get. It’s just a bunch of ideas. There are specific Agile approaches, such as Extreme Programming and Scrum, that will tell you how to be Agile, but you still have to be on board with the underlying philosophy.

And for a lot of organizations, that underlying philosophy—adapting plans and putting people first—is really, really foreign.

The tragedy of the Cargo Cult is its adherence to the superficial, outward signs of some idea combined with ignorance of how that idea actually works. In the story, the islanders replicated all the elements of cargo drops—the airstrip, the tower, the headphones—but didn’t understand the vast infrastructure that enabled airplanes to arrive.

The same tragedy occurs with Agile. People want Agile’s Cargo: better results, more visibility, fewer business failures. But they don’t understand the underlying philosophy, and often wouldn’t agree with it even if they did. They want to buy Agile, but you can’t buy an idea.

What they can buy is the outward signs of Agile. Stand-up meetings! Stories! Tools! Certifications! There’s lots of stuff labeled Agile, and plenty of people eager to sell it to you. It’s often sold as “enterprise-grade,” which is a way of saying “don’t worry, you won’t have to change.” Uncomfortable ideas like “adaptive planning” and “people-centric” are ignored.

And that’s how you get a Cargo Cult. All the activity; none of the results. The Agile part is missing.

“At my old company they wasted a huge number of man-hours in meetings.”

“[Agile] cost an entire team (30+) of people their jobs as they produced almost nothing for almost a year.”

“All [Agile] means is developers get shafted when the project changes...the day before delivery.”

Real comments about Agile from around the web

The name Agile is everywhere. The ideas of Agile aren’t. It’s become self-perpetuating: for many, the only Agile they know is Cargo Cult Agile.

Cargo Cult Agile icon

It’s time to fix that. In the rest of this book, I’ll show you how to apply Agile ideas for real. Keep an eye out for the Cargo Cult Agilists who have infiltrated the book. (You can also find them in the index.) They’ll show you what not to do.

Ready? Let’s go.

Share your thoughts about this excerpt on the AoAD2 mailing list or Discord server. Or come to the weekly book club!

For more excerpts from the book, see the Second Edition home page.

Second Edition of The Art of Agile Development Now Available

The second edition of The Art of Agile Development is now available for pre-order on Amazon!

Get it here.

This new edition has been radically revised and updated. If you liked the first edition, you’ll love this one. Here’s what reviewers had to say:

From code to product delivery, this book has it all. Decades of hard-earned knowledge made readable and digestible—a must-have for anybody working with or on a software development team.

Avi Kessner, Staff Engineer, Forter

The Art of Agile Development, Second Edition achieves quite a feat, condensing modern software delivery into a short, readable, and enjoyable book.

Gojko Adzic, author of Running Servless, Impact Mapping, and Specfication by Example

The first edition of this book mesmerized me to the point that i still have it on my bookshelf as a reference. The second edition keeps this recipe and adds even more insights from the last decade.

Benjamin Muskalla, Senior Software Engineer, GitHub

One of the most comprehensive books in agile software development I’ve ever read. Very pragmatic, with powerful examples easily applicable to any software development project regardless of tech stack, team size, or industry domain.

Luiza Nunes, Program Manager, ThoughtWorks

James has been around since early-agile days and knows his stuff. This book cuts through the crap in our industry, the meaningless “agile” that is all around, and provides a thorough, holistic approach.

Bas Vodde, Co-creator of LeSS

For excerpts and more information, see the second edition home page.

Agile Adoption on the “Agile in Action” Podcast

I appeared on Bill Raymond’s Agile in Action podcast this week. It’s a nice, wide-ranging discussion about Agile adoption, the Agile Fluency® Model, and the ways companies can invest in agility.

Listen here.

AoAD2 Chapter: Scaling Agility

This is an excerpt from The Art of Agile Development, Second Edition. Visit the Second Edition home page for additional excerpts and more!

This excerpt is copyright 2007, 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.

Scaling Agility

In a perfect world, every Agile team would be perfectly isolated, completely owning its product or portfolio of products. Cross-team coordination is a common source of delays and errors. If every team were isolated, that wouldn’t be a problem.

It’s also not at all realistic. A typical Agile team has 4–10 people. That’s often not enough.

So, then, how do you scale? Although this book is focused on individual Agile teams, the question is important enough to deserve a chapter of its own.

Scaling Fluency

Far too often, organizations invest in scaling Agile without investing in teams’ fluency or organizational capability.

Far too often, organizations try to scale Agile without actually having the ability to be Agile in the first place. They invest a lot of time and money in the large-scale Agile flavor of the day, without investing in teams’ fluency or organizational capability. It never works.

To scale Agile, you’ll need to scale your organization’s ability to be Agile. This involves three parts: organizational capability, coaching capability, and team capability.

...to continue reading, buy the book!

In this Section

  1. Scaling Agility
    1. Scaling Fluency
      1. Organizational Capability
      2. Coaching Capability
      3. Team Capability
        1. Sidebar: Second Adopter Syndrome
    2. Scaling Products and Portfolios
      1. Scaling Vertically
        1. LeSS
        2. Adopting LeSS
        3. FAST
        4. Adopting FAST
        5. Challenges and benefits of vertical scaling
      2. Scaling Horizontally
      3. Scaling Vertically and Horizontally
      4. My Recommendation
        1. Sidebar: What About SAFe?

Discuss the book on the AoAD2 mailing list or Discord server. Or come to the weekly book club!

For more excerpts from the book, see the Second Edition home page.

AoAD2 Chapter: Into the Future

This is an excerpt from The Art of Agile Development, Second Edition. Visit the Second Edition home page for additional excerpts and more!

This excerpt is copyright 2007, 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.

Into the Future

Agile teams never stop learning, experimenting, and improving. The practices in this book are only the starting point. Once you understand a practice, make it yours! Experiment with alternatives and seek out new ideas. As you become more fluent, deliberately break the rules and see what happens. You’ll learn why the rules exist...and what their limits are.

What comes after that? That’s for you to decide. Agile is always customized to the needs of the team.

In the Agile Fluency Model, Diana Larsen and I identified a possible fourth zone: Strengthening. If you look carefully, each zone represents a different expansion of the team’s circle of control: Focusing gives the team ownership of its tasks; Delivering gives it ownership of its releases; Optimizing gives it ownership of its product.

Strengthening continues this trend by expanding teams’ ownership over organizational strategy. People don’t just make decisions focused on their teams; they come together to make decisions affecting many teams. One example that’s starting to enter the mainstream is team self-selection. In team self-selection, team members decide for themselves which team they’ll be part of, rather than being assigned by management.

Sound crazy? It’s not. It’s carefully structured, not a free-for-all. (See [Mamoli2015] for details.) I’ve used team self-selection myself and it’s surprisingly effective. The results are better than I’ve seen from traditional manager-driven selection. It leads to teams that are highly productive out of the gate.

The Strengthening zone is about this sort of bottom-up decision making. Governance approaches such as Sociocracy (see https://www.sociocracy.info) and Holacracy (see https://www.holacracy.org) are experimenting in this space, as are companies such as Valve Software, Semco, and W. L. Gore & Associates. Jutta Eckstein and John Buck’s book Company-wide Agility with Beyond Budgeting, Open Space & Sociocracy [Eckstein2020] goes into more detail. For a lighter-weight introduction to the philosophy, see Ricardo Semler’s Maverick. [Semler1995] It’s a fascinating account of the author’s revitalization of his company’s management approach.

That said, the Agile Fluency Model has never been a maturity model. You’re not required to pass through the zones in order, or to achieve fluency in every zone. Although individual practices, such as team self-selection, have their place, I suspect full Strengthening fluency is inappropriate for most companies. But if you want to live on the cutting edge and join the ranks of the innovators who made Agile what it is today, the Strengthening zone is one place to start. Beyond that...who knows? There are additional zones waiting to be discovered.

Ultimately, though, Agile doesn’t matter. Really! What matters is success, for your team members, organization, and stakeholders, in whatever way they define it. Agile practices, principles, and ideas are merely guides along the way. Start by following the practices rigorously. Learn how to apply the principles and key ideas. Break the rules, experiment, see what works, and learn some more. Share your insights and passion, and learn even more.

Over time, with discipline and experience, the practices and principles will become less important. When doing the right thing is a matter of instinct and intuition, finely honed by experience, it’s time to leave rules and principles behind. It won’t matter what you call it. When your intuition leads to great software that serves a valuable purpose, and your wisdom inspires the next generation of teams, you will have mastered the art of Agile development.

...to continue reading, buy the book!

In this Section

  1. Into the Future

Discuss the book on the AoAD2 mailing list or Discord server. Or come to the weekly book club!

For more excerpts from the book, see the Second Edition home page.

AoAD2 Chapter: Discovery

This is an excerpt from The Art of Agile Development, Second Edition. Visit the Second Edition home page for additional excerpts and more!

This excerpt is copyright 2007, 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.

Discovery

Optimizing teams make their own product decisions. How do they know what to build?

Ally
Whole Team

Partly, they know what to build because they include people with product expertise. Those team members have the background and training to decide what to do.

But the fact is, at least at the beginning of a new product, nobody is 100% sure what to do. Some people pretend to know, but Optimizing teams don’t. Their ideas are, at best, very good guesses about what will lead to success.

The job of the Optimizing team isn’t to know what to build, but to discover what to build.

So the job of the Optimizing team isn’t to know what to build, but to discover what to build. Steve Blank, whose work was the basis for the Lean Startup movement, put it this way:

[T]he task is unambiguous—learn and discover what problems customers have, and whether your product concept solves that problem; understand who will buy it; and use that knowledge to build a sales roadmap so a sales team can sell it to them. And [you] must have the agility to move with sudden and rapid shifts based on what customers have to say and the clout to reconfigure [your team] when customer feedback requires it. [Blank2020a] (app. A)

Steve Blank, The Four Steps to the Epiphany

Steve Blank was talking about startups, but this quote applies equally well to Optimizing teams. Even if you aren’t selling your software! No matter who your customers and users are—even if they’re Keven and Kyla, who sit in the next cubicle over—your job is to figure out how to bring them value. And, just as importantly, how to do so in a way they will actually buy or use.

...to continue reading, buy the book!

In this Section

  1. Discovery
    1. Validated Learning
    2. Adaptability
    3. Experiments and Further Reading

Discuss the book on the AoAD2 mailing list or Discord server. Or come to the weekly book club!

For more excerpts from the book, see the Second Edition home page.

AoAD2 Chapter: Autonomy

This is an excerpt from The Art of Agile Development, Second Edition. Visit the Second Edition home page for additional excerpts and more!

This excerpt is copyright 2007, 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.

Autonomy

Optimizing fluency is fairly rare, but it’s not because the Optimizing zone represents a big change in Agile practices. On the contrary: Optimizing is mostly an application of the practices found throughout the rest of this book. Optimizing fluency isn’t rare because it’s hard; it’s rare because it requires a level of team autonomy most organizations aren’t ready to support.

Optimizing requires a level of team autonomy most organizations aren’t ready to support.

Everybody knows Agile teams are supposed to be autonomous, but organizations with Optimizing teams really mean it. For them, autonomy is more than just enabling teams to work independently. They give their teams full responsibility for their finances and product plans, too.

Business Expertise

Ally
Whole Team

Of course, for your team to own its financial and product decisions, the team needs to have the ability to make good decisions. A whole team consisting of both business and development expertise has always been the goal, but many organizations short-change the business side of their teams. They assign a product manager who can participate only a few hours a week, or assign product “owners” who have no real decision-making authority. Some teams get the worst of both worlds: product owners who are spread too thin and have no decision-making authority.

Optimizing teams have real business authority and expertise. It’s not siloed behind a single person, either. Everybody on the team takes an interest in producing value. Some more than others, of course, but there’s no jealous hoarding of responsibility. You’ll get the best results when your entire team sees its job as learning how to better serve customers, users, and stakeholders.

...to continue reading, buy the book!

In this Section

  1. Autonomy
    1. Business Expertise
    2. Business Decisions
    3. Accountability and Oversight
    4. Funding
    5. Experiments and Further Reading

Discuss the book on the AoAD2 mailing list or Discord server. Or come to the weekly book club!

For more excerpts from the book, see the Second Edition home page.

AoAD2 Part IV: Optimizing Outcomes (Introduction)

This is an excerpt from The Art of Agile Development, Second Edition. Visit the Second Edition home page for additional excerpts and more!

This excerpt is copyright 2007, 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.

Optimizing Outcomes

October has rolled around again. Last year, your team achieved Delivering fluency (see Part III). At the time, some team members wanted to push for Optimizing fluency, too, but management was skeptical. You couldn’t get the support you needed.

Since you’ve achieved Delivering fluency, though, your team has been firing on all cylinders. Productivity went way up; defects, way down. Hanna, your product manager, was having trouble keeping up. She delegated more and more responsibilities to the team, which rose to the challenge.

It got noticed. Hanna was singing your praises to the marketing director, and your boss was talking you up to the engineering director. The time was right to push for Optimizing fluency again. This time, it worked. Hanna was assigned to join your team full time. Not only that, she got permission to try “the Agile experiment.”

“The Agile experiment” is what they’re calling the way Hanna works with your team. Instead of having to go through a yearly planning exercise like the rest of Marketing, she got permission to own your team’s financials. She meets with her boss regularly to share statistics such as revenue and customer retention, and she’s constantly trying out new ideas and experiments. (Her colleagues are jealous. They still have to go through six weeks of budget and target-setting hell every year.)

It’s not just Hanna. The whole team is getting in on the action. Although Hanna is first among equals when it comes to product marketing expertise, other members of the team have developed their own areas of expertise. Shayna, in particular, loves visiting customer sites to see how people work.

Shayna’s just asked for the team’s attention. “I just finished a remote session with Magda,” she says. “You all remember Magda, right?” Nods all around. Magda is a developer who works for one of your new customers. Her company’s bigger than your normal customers, so they’ve been pretty demanding.

“Magda’s company has been dealing with an increasingly complex tax situation,” Shayna continues. “They have remote employees in more and more countries all over the world, and dealing with the various taxes and employment law is overwhelming. Magda’s heading up a team to automate some of that work, and she wanted to know how to integrate with our API.”

“But it got me thinking,” Shayna’s voice raises in excitement. “That isn’t too far off from what we do already. What if we sold an add-on module for international employment? It’s a lot of work, but we could start one country at a time. And Bo, you have some experience in this area, right?” Bo nods thoughtfully.

Hanna purses her lips. “It’s a big bet,” she says. “But it could have a huge pay-off. This could crack open the market for more companies like Magda’s. It would definitely widen our moat. None of our direct competitors have anything like that, and the big players charge two arms, a leg, and half your torso in professional services fees. Plus, we’re a lot more user-friendly.” She grins. It has a lot of teeth. “We’d only need to charge an arm and a leg. What do the rest of you think?”

Your team engages in a rapid-fire discussion of the idea. As you come to the consensus that it’s worth pursuing, Hanna nods sharply. “I love it. We’ll need to validate the market and figure out how to break it down into smaller bets. I’ll put a story on next week’s plan to come up with Build-Measure-Learn experiments. We can start on them after we release our current increment. In the meantime, I’ll do some research and run it by the boss. If the experiments work out, we’ll need her to approve more funding and a change to our mission.”

“Thanks, Shayna,” she finishes. “This is why I love being part of this team.”

...to continue reading, buy the book!

In this Section

  1. Optimizing Outcomes
    1. Welcome to the Optimizing Zone
    2. Achieving Optimizing Fluency

Discuss the book on the AoAD2 mailing list or Discord server. Or come to the weekly book club!

For more excerpts from the book, see the Second Edition home page.

AoAD2 Practice: Team Dynamics

This is an excerpt from The Art of Agile Development, Second Edition. Visit the Second Edition home page for additional excerpts and more!

This excerpt is copyright 2007, 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.

Team Dynamics

Audience
Whole Team

by Diana Larsen

We steadily improve our ability to work together.

Your team’s ability to work together forms the bedrock of its ability to develop and deliver software. You need collaboration skills, the ability to share leadership roles, and an understanding of how teams evolve over time. Together, these skills determine your team dynamics.

Team dynamics are the invisible undercurrents that determine your team’s culture. They’re the way people interact and cooperate. Healthy team dynamics lead to a culture of achievement and well-being. Unhealthy team dynamics lead to a culture of disappointment and dysfunction.

Anyone on the team can have a role in influencing these dynamics. Use the ideas in this practice to suggest ways to improve team members' capability to work together.

...to continue reading, buy the book!

In this Section

  1. Team Dynamics
    1. What Makes a Team?
    2. Team Development
      1. Forming: The new kid in class
      2. Storming: Group adolescence
      3. Norming: We’re #1
      4. Performing: Team synergy
      5. Adjourning: Separating and moving on
    3. Communication, Collaboration, and Interaction
      1. Start with a strong base of trust
      2. Support your growing trust with three-fold commitment
      3. Right-size conflicts with feedback
      4. Spark creativity and innovation
      5. Sustain high performance
    4. Shared Leadership
    5. Toxic Behavior
    6. Questions
    7. Prerequisites
    8. Indicators
    9. Alternatives and Experiments
    10. Further Reading

Discuss the book on the AoAD2 mailing list or Discord server. Or come to the weekly book club!

For more excerpts from the book, see the Second Edition home page.

AoAD2 Chapter: Improvement (introduction)

This is an excerpt from The Art of Agile Development, Second Edition. Visit the Second Edition home page for additional excerpts and more!

This excerpt is copyright 2007, 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.

Improvement

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Manifesto for Agile Software Development

Feedback and adaptation are central to Agile, and that applies to the team’s approach to Agile itself. Although you might start with an off-the-shelf Agile method, every team is expected to customize its method for itself.

As with everything else in Agile, this customization happens through iteration, reflection, and feedback. Emphasize the things that work; improve the things that don’t. These practices will help you do so:

  • The “Retrospectives” practice helps your team continually improve.

  • The “Team Dynamics” practice improves your team’s ability to work together.

  • The “Impediment Removal” practice focuses your team’s improvement efforts where they’ll make the most difference.

...to continue reading, buy the book!

In this Section

  1. Improvement
    1. Sidebar: Improvement Sources

Discuss the book on the AoAD2 mailing list or Discord server. Or come to the weekly book club!

For more excerpts from the book, see the Second Edition home page.