Book Notes #09: Becoming Agile in an Imperfect World by Ahmed Sidky and Greg Smith

Title: Becoming Agile in an Imperfect World
Author: Ahmed Sidky and Greg Smith
Year: 2009
Pages: 408

Let’s face it—most companies aren’t startups with blank slates and ping-pong tables. They’ve got legacy systems, rigid hierarchies, and meetings about meetings.

That’s what makes Becoming Agile in an Imperfect World such a refreshing read. Instead of pitching Agile as a perfect system for perfect teams, it shows you how to make Agile work when everything around you is, well, not that Agile.

It’s honest, practical, and full of real-world guidance for teams who want to improve without blowing everything up.

Whether you’re new to Agile or knee-deep in a transformation, this book meets you where you are.

As a result, I gave this book a rating of 7.5/10.

For me, a book with a note 10 is one I consider reading again every year. Among the books I rank with 10, for example, are How to Win Friends and Influence People and Factfulness.

3 Reasons to Read Becoming Agile in an Imperfect World

Book Overview

Most books about Agile start with the theory—principles, values, maybe a manifesto or two—and then leave you with the feeling that if your company doesn’t already look like Silicon Valley, you’re doing it wrong. Becoming Agile in an Imperfect World takes a very different route. It doesn’t sell you perfection. It meets you where you are—right in the mess of existing processes, resistant teams, and deadlines that won’t move.

At its heart, this book is a story about change. But not the shiny, inspiring kind of change where everyone suddenly becomes an Agile evangelist. It’s about the real kind—slow, uneven, a little awkward, but possible. Greg Smith and Ahmed Sidky walk you through how one company, Acme Media, took the leap into Agile without a blank slate or a brand-new team. They had legacy systems, existing workflows, and a lot of uncertainty. And yet, they made it work.

What makes this book different is that it doesn’t ask you to blow everything up. Instead, it starts by encouraging you to look at what you’re already doing. The authors suggest documenting your current process—not the official one that lives in some dusty folder, but the real one your team actually follows. From there, you identify what’s working, what’s not, and what could benefit from a little agility. The magic isn’t in the method—it’s in the mindset.

The story of Acme’s pilot project is the backbone of the book. As they experiment with feature cards, planning poker, daily stand-ups, and retrospectives, we see Agile in motion—not as a rigid framework, but as a living, evolving way of working. They learn the hard way that not all features are created equal. Some are too big, some are misunderstood, and some sound great until you try to build them. The team adapts not because the book tells them to, but because they have no choice. The beauty is in how they respond.

What’s striking is how much the book emphasizes people. Agile here isn’t just about story points and burn-down charts. It’s about conversations that weren’t happening before. It’s about testers being involved from the start, developers talking to customers, and teams realizing that done doesn’t just mean “code complete”—it means “valuable and usable.” There’s a quiet revolution in redefining what “done” really means.

And the imperfections? They’re baked into the process. The team stumbles. They overestimate. They forget things. But instead of hiding those mistakes, the retrospective becomes a space to reflect and grow. The authors don’t romanticize failure—they normalize it. Because in a real Agile environment, the goal isn’t perfection. It’s continuous improvement.

As the book wraps up, it zooms out. How do you scale this beyond a pilot? How do you bring Agile to an organization where not everyone is on board? Here, the authors introduce the SAMI framework—not as a checklist, but as a roadmap. It’s not about becoming “fully Agile” by some external standard. It’s about evolving in a way that makes sense for your team, your goals, and your culture.

By the end, you realize that this isn’t a book about Agile methodology—it’s a book about mindset. It’s about listening better, planning smarter, adapting faster, and building stronger teams. It’s a reminder that change doesn’t have to start with disruption. It can start with curiosity, one team, and one project at a time.

If you’re working in a company that feels too traditional, too slow, or too set in its ways to go Agile—this book might just be what you need. Not because it promises a smooth ride, but because it shows that even in an imperfect world, becoming Agile is still possible.

Chapter by Chapter

Chapter 1 – Moving to Agile

Starting with urgency, not theory

The book opens with a powerful story—not about software, but about a real-life mining accident at Quecreek in 2002. The authors use this dramatic rescue mission to show how teams under pressure must prioritize, adapt, and collaborate quickly. The story is emotional, but it’s not there just for drama. It sets the tone for the entire book: in complex, high-stakes situations, sticking rigidly to a plan doesn’t work. What matters is focusing on the highest priority, being flexible, and trusting the team. These are the same principles that Agile encourages in software development.

Agile isn’t a process—it’s a mindset

The authors make it clear early on: Agile isn’t just a set of tools or practices; it’s a way of thinking. Many people see Agile as just another process, but this chapter explains that Agile is really about values and principles. Using a simple visual (figure 1.2), the authors show how Agile values guide principles, which in turn inspire specific practices. And while practices like standups or user stories are helpful, they’re only meaningful if they’re rooted in the right mindset.

The chapter then dives into the Agile Manifesto and its values—favoring people over tools, collaboration over contracts, and change over rigid planning. These aren’t just slogans. They’re a response to the traditional, plan-driven development world, where teams often focus on delivering documents instead of value. The 12 principles of Agile are explored one by one, showing how they shift focus from fixed plans to flexible, value-driven development. What makes this part engaging is how relatable the examples are—like how delivering 30% of actual software is much better than 100% of paper specs.

From plan-driven to value-driven

A major shift highlighted in this chapter is how Agile flips the usual project logic. Instead of fixing scope and flexing time, Agile fixes time and resources and lets scope stay flexible. That means teams deliver the most valuable features first, knowing they might not finish everything. The authors back this up with a study from the Standish Group showing that nearly half of software features are never used—so why waste time building them?

This insight leads into the core business case for Agile. Agile isn’t just developer-friendly—it helps businesses succeed. The VersionOne survey results show real benefits: higher productivity, better quality, faster delivery, and lower costs. But more than stats, the authors connect Agile to five key business goals: customer retention, accurate delivery, innovation, speed, and a motivated workforce. Agile supports all of these through principles like frequent delivery, collaboration, and technical excellence.

Tailoring Agile to your reality

The chapter closes with an outline of what’s to come. The authors emphasize that there’s no one-size-fits-all approach to Agile. Each company has its own constraints, and successful Agile transformation respects those realities. That’s why this book focuses on real-world implementation—starting with assessment, securing buy-in, understanding your current process, running a pilot, and scaling up. A personal story from Greg about working in a financial institution adds one final punch: Agile isn’t just a reaction to crisis—it should be a proactive strategy.

Chapter 2 – The Story of Acme Media

Introducing Acme Media

This chapter introduces the case study that the rest of the book will follow—Acme Media. It’s a fictional company, but the situations it faces are drawn directly from real experiences the authors had with actual organizations. Acme Media runs three websites tied to a TV station: one for news, another for local classifieds, and a third for travel and outdoor content. For a long time, these sites weren’t seen as important—more of an afterthought than a priority. But with the rise of digital advertising and increasing site traffic, things changed quickly. Suddenly, the websites were a critical revenue source, and Acme Media needed to deliver projects faster and more reliably to stay competitive.

Why the shift to Agile?

The urgency pushed the company to rethink how it managed software projects. Deadlines were being missed, and that was driving advertisers and users away. That’s where Wendy Johnson, Acme’s project manager, comes in. After speaking with an Agile coach named Jim Moore and learning about other companies’ successes, Wendy convinced leadership to give Agile a try. The plan was to start with a pilot project supported by two teams: a core team, who would design and review the new process with help from Jim, and a pilot team, who would try out the new process and give feedback.

What’s refreshing is how the book recognizes the human side of change. Team members at Acme Media have different backgrounds—some are used to formal processes, some have no defined process experience, and a few are already familiar with Agile. And just like in any real company, there’s a mix of enthusiasm, skepticism, and neutrality. Rather than ignoring this diversity, the book embraces it, showing how everyone’s input—especially the skeptics’—will shape the new process.

What does “becoming Agile” actually look like?

To help readers picture what a real Agile transition looks like, the chapter shares a story from a company called Archway Software. Originally working in a rigid, waterfall-like process, Archway released software every four months but faced increasing customer dissatisfaction and change requests that couldn’t be addressed quickly. They learned from another company—an insurance firm—that had embraced faster release cycles, physical space redesigns to boost collaboration, and early feedback loops with customers.

Archway’s journey to Agile didn’t happen all at once. They first shortened release cycles and restructured work to focus on critical features. Then, they adjusted again after seeing that work naturally happened in parallel—requirements, design, and coding often overlapped. They also added regular customer demos and planned for iteration-based re-planning instead of pretending everything could be fixed upfront. Over time, they built a truly iterative process that aligned with how teams actually work—not how the process manual says they should work.

Setting the stage for what’s next

By the end of this chapter, the groundwork is laid. We’ve seen how a company’s priorities can shift quickly when business pressure mounts, and we’re introduced to a real-life Agile transition that didn’t rely on magic or perfect conditions—it evolved through experimentation and reflection. The rest of the book will follow Acme Media’s journey as they design and test their own Agile process, tailored to their unique constraints and culture.

Chapter 3 – Are You Ready for Agile?

The Key Question: How Much Agility Are You Ready For?

This chapter is focused on preparing your team and organization for Agile—specifically, understanding not just if you’re ready for Agile, but how much Agile you can realistically handle today. The book emphasizes that becoming Agile is a journey, not a one-time transformation. It involves continually adapting and scaling Agile practices based on your environment. The chapter helps set the stage for this ongoing evolution by providing tools to assess where your organization stands and what level of agility is achievable right now.

Defining Agile Goals

The chapter starts by clarifying the goals of an Agile process, focusing on outcomes rather than just practices. Agile isn’t about forcing specific methodologies like pair programming or strict co-location; it’s about achieving specific goals that improve the way you work. These include increasing customer involvement, improving prioritization, boosting team buy-in, and adapting to change during development. The authors emphasize that Agile is not about perfecting specific practices but aligning them with the broader goal of delivering more value, more quickly, with greater flexibility.

For instance, increased customer involvement in Agile means feedback isn’t limited to the start and end of a project. Instead, customers are engaged throughout the process—making prioritization easier and ensuring the product delivered aligns with real needs. This approach also supports continuous risk management by enabling frequent reassessments and iterations based on new insights, keeping projects on track and minimizing unpleasant surprises.

Understanding Scrum and XP

As the chapter progresses, it introduces two of the most widely used Agile methodologies: Scrum and Extreme Programming (XP). Both methods have unique strengths and weaknesses. Scrum, for example, is great for teams that need a repeatable process and clear roles like ScrumMaster and Product Owner, but it struggles with teams that need specialized skills. XP, on the other hand, is more prescriptive with practices like pair programming and Test-Driven Development (TDD), but it can be challenging for larger teams or projects with highly specialized needs.

Creating Your Own Agile Process

Rather than advocating for the blanket adoption of Scrum or XP, the authors encourage a more tailored approach. They suggest customizing Agile practices to fit your specific environment—what they call “creating your own flavor.” This means taking elements from different Agile frameworks (or none at all) and adapting them to suit your team’s unique challenges, culture, and goals. The authors stress that Agile should be flexible and evolve over time, with constant iterations and improvements based on feedback from your team and customers.

Challenges and Roadblocks

The chapter doesn’t shy away from discussing the difficulties in adopting Agile. Challenges like lack of Agile knowledge, large or distributed teams, fixed-bid contracts, and team members with specialized skill sets can all impede progress. However, the authors assure readers that these roadblocks are not insurmountable. For example, they suggest dealing with specialized skill sets by promoting cross-training and teamwork. Similarly, they recommend breaking large projects into smaller, manageable teams to avoid the communication breakdowns that can occur as teams grow.

Key Takeaways

• Agile isn’t an all-or-nothing proposition; you can start small and scale up as your team and organization adjust.
• Focus on the goals of Agile (like customer collaboration, adaptive planning, and risk management) rather than rigidly sticking to specific practices.
• A hybrid approach—combining elements from Scrum, XP, or creating a custom process—may be more effective than adopting a single framework.
• Roadblocks are inevitable, but with proper planning and continuous adjustment, they can be overcome.

The chapter wraps up by teasing the next steps in the Agile migration process, highlighting the importance of using assessment tools to evaluate your current state and determine the right practices to start with. In Chapter 4, the authors promise to help you assess your readiness and identify the specific Agile practices that are most appropriate for your team’s current situation.

Chapter 4 – The Fitness Test: All About Readiness Assessments

The Importance of Readiness Assessments

The chapter begins by comparing the Agile transition to running a marathon. Just like someone attempting a marathon without preparation, organizations may be eager to adopt Agile but fail to assess if they have the necessary foundation to succeed. A readiness assessment serves as a crucial first step, helping teams understand whether they’re prepared for the Agile journey and highlighting the areas that need improvement before they start.

The authors draw on various research and articles to emphasize the importance of preparation. Conducting a thorough readiness assessment ensures that an organization isn’t blindly rushing into Agile adoption. Without this preparation, teams may face unforeseen challenges, leading to resistance, wasted resources, and even the abandonment of Agile practices altogether. These risks can be minimized by assessing the organization’s readiness upfront.

Reducing the Risks of Agile Adoption

The chapter then dives into how readiness assessments help mitigate risks by providing clarity on whether the organization can handle specific Agile practices. For instance, collaborative planning requires management and developer buy-in, trust, and a specific organizational culture. If these characteristics are missing, the practice could fail, resulting in poor morale, unproductive meetings, and eventual rejection of Agile.

By assessing these factors early, teams can identify which practices might be too difficult to adopt at the moment, allowing them to either adjust their approach or delay certain Agile practices until the necessary organizational changes have been made. This proactive preparation helps avoid the common negative outcomes of Agile adoption attempts, like decreased productivity or a frustrated workforce.

Increasing Productivity During Transitions

The authors introduce the Virginia Satir change curve, which shows how transitions typically go through a period of resistance and chaos. This phase can cause a drop in productivity. However, with a proper readiness assessment, this chaotic phase can be shortened, leading to a smoother transition with less productivity loss. They argue that if organizations do their homework before diving into Agile, they can reduce the time spent in the difficult “chaos” stage, keeping the transition process efficient and productive.

Getting Executive Buy-In

One of the major hurdles in Agile adoption is getting executive support. The authors stress that a readiness assessment is crucial for showing executives the risks, benefits, and efforts required for the transition. If the assessment shows that the organization is not ready for certain Agile practices, it gives leadership a clear understanding of what needs to change. This visibility allows executives to make informed decisions and prepare for the Agile migration with a solid understanding of what will work and what won’t.

Conducting Readiness Assessments

The chapter concludes by introducing a practical guide for conducting readiness assessments. The process is broken down into several steps: first, identify key Agile practices, then assess organizational characteristics that influence the success of each practice. The readiness assessment tool, Dr. Agile, is introduced, which offers over 300 indicators to evaluate an organization’s readiness for more than 40 Agile practices. It’s a flexible tool that can be tailored to suit the needs of any organization.

The chapter emphasizes that readiness assessments should not be a one-time activity but an ongoing part of the Agile process. As teams evolve, their readiness will change, and regular assessments ensure that Agile adoption stays on track.

Key Takeaways

• Readiness assessments are essential before adopting Agile practices to avoid risks and challenges.
• These assessments provide valuable data that help organizations understand which practices they are ready for and which might require further preparation.
• The use of assessments increases the likelihood of successful Agile adoption by preparing teams and executives for the transition.
• Dr. Agile is an online tool that can assist in conducting comprehensive readiness assessments for over 40 Agile practices.

This chapter sets the stage for the next one by preparing teams to assess their readiness for Agile. It also positions executives to make informed decisions based on the assessment results. The following chapter will focus on gaining executive buy-in and ensuring leadership is aligned with the Agile transition strategy.

Chapter 5 – The Importance of Obtaining Executive Support

Why Executive Support is Crucial

The chapter opens with a quote from Ralph Waldo Emerson, stressing that nothing great is achieved without enthusiasm—especially when it comes to executive support. Executives hold the power to stop any major initiative, including a shift to Agile, if they aren’t fully on board from the beginning. Without their backing, the initiative risks getting sidetracked by endless meetings, unclear goals, and a lack of direction. This chapter focuses on how to secure and maintain executive support for Agile adoption, which is vital for its success.

Addressing Executive Concerns

Executives will have a few key concerns when considering Agile adoption, and the chapter breaks down the answers you should provide. The first major question is: Why pursue Agile? The authors list several compelling reasons, such as needing a consistent delivery process when there’s no existing framework, responding to increasing customer dissatisfaction, and dealing with the volatility and complexity of modern projects. These reasons resonate with executives, who want to know how Agile will help the organization.

Importantly, the authors emphasize that executives must see the value in Agile, not just as a trendy approach or a resume booster. While the benefits of Agile, such as improved delivery times and quality, are often supported by statistics, they aren’t enough on their own. Executives also need to understand the deeper intangibles: the passion behind the adoption, the effort required, and the executive buy-in necessary for success. The chapter urges leaders to focus on why Agile is relevant to their organization’s unique challenges.

Costs and Risks of Migrating to Agile

Another significant consideration for executives is the cost of adopting Agile. The initial financial investment can include the cost of hiring an Agile coach or consulting company, which can range from a few thousand to tens of thousands of dollars depending on the level of expertise required. The core team will also need to dedicate a portion of their time to learning and adjusting to Agile practices, which comes at the expense of their usual duties. Additionally, the first few Agile projects may be slower as the team adapts to new processes. The authors suggest executives should be prepared for this learning curve but reassure them that once the team adapts, productivity will increase.

The authors also highlight the risks of not adopting Agile. These include declining customer satisfaction, the loss of key employees, and missed deadlines. If the organization doesn’t address its growing challenges, the consequences could be far worse than the short-term costs associated with Agile adoption.

Managing the Risks in Agile Migration

The chapter acknowledges that while the risks of Agile adoption are low when managed correctly, poor management can lead to failures. Key risks include choosing the wrong projects to pilot Agile (starting with critical projects too soon), failing to get employee buy-in, and improper implementation of Agile practices without sufficient training or coaching. The authors suggest several best practices for mitigating these risks, such as starting with non-critical projects, ensuring adequate training, and working closely with employees to integrate Agile successfully.

The Role of the Executive Sponsor

One of the most important elements for Agile success is securing an executive sponsor. This sponsor acts as the link between the Agile team and the executive team, helping to clear roadblocks, secure funding, and ensure the initiative aligns with the organization’s overall goals. The sponsor also plays a crucial role in managing organizational change and setting up a rewards structure that encourages Agile behaviors.

Communicating with Executives

Frequent communication with the executive team is essential throughout the migration process. The authors suggest regular status updates and even informal interactions with executives to keep them engaged. An executive sponsor helps maintain this communication and ensures the executive team stays informed and supportive. These interactions ensure that the team has the backing it needs and that the Agile adoption process stays aligned with the company’s strategic objectives.

Acme Media’s Experience

The chapter uses the example of Acme Media to illustrate how securing executive support worked in practice. Wendy, a project manager at Acme Media, was initially unsure about Agile but eventually convinced her CIO, Steve, to give it a try. The CIO’s initial concerns about cost and practicality were addressed through discussions with an Agile coach, who explained how Agile could be implemented without significant upfront costs or tool investments. Once Steve understood the potential benefits and felt comfortable with the approach, he agreed to pilot Agile.

Key Takeaways

• Executives must be involved in the decision to adopt Agile from the start to avoid roadblocks later.
• Providing clear, business-oriented answers to the questions of “Why Agile?” and “What’s in it for me?” is crucial for gaining executive support.
• The costs and risks of Agile migration need to be communicated clearly, and executives should be prepared for a learning curve.
• An executive sponsor is essential for guiding the migration and ensuring it aligns with company goals.
• Regular communication with executives helps maintain momentum and buy-in throughout the Agile transition.

This chapter sets up the importance of executive support in Agile adoption. The next chapter will shift focus to the “doers”—the core team that drives Agile adoption from the ground level.

Chapter 6 – Improving Buy-In by Creating a Core Team

Why You Need a Core Team

For any Agile migration to succeed beyond just a few projects, it’s crucial to build the change from within the organization. This chapter introduces the concept of the core team, a group of people who will be responsible for learning about Agile and helping integrate it into the company’s processes. The core team is not just about management pushing change but involves the doers—people who are directly involved in the software development process. This makes the migration more authentic and relatable for the rest of the team, as it comes from the people who understand the realities of development.

The core team is powerful for three reasons: they are mostly composed of doers, they know the ins and outs of the current development environment, and their influence spreads across the company. Members can bring new practices back to their own teams, helping to spread awareness and buy-in. The authors emphasize that it’s more effective to grow the methodology internally rather than outsourcing the development of the process to consultants.

Who Should Be in the Core Team?

When assembling the core team, it’s important to involve a diverse mix of people, representing different functions and perspectives within the organization. The authors recommend a core team size between 5 to 10 people, large enough to ensure diversity, but small enough to remain agile. It’s crucial to have people who are open to change, enthusiastic about Agile, and ready to challenge old ways of doing things.

The team should include individuals from various functions—such as project management, development, quality assurance, operations, and product management. Each person brings a different viewpoint, which will allow the team to scrutinize the new Agile methodology from all angles. This diversity helps ensure that the methodology is realistic and well-rounded, catering to different needs across the organization.

The Kickoff Meeting

Once the team is in place, the first step is to hold a kickoff meeting to set expectations and explain the goals of the migration. Steve Winters, the CIO at Acme Media, starts his kickoff meeting by framing the company’s needs. He discusses the rise in demand for new features, the challenges the current processes are facing, and the importance of finding a better way to deal with urgent projects. The goal is to show the core team that their work is critical to the company’s success, ensuring they understand the real-world importance of the methodology they will help develop.

The authors also highlight the types of questions the core team might ask at the kickoff meeting. Some may feel unprepared, asking if they need consultants or questioning their roles in the process. The response is that while consultants can provide valuable training, the core team must take ownership of developing the methodology. The team will need to document existing processes, design new ones, test them on smaller projects, and refine the methodology over time.

Tough Questions and Answers

The authors anticipate resistance to change and provide a set of responses to common concerns, such as the fear of failure based on past experiences with failed process changes. They stress that this time, the methodology will be created by experts familiar with the business. The process will be iterative, with a focus on learning and adapting rather than forcing a rigid methodology onto the team. This approach ensures that the transition to Agile will be smoother and less disruptive.

Another question likely to arise is the role of the leader of the core team. The authors explain that the leader’s role is to facilitate discussions, ensure that meetings run efficiently, and keep the team focused on the task at hand. The core team will remain equal in status, with no hierarchy in decision-making, ensuring that everyone’s voice is heard and valued.

Key Takeaways

• A core team made up of doers, not just managers, is essential for an Agile migration that lasts beyond a few projects.
• The team should be diverse, representing various functions within the organization, with a mix of perspectives.
• The core team is responsible for designing the methodology, testing it, and refining it iteratively.
• The core team should be given the space to own the methodology development and not rely solely on consultants.
• Frequent, open communication with the executive sponsor and clear expectations are key to a successful kickoff.

This chapter sets the stage for building a core team that will drive the Agile migration. In Chapter 7, the authors will explore the cultural aspects of creating an Agile environment, focusing on how the mindset of the organization must evolve alongside the process changes.

Chapter 7 – The Mindset of an Agile Leader

The Shift from Process to Culture

In this chapter, the authors explore one of the most important aspects of Agile adoption: the shift in mindset that must accompany the transition. It’s not just about changing processes—successful Agile transformation requires a deep cultural shift within the company. The authors share a real-life example where an Agile approach was used in a tight deadline scenario, but it wasn’t a complete Agile adoption. This story emphasizes that Agile needs time to take hold; it’s not an instant fix. Teams need time to get comfortable with the new way of working, and leaders need to learn how to guide them effectively.

The cultural challenges that most companies face when adopting Agile are explained clearly: people get comfortable with their existing processes, managers are often trained to control rather than empower, and employees may fear losing their jobs if Agile reduces the need for oversight. These concerns can hinder Agile adoption, which is why the authors suggest addressing them head-on. They propose that companies need a clear plan to gain support from all levels of the organization, from line management to project teams to executives. In addition, Agile practices like customer involvement, early testing, and collaborative decision-making can help foster an Agile mindset across the company.

The Role of an Agile Coach

The chapter then shifts to discuss the role of an Agile coach, someone who will guide the company through its Agile transformation. The authors stress that while consultants and trainers can be useful, the key to success is hiring a coach with proven experience and the ability to adapt their methods to your organization’s unique needs. A good coach doesn’t push a single methodology but helps teams understand the principles of Agile and guides them in customizing a process that works for their specific situation.

Attributes of a good coach include having experience in multiple industries and Agile methodologies, the ability to work directly with teams, and strong soft skills to motivate and inspire individuals. The authors suggest finding a coach who isn’t just knowledgeable but also someone with whom the team can develop a comfortable working relationship. Coaching shouldn’t be an ongoing crutch; instead, it should be a support mechanism that gradually fades as the team gains confidence and self-sufficiency.

Agile Management: Shepherding, Not Directing

A major focus in this chapter is on Agile management. The traditional role of a manager—directing and controlling—is flipped in an Agile environment. Managers in an Agile setting act more as facilitators, mentors, and supporters than decision-makers. The authors introduce the concept of “light-touch leadership,” where the manager’s role is to articulate goals, facilitate team interactions, and remove obstacles that prevent progress. Managers must also help teams break down their work into smaller, manageable pieces that can be delivered quickly and ensure that the work aligns with customer needs.

The role of the manager is to create a supportive environment where the team can thrive and innovate, rather than simply directing what they should do. This concept challenges traditional management styles and highlights the importance of empowering teams to take ownership of their work.

Soft Skills in Agile Leadership

The chapter dives deeply into the importance of soft skills for Agile leaders. These include effective communication, problem-solving, diplomacy, and empathy—skills that are critical for fostering collaboration and trust within Agile teams. Managers need to listen actively, mediate conflicts, and ensure that everyone is aligned with the project’s goals. The authors emphasize that soft skills are just as important, if not more so, than technical skills in Agile leadership.

Leading Through Ownership and Responsibility

As teams transition to Agile, ownership becomes a crucial element. In an Agile environment, the entire team takes responsibility for the project’s success, rather than a single manager or leader. This sense of ownership helps foster greater collaboration, as team members work together to find solutions to problems. The authors introduce the ABO Continuum—awareness, buy-in, and ownership—which represents the phases teams go through in accepting a new process. The goal is to help the team move from mere awareness of Agile to full ownership of the process.

Creating an Agile Team Mindset

The final part of the chapter focuses on building an Agile team culture. Successful Agile teams are collaborative, transparent, and focused on delivering customer value. They foster a culture of trust and openness, where team members are encouraged to challenge each other’s ideas and bring their own perspectives to the table. The authors stress that diversity within the team is essential to avoid groupthink, which can stifle innovation and lead to poor decision-making.

Additionally, the chapter discusses how individual characteristics influence team performance, emphasizing the importance of motivation, career stage, and reward structures in fostering an Agile mindset. It’s important to create an environment that attracts and retains talented individuals by offering meaningful work, clear goals, and opportunities for growth.

Key Takeaways

• Agile transformation isn’t just about changing processes; it requires a cultural shift within the organization.
• An Agile coach is essential for guiding the team, but the goal is to eventually make the team self-sufficient.
• Agile managers need to shift from directing to facilitating and mentoring, focusing on supporting the team rather than controlling them.
• Soft skills like communication, empathy, and problem-solving are critical for Agile leadership.
• Teams need to feel ownership over the process to truly succeed in an Agile environment.
• A successful Agile team is diverse, transparent, and collaborative, with a focus on customer value.

This chapter lays the foundation for building an Agile team and mindset. In Chapter 8, we will follow the Acme Media core team as they begin reviewing their existing processes and start designing their custom Agile methodology.

Chapter 8 – Injecting Agility into Your Current Process

Understanding Your Current Process

The chapter begins with the importance of first understanding your current process before introducing any changes. The authors emphasize the need to “reverse-engineer” your existing development methodology—be it waterfall, Scrum, or a custom model—by documenting it from scratch. This is crucial because many companies have outdated documentation that doesn’t reflect the real development practices. The authors suggest a simple, hands-on approach: using index cards and butcher paper to visualize the current flow. This method not only provides clarity but also makes it easy for the entire team to participate and contribute to the documentation.

Acme Media, the company used in the case study, follows this process. They focus on documenting the current practices for their classifieds site first. The team is divided into smaller subteams, each responsible for documenting a specific phase of the process, such as initiation, requirements analysis, design, and development. After a week of documentation, they have a comprehensive view of their process and can begin identifying areas for improvement.

Deciding What to Keep: Identifying Existing Valuable Practices

Once the existing process is documented, the next step is to identify which parts of it are valuable and should be kept. The Acme Media team discovers that not all their current practices need to be discarded. In fact, some of the steps that have evolved over time, like requiring unit testing and smoke testing, align well with Agile principles and are worth preserving. These “keeper” practices help ensure consistency, quality, and customer satisfaction, which are key to Agile’s focus on delivering value early and iterating based on feedback.

Acme also realizes that some processes, like making technical specifications optional and incorporating regular company-wide bug stomps, fit naturally into an Agile mindset. These processes were born from trial and error, and they recognize that Agile isn’t about sticking to a rigid process but about being flexible and responsive to what works.

Documenting a Perfect Process

Another tool that the authors recommend is imagining a “perfect process” that could exist without constraints. This exercise helps the team envision the best possible Agile process and allows them to compare it to their existing methodology. By understanding the gaps between the two, teams can more easily decide where and how to introduce changes. In Acme’s case, the team starts designing a perfect Agile process before they adapt their existing one. This approach helps them identify the areas where Agile principles can be injected without disrupting the flow too much.

Enhancing the Existing Process

The next step is to enhance the existing process by introducing Agile elements. Acme’s core team focuses on several areas of improvement, such as shortening the planning phase, getting the development team more involved in prioritizing features, and introducing daily stand-ups. The team also discusses the need for quicker adaptation to changes and identifies specific changes, like allowing for faster decision-making during the planning phase and emphasizing early validation of customer requirements.

Acme also focuses on integrating Agile principles with their existing tools and infrastructure. They discuss how iterative development and quick customer demos can help them adapt to changes more easily, which is a hallmark of Agile. They emphasize the importance of allowing changes to occur throughout the project lifecycle and adapting the methodology as they learn.

Testing the New Methodology

After designing the new Agile process, the next step is to test it. Acme Media plans to pilot the process with a project to see how it performs in real-life scenarios. This test will allow them to spot any issues that can’t be identified on paper and refine their process accordingly. The authors emphasize the importance of time-boxing the design and testing phase to avoid endless iteration and to maintain momentum.

Key Takeaways

• Understanding and documenting your current processes is essential before making any changes.
• Agile is about customizing and adapting processes to fit the unique needs and constraints of your organization.
• Not everything in your current process needs to be discarded; valuable practices can be retained.
• Visualizing a perfect process can help identify areas for improvement and guide the design of a new Agile methodology.
• Agile transformation should be incremental, starting with non-risky areas and expanding gradually.
• Testing the new process on a pilot project is crucial to identify real-world challenges and refine the methodology.

This chapter sets the stage for piloting the new Agile methodology in a real project. The next chapter will guide the team through the process of launching the pilot and fine-tuning the methodology based on real-world feedback.

Chapter 9 – Selecting a Pilot Project

Choosing the Right Pilot Project

In this chapter, the authors focus on the importance of selecting the right pilot project to test your new Agile process. The chapter starts with an analogy involving a bathroom remodel, where Greg’s wife points out a problem with the paint job, which was chosen without testing. Similarly, when adopting Agile, it’s crucial to pilot the new process on a project before rolling it out across the entire organization. The pilot project helps test the process, identify weaknesses, and gather feedback to refine the methodology before scaling.

The chapter emphasizes that the goal of the pilot is not just to complete a project but to see how well Agile works within the existing structure. This is a chance to gather feedback, improve the methodology, and understand how the process will function across different areas of the organization.

Characteristics of a Good Pilot Project

To ensure that the pilot is successful, the authors outline several characteristics that make a good pilot project:

• Time-Frame: The pilot should be relatively short, typically lasting between 2 to 8 weeks. A shorter project allows for quicker feedback and adjustments. Projects that run too long or too short can either delay the feedback loop or limit the scope of the Agile test.
• Medium Priority: The pilot should be of medium priority, meaning it is important enough to push the team but not so critical that failure would have serious consequences. A critical project could lead to panic and a return to old methods if things go wrong. Examples of medium-priority projects might include minor product feature upgrades or internal process improvements.
• Comprehensive: The pilot should involve multiple phases and areas of the project, including requirements, design, development, testing, and implementation. The goal is to test how Agile integrates across different functions, so a segmented approach that tests only part of the process may not provide meaningful insights.
• No External Customers: It’s recommended to avoid involving external customers during the pilot phase. The reason for this is that piloting the process without customers allows teams to identify issues and make adjustments without the pressure of delivering a product to an external party. Instead, internal product managers or proxies can represent the customer’s interests.

Acme Media’s Pilot Selection

The chapter then uses Acme Media as a case study to demonstrate the process of selecting a pilot project. Acme Media’s project backlog is reviewed, and several potential projects are considered. The team filters out projects that are too large (such as those estimated to last more than 8 weeks) or too small (such as small feature enhancements that don’t involve multiple phases).

Acme Media ultimately selects the free merchandise advertising project as its pilot. This project is medium-priority, estimated to last 7 weeks, and touches multiple areas of the organization, making it a suitable test for the new Agile methodology. It also avoids external customers, as the project is internally focused, with an internal product manager acting as the customer.

Key Takeaways

• The pilot project should be brief (2-8 weeks) to allow quick feedback and adjustments.
• It should be of medium priority to ensure urgency without the risk of failure.
• The pilot should involve multiple phases and functions to fully test the Agile process.
• Avoid involving external customers during the pilot to prevent the mixing of issues with customer expectations.
• The pilot is crucial for refining the Agile methodology and preparing it for scaling.

The chapter concludes by setting the stage for the next step—launching the pilot project at Acme Media. In the following chapter, we will see how Acme Media moves forward with the feasibility assessment and starts implementing the Agile process in real-life conditions.

Chapter 10 – Feasibility: Is This Project Viable?

The Importance of Feasibility Analysis

In this chapter, the authors delve into the feasibility phase, explaining how it helps determine whether a project idea is worth pursuing or should be discarded. They discuss the delicate balance between performing too little or too much validation before deciding whether to move forward. Minimal validation often leads to projects that provide limited value or fail outright, while excessive validation can drain time and resources before the project even begins. A time-boxed approach to feasibility is suggested, with a recommended duration of 2 to 5 days to avoid over-analysis while still gathering enough information to make an informed decision.

The goal of the feasibility phase is not to develop a fully detailed plan but to quickly assess the potential value and risks of the project. Acme Media uses a 3-day time limit for feasibility work to ensure efficiency, allowing the team to quickly decide whether the project is worth pursuing further. Importantly, the team is empowered to cancel the project if they determine it isn’t viable during the feasibility phase, preventing wasted resources.

Feasibility in the Agile Lifecycle

Feasibility is a crucial first step in Acme Media’s customized Agile process. The authors illustrate how the feasibility phase fits within the larger lifecycle, which includes planning, development, adaptation, and deployment. Feasibility serves as a quick check on the idea’s value, while planning dives deeper into breaking the project down into user stories and features. Development follows with iterative cycles of building and delivering features, and adaptation ensures the product aligns with customer needs. The deployment phase wraps up the process by delivering the product to the customer.

Acme Media uses this process for its pilot project, “free merchandise advertising (FMA).” The company’s leadership team has already deemed the project worthy of feasibility analysis, and now they need to verify its viability in terms of value, risks, and resources before proceeding to planning.

Selecting a Feasibility Team

Acme Media identifies a small, focused team to handle the feasibility work for FMA. This team includes a developer, designer, and customer representative—key roles that will provide the necessary perspectives for assessing the project’s value and potential risks. A product manager is assigned to oversee the process, but Acme avoids assigning a formal project manager until the feasibility phase is complete. This approach minimizes resource allocation until the project proves its worth.

The team is responsible for gathering information and performing research in their respective areas, using tools like the Feasibility Discussion Guide to guide their analysis. Once the time-boxed feasibility period ends, the team will present their findings to an approval body, which will decide whether to proceed.

Feasibility Investigation at Acme Media

Jay, the product manager at Acme Media, introduces the FMA project to the feasibility team, providing them with initial requirements and objectives. The team uses this information to evaluate the viability of the project and identify any potential showstoppers. In the early stages of the investigation, the team discovers a critical issue: the project might not be viable because the success of the advertising model relies heavily on attracting users to the site. Without a solid user base, the advertisements would not generate enough traffic to be valuable.

Rather than abandoning the project at this point, the team brainstorms solutions to address the issue, ultimately deciding to modify the concept by incorporating an online auction feature to make the site more attractive to both buyers and sellers.

Modifying the Idea During Feasibility

The feasibility team’s feedback leads to significant changes in the project proposal. Instead of merely offering free merchandise advertising, the project evolves into an online auction service called Auctionator. This change is driven by the team’s recognition of the need to differentiate the service from competitors like Craigslist and eBay. The auction model also addresses concerns about attracting more users, as it provides a more engaging platform for buyers and sellers.

The feasibility team also discusses the technical challenges of implementing an auction system, such as the need to build new functionality and integrate payment systems. They decide that the auction functionality will be kept minimal for the pilot, avoiding unnecessary complexity and focusing on the core features needed to test the idea’s viability.

Key Takeaways

• The feasibility phase is essential for quickly determining whether a project should proceed, with a time-boxed approach preventing over-analysis.
• Feasibility work should be conducted by a small, focused team that can assess the project’s viability from multiple perspectives.
• The feasibility phase can lead to the modification or even cancellation of a project if critical issues are identified early.
• Even if a project initially appears unfeasible, creative problem-solving during the feasibility phase can lead to viable alternatives or adjustments.
• The findings from the feasibility phase should be summarized in a cost/benefit analysis and presented to executives for final approval.

With the feasibility analysis complete, Acme Media prepares to move into the planning phase, where the modified idea will be broken down into specific features, and the project will be scheduled for development. The next chapter will explore the planning phase, focusing on how the team can prioritize features and create a flexible, adaptable plan for delivering the project.

Chapter 11 – Aligning the Pilot Team with the Project

Identifying the Pilot Team

Once the project has passed the feasibility analysis, it’s time to select the team that will actually deliver the project. Ideally, the team should start with the members of the feasibility team, as they already have valuable insights into the project’s context. Acme Media uses a flexible resource pool approach for project assignments. This structure ensures that people with the right skills can be chosen for the project, but also allows for learning across different domains. Some members of the core team are involved to provide mentoring to the pilot team, ensuring the adoption of Agile principles in practice.

The authors emphasize the importance of a dedicated team—a core principle in Agile. This doesn’t always mean 100% dedication, especially in larger companies with multiple projects, but it’s crucial that each team member’s role and time commitment are clear from the start. For Acme Media, three core-team members will work closely with the pilot project team, with Wendy Johnson, the project manager, actively involved in day-to-day operations. This strong foundation of experienced mentors will help the pilot team navigate any challenges during the Agile process.

Preparing the Pilot Team

Preparing the team involves more than just selecting the right people; it’s also about ensuring they understand Agile principles and the customized process they will be following. The core team plays a significant role here by providing training and support. This training typically includes an overview of Agile principles and an introduction to the specific processes designed by the core team for the project. The training, typically one or two days long, will help team members understand how Agile works in their unique context.

However, the authors note that some resistance is expected. Team members who are unfamiliar with Agile might struggle with its principles, especially when they’re used to a more controlled, detailed planning process. They may also question the lack of explicit, step-by-step directions that were common in traditional project management. In these cases, it’s crucial to create an open environment where concerns are heard, and the benefits of Agile are clearly explained and aligned with the team’s experiences.

Providing a Mechanism for Feedback

Feedback is central to Agile, and a structured feedback loop is set up early. The pilot team should provide feedback during the project, which is shared with the core team during regular meetings. This allows the core team to assess how well the methodology is working in practice, identify areas for improvement, and provide additional support when needed. The authors stress the importance of fostering a culture where feedback is viewed as a tool for improvement rather than criticism.

Envisioning the Product

Once the team is aligned, the next step is to create a shared vision of the product. This step is crucial to ensure that everyone understands the project’s goals and can collaborate effectively to deliver the desired value. The team works together to create an elevator statement, a concise summary that communicates the project’s value. This helps to unify the team around a common understanding of the product and its benefits. For example, Acme Media’s Auctionator project is summarized as a local online auction system that allows users to bid and buy goods, with unique features distinguishing it from competitors like eBay and Craigslist.

The process of creating an elevator statement involves answering several key questions, such as who the customer is, what their needs are, and how the product differs from competitors. The goal is to make the value of the project clear and compelling, ensuring that everyone on the team is motivated and aligned.

Identifying Features

The next task is to begin identifying the project’s key features. Acme Media uses feature cards, a tool to list features from a user perspective, which helps move the discussion away from technical tasks and toward user-centric value. Features like “The ability for a seller to place an item up for bid” are reframed as “Ability to place an item up for bid,” emphasizing the user experience. This method helps create clarity around what the user needs and ensures the team focuses on delivering real value to the customer.

The Tradeoff Matrix

The authors introduce the tradeoff matrix as a tool to help the team prioritize project goals. In the matrix, three factors—schedule, resources, and scope—are ranked by priority. Acme Media’s tradeoff matrix helps them clarify what will take precedence in case of constraints. For example, the schedule is marked as fixed, meaning the project must be delivered within the specified timeframe. Resources are flexible, allowing for additional team members if necessary. Scope, however, is highly flexible, meaning features might need to be adjusted or deprioritized if time or resources are constrained.

Project Worksheet

Finally, the project worksheet is introduced as a tool to consolidate all the insights gathered during the feasibility and planning phases. The worksheet includes sections on team members, the project’s objective, identified risks, technical considerations, stakeholders, and the expected benefits. It serves as a snapshot of the project’s status and goals, providing a quick overview for stakeholders and keeping the team focused on the project’s value proposition.

Key Takeaways

• Alignment of the project team is crucial for ensuring a shared vision and understanding of the project’s goals.
• Providing Agile training and mentoring helps the pilot team understand the process and gain confidence.
• Creating an elevator statement and identifying key features helps align the team around the product’s value.
• The tradeoff matrix is essential for setting project priorities and making informed decisions when facing constraints.
• The project worksheet serves as a summary document that provides a clear overview of the project’s status and value.

With the team aligned, the project vision established, and priorities set, the next step is to move into detailed planning. In Chapter 12, we’ll explore how to define and prioritize features, turning the project worksheet into actionable tasks for the team.

Chapter 12 – Feature Cards: A Tool for “Just Enough” Planning

What are Feature Cards?

This chapter focuses on feature cards, a tool designed to gather just enough information for effective planning without resorting to detailed specifications. Feature cards are used to describe features from a high level, supporting the team in understanding the scope and value of each feature while enabling flexibility in Agile development. These cards allow for iterative discussions and are built with enough detail to prioritize, sequence, and estimate features but without locking the team into rigid documentation.

Feature cards are not meant to replace functional specifications. Instead, they help start the conversation between the team and the customer, ensuring that there’s a mutual understanding of the value and requirements of a feature. The feature card contains basic information such as the feature name, description, and customer value, alongside additional fields like estimated work effort, usage frequency, and dependencies on other features.

Structure of a Feature Card

The chapter provides a breakdown of the essential components of a feature card, each designed to facilitate quick decision-making and collaboration. Key fields include:

• Feature ID: A unique number for tracking.
• Feature Name: A description of what the feature allows the user to do.
• Description: A deeper explanation of the feature’s functionality.
• Feature Type: Whether it’s a customer-facing or technical feature.
• Estimated Work Effort: The estimated labor required for implementation.
• Story Points: A measure of the feature’s size relative to others.
• Customer Value: Rated as critical, high, medium, or low from the customer’s perspective.
• Usage Frequency: How often the feature will be used (e.g., daily, weekly).
• Requirements and Technical Uncertainty: Measures of how clear the customer requirements and technical approach are.
• Dependencies: Other features that need to be implemented before this one.

These fields provide a comprehensive but concise snapshot of the feature, enabling the team to begin the planning and prioritization process.

Creating Feature Cards

The feature card creation process involves team collaboration. The project team brainstorms the features with the customer or product owner and documents them on index cards. The goal is to capture just enough information to start working, not to create exhaustive documentation. This iterative, team-based process ensures that everyone involved has a shared understanding of the features. During the exercise, hidden dependencies and further refinements often come to light, which might lead to breaking down larger features into smaller, more manageable tasks.

Example from Acme Media

Acme Media’s team is guided through the feature-card exercise for their Auctionator project. One of the features is the ability to place bids on items. After discussing with the customer, the team identifies the need for user registration before bidding can occur, and this becomes a dependency that needs to be tracked. Through this exercise, the team refines the feature cards, adds necessary details, and prepares them for further prioritization and sequencing.

Reviewing Feature Cards

Once the cards are created, the team reviews them together. This step ensures that any missing details are filled in and that everyone on the team understands the features and their importance. The discussions during the review can lead to additional insights or questions that help refine the feature cards further. For example, the team discusses user interface decisions and system requirements, ensuring that these considerations are captured on the cards.

The goal of this review is to align the team around the features and their priorities, helping to prevent any misunderstandings or misalignments later in the process.

Benefits of Feature Cards

Feature cards offer several advantages:

• Customer Focus: By framing features in terms of the customer’s needs and value, feature cards help the team stay focused on what matters most.
• Identifying Risks Early: Fields that assess requirements and technical uncertainty help the team identify potential risks early in the process.
• Common Understanding: Since feature cards are created collaboratively, they help ensure that the entire team has a clear and shared understanding of the project’s goals and scope.

Feature Cards vs. Other Tools

The authors compare feature cards with other planning tools like user stories, use cases, and functional specifications. While user stories are similar to feature cards, feature cards include additional fields for uncertainty and dependencies, making them more comprehensive for planning purposes. The chapter cautions against using detailed functional specifications too early in the process, as this can lead to unnecessary complexity and delay in Agile environments. Instead, feature cards focus on gathering enough information to begin development and prioritize features without getting bogged down in excessive documentation.

Limitations of Feature Cards

Though powerful, feature cards aren’t perfect for every scenario. In complex projects with many interdependencies, they may not provide enough detail to meet external compliance or traceability requirements. Additionally, they rely on customer involvement, so if the customer is unavailable, proxies or additional artifacts might be needed to fill the gap.

Key Takeaways

• Feature cards are a lightweight tool that helps plan a project with just enough detail to prioritize, sequence, and estimate.
• They help maintain customer focus and align the team around shared goals.
• Feature cards are designed to start the conversation, not replace detailed specifications.
• Collaboration during the creation and review of feature cards ensures a common understanding of the project.
• Feature cards help identify risks early and facilitate flexibility in the development process.

This chapter sets the stage for prioritizing features and preparing for iteration planning. With feature cards in place, the next step is to organize and refine them in preparation for the actual development cycles.

Chapter 13 – Prioritizing the Backlog

The Importance of Prioritization

In this chapter, the authors discuss the art and importance of prioritizing features in a project, emphasizing that effective prioritization ensures the most valuable functionality reaches the customer first. Without proper prioritization, projects often suffer from scope creep or fail to deliver critical functionality. The chapter introduces the concept of iterating on features, where the most essential features are completed first, followed by others in subsequent iterations, ensuring that valuable features are usable even if the project isn’t fully completed.

Guidelines for Prioritizing Features

The chapter offers several guidelines for prioritizing, sequencing, and grouping features. These guidelines help teams decide which features should be tackled first:

• Value to the Customer: Features should be ranked based on their importance to the user. High-value features that directly impact the customer’s experience should be prioritized.
• Risk: High-risk features, such as those with technical uncertainty or dependencies on third parties, should also be addressed early to give the team time to resolve issues.
• Groupings: Features that work together to provide value should be grouped and delivered together. For instance, placing an item up for bid and the ability to bid on an item should be grouped because they both provide value to the customer when delivered together.
• Interface and Dependencies: Features that depend on interfaces or third-party vendors should also be prioritized early to manage risks and avoid delays later.

The Prioritization Exercise at Acme Media

The chapter walks through Acme Media’s feature-card prioritization exercise. After completing the feature-card exercise, the team reviews the features from a business perspective. The customer (product manager, Jay) confirms the business value of each feature, and the team organizes the features based on value.

After sorting features by customer value, the team moves on to dependencies. For instance, the ability to register on the site is a prerequisite for several other features. Recognizing these dependencies helps the team sequence the tasks logically. The highest-priority features that tie into others are placed at the top of the list to ensure a smooth workflow.

Evaluating Risk

The next step in the prioritization process involves evaluating risk. Features with high risk (due to technical uncertainty or external dependencies) are assessed for their impact on the project. The authors present a three-step approach for handling high-risk features:

1. High risk and high value: These should be moved to the top of the list so they can be worked on early in the project.
2. High risk and medium value: These need case-by-case evaluation, with decisions based on how the customer perceives their value.
3. High risk and low value: These should be moved to the bottom of the list or even removed from the project.

The Acme Media team follows this approach and adjusts the feature list accordingly. For example, features with high technical risk, like the auction engine, are moved up to allow time to address any issues, while features like the auction browser toolbar (with high technical uncertainty and low customer value) are pushed to the bottom.

Grouping Features

After prioritizing by value and risk, the team groups related features together. Features that must be delivered together to provide value are grouped, such as the ability to place an item up for bid and the ability to bid on an item. These features are placed in Group A, ensuring that they are worked on and delivered together in the project.

Final Prioritization and Risk Review

The team finishes sorting the features by reviewing all the prioritized features in terms of customer value, risk, and dependency. This method helps ensure that the project stays focused on delivering maximum value, while also addressing potential risks early. The team also removes some low-value, high-risk features from the project, ensuring that efforts are focused on high-priority tasks.

Key Takeaways

• Prioritization helps deliver the most valuable features first, ensuring that even incomplete projects provide usable, customer-facing functionality.
• Features should be prioritized based on business value, technical risk, dependencies, and customer needs.
• Grouping related features ensures that critical functionality is delivered together.
• Evaluating risk and handling high-risk features early in the project allows teams to manage challenges without compromising project timelines.
• The prioritization process is collaborative and should involve both the customer and the development team to ensure alignment and buy-in.

With the backlog prioritized, the next step will be to estimate the effort needed for each feature. In Chapter 14, the authors will discuss how to assign features to iterations based on the prioritized backlog and begin the process of estimating time and effort.

Chapter 14 – Estimating at the Right Level with the Right People

Estimating Software Development: The Challenges

This chapter begins by addressing a common issue in software development: the challenge of estimating how long a project will take. Traditional estimation techniques, which treat software development like widget production, fall short because software is unique and constantly evolving. Unlike manufacturing where you can measure how long it takes to produce a product based on repetition, software projects are dynamic, and each task is often different from the last. As the authors explain, Agile estimation methods don’t promise to eliminate uncertainty, but they improve accuracy as the project progresses by factoring in actual work completed during iterations.

Contrasting Traditional and Agile Estimation Techniques

The authors highlight the problems with traditional estimation, which relies on detailed analysis and specification of features up front. With traditional methods, teams often spend weeks or months creating detailed plans, only to find that their estimates are inaccurate when it’s time to execute. Agile estimation, in contrast, uses a phased approach. Initially, features are estimated in terms of size, not duration, which allows the team to prioritize and plan the release of features early on. Over time, the estimates become more accurate as the team works through the iterations.

The Importance of Whole-Team Estimation

A significant change in Agile is the inclusion of the entire team in the estimation process. The authors discuss how involving all team members—developers, testers, analysts, DBAs, and architects—leads to more accurate estimates. When a team estimates a feature, they draw from diverse perspectives, ensuring that no detail is overlooked. The chapter introduces the idea that a more inclusive approach results in estimates that are not only more accurate but also create a stronger sense of team ownership and accountability. A key point is that whole-team estimation avoids the “groupthink” effect that can occur when only a few experts are involved.

A Step Toward Agility: Estimating Size, Not Effort

The chapter introduces story points as a way to estimate features. Rather than estimating the time needed for each feature, story points measure the relative size of a feature compared to others. This approach allows teams to begin estimating without needing all the details upfront. For example, instead of saying “Feature A will take 20 hours,” the team might say “Feature A is about the same size as Feature B, which we estimated at 5 points.” This relative sizing helps teams begin to create a high-level release plan, which is refined as they move through iterations.

Using Story Points for Quick Estimation

The authors explain that story points provide a quick way to estimate features and create a release schedule, allowing the team to prioritize work without getting bogged down in detailed analysis. The story-point technique doesn’t require exhaustive breakdowns of each task but instead compares features to each other, making it easier to develop an initial estimate for the project timeline.

Planning Poker

One way to facilitate team-based estimation is through planning poker. In this process, each team member uses cards with values (usually based on the Fibonacci sequence: 1, 2, 3, 5, 8) to vote on the estimated size of a feature. The team discusses the feature until everyone is aligned, and then each person submits their estimate anonymously. If there’s a discrepancy, the team discusses their reasoning and revises the estimate. This method ensures that the estimates are based on diverse perspectives and avoids the influence of more dominant voices in the room.

Estimating at Acme Media

The chapter uses Acme Media as an example of how to apply story points. The team starts by identifying two reference points (features that are sized at 2 and 5 story points) and then uses these to estimate the remaining features. This technique helps them quickly determine the relative size of each feature and prepare for the first iteration of development. The estimated backlog provides the team with a clearer picture of their capacity and enables them to prioritize features based on customer value.

Key Takeaways

• Traditional estimation techniques often fail in software development because they rely on static assumptions that don’t fit the dynamic nature of software projects.
• Agile estimation techniques, such as story points, allow teams to estimate features based on size and complexity, rather than trying to predict exact durations.
• Whole-team estimation improves accuracy by involving everyone who will work on the project, increasing buy-in and accountability.
• Story points provide a way to estimate features quickly and effectively without needing detailed task analysis.
• Planning poker ensures that estimates are based on diverse perspectives and that no one person’s opinion dominates the process.

The chapter wraps up by pointing out that while initial estimates are helpful for laying out an overall release schedule, the true value of story points becomes evident in subsequent iterations. In the next chapters, the team will use the estimates to plan specific iterations and refine the overall project timeline as they progress.

Chapter 15 – Release Planning: Envisioning the Overall Schedule

Release Planning Overview

This chapter addresses the process of creating a release plan, which is essential for guiding the development team and ensuring that the project stays on track. The authors discuss the importance of defining various components of the release plan, including iteration lengths, time required between iterations, and the overall timeline for the project. The release plan provides clarity on what will be delivered when and helps align team members, stakeholders, and other departments involved in the project.

Defining the Pieces of a Release Plan

To create an effective release plan, several pieces of information must be gathered:

1. Iteration 0 Length: This is the time needed to prepare the project for development iterations. This includes tasks like setting up the environment, organizing tools, and completing any preliminary work. For Acme Media’s Auctionator project, they estimated one week for Iteration 0, which includes setting up bug-tracking tools and testing the API from a messaging vendor.
2. Development Iteration Length: Agile projects use time-boxed development iterations, and the length of these iterations affects the overall release schedule. Acme Media decided on 2-week iterations for their project after reviewing industry best practices, finding this to be the optimal timeframe for their team.
3. Time Between Iterations: The chapter suggests allowing time between iterations for tasks such as acceptance testing, sprint retrospectives, and backlog review. While more experienced teams may only need 1-2 days, a team new to Agile (like Acme Media) might need up to a week to effectively close out an iteration and prepare for the next.
4. Project Deadline: The project deadline is a crucial constraint for most projects. In Acme Media’s case, the deadline was set for June 15, and this date guided their planning. The authors recommend starting with a clear project deadline and working backward to define the other components of the release plan.

Completing the Release Plan by Assigning Features to Iterations

Once the release schedule and iteration lengths are defined, the next step is to assign features to iterations. Acme Media’s team uses story points to estimate their capacity for each iteration. Since this is their first Agile project, they begin by assigning features based on the estimates of their first iteration. As they gain more experience with Agile, they will refine these estimates.

The authors recommend considering a few key guidelines during the assignment process:

• Deliver Customer Value: Each iteration should deliver useful functionality to the customer. Even in the first iteration, Acme Media ensures that it will deliver the minimal set of features necessary for the Auctionator system to function.
• Dependencies: Features that rely on each other should be grouped together in the same iteration. This prevents the team from splitting features that would provide little value if not completed together.
• High-Risk, High-Priority Features: These should be placed in earlier iterations to address risks and uncertainties as early as possible. Acme Media starts testing vendor interfaces during Iteration 0 to identify potential issues early.

Communicating the Release Plan

Once the release plan is established, the next important step is to communicate it to stakeholders, support teams, and other departments. Acme Media’s project manager, Wendy, organizes a kickoff meeting to present the release plan to everyone involved in the project. This meeting helps ensure that all stakeholders understand the project’s scope, timeline, and the importance of each iteration.

The kickoff meeting also includes representatives from operations, security, load testing, marketing, and training teams, all of whom need to know when their support will be required. The authors emphasize that the kickoff meeting should be a collaborative event, where multiple team members present and discuss the release plan to increase transparency and ensure alignment.

Key Takeaways

• Creating a release plan is essential for ensuring a project stays on schedule and meets its objectives.
• Key components of the release plan include defining iteration lengths, time between iterations, and determining the overall project timeline.
• Iterations should be spaced based on the team’s maturity and the tasks that need to be completed between iterations, such as testing and backlog review.
• Assigning features to iterations should be based on value to the customer, dependencies, and prioritization of high-risk features.
• The release plan should be communicated effectively to all stakeholders to ensure their understanding and support for the project.

The chapter wraps up by preparing Acme Media for the next steps in the Agile process. With the release plan in place, the team is now ready to move into detailed planning for the first iteration. The next chapter will explore how to break down the features assigned to Iteration 1 into specific tasks and estimate the effort required for each one.

Chapter 16 – Iteration Planning: The Nitty-Gritty Details

Defining “Done” and Feature Completeness

The chapter begins by emphasizing the importance of clearly defining what “done” means for a feature within an iteration. This ensures that the team understands exactly what is expected for each feature and how they can confirm its completion. The authors recommend reviewing acceptance tests during iteration planning to help the team define these criteria. Acceptance tests should be clear, concise, and in a boolean format, meaning they can be verified as either true or false. The customer’s role in explaining and reviewing these tests is also crucial, as it helps the team align on success criteria.

For Acme Media, the customer plays a key role in user acceptance testing at the end of each iteration, ensuring that the delivered features meet customer requirements. This approach avoids the need for continuous customer involvement during development, yet ensures features are checked for completeness as they are developed.

Feature Modeling to Break Down Tasks

One of the main activities in iteration planning is breaking down features into actionable tasks. The authors introduce feature modeling as an effective tool for this. Instead of jumping straight into design, feature modeling allows teams to understand the user interaction and screens needed to support each feature, which helps identify tasks in a structured way. For Acme Media, feature modeling is used for their project Auctionator. The team models the “ability to bid” feature by outlining workflows, identifying screens, and adding details about user interactions.

During the feature modeling process, the team identifies new features and tasks that were not initially planned for. For example, the process of bidding leads to the discovery of a need for a bid retraction feature, and the team creates new feature cards for this. By identifying these tasks early, the team can better plan the iteration and avoid surprises later in development.

Estimating Tasks

After breaking down the features, the team estimates the effort required for each task. The estimation process involves assigning tasks to team members based on their skills and availability. At Acme Media, the team uses a spreadsheet to track task estimates and capacity, ensuring that the work assigned to each iteration matches the team’s available resources. The authors emphasize that while tools can help with tracking, the final decision on how much work to take on belongs to the team, based on their capacity and confidence.

Iteration Capacity

The chapter further explores how teams calculate their iteration capacity. In the case of Acme Media, they estimate how many working hours are available during each iteration, taking into account each team member’s specialization. For new Agile teams, task assignments may be constrained by individual expertise, but over time, cross-training can reduce dependency on specific team members for specific tasks. The team uses this capacity calculation to ensure they don’t overcommit during the iteration and to help manage the workload effectively.

Tools for Tracking Status

To ensure transparency, Acme Media uses various tools to track their iteration progress. The team uses a burn down chart to monitor how much work is left each day, helping them identify whether they are on track. If there is a lag or delay, this tool provides real-time feedback so adjustments can be made.

For more complex iterations, Acme Media uses Microsoft Project to track dependencies and integrate work from various team members. While some believe using Microsoft Project is incompatible with Agile practices, the authors argue that it can be helpful if used in a lightweight, supportive way. In Acme Media’s case, the tool helped visualize task dependencies and provided additional support for managing complex iterations.

Tracking Release Status with the Progress Matrix

To keep stakeholders informed, Acme Media uses a Progress Matrix to track the overall release status. This matrix provides a clear and easy-to-understand view of where the project stands at various stages, such as feature completion, unit testing, and customer approval. The matrix makes it easy for the entire team to quickly grasp the project’s progress and for the customer to get updates on the status of specific features.

Key Takeaways

• Acceptance tests must be defined at the start of iteration planning to ensure everyone understands what “done” means for each feature.
• Feature modeling is an effective tool to break down features into tasks and identify additional features or tasks early.
• Estimating tasks involves considering the team’s capacity and using tools to track how much work can be realistically completed.
• Iteration capacity should be carefully calculated to ensure that the team doesn’t overcommit.
• Tools like burn down charts and the Progress Matrix help track iteration progress and release status, ensuring transparency across the team and stakeholders.

The chapter concludes by explaining that after breaking down and estimating tasks for the first iteration, the team is now ready to start construction. In some projects, particularly in steady-state release environments, work will begin immediately. For other projects, some pre-work (iteration 0) may still be necessary, which will be explored in the next chapter.

Chapter 17 – Start Your Engines: Iteration 0

Introduction to Iteration 0

The chapter introduces Iteration 0 as a crucial preparatory phase before actual development begins. While many Agile communities may use this term loosely, Iteration 0 is about doing foundational work that is necessary to kickstart the project. Typically lasting about a week, but it can be more or less depending on project complexity, Iteration 0 allows teams to get organized and prepared before diving into the full development cycle. It focuses on architectural planning, environment setup, third-party contract finalization, and other critical activities to reduce risks during the development phase.

Key Activities in Iteration 0

• Initial Vision for Architecture: In the first part of Iteration 0, the team revisits the architecture after gaining more details from the feature-card exercise. This step is essential to ensure that the architecture aligns with the upcoming development requirements. It includes defining infrastructure, security models, application flow, and any third-party dependencies.
• Contracting with Third Parties: The authors highlight that many projects involve working with third-party services, such as obtaining additional licenses or integrating with external vendors (e.g., email services, data feeds, or search services). Finalizing contracts during Iteration 0 helps streamline the development process, reducing interruptions later on.
• Preparing Environments and Support Tools: Iteration 0 is also when teams should get their technical environment ready for development. This includes setting up version control systems, ensuring automated build tools are in place, preparing defect tracking tools, and ensuring developers have the necessary workstations and frameworks. Additionally, teams should set up support tools like load testing and time-tracking systems to track project progress.
• Obtaining Funding: For larger projects, obtaining funding can be a critical part of Iteration 0. It may involve seeking approval from an executive review group or presenting a business case to get the necessary resources and capital. This step helps avoid project delays once development officially begins.

What Can Be Done in Iteration 0 (Cheating)

The authors suggest that Iteration 0 is an excellent time for “cheating,” or starting work ahead of time. Although this phase is technically pre-development, the team can still reduce risk by initiating activities such as:

• Scoping: Continuously interacting with the customer to refine feature requirements.
• Prototyping: Creating early prototypes and mockups to visualize key features and design elements.
• Testing Interfaces: If the project involves third-party integrations or APIs, testing these interfaces early can uncover potential problems.
• Defining Test Cases: Beginning the work of creating test cases for features.
• Working on Risks and Issues: Addressing potential blockers, including compliance checks, resource reservations, and setting up contingency plans for known risks.
• Preparing Training: Planning for end-user training and developing materials for the deployment phase.
• Communication and Marketing Planning: Identifying key audiences and setting up the communication channels needed to keep stakeholders informed throughout the project.

The chapter concludes with a transition to Chapter 18, where the focus will shift to the actual development work and how Agile processes are implemented during the development phase. The groundwork laid in Iteration 0 enables teams to begin development in a smoother and more structured manner, increasing the likelihood of project success.

Key Takeaways

• Iteration 0 is a vital preparatory phase in Agile that helps teams set up their technical environments, contracts, and project frameworks before development begins.
• Teams can use Iteration 0 to start work on prototypes, scoping features, testing interfaces, and preparing for risks.
• Funding and environment setup are important aspects of Iteration 0 to ensure a smooth project launch.
• While not formally part of the development cycle, Iteration 0 allows teams to do preliminary work that reduces risks later in the project.

Chapter 18 – Delivering Working Software

Introduction to Agile Development

In this chapter, the authors explain the core concept of Agile development—delivering working software early and often, which marks the significant shift from traditional waterfall models. They emphasize that project progress should be measured by the delivery of working code, rather than the completion of tasks. Although a project might appear halfway complete according to task-based metrics, from a customer’s perspective, it is only truly 0% complete until they see usable software. This is a crucial mindset change in Agile—ensuring that features are always deployable and valuable from the customer’s viewpoint.

Agile Principles in Practice

The authors explore the core Agile principles that guide development and testing:

1. Satisfy the customer through early and continuous delivery of valuable software.
2. Business and development teams should collaborate daily.
3. Prefer face-to-face communication over other forms.
4. Focus on technical excellence and good design.
5. Keep things simple by maximizing the amount of work not done.
6. Welcome changing requirements, even late in the development cycle.
7. Test early and often.
8. Continuously integrate code changes.
9. Obtain customer feedback as soon as possible.
10. Minimize distractions during development iterations.

Each of these principles is aimed at optimizing collaboration, delivering features that matter most, and ensuring that software remains flexible and adaptive to change.

Acme Media’s Agile Journey

Acme Media’s transition from traditional processes to Agile is exemplified through their new iterative approach. Prior to Agile, Acme Media delivered all software at the end of the project, regardless of priority. The new method focuses on delivering the most valuable features first, working in small, frequent iterations that provide usable, working software to the customer at every stage.

The team now integrates feedback early in the process. For example, Acme’s development team no longer waits until the final product to show the customer the software. Instead, they deliver working software in incremental batches, ensuring that the customer’s needs are met and issues are addressed early. By adopting this iterative process, Acme can react to customer feedback faster and adjust the direction of development to ensure value is consistently delivered.

Supporting Agile Principles During Development

The chapter further delves into how Acme Media embraces these principles during development and testing:

• Early Delivery: Acme ensures that key features are delivered early to gain customer feedback, instead of waiting until the project is complete. This early delivery approach helps mitigate the risk of missing customer needs.
• Collaboration Between Business and Development: In their previous method, business analysts worked separately from developers, leading to disjointed communication. Now, developers and business stakeholders (including customers) collaborate daily, which enhances understanding and alignment of the project’s requirements.
• Face-to-Face Communication: Acme’s team has made efforts to reduce reliance on emails and instant messages, opting for more direct, face-to-face communication. This helps to quickly resolve misunderstandings and maintain a flow of conversation that benefits the development process.
• Focus on Technical Excellence: Acme’s developers balance the need for technical excellence with the need for rapid delivery. While they avoid perfecting every design detail upfront, they ensure that their software architecture remains scalable and adaptable to future changes.

Dealing with Changing Requirements

Agile recognizes that change is inevitable, especially when working with customers. The authors discuss how Acme Media has shifted from being resistant to changes (often labeled as “scope creep”) to welcoming changes that are necessary for meeting real customer needs. For example, a customer may realize mid-project that a feature needs to be altered, and Agile allows for these changes to be incorporated without derailing the project. Acme embraces the idea that changes in requirements are not an obstacle but an opportunity to ensure the software truly meets the customer’s needs.

Testing and Continuous Integration

Acme’s development team now follows Agile practices by testing early and integrating changes continuously. In the past, testing at Acme was delayed until the end of development, which caused delays when issues were found late in the cycle. Now, they test as soon as possible, starting during the feature-card exercise to identify potential integration issues early. They also use continuous integration to ensure that every change made to the codebase is integrated into the main codebase frequently, which helps avoid conflicts and inconsistencies.

The Iterative Process of Feature Completion

As features are developed, they go through an iterative process that includes:

1. Reviewing Design and Technology Options: Developers assess several options for solving a problem, choosing the one that aligns with the feature’s requirements.
2. Collaborating with the Customer: When issues arise during development, developers continue refining the requirements with the customer to ensure that the software meets expectations.
3. Testing and Unit Testing: Each feature undergoes rigorous testing. Unit tests are written and executed before code is implemented to ensure that the new feature works as expected.

Work in Parallel and Cross-Functional Teams

A key challenge in Agile development is the need to work on features in parallel, especially when they are interdependent. Acme Media’s team frequently builds features in parallel, with developers constantly interacting to adjust their work based on the evolving understanding of requirements.

Additionally, the team emphasizes cross-functional collaboration, where members with different skill sets work together, ensuring the feature progresses smoothly without bottlenecks.

Key Takeaways

• Agile is measured by delivering working software, not just completing tasks or milestones.
• The Agile principles, like early delivery and welcoming changes, help create an environment that continuously adapts to customer needs.
• Continuous communication between developers and business people enhances understanding and minimizes delays.
• Testing early and integrating changes frequently are key Agile practices that prevent issues later in development.
• Parallel work on interdependent features requires constant collaboration and adaptation.
• Agile encourages cross-functional collaboration, allowing teams to work together more effectively.

The chapter concludes by preparing Acme Media to continue its development process. The next chapter will explore testing in more detail, providing insight into the types of tests that occur during a software release, which ensures the software is robust and meets quality standards.

Chapter 19 – Testing: Did You Do It Right?

Introduction to Testing in Agile

This chapter delves into Agile testing principles, emphasizing the importance of embedding quality into the product from the beginning. Drawing from the work of W. Edwards Deming and his focus on building quality into products, the chapter explains how Agile encourages teams to detect and address defects early. The aim is to reduce the reliance on inspection and quality control by focusing on defect prevention during development.

Building Quality in the Process

In an Agile environment, the goal is to bring the tester into the process early, before development starts. This collaboration between testers and developers is crucial for identifying potential problems before they become larger issues. One of the main points is the use of mistake-proofing or designing the development process to prevent defects from occurring in the first place. This includes automating code integration and using tools like Test-Driven Development (TDD) to ensure that tests are written before the code is developed, making it easier to catch issues early.

Unit Testing

The chapter moves on to discuss unit testing at Acme Media, where the team improved their process for testing individual units of code. Initially, developers at Acme performed manual testing of their code, but this approach was flawed because it relied on memory and manual execution, which led to delays and missed issues. After learning more about unit testing in their Agile training, Acme decided to automate unit tests. By writing scripts that test the functions, procedures, and classes, developers can quickly detect issues, especially during refactoring or when changes are made to the code.

The key benefits of unit testing include:

• Quicker Feedback: Developers receive faster feedback on the quality of their code, making it easier to pinpoint and fix bugs.
• Refactoring Support: Automated unit tests ensure that changes to the codebase don’t inadvertently break existing features.
• Continuous Integration: Unit tests can be integrated into the continuous integration process, which makes it easier to identify issues as soon as new code is integrated.

Integration Testing

Acme Media had an existing process for integration testing, where code from multiple developers was combined and tested together. However, the process had its challenges. The team would often wait several days before integrating code, which led to issues when they finally performed the integration test. To address this, Acme decided to adopt continuous integration, integrating code daily rather than weekly. This helps uncover problems sooner and reduces the time spent resolving integration issues. They also worked on increasing the automation of the build process, reducing the time it took to complete a build and integrating it into the team’s workflow more efficiently.

Functional Testing

Functional testing verifies that the software meets the specified requirements and works as expected. Acme Media used to perform functional testing in batches at the end of each 5-day cycle, but this led to inefficiencies because not all features were delivered in order of priority. Now, Acme uses iterative planning to ensure that the most critical features are tested first, with testing occurring throughout the iteration. This helps catch bugs earlier and ensures that the highest-priority features are working before others.

Acme also involved testers earlier in the process. Instead of waiting until after development, testers now participate in feature-card exercises and feature modeling. This collaboration helps identify potential issues before coding starts, reducing the risk of bugs later in development.

Exploratory Testing

The chapter introduces exploratory testing, a practice in which testers explore the software to find defects that may not be easily identified with functional tests. Acme Media holds company-wide bug stomp events, a form of exploratory testing where the team actively tries to break the software by using it in ways that the developers may not have anticipated. This helps identify usability issues or areas where the system behaves in unexpected ways. The chapter emphasizes the importance of exploratory testing, especially before releasing software to users, as it helps uncover hidden issues that functional testing might miss.

Test Automation

The chapter also highlights the value of test automation. The authors suggest that automation can save time in the long run, particularly for tasks like regression testing, where you need to verify that new code hasn’t broken existing functionality. For Acme Media, automating the build verification tests allowed the offshore team to run tests every night without requiring constant supervision from the onshore QA lead. While automating tests can be time-consuming initially, it provides a return on investment by freeing up testers to focus on more strategic tasks.

Key Points

• Agile focuses on building quality into the product from the beginning, reducing the need for later inspections and defect identification.
• Unit testing helps developers receive fast feedback and supports refactoring without breaking existing code.
• Continuous integration and more frequent builds help uncover integration issues earlier in the process.
• Functional testing is now integrated into the iteration cycle, ensuring that high-priority features are tested first.
• Exploratory testing is critical for identifying hidden defects that aren’t easily found through structured tests.
• Test automation is essential for ensuring that existing functionality isn’t broken during development, although it’s important to carefully assess where automation makes sense.

The chapter concludes by preparing Acme Media for the next phase: adapting to feedback from customers after the demonstration of the software. The next chapter will explore how to manage this adaptation process, ensuring that the team stays aligned with the customer’s needs.

Chapter 20 – Adapting: Reacting Positively to Change

Introduction to Adapting in Agile

This chapter explores the critical concept of adapting to change during an Agile project. It underscores that change is inevitable and part of the process. The authors emphasize the importance of being prepared to respond to changes as they occur, whether it’s through shifts in customer requirements, unforeseen technical constraints, or external factors such as market changes. Agile thrives on the ability to adapt quickly, ensuring that teams can respond to new information and feedback to continuously improve and deliver value.

Common Reasons for Adapting

The chapter outlines several common reasons why teams need to adapt during a project:

• Feature Is Larger Than Expected: Often, a feature turns out to be more complex than initially anticipated. Teams can adapt by prioritizing the critical aspects of the feature and deferring or removing non-essential elements. Sometimes, teams decide to continue the work into the next iteration if the feature is too big to finish on time.
• Customer Refinement of Requirements: Customers often refine their needs after seeing early iterations. Agile teams embrace these changes, working with the customer to adjust the project scope, and re-prioritize features based on these new insights.
• Changing Business Needs: The business environment can shift mid-project, and teams need to adapt to these changes. For example, if a competitor releases a similar product, a team might have to adjust their plans to differentiate their product.
• Technical Constraints: During development, unforeseen technical issues can arise, such as performance bottlenecks or compatibility issues. Teams can adapt by revisiting the design, considering workarounds, or postponing non-critical features.
• Unavailable Team Member: If a team member becomes unavailable during an iteration, it might affect the team’s progress. Teams need to adapt by redistributing tasks or adjusting priorities.
• Third-Party Delays: If third parties fail to deliver as expected, teams must either do the work themselves or adjust their plans accordingly.
• Team Throughput Lower than Expected: Sometimes, teams underperform in an iteration due to unforeseen complications. This may require adjusting expectations, extending the iteration, or revisiting the work in the next cycle.

Adapting During an Iteration

The authors discuss two main approaches to adapting during an iteration:

1. Limited Customer Interaction: Some teams prefer to minimize customer interaction during an iteration to maintain focus. They complete development and then present their work at the end.
2. Frequent Customer Interaction: Other teams, especially those embracing Agile fully, welcome ongoing customer interaction throughout the iteration, allowing them to refine features and make adjustments based on feedback as development progresses.

Adapting After an Iteration

At the end of each iteration, teams focus on four key activities:

1. Demonstrating and Gathering Feedback: Teams present their work to the customer and stakeholders, gathering feedback to understand what works and what needs adjustment.
2. Re-evaluating Priorities: Based on feedback and new discoveries, teams reassess priorities. Some features might be deferred or removed, and new features may be introduced.
3. Reviewing Team Performance and Velocity: Teams analyze their performance, assessing how many story points they completed compared to their estimates. This helps refine future capacity planning.
4. Re-planning for the Next Iteration: The team revisits the plan for the next iteration, adjusting it based on the feedback and insights gained from the current iteration.

How Acme Media Adapts During Iteration 1

Acme Media’s Auctionator project provides several examples of adapting during the iteration:

• Change in Feature Scope: The team discovered that adding a search filter by location was a valuable feature that needed to be integrated, even though it wasn’t initially planned.
• Technical Performance Issue: During iteration 1, Acme’s team identified a performance bottleneck when simulating concurrent bidding. The issue was resolved by optimizing the server’s performance, caching bidding data to improve speed.
• Underestimating Registration Needs: Acme also discovered that allowing users to bid without registering caused issues, leading to the decision to require registration for bidding. This change was agreed upon with the customer after assessing the impact.

Key Takeaways

• Adapting to change is a core component of Agile, and it happens continuously throughout the project lifecycle.
• Agile teams need to be flexible in responding to customer feedback, technical issues, and changes in business priorities.
• Adapting at the end of an iteration involves gathering feedback, reassessing priorities, evaluating team performance, and adjusting plans for the next iteration.
• The goal of adaptation is to always align the product with customer needs, ensuring that the project delivers maximum value even when conditions change.

The chapter concludes by preparing teams for the final steps of the Agile process. After completing several iterations and adapting to change, the next phase involves final preparations for deployment and delivering the product to the customer. The following chapter will focus on this critical stage of project delivery.

Chapter 21 – Delivery: Bringing It All Together

Introduction to Delivery Challenges

This chapter begins by tackling an essential question: why is delivery so complicated in Agile? Despite Agile teams ensuring each iteration is production-ready, releasing software often involves more complexity. In particular, releasing a set of features simultaneously can be challenging, especially when the features are interdependent. This is the case for Acme Media’s Auctionator project, where several auction-related features must work together before deployment.

In many projects, delivering working software is just the beginning. The actual release involves coordination across various teams—marketing, support, operations, and compliance. Acme’s process serves as an example of what needs to be done to prepare for release, which includes training users, preparing for support, executing marketing plans, and ensuring that all systems are ready for deployment.

When to Release

The chapter identifies several triggers that may prompt a release to production:

• Supporting Constraints: Project deadlines may be driven by customer contracts, regulatory requirements, resource availability, or the need to respond to competitors. Acme Media’s Auctionator project, for example, was pushed forward to meet customer expectations and market pressure.
• Predetermined Release Schedules: Some teams follow a fixed release cycle. Acme Media uses such a rhythm to manage expectations and align their releases with regular schedules, making it easier for both the team and the customers.
• Sufficient Value for Deployment: The ideal trigger for a release is when enough value has been delivered to the customer, ensuring the features meet their needs. This is typically confirmed at the end of each iteration when feedback and assessment guide whether to deploy the features or wait for more work.

The decision to release isn’t made lightly, and the chapter explains that while deploying every iteration may seem appealing, the complexity and cost involved often outweigh the benefits. Acme, for example, chose not to deploy at the end of iteration 1, as there was a need for additional features to create a more robust system for the users.

Final Testing

Before deployment, thorough testing is crucial:

• Functional Testing: Even though each iteration undergoes functional testing, the final release still needs a thorough round of testing to ensure that the last set of features works well together with the rest of the system.
• User Acceptance Testing (UAT): Some teams need to go through formal acceptance processes before deployment, especially if required by contracts or regulations.
• Performance Analysis: This includes final tests to check if the system can handle the load it will face in the production environment.

The importance of these tests is underscored, especially for nonfunctional requirements like system availability, data recovery, and load handling, which are often neglected during development but are crucial for smooth post-deployment operation.

Preparing Support Groups and Processes

Agile teams begin thinking about maintenance and support from day one. For example, Acme Media maintains a Maintenance and Support Worksheet, documenting everything from the location of supporting documentation to job schedules and known issues. This worksheet helps ensure that the team can address any operational needs quickly after deployment.

Support teams, including help desks, need to be prepared for new features and changes. Acme ensures that all support staff is trained to handle issues, with escalation paths in place for critical problems.

Communication and Training

Effective communication is vital for ensuring all stakeholders are aligned before going live. Acme Media created a communication and training plan for various audiences:

• End-users need to be notified of new features and the transition from old systems.
• Internal teams such as sales and help desk need to be trained to support the new release.
• Marketing teams must be prepared to promote the new features.

Go/No-Go Decision and Deployment Planning

The decision to go live is a collaborative process. Acme Media’s team considers factors like the stability of the code, outstanding defects, and readiness of support groups before making the final decision. Acme uses a checklist to assess the readiness of the system for deployment, covering areas like feature completeness, user acceptance, and performance.

Deployment Considerations

Acme’s deployment process takes into account several factors:

• Architecture: The team uses a disaster recovery environment to test the deployment plan, ensuring that the code works as expected.
• Safe Window: Deployment windows are chosen based on factors like holidays, resource availability, and user activity, with minimal disruption to users.
• Migration and Conversion: Although Acme doesn’t need to migrate data for the Auctionator project, they do have to phase out old systems, which requires a careful plan.

Finalizing Deployment Steps

Acme prepares deployment scripts during each iteration to ensure a smooth process. The team works collaboratively in a conference room during the deployment, solving issues as they arise. The deployment is executed methodically, with various steps in the process clearly outlined and assigned to the responsible team members.

Reducing Risk with a Pilot

Acme minimizes risk by deploying first to a disaster recovery environment before going live. For teams without a DR environment, a pilot or soft launch is another strategy. By releasing to a small audience first, teams can gather feedback and identify issues before a full-scale deployment.

Celebrating the Success

Once the deployment is completed, Acme Media celebrates the successful launch of the Auctionator. The authors stress that celebrating is crucial to maintaining team morale and acknowledging the effort that went into delivering the project. Recognizing achievements fosters pride and motivation, and it helps reinforce a shared sense of success.

Key Takeaways

• Software is developed in deployable units every iteration, but full deployment is more complex and requires additional steps like testing, support preparation, and communication.
• Releases can be triggered by deadlines, schedules, or when enough value is delivered, with customer involvement being key in this decision.
• Final testing, including functional, user acceptance, and performance tests, is critical before going live.
• Support teams need to be prepared with proper documentation and processes to handle post-deployment issues.
• A collaborative deployment process, including testing in a disaster recovery environment or through a pilot, can reduce risks.

The chapter concludes by preparing teams for a retrospective, which will help them analyze what went well in the deployment process and what could be improved in future releases.

Chapter 22 – The Retrospective: Working Together to Improve

Introduction to the Retrospective

This chapter focuses on the retrospective, a core practice in Agile that provides an opportunity for the team to reflect on their processes and identify areas for improvement. The retrospective is a regular check-in, where the team can discuss what went well, what went wrong, and how they can enhance their approach going forward. The authors explain that although retrospectives are essential, they often turn into unproductive complaint sessions unless properly structured. To avoid this, they outline a process that helps teams extract actionable insights and ensure that improvements are documented and followed up on.

Setting Expectations for the Retrospective

The chapter begins by stressing the importance of setting clear expectations before the retrospective. By providing guidelines to the team in advance, they will have time to reflect on the project and come prepared with their observations. The retrospective aims to identify:

• What went well: These are the successful elements of the project that should be repeated in future work.
• What went poorly: These are areas that need improvement and require a change in process.

Acme Media’s team follows this process, where they are trained to focus on improving the development process, not evaluating the project’s success. This distinction helps avoid the trap of blaming individuals or reviewing project outcomes, ensuring that the focus stays on refining the methodology.

The Survey: Pre-Retrospective Reflection

To facilitate productive retrospectives, Acme Media surveys the team members in advance, giving them time to reflect on the project before the meeting. The survey is structured to encourage participants to think critically about their experiences, with tailored questions specific to the project’s context. Anonymity in the survey responses helps ensure honest feedback. After gathering the results, the facilitator aggregates and shares them with the team before the meeting, helping the team to prepare for focused discussions.

This survey process ensures that the retrospective doesn’t become a rushed or chaotic meeting. It also helps surface issues early, allowing the meeting to focus on addressing root causes instead of merely documenting complaints.

Conducting the Retrospective Meeting

When it comes time for the retrospective meeting, the facilitator ensures that the meeting stays focused. The goal is to dive into the most important areas first, beginning with those where the team feels they’ve done well or poorly. This ensures that critical issues are addressed while also recognizing successful aspects of the process. A strong facilitator is crucial to keep the meeting productive, especially when team members have diverse perspectives or varying levels of comfort with speaking up.

Acme Media’s retrospective highlights several different personalities within the team, and the facilitator works to ensure that everyone’s voice is heard. While some team members are naturally outspoken, others need prompting to contribute, and some prefer to listen and reflect. Effective retrospectives require a facilitator who can balance these different dynamics and ensure that everyone is included in the conversation.

Identifying Root Causes and Turning Feedback into Action

The authors emphasize the importance of digging deeper into issues during the retrospective. For example, when a team member expresses difficulty testing a complex feature, the facilitator asks probing questions to uncover the root causes of the problem. In this case, the team realized that their feature cards lacked sufficient detail to handle the complexity of the bidding functionality. This insight led to the decision to break down complex features into smaller, more detailed cards and to improve the documentation process.

By identifying and addressing the root causes, the team can make meaningful improvements to their processes. Action items are prioritized, and the team commits to addressing the most important issues first.

Finalizing the Retrospective: Prioritizing Improvements

The chapter concludes by explaining how to prioritize the improvements that arise from the retrospective. The team lists out action items and organizes them based on importance. These action items are displayed prominently in the team’s workspace, ensuring visibility and accountability. During the next retrospective, the team revisits these improvements to assess whether they’ve been successfully implemented and whether further changes are needed.

Key Takeaways

• Retrospectives are vital for continuous improvement but require careful facilitation to avoid becoming complaint sessions.
• Setting expectations before the meeting helps participants prepare and focus on process improvements.
• Surveys before the retrospective allow team members to reflect on the project and surface key issues for discussion.
• A strong facilitator ensures that the meeting stays on track, balancing diverse personalities and encouraging participation from everyone.
• Identifying root causes during the retrospective helps the team develop actionable improvements.
• Prioritizing improvements and reviewing them in subsequent retrospectives ensures that the team continues to evolve and refine their process.

This chapter wraps up the discussion of the retrospective process, highlighting how it feeds into the larger goal of improving team performance. The next chapter will explore how to scale Agile methodologies across larger teams and organizations, building on the insights gained from pilot projects and retrospectives.

Chapter 23 – Extending the New Process Across Your Company

Scaling Beyond the Pilot

This final chapter shifts the focus from running a successful Agile pilot to scaling Agile practices across an entire company. While the pilot project helps a team experience Agile in action, applying it organization-wide—especially in medium to large companies—requires a deliberate and strategic approach. For smaller companies, the pilot might be enough. But larger enterprises need frameworks, leadership alignment, and a roadmap to evolve from isolated pilots to enterprise-wide agility.

What Happens After the Pilot

The authors list common findings from Agile pilots:

• Slower Pace: Teams feel slower at first because they’re still learning. Like someone following a detailed manual before gaining muscle memory, the early steps take time—but that’s natural.
• Confusion: Different interpretations of Agile practices often emerge. This isn’t a bad sign—it opens the door for conversation and alignment, which helps standardize how Agile will work in the company.
• Team Polarization: Some team members embrace Agile, others resist. It’s important to distinguish constructive feedback from blanket skepticism and use coaching or management intervention where necessary.
• Starting to Feel Agile: Perhaps the most powerful outcome of a pilot is that Agile stops being just theory. The team experiences it, learns from it, and begins to define what Agile means in their specific context.

Acme Media’s Retrospective Learnings

Acme’s core team evaluated their pilot using five Agile enablers:

1. Embracing Change: They improved from 20% to 50%, catching issues earlier with daily meetings—but still struggle to let go of traditional ways.
2. Customer Involvement: A big shift from getting feedback only at the end to working closely with the customer throughout. Developers are still hesitant to show incomplete code, but they’re progressing.
3. Frequent Delivery: Their biggest leap. From 0% to 50%. They now prioritize what matters and plan iterations around critical functionality, though they still need discipline to respect iteration deadlines.
4. Technical Excellence: They moved from 40% to 50%, embracing prototypes and smaller, time-boxed architectural efforts. They’re planning to experiment with TDD and increase automation.
5. Human-Centric Practices: Daily stand-ups improved communication, and teams started self-organizing. Still, there’s work to be done—like improving participation, documenting key decisions, and eliminating side discussions.

Moving From Pilot to Enterprise Adoption

The book introduces the Technology Adoption Lifecycle to explain how change spreads in organizations—from innovators and early adopters, to the early majority, late majority, and finally laggards. The gap between early adopters and the early majority is known as the chasm, and crossing it is critical.

Rather than a “big bang” rollout, the authors suggest evolutionary change, introducing proven Agile practices incrementally, based on what worked in the pilot. This approach respects different adoption mindsets and reduces chaos and resistance.

The SAMI Framework

To support enterprise adoption, the authors present the Sidky Agile Measurement Index (SAMI)—a structured framework to guide Agile adoption step-by-step. SAMI is not a grading system like CMMI, but a roadmap based on Agile values. It breaks down the path to agility into five levels:

1. Collaborative – Enhancing communication and collaboration.
2. Evolutionary – Delivering software early and continuously.
3. Effective and Integrated – Creating working software in an integrated environment.
4. Adaptive – Responding to change through feedback loops.
5. Encompassing – Creating an environment that sustains agility.

Each level includes principles and practices aligned to Agile values like embracing change, frequent delivery, human-centric design, technical excellence, and customer collaboration. The SAMI helps avoid randomly applying Agile practices and instead focuses on values and outcomes that matter.

The authors close with a practical reminder: don’t pursue Agile just for the sake of it. Use what works. Agile is valuable because it aligns with real business needs—delivering faster, reducing waste, and keeping customers happy. And while the SAMI provides guidance, what really matters is how you tailor it to your own context.

They leave us with two powerful takeaways:

1. Stay committed to continuous learning. Agile today is the best we have—but tomorrow could bring something better. Stay open.
2. Always tie your process back to business outcomes. Agile isn’t just a philosophy; it’s a means to build better products and grow the business.

4 Key Ideas from Becoming Agile in an Imperfect World

6 Main Lessons from Becoming Agile in an Imperfect World

My Book Highlights & Quotes

First, agile development is frequently initiated as a grassroots movement to develop better software—it is seen as a “developer thing.” Consequently, development managers and customer organizations are often not on board. This is a mistake, because dramatic improvements from agile development require a different mindset on the part of both development managers and the organizations for which the software is being developed

Second, some companies have made serious missteps in applying agile—perhaps by developing an unmaintainable code base or creating an unsupportable set of expectations in the minds of development teams or customers. Sometimes an agile implementation follows a simple recipe that is a bad fit to the company needs; sometimes the implementation is perfect for some people in the company (developers, for instance), but it doesn’t take into account the needs of others (testers, for example)

Finally, agile development might be considered a silver bullet—a quick and easy fix to problems that plague software development. In this case, the hard work required to make agile successful is ignored, and when companies come to the realization that agile is not going to be as easy as they anticipated, all too often commitment dissipates

Conclusion

Becoming Agile in an Imperfect World isn’t trying to impress you with theory—it’s here to help.

It shows that real teams, in real companies, can do better work by thinking differently. Not perfectly. Just better.

It’s a book that reminds us progress doesn’t come from doing Agile “right”—it comes from doing it in a way that works for you, your team, and the challenges you actually face.

If you’re looking for practical inspiration wrapped in down-to-earth advice, this one’s worth your time.

I am incredibly grateful that you have taken the time to read this post.

Support my work by sharing my content with your network using the sharing buttons below.

Want to show your support and appreciation tangibly?

Creating these posts takes time, effort, and lots of coffee—but it’s totally worth it!

If you’d like to show some support and help keep me stay energized for the next one, buying me a virtual coffee is a simple (and friendly!) way to do it.

Do you want to get new content in your Email?

Do you want to explore more?

Check my main categories of content below:

• Book Notes
• Career Development
• Essays
• Explaining
• Leadership
• Lean and Agile
• Management
• Personal Development
• Project Management
• Reading Insights
• Technology

Navigate between the many topics covered in this website:

Agile Agile Coaching Agile Transformation Art Artificial Intelligence Blockchain Books Business Business Tales C-Suite Career Coaching Communication Creativity Culture Cybersecurity Decision Making Design DevOps Digital Transformation Economy Emotional Intelligence ESG Feedback Finance Flow Focus Gaming Generative AI Goals GPT Habits Harvard Health History Innovation Kanban Large Language Models Leadership Lean Learning LeSS Machine Learning Magazine Management Marketing McKinsey Mentorship Metaverse Metrics Mindset Minimalism MIT Motivation Negotiation Networking Neuroscience NFT Ownership Paper Parenting Planning PMBOK PMI PMO Politics Portfolio Management Productivity Products Program Management Project Management Readings Remote Work Risk Management Routines Scrum Self-Improvement Self-Management Sleep Social Media Startups Strategy Team Building Technology Time Management Volunteering Web3 Work

Do you want to check previous Book Notes? Check these from the last couple of weeks:

• Book Notes #127: The Laws of Simplicity by John Maeda2025-04-04
• Book Notes #126: Inevitable by Mike Colias2025-03-24
• Book Notes #125: Revenge of the Tipping Point by Malcolm Gladwell2025-03-21
• Book Notes #124: Radical Candor by Kim Scott2024-09-04
• Book Notes #123: The Personal MBA by Josh Kaufman2024-05-09

Support my work by sharing my content with your network using the sharing buttons below.

Want to show your support tangibly? A virtual coffee is a small but nice way to show your appreciation and give me the extra energy to keep crafting valuable content! Pay me a coffee: