Nullables Livestream #2: Exploring Architecture

We use the DiceRoller class to dig into the conceptual differences between Hexagonal Architecture and A-Frame Architecture, and think about at what belongs in the “logic,” “infrastructure,” and “application” layers. Ultimately, we’re able to eliminate the class entirely.

Visit the episode archive for more.

About the Nullables & A-Frame Architecture Livestream

In this weekly livestream series, which is currently ongoing, I pair up with Ted M. Young, aka jitterted. We look at Nullables and A-Frame Architecture as an alternative to Mocks, Spies, and Hexagonal Architecture. Each episode combines a healthy dose of architecture and design discussion with hands-on coding.

Watch us live every Tuesday! For details, see the event page. For more episode recordings, see the episode archive.

Nullables Livestream #1: Nullable Die Rolls

In our first session, we introduce the codebase we’re working on: Ted’s yacht-tdd, which is a web-based Yahtzee-like dice game written in Java and using the Spring framework.

We introduce the core concepts of Nullables, and modify Ted’s DieRoller class to be nullable, in place of his existing stub-based approach. Along the way, we have a lot of great conversations about the similarities and differences between Hexagonal Architecture and A-Frame Architecture.

Visit the episode archive for more.

About the Nullables & A-Frame Architecture Livestream

In this weekly livestream series, which is currently ongoing, I pair up with Ted M. Young, aka jitterted. We look at Nullables and A-Frame Architecture as an alternative to Mocks, Spies, and Hexagonal Architecture. Each episode combines a healthy dose of architecture and design discussion with hands-on coding.

Watch us live every Tuesday! For details, see the event page. For more episode recordings, see the episode archive.

Dec
6
2022
Livestream: Nullables and A-Frame Architecture with Ted M. Young

Tuesdays from 2-5pm Pacific, I’m livecoding on Twitch with Ted M. Young, aka jitterted. We’re going to be looking at Nullables and A-Frame Architecture as an alternative to Mocks, Spies, and Hexagonal Architecture. Should be a good time. Join us if you like to get down and dirty with technical details.

December 6

In our next session, we’ll look at the HttpAverageScoreFetcher and HttpScoreCategoryNotifier classes. These adapters are part of Ted’s implementation of Hexagonal Architecture: they retrieve and store data from a separate “Yacht Tracker” service. We’ll make the adapters nullable, and if we have time, convert them from Hexagonal Architecture to A-Frame Architecture.

Episode Recordings

Find recordings of past episodes here.

The Talent Pump

The recent brouhaha around Elon Musk’s acquisition of Twitter reminded me of something I saw on Ward Cunningham’s C2 Wiki many years ago: the talent pump. It works like this:

  1. In good times, the company expands rapidly, hiring as many people as they can. They get a normal, bell-curve distribution of ability.

  2. In bad times, the company contracts aggressively, encouraging people to leave voluntarily. The best people leave first, because they can most easily get new jobs.

  3. Repeat. Average distribution in, best people out. Average distribution in, best people out. Pretty soon, your company is decidedly below average.

If you’re in a leadership position, now’s a good time to ask yourself: have I created a talent pump?

FAST: An Innovative Way to Scale

I’ve given a few talks on FAST (Fluid Scaling Technology) this year. They cover the same material, but in varying levels of depth and with different audience questions.

The recordings are below. Here’s the abstract:

How can multiple teams work together on a single product? The common wisdom is to carefully align teams and responsibilities to create autonomous teams. But, invariably, this approach eventually runs into cross-team bottlenecks, challenges aligning responsibilities to teams, and difficulties creating cross-functional teams.

Fluid Scaling Technology, or FAST, is an innovative new approach that solves these problems. It uses frequent team self-selection to prevent bottlenecks, share knowledge amongst teams, and ensure the right people are working on the right things. It’s simple and lightweight.

Join James Shore as he shares his experiences with scaling Agile—first with traditional approaches, and more recently with FAST. Learn what works, what doesn’t, and how you can try FAST in your organization.

Hands-On Agile Meetup

I presented at the Hands-On Agile meetup on September 27th. This presentation was about 45 minutes long, and the video has been edited to cut out pauses and move questions to the end, so this is a nicely concise version. The recording and slides are available here, and I’ve also embedded the video below:

Agile 2022

I spoke at the Agile 2022 conference on July 21st. This was an in-person session and 75 minutes long. The recording is available to Agile Alliance members. Scroll down towards the bottom, or search for “James Shore” on the page.

A picture of James Shore presenting “FAST: An Innovative Way to Scale” at Agile 2022.

Agile New England

I presented the session to Agile New England on July 14th. This was an online session and 90 minutes long. The recording is here. You’ll have to create an account, but it’s free.

A picture of James Shore presenting “FAST: An Innovative Way to Scale” at Agile New England.

Free Art of Agile Development Practices Available

It’s been nearly a year since the new edition of The Art of Agile Development was released, and I’m celebrating by making a baker’s dozen of its practices available for free!

You can find the excerpts in the online table of contents. Or use this handy list:

  1. Free Introductory Material:
    1. What is Agile?
    2. How to Be Agile
    3. Choose Your Agility
  2. Free Practices:
    1. Teamwork:
      1. Whole Team
      2. Team Room
    2. Planning:
      1. Stories
      2. Adaptive Planning
    3. Ownership:
      1. Task Planning
      2. Capacity
    4. Accountability:
      1. Stakeholder Trust
    5. Collaboration:
      1. Collective Code Ownership
    6. Development:
      1. Zero Friction
      2. Test-Driven Development
    7. Design:
      1. Incremental Design
    8. DevOps:
      1. Build for Operation
    9. Quality:
      1. No Bugs

For more information about the book, including an amazing series of video discussions and interviews about Agile topics, see the Art of Agile Development page.

Boundary Objects Discussion on the Oddly Influenced Podcast

Brian Marick had me on his Oddly Influenced podcast to talk about boundary objects.

Boundary objects, if you’re not familiar with them, are a tool for creating shared understanding. They’re a concrete model that people with different perspectives use to combine their views. I first heard about them from Brian many years ago, and now I use them as a regular part of my practice.

I love this interview because it’s so different than a typical Agile discussion. Boundary objects are simultaneously academic and obscure; and immensely pragmatic and useful. We had a fantastic discussion about how boundary objects work in practice. I highly recommend it.

You can listen to the episode here or view the transcript here.

Agile Book Club: Optimizing Outcomes

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. In the Agile Fluency Model, this is called Optimizing fluency. In this, our final book club session, Mary and Tom Poppendieck join us to discuss how to achieve it.

Mary and Tom Poppendieck wrote the classic book Lean Software Development in 2003, outlining the application of Lean principles to software engineering. Subsequent books include Implementing Lean Software Development, published in 2006, Leading Lean Software Development in 2009, and The Lean Mindset in 2013. Over the past two decades they have extended these ideas at www.leanessays.com.

Reading:
📖 Optimizing Outcomes
📖 Autonomy
📖 Discovery
📖 Into the Future

🎙 Discussion prompts:

  • Optimizing outcomes depends on a truly cross-functional team with a clear purpose and ownership over its business decisions. What does that look like in practice?

  • What does it mean for a team to have financial responsibility, and how can organizations make that work?

  • Feedback and learning is crucial for success, and that requires teams to have a direct connection to their customers and stakeholders. How can teams make the most of that connection?

  • Let’s talk about options. How can teams use options and adaptability to improve their outcomes?

About the Book Club

From October 2021 to August 2022, I hosted a call-in talk show based on the second edition of The Art of Agile Development. The series used the book as a jumping-off point for wide-ranging discussions about Agile ideas and practices, and had a star-studded guest list.

For an archive of past sessions, visit the book club index. For more about the book, visit the Art of Agile Development home page.

Agile Book Club: Incident Analysis

Despite your best efforts, your software will sometimes fail to work as it should. Some failures will be minor; others will be more significant. Either way, once the dust has settled, you need to figure out what happened and how you can improve. This is incident analysis.

Reading:
📖 Incident Analysis

🎙 Discussion prompts:

  • Think of an incident or bug you were involved with. What happened? Share the story.

  • When you look back at that incident/bug, what were some of its causes?

  • What aspects of your development system contributed to the incident or bug? Which aspects made it less harmful?

  • How could your development system be improved to make incidents and bugs less likely in the future?

About the Book Club

From October 2021 to August 2022, I hosted a call-in talk show based on the second edition of The Art of Agile Development. The series used the book as a jumping-off point for wide-ranging discussions about Agile ideas and practices, and had a star-studded guest list.

For an archive of past sessions, visit the book club index. For more about the book, visit the Art of Agile Development home page.

Agile Book Club: Team Dynamics

Team dynamics form the bedrock of Agile teams’ ability to develop and deliver software. They’re the invisible undercurrents that determine your team’s culture. In this session, Diana Larsen and Linda Rising help us explore the dynamics that make and break Agile teams.

Diana Larsen is a team dynamics expert and change guru who’s been part of the Agile community since the beginning. She’s best known for coauthoring Agile Retrospectives: Making Good Teams Great with Esther Derby. She authored the section on team dynamics in The Art of Agile Development.

Linda Rising describes herself as “incredibly old but still agile and interested in almost anything—including bonobos and trees!” She's been working on teams her entire life, starting with pick-up softball games where she pitched and hit fungos to her two younger brothers.

Reading:
📖 Team Dynamics

🎙 Discussion prompts:

  • The Tuckman Model (“Forming,” “Storming,” “Norming,” and “Performing”) is a classic lens into team dynamics. What do you see as the strengths and weaknesses of that model?

  • Let’s talk about trust. What role does trust play in a healthy team, and how can it be created?

  • Agile teams self-organize and share leadership. What does that look like in practice? How can people develop their shared leadership skills?

  • What role do managers play in creating healthy team dynamics?

About the Book Club

From October 2021 to August 2022, I hosted a call-in talk show based on the second edition of The Art of Agile Development. The series used the book as a jumping-off point for wide-ranging discussions about Agile ideas and practices, and had a star-studded guest list.

For an archive of past sessions, visit the book club index. For more about the book, visit the Art of Agile Development 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 and Holacracy 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.

Share your thoughts about this excerpt on the AoAD2 mailing list or Discord server. For videos and interviews regarding the book, see the book club archive.

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. For videos and interviews regarding the book, see the book club archive.

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. For videos and interviews regarding the book, see the book club archive.

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

Welcome to the Optimizing Zone

The Optimizing zone is for teams who want to create more value.

The Optimizing zone is for teams who want to create more value. They take ownership of their product plans and budget so they can experiment, iterate, and learn. This allows them to produce software that leads their market. Specifically, teams who are fluent at Optimizing:1

1These lists are derived from [Shore2018b].

  • Deliver products that meet business objectives and market needs. (Teams fluent in the other zones deliver what they’re asked to deliver, which isn’t necessarily the same.)

  • Include broad-based expertise that promotes optimal cost/value decisions.

  • Understand where their products stand in the market and how they’ll improve their position.

  • Coordinate with leadership to cancel or pivot low-value products early.

  • Learn from market feedback to anticipate customer needs and create new business opportunities.

  • Make business decisions quickly and effectively.

To achieve these benefits, teams need to develop the following skills. Doing so requires the investments described in the “Invest in Agility” chapter.

The team responds to business needs:

  • The team describes its plans and progress in terms of business metric outcomes jointly identified with management.

  • The team collaborates with internal and external stakeholders to determine when and how roadmaps will provide the best return on investment.

The team works as a trusted, autonomous team:

  • The team coordinates with management to understand and refine its role in achieving the organization’s overall business strategy.

  • Team members jointly take responsibility, and accept accountability, for achieving the business outcomes they identify.

  • Management gives the team the resources and authority it needs to autonomously achieve its business outcomes.

  • Management ensures that the team includes dedicated team members who have all the day-to-day skills the team needs to understand the market and achieve its business outcomes.

The team pursues product greatness:

  • The team engages with its customers and market to understand product needs and opportunities.

  • The team creates hypotheses about business opportunities and conducts experiments to test them.

  • The team plans and develops its work in a way that allows it to completely change plans, without waste, given less than a month’s notice.

Achieving Optimizing Fluency

The investments needed for Optimizing fluency challenge the preconceptions and established order of most companies. It requires giving up a lot of control and putting a lot of trust in the team. There’s oversight, but it can still be scary.

As a result, you’ll usually need to demonstrate success with Focusing and Delivering fluency for a few years before your company will give you the authority and autonomy needed for Optimizing fluency. Early stage startups tend to be an exception, but everyone else will have some trust-building to do.

By the time you’re ready for Optimizing, your team is likely to have mastered the rest of the practices in this book. You won’t need a how-to guide any more. You’ll have mastered the art.

So the chapters in this part are short and sweet. They’ll help you get started, and provide clues about what to try next. It’s up to you to take what you’ve learned about Agile development, combine it with these ideas, and create something great of your own.

These chapters will help you get started:

  • The “Autonomy” chapter discusses the nature of autonomous teams.

  • The “Discovery” chapter discusses ways your team can learn.

  • The “Into the Future” chapter wraps up with a look at what comes next.

Share your thoughts about this excerpt on the AoAD2 mailing list or Discord server. For videos and interviews regarding the book, see the book club archive.

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

Agile Book Club: Blind Spot Discovery

Fluent Agile teams are very good at building quality into their code, but nobody’s perfect. Every team has blind spots. How do you discover your team’s unknown unknowns? Janet Gregory and Abby Bangser join us to explore this question.

Janet Gregory is co-author with Lisa Crispin on three books on Agile Testing. She consults with agile teams to help them integrate testing activities into their daily work. She is also co-founder of the Agile Testing Fellowship, offering holistic and agile testing courses around the world.

Abby Bangser is a Principal Engineer with a passion for bringing product and software engineering practices to internal infrastructure and tooling. Currently Abby is working with Syntasso to enable platform teams to build the secure, scalable and usable platforms. Outside of work, Abby co-hosts #CoffeeOps London meetup, is a SLOConf global captain, and hobbles around a tag rugby field as much as she can.

Reading:
📖 Blind Spot Discovery

🎙 Discussion prompts:

  • Blind spot discovery is ultimately about finding important gaps in your team’s understanding. What are some of your favorite techniques for finding blind spots?

  • How is blind spot discovery different from traditional testing activities? Who should be doing it?

  • As the book discusses, some of the most commonly overlooked blind spots involve how organizations decide what to build. How can teams discover these blind spots and influence changes?

  • The possibility of blind spots can, itself, be a blind spot. How would you suggest introducing blind spot discovery to an organization?

About the Book Club

From October 2021 to August 2022, I hosted a call-in talk show based on the second edition of The Art of Agile Development. The series used the book as a jumping-off point for wide-ranging discussions about Agile ideas and practices, and had a star-studded guest list.

For an archive of past sessions, visit the book club index. For more about the book, visit the Art of Agile Development home page.