Book Notes #41: Agile by Andre Faria Gomes

Title: Agile
Author: Andre Faria
Year: 2013
Pages: 165

Today, agile methodologies are one of the most efficient ways to guide a project from beginning to end without complications and with a constant focus on delivering value to the customer. According to André Faria Gomes, renowned coach and team leader, Agile comes in different flavours. 

In addition to showing how Kanban, XP, and Scrum can be used together, he also shows how to incorporate each method into his day-to-day work.

Having read the book in Portuguese, I made notes in Portuguese as well. It is a translation made by me, not an official translation.

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 Agile

Book Overview

What if the biggest waste in software development isn’t bad code—but building the right thing at the wrong time?

That’s the unsettling idea that opens André Faria Gomes’s Agile: Desenvolvimento de Software com Entregas Frequentes e Foco no Valor de Negócio. It’s not a book about frameworks, rituals, or buzzwords.

It’s a reminder that Agile, at its core, is about delivering real value in a world that refuses to sit still.

Right from the first pages, Gomes invites us into the real world of project delays, misaligned expectations, and painful rework. He starts with Joana, a character you’ve probably met before—or maybe you’ve been her. After eight months of carefully gathering requirements for a major banking project, she learns that everything she planned for is now irrelevant.

The merger that changed the bank’s operations happened years ago. The need no longer exists. All that documentation? Useless. That moment sets the tone: in software, time is a ruthless editor, and what matters most isn’t how much you plan—it’s how quickly you learn.

And that’s where Agile enters—not as a silver bullet, but as a mindset shift. Gomes walks us through the story behind the Agile Manifesto, born from the frustrations of developers who were tired of delivering too late and too far from the customer’s real needs.

What makes his explanation different is how grounded it feels. You’re not just reading about values on a wall—you’re invited to think about how those values play out when your team is behind, the customer is anxious, and priorities are changing faster than your roadmap.

Throughout the book, Gomes keeps circling back to one word: value. It’s the anchor point for every chapter. Delivering value, prioritizing value, optimizing value. Agile, as he explains it, isn’t just about iterations or user stories—it’s about making sure that what you build actually matters. And to do that, you need more than process. You need fluency.

The idea of Agile fluency is one of the book’s strongest insights. It’s not enough to know the rules. True fluency, Gomes argues, is when a team can respond to challenges without losing focus on what matters. Like speaking a language under pressure, fluency is when Agile principles guide your instinctive responses—not just your planning sessions. It’s what separates teams that go through the motions from those that adapt and thrive.

What’s refreshing is how Gomes doesn’t romanticize Agile. He knows it’s hard. He acknowledges that just doing daily standups and calling work “sprints” doesn’t guarantee results.

Fluency takes time. It takes discipline. And it takes teams who are willing to reflect, adjust, and keep learning—even when things are going well.

One of the book’s most practical ideas is the shift from delivering features to delivering outcomes. Gomes challenges the traditional approach where teams chase deadlines and build everything on the spec list. Instead, he asks us to zoom in on what really adds value. Does the feature solve a problem? Will users care about it? Are we solving yesterday’s issue or anticipating tomorrow’s need?

This mindset shift isn’t theoretical. It changes how backlogs are prioritized, how success is measured, and how teams interact with customers. The role of the Product Owner, for instance, becomes far more strategic.

They’re not just managing scope—they’re actively steering the team toward high-impact results. And that requires tight collaboration, fast feedback loops, and a willingness to say no to work that looks important but delivers little.

Later chapters explore how to optimize not just the product, but the whole system. Gomes talks about flow, bottlenecks, dependencies, and the invisible walls between teams. It’s not the kind of stuff that makes headlines in Agile circles, but it’s exactly where most organizations struggle.

The real challenge, he argues, isn’t building software quickly—it’s getting the whole organization to support that pace without burning out or breaking down.

And he doesn’t let leadership off the hook. For Agile to work, the system needs to support it. That means empowering teams, aligning goals, removing silos, and—perhaps most importantly—trusting that small, iterative steps can lead to big results. It’s a quiet but powerful call to rethink how work is managed at every level.

By the final chapter, Gomes brings it all together with a simple question: what now? After adopting Agile practices, building fluency, and learning how to deliver and optimize value, the journey isn’t over.

Agile is not a finish line—it’s a habit. A way of thinking. A culture of learning. And sustaining that culture takes champions, leaders, and teams who are willing to keep asking what’s working, what’s not, and what value looks like today—not last quarter.

If you’re looking for a book that gives you a checklist or a detailed how-to guide for Scrum ceremonies, this isn’t it. But if you want to understand what Agile really means—beyond the buzzwords—and why it still matters, this book is a great companion.

It won’t hype you up with jargon. It will ground you in the kind of thinking that actually changes how teams work.

And maybe, just maybe, help you avoid building something perfectly that nobody needs anymore.

Chapter by Chapter

Chapter 1 – Introduction to Agile Methods

The chapter begins by presenting a familiar problem in the software development world. Joana, working on a large project at a bank, spends eight months gathering requirements and preparing all the necessary documentation. However, when the project is finally ready, she discovers that the problem the software was meant to solve had already been addressed two years earlier due to a bank merger. The project is canceled, and all that effort is wasted.

This situation highlights the issue with traditional methods of software development, where requirements are gathered upfront and fixed. Once the process starts, there’s little room to adapt to changes or new insights. The author uses this scenario to introduce the core issue Agile aims to solve: the need to deliver software that remains aligned with customer needs, even when those needs change over time.

Agile: A New Way to Work

Agile offers a solution by embracing change, delivering value quickly, and focusing on collaboration rather than excessive documentation. Instead of spending months planning everything upfront, Agile encourages teams to deliver software incrementally, with each iteration getting feedback from stakeholders to ensure it meets their needs. The focus is on real progress, measured by working software, not paperwork or tasks checked off.

The Birth of Agile

The chapter goes on to explain the origins of Agile, tracing it back to 2001 when a group of frustrated developers met in a ski resort in Utah. These developers, disillusioned by the rigid and slow processes of traditional software development, created what we now know as the Agile Manifesto. The manifesto focuses on four core values:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

These values advocate for a more flexible and responsive approach to development, placing greater emphasis on people and outcomes rather than following strict processes. The goal is not to discard the items on the right side of each pair, but to give more importance to those on the left.

Agile Principles and Methods

While the manifesto presents high-level values, it also includes twelve principles that guide Agile development. These principles emphasize things like delivering value early and frequently, welcoming change, and maintaining a sustainable pace. They encourage continuous improvement, allowing teams to adapt and evolve the product as they go. This iterative and flexible approach contrasts sharply with the traditional waterfall method, where each phase is locked in before moving on to the next.

From Waterfall to Agile

The chapter compares Agile to the traditional “waterfall” model of software development. In waterfall, everything is planned upfront—requirements are gathered, the system is designed, then it is built, tested, and deployed. This approach works well when requirements are stable and well understood, but it struggles when the business or technology landscape changes, as was the case in Joana’s project.

Agile, on the other hand, operates with shorter cycles and a continuous flow of feedback. It breaks the project into smaller, manageable pieces (called iterations) that are developed, tested, and released incrementally. By doing so, Agile allows teams to adapt to new information or changes in direction much faster.

The Shift in Mindset

One of the key points the author emphasizes is that Agile is not just a set of practices—it’s a shift in mindset. It’s about focusing on people, collaboration, and flexibility. Instead of rigidly following a set plan, Agile teams adjust their course based on what they learn along the way. This is a major change in how we traditionally think about software development.

Popular Agile Methods

The chapter introduces several popular Agile methodologies that have emerged over the years, including:

• Scrum: Focuses on managing work through structured cycles called sprints.
• Extreme Programming (XP): Aims for technical excellence with practices like test-driven development and pair programming.
• Kanban: Focuses on visualizing work and limiting work in progress to improve flow.
• Feature-Driven Development (FDD): Organizes work around building specific features, prioritizing value to the customer.

These methods are not rigid; they are meant to be flexible and adaptable to each team’s context. The idea is to take the best practices from these approaches and apply them in a way that suits the project’s unique needs.

Agility in Action

At its core, Agile methods are iterative. Each cycle includes planning, building, testing, and reviewing—enabling teams to quickly pivot and improve the product based on feedback. This stands in contrast to traditional approaches where feedback often comes too late in the process. Agile’s ability to incorporate feedback early and often is one of its key advantages.

The chapter wraps up by making it clear that Agile is not a perfect, one-size-fits-all solution. It’s simply a more flexible and adaptable approach that allows teams to better handle the uncertainty and complexity of software development. It doesn’t eliminate planning but encourages an approach where plans can evolve based on feedback and real-world data.

Agile focuses on people and outcomes, aiming to create working software that adds value from the beginning of the project. The goal is not to be rigid or stick to a plan at all costs, but to deliver something useful and valuable as quickly as possible.

Chapter 2 – Agile Fluency

This chapter takes a deeper look at the concept of Agile fluency—the idea that it’s not enough to simply understand Agile methods; teams need to truly embody them and practice them effectively. The author compares it to learning a new language. Just as a beginner might know some words but struggle with real conversations, teams might know the terminology of Agile but not yet fully grasp how to use it to navigate the complexities of software development.

Fluency is about more than knowledge—it’s about skill and adaptability. A fluent Agile team doesn’t just know the practices, they can use them naturally in response to challenges. They don’t need constant guidance or reminders to follow the right processes; instead, they make decisions in line with Agile values and principles, adapting to the context of the situation.

The Stages of Agile Fluency

The author introduces a model with four distinct stages of Agile fluency that a team progresses through over time. Each stage is more advanced than the last and reflects deeper integration of Agile principles into the team’s culture and work processes. The stages are:

1. Focus on Value: At this stage, teams are starting to understand that Agile is not just about faster delivery but about delivering value. They begin practicing Agile ceremonies, like sprints and standups, but they are still learning how to measure the true value of their work. The focus here is on understanding what adds value to the customer and aligning the work with business goals.
2. Delivery of Value: In this stage, teams are consistently delivering valuable features. They’ve become more comfortable with the Agile processes, and the focus is shifting toward delivering high-quality, working software. However, they are still refining their skills in terms of managing dependencies, estimating work, and dealing with more complex situations.
3. Optimization of Value: By this point, teams are highly skilled at delivering working software, and they focus on optimizing the value they deliver. This stage involves refining workflows, improving team collaboration, and ensuring that every part of the process maximizes value. Teams in this stage tend to have a much better understanding of customer needs and work to reduce waste and inefficiency.
4. Systemic Optimization: The final stage involves looking beyond the team and considering how the entire system—organization, processes, and tools—can be optimized to deliver even more value. Teams at this stage have internalized Agile principles to the point that they can apply them at a systemic level. They collaborate effectively across departments, optimize workflows for the entire organization, and continuously improve their practices in a way that maximizes the value delivered at every level.

Fluency Requires Regular Practice

The author emphasizes that Agile fluency is not a destination but a continuous journey. Just like learning a new language, it requires regular practice, reflection, and adaptation. The more fluent the team becomes, the more they can respond to changing circumstances without losing momentum. This fluency enables teams to react swiftly to customer feedback, pivot when necessary, and continuously improve without losing sight of the bigger picture.

The author also points out that fluent teams are more effective at embracing change. They aren’t afraid of pivoting when new information comes in. Instead of being rigid about the original plan, they embrace the opportunity to improve. Agile fluency means being comfortable with change, knowing when to course-correct, and doing so without breaking the flow of work.

Technical Excellence and Fluency

A key part of Agile fluency is technical excellence. The author argues that just as teams need fluency in Agile practices, they also need technical fluency to implement those practices effectively. It’s not enough to just have Agile ceremonies and sprints if the team’s technical practices aren’t up to par. Techniques like test-driven development (TDD), pair programming, and continuous integration are critical to ensuring that the software being delivered is of high quality and can be easily adapted as new requirements emerge.

Fluency Isn’t Just About Processes

Another interesting part of the chapter is the emphasis on Agile mindset. The author makes it clear that fluency isn’t about following a checklist of Agile practices—it’s about truly internalizing the mindset behind those practices. Teams need to embrace a collaborative, customer-focused, and iterative approach to development. This mindset shift is what allows them to be adaptable and responsive to change.

The Role of the Scrum Master in Fluency

The author also touches on the role of the Scrum Master in helping teams achieve Agile fluency. Scrum Masters are more than just facilitators; they’re coaches who help the team improve their processes, remove obstacles, and maintain the right mindset. They play a critical role in guiding the team through the stages of fluency, offering support as needed and ensuring that the team continues to grow in its understanding of Agile principles.

The chapter concludes by reminding readers that fluency doesn’t happen overnight. It’s a gradual process that requires patience and commitment. Just as with language learning, fluency in Agile is achieved through consistent practice, reflection, and the willingness to adapt. The more a team practices Agile, the more skilled and fluent they become, and the better they are at delivering value to customers.

In short, Agile fluency is about becoming so comfortable with Agile principles that they become second nature. Fluent teams don’t just “do” Agile—they live it. They continuously improve their practices, adapt to feedback, and focus on delivering value to the customer in a way that’s sustainable and efficient.

Chapter 3 – Focus on Business Value

This chapter focuses on one of the most important principles in Agile: delivering real business value. The author argues that Agile is not just about being fast or efficient—it’s about ensuring that what you’re building actually matters and adds value to the business. It’s a shift in mindset from just delivering features to delivering outcomes that have a tangible impact on the customer and the business.

Aligning Work with Business Goals

The chapter starts by addressing the common problem where the development team and business teams aren’t fully aligned. Often, business teams set goals for the project, and the development team works toward them, but the result is sometimes a product that doesn’t meet the actual needs of the business or customer. This misalignment can lead to wasted effort and resources, as was the case in the example from Chapter 1, where Joana’s project was ultimately canceled after a long development period.

In Agile, the author explains, the focus is on continually aligning the work with business goals and customer needs. This ensures that the team is always working on what matters most. Instead of locking down the requirements at the start and sticking to them no matter what, Agile teams engage in regular feedback cycles with stakeholders to make sure the work being done is always aligned with what the business actually needs at that moment.

Value-Driven Development

A key concept introduced here is value-driven development. The author emphasizes that it’s not enough to just build features based on what the client asks for. Instead, teams need to focus on the value that each feature brings to the customer. The goal is to prioritize features that solve the most critical problems or provide the most benefit, rather than just checking off a list of requests. In Agile, this is often achieved through tools like user stories, which help the team focus on the value each feature delivers.

One of the most important lessons in this chapter is that delivering value requires constant reflection. It’s not just about building the features that were initially planned or requested; it’s about ensuring that those features still deliver value to the customer as the project progresses. This means that teams must be open to change and feedback, constantly reassessing the priorities based on what they learn along the way.

Prioritizing Business Value

The author introduces the concept of prioritization and how it plays a critical role in delivering value. Agile teams need to be ruthless in prioritizing the work that has the highest impact on business goals and customer satisfaction. The Product Owner plays a critical role in this process, working closely with the team to ensure that the backlog reflects the most important and valuable work at any given time. The author stresses that teams should focus on delivering the most impactful features first, ensuring that value is delivered incrementally and early in the process.

The chapter also points out that business value isn’t just about features. It’s also about making sure the product is well-architected, scalable, and easy to maintain. Teams need to think about long-term value, not just short-term gains. This means ensuring that the software is built with technical excellence and sustainability in mind, which will make it easier to deliver future value over time.

The Role of the Product Owner

A significant part of this chapter is dedicated to the role of the Product Owner. The Product Owner is responsible for defining the business value and ensuring that the team is focused on the most important features. The author emphasizes that this is no easy task—it requires deep understanding of the customer, the business, and the project’s goals. The Product Owner needs to be able to prioritize work effectively, communicate with stakeholders, and constantly refine the backlog to reflect the most valuable work.

The chapter also discusses how the Product Owner and development team need to collaborate closely. Agile is not about just handing over a list of features to be built; it’s about constant communication and collaboration to ensure that everyone is aligned on what’s important and why. By maintaining this close relationship, the team can ensure that they’re always focused on delivering the highest value to the customer.

Customer Collaboration

Another important idea explored in this chapter is customer collaboration. The author argues that instead of treating the customer like an outside entity to be protected by contracts and documents, Agile invites them to be a part of the development process. This allows the team to continuously gather feedback, test assumptions, and refine their work based on what the customer actually needs.

The author makes the case that collaborating with customers frequently leads to better results. Customers can help the team prioritize features, clarify requirements, and provide valuable feedback early on, ensuring that the team is always heading in the right direction.

Responding to Change

Finally, the chapter discusses the importance of responding to change. In Agile, the belief is that change is inevitable, especially in complex projects. The author explains that instead of fighting change, teams should embrace it. This is one of the key benefits of Agile: it allows teams to adapt to shifting priorities, new information, or unexpected challenges without losing momentum.

By continuously seeking feedback and iterating on their work, Agile teams can make adjustments as needed, ensuring that the product remains aligned with customer needs and business goals. This focus on flexibility and responsiveness helps teams stay relevant and deliver real value throughout the project.

Chapter 3 reinforces the idea that value should be at the heart of everything in Agile. Agile teams focus on delivering high-quality software that meets real business needs, and they do so by collaborating with customers, prioritizing the most valuable features, and constantly adapting to changing requirements. The goal is not just to build software, but to build the right software—software that solves problems, adds value, and meets the needs of the business and its customers.

Chapter 4 – Delivering Value

In this chapter, the focus shifts to the practical aspect of delivering value in Agile development. While Chapter 3 emphasized the importance of understanding and prioritizing value, this chapter discusses how to actually deliver that value in a sustainable and effective way. The author explains that it’s not enough to just know what’s valuable—you must also be able to deliver it quickly and continuously.

The Core of Agile Delivery

The author begins by explaining that delivering value in Agile is about short, iterative cycles. Instead of waiting months or even years to release a product, Agile teams break down the project into small increments (called sprints or iterations) and deliver value with each one. Each increment should be a small, fully functional piece of the product that can be tested, used, and improved upon. This allows for faster feedback and helps the team make course corrections quickly.

Continuous Delivery vs. Big Bang Releases

A central point the author makes is the difference between continuous delivery and the traditional “big bang” release. In traditional development, teams often work for months or years on a product and release it all at once. This creates a high-risk situation because if the product doesn’t meet expectations, there’s little opportunity to make adjustments before launch.

In contrast, Agile teams focus on releasing small, working versions of the product regularly. These small releases allow the team to get feedback early and often, reducing the risk of delivering something that doesn’t meet the customer’s needs. Continuous delivery is about ensuring that there’s always a working version of the product that can be shared with stakeholders, customers, or users. This ongoing release process makes it easier to respond to feedback and deliver value in real-time.

The Role of the Product Owner in Delivery

The chapter emphasizes the role of the Product Owner in ensuring that value is delivered. The Product Owner is responsible for ensuring that the work being done aligns with the customer’s needs and business goals. They manage the Product Backlog, which is a list of features, enhancements, and fixes that need to be worked on. By maintaining a prioritized list of valuable work, the Product Owner ensures that the team is always working on the most important tasks first.

A key responsibility of the Product Owner is to collaborate closely with the team. Agile is about constant communication, and the Product Owner needs to be involved in regular meetings, sprint reviews, and feedback loops. This close collaboration ensures that the team is always delivering the right value at the right time.

Managing Stakeholder Expectations

Another critical part of delivering value is managing stakeholder expectations. The author explains that stakeholders, such as business leaders or customers, often have different ideas of what “value” looks like. It’s the Product Owner’s job to manage these expectations, ensuring that everyone is on the same page about what will be delivered and when. Agile’s iterative approach allows the Product Owner to regularly update stakeholders on progress, adjust priorities, and demonstrate value early on.

Feedback Loops and Iteration

The chapter highlights the importance of feedback loops in delivering value. In Agile, feedback comes in many forms: from customers, from internal stakeholders, from automated tests, and from team members. Feedback helps the team understand if they are on the right track and whether the features they are building are truly adding value.

The author emphasizes that the faster the feedback, the quicker the course corrections. After each iteration, the team should ask questions like: “Is this feature what the customer needs?” “Does it work as intended?” “Is it bringing value to the business?” By answering these questions regularly, the team can adapt and ensure that they’re always delivering value.

The Definition of Done

A key concept introduced in this chapter is the Definition of Done (DoD). The DoD is a shared understanding of what constitutes a completed feature. It’s a checklist that ensures that every feature delivered is fully functional, tested, and ready for release. The DoD might include things like:

• Code is written and reviewed
• Unit tests have passed
• Documentation is updated
• Feature is demoed and accepted by the Product Owner

By having a clear and agreed-upon Definition of Done, the team ensures that no work is considered “done” until it meets all necessary criteria. This helps maintain a high level of quality and ensures that the value being delivered is solid and reliable.

Small, Incremental Changes

The author stresses that delivering value is best done through small, incremental changes. By breaking the work into smaller pieces, teams can deliver value faster and adjust course as needed. This approach is less risky because it allows the team to test assumptions and adapt based on real feedback.

Rather than trying to solve everything in one go, Agile teams tackle smaller problems, delivering small but meaningful changes that can be built upon over time. This ensures that each release adds real value, even if it’s just a small part of the overall vision.

The Role of Quality in Delivering Value

Another important point in this chapter is the connection between quality and value. The author argues that quality is an integral part of value delivery. If the software being delivered is buggy or unreliable, it’s not valuable, no matter how many features it has. Agile teams focus on maintaining high quality by automating tests, integrating code regularly, and following good coding practices. By ensuring that the software is high quality from the start, teams can deliver value more reliably and avoid the risk of delivering products that don’t meet customer expectations.

Chapter 4 reinforces the idea that delivering value is an ongoing process that requires continuous feedback, collaboration, and iteration. Agile is all about delivering working software in small, incremental pieces, which allows for faster feedback and better alignment with customer needs. The key is to prioritize value, focus on quality, and deliver early and often. By doing so, Agile teams can ensure that the work they’re doing is always aligned with the business goals and that they’re delivering real value to the customer, one iteration at a time.

Chapter 5 – Optimizing Value

This chapter delves into the concept of optimizing value—how to ensure that the value delivered by an Agile team is not only sustained but also maximized. The author explains that delivering value is important, but it’s equally crucial to continuously refine the process and product to get the most out of the team’s efforts. In Agile, optimization is about finding ways to improve how work is done, increasing efficiency, and enhancing the overall impact of the product.

The Need for Continuous Improvement

The chapter begins by emphasizing that Agile is not a one-time fix—it’s about continuous improvement. The author highlights that once the team starts delivering value, it doesn’t stop there. Agile teams are constantly looking for ways to optimize their workflows, improve collaboration, and enhance the product based on real-time feedback.

The idea of optimizing value is tied to the principle of delivering value faster and more efficiently without sacrificing quality. The author argues that the key to achieving this lies in the iterative process of delivering small increments of value and refining the work after each iteration. Rather than aiming for perfection upfront, Agile teams aim to make small, continuous improvements that build upon each other over time.

Reducing Waste and Improving Flow

One of the central themes in this chapter is the idea of reducing waste. The author draws on lean principles and emphasizes that Agile teams should be focused on eliminating anything that doesn’t add value to the customer. Whether it’s unnecessary features, redundant processes, or excessive documentation, waste can slow down the team and prevent them from delivering value efficiently.

The chapter explores the concept of flow—the smooth and continuous movement of work through the system. The author explains that optimizing flow means ensuring that work items move through the system with as few delays as possible. In Agile, this is achieved by limiting work in progress (WIP) and focusing on finishing tasks before taking on new ones. By limiting WIP, teams can avoid bottlenecks and reduce the complexity of juggling too many tasks at once, ensuring a faster, more efficient delivery cycle.

Continuous Feedback for Improvement

Another important concept in this chapter is the role of feedback in optimizing value. The author stresses that feedback is the lifeblood of Agile. Regular feedback loops allow teams to assess whether the features they’re building are truly meeting the needs of the customer and business. Whether through sprint reviews, retrospectives, or customer surveys, feedback helps the team identify areas for improvement and adjust their approach accordingly.

The chapter emphasizes that quick feedback loops lead to faster adjustments and better outcomes. The faster the team can gather feedback and make changes, the quicker they can deliver value that meets customer expectations. The author argues that feedback is the mechanism by which the team can learn what’s working, what’s not, and where optimization is needed.

Empowering the Team to Optimize

The author also highlights the importance of empowering the team to take ownership of optimizing their workflows. Agile is not about micromanaging; it’s about giving teams the autonomy to identify inefficiencies and find solutions themselves. When teams are empowered to make decisions about how to improve their processes, they are more likely to engage in continuous learning and improvement.

The chapter also introduces the idea that teams need to experiment in order to find the best ways to optimize value. Whether it’s trying new tools, tweaking the process, or experimenting with different ways of working, Agile encourages a mindset of experimentation and learning. This freedom to try new things without fear of failure allows teams to discover more effective ways of delivering value over time.

The Role of Technical Excellence in Optimization

One of the key insights in this chapter is the role of technical excellence in optimizing value. The author argues that delivering high-quality, maintainable code is crucial for long-term optimization. Without a focus on technical excellence, teams risk accumulating technical debt, which can slow down progress and reduce the ability to optimize value in the future.

By maintaining high standards for coding practices, automating tests, and using tools for continuous integration, Agile teams ensure that their software remains flexible and easy to adapt. This focus on quality and excellence allows the team to make changes and deliver new features more efficiently, ensuring that value can be continuously optimized without facing roadblocks due to poor technical foundations.

Scaling Agile to Optimize Value

The chapter also touches on scaling Agile—how larger organizations can apply Agile principles to optimize value across multiple teams. The author emphasizes that scaling Agile doesn’t mean forcing every team to follow the exact same processes. Instead, it’s about ensuring that all teams are aligned on the same core principles of delivering value, collaborating effectively, and optimizing their work.

The author suggests that cross-functional collaboration is key when scaling Agile. Teams should work together across departments and functions to ensure that value is being delivered across the entire organization. The more aligned the teams are, the easier it is to optimize value across the board.

Sustainability and Long-Term Value

The chapter wraps up by focusing on sustainability—the idea that optimizing value isn’t just about short-term gains. Agile teams must create processes that are sustainable in the long term. Pushing teams too hard or focusing only on immediate results can lead to burnout, lower morale, and a reduction in overall productivity. Sustainable practices, on the other hand, ensure that teams can continue to deliver value over time without sacrificing their well-being or the quality of their work.

The author stresses that optimizing value is about building a culture of continuous improvement that lasts. By focusing on long-term sustainability, teams can ensure that they are always delivering value in the most efficient and effective way possible.

Chapter 5 makes a compelling case for continuous optimization in Agile. Delivering value is not a one-time achievement—it’s an ongoing process that requires teams to consistently evaluate their work, eliminate waste, and find ways to improve. Through feedback loops, empowered teams, and a focus on technical excellence, Agile teams can optimize their workflows and continue to deliver high-quality, valuable software. The key is to make small, incremental improvements that build on each other, creating a cycle of continuous value delivery.

Chapter 6 – Optimizing the System

This chapter takes a step back and looks at the larger system in which Agile teams operate. While previous chapters focused on optimizing value at the team level, the author now shifts the focus to optimizing the entire system—beyond the individual team—to ensure that value is delivered across the organization. The idea here is that the system itself can be a barrier to value delivery, and in order to maximize efficiency, the entire workflow—from team to organization—needs to be optimized.

Systems Thinking in Agile

The author begins by introducing the concept of systems thinking. In a complex environment like software development, the performance of a team is often influenced by factors outside the team’s control. Whether it’s delays caused by dependencies, poor communication between departments, or inefficient tools, these external factors can slow down the flow of work and hinder the team’s ability to deliver value efficiently.

The author argues that Agile teams must think beyond their immediate environment and consider how their work fits into the broader system. Instead of focusing solely on improving the team’s internal processes, Agile teams need to identify and eliminate obstacles that exist across the organization. This includes improving communication between teams, streamlining handoffs, and removing bottlenecks in the flow of work that affect value delivery.

Optimizing Across Teams and Departments

One key area the author addresses is how teams and departments must collaborate more effectively. While Agile teams often operate within their own boundaries, the reality is that many projects require coordination across multiple teams, departments, or even organizations. The author stresses that the best results come from teams working together to deliver value at the system level, rather than merely focusing on optimizing their individual workflows.

The chapter highlights that alignment between teams is crucial for effective collaboration. Agile organizations need to ensure that all teams are working toward the same goals, using the same principles, and communicating effectively to avoid misalignment. This alignment helps break down silos and ensures that value flows smoothly across all levels of the organization.

Breaking Down Silos

One of the major challenges in many organizations is the existence of silos—separate teams or departments that work independently and do not communicate or collaborate well with others. These silos can create delays, miscommunication, and inefficiencies. The author argues that in an Agile environment, these silos must be broken down in order to optimize the system. Teams need to collaborate more closely with each other, share information, and work together toward a common goal.

Reducing Dependencies

Another critical aspect of optimizing the system is reducing dependencies. Dependencies between teams or departments can create bottlenecks and slow down the flow of work. The author explains that by minimizing dependencies, teams can work more autonomously and make progress faster. For example, Agile teams should strive to own their entire value stream—from concept to delivery—so that they don’t rely on other teams for crucial parts of the process.

Reducing dependencies requires creating cross-functional teams that have the skills needed to complete the work end-to-end, without waiting for input from other teams. The author emphasizes that this approach leads to faster delivery and a more efficient workflow.

Tools and Practices for System Optimization

The chapter also discusses the role of tools and practices in optimizing the system. While Agile emphasizes people and processes over tools, the author acknowledges that the right tools can support system optimization. For example, automated testing, continuous integration, and collaborative project management tools can help streamline processes and ensure that teams can deliver value more efficiently.

However, the author also warns against over-reliance on tools. Tools should support the work, not dictate how it’s done. Agile is about flexibility and adaptability, and the tools used by teams should enhance those principles, not restrict them.

Leadership’s Role in Systemic Optimization

A major part of optimizing the system is the role of leadership. The author stresses that leadership at all levels must support the transition to an Agile mindset and actively work to remove barriers that hinder value delivery. This involves creating an environment where teams are empowered to make decisions, where cross-team collaboration is encouraged, and where feedback is valued.

Leaders need to ensure that the organization’s structure and processes are aligned with Agile principles. This means ensuring that Agile practices are supported across all departments, not just within individual teams. Leaders should work to remove hierarchical barriers and promote a culture of transparency, continuous improvement, and collaboration.

The Role of Metrics in System Optimization

The chapter also explores the role of metrics in optimizing the system. The author explains that measuring the right things is critical to understanding whether the system is performing well. However, it’s important that the right metrics are chosen—metrics that focus on the value being delivered, not just the speed or volume of work.

Some examples of useful metrics include:

• Lead time (the time it takes for a feature to move from idea to delivery)
• Cycle time (the time it takes to complete a specific piece of work)
• Flow efficiency (how much of the time in the workflow is spent actually creating value)

By tracking these metrics, teams can identify bottlenecks, improve flow, and make adjustments to optimize the system.

Feedback at the System Level

Finally, the author highlights the importance of system-level feedback. While individual teams benefit from regular feedback loops, the entire system must also be continuously evaluated. Feedback from customers, stakeholders, and other teams can provide valuable insights into how well the system is performing and where improvements can be made. Regular retrospectives should be conducted at both the team and organizational levels to identify areas for improvement and make adjustments accordingly.

Chapter 6 emphasizes that optimizing value at the system level is just as important as optimizing within individual teams. By thinking in terms of the entire system, Agile teams can remove obstacles, reduce dependencies, and improve collaboration across departments. The chapter calls for leadership to actively support Agile practices across the organization and work to create an environment where teams can work efficiently and effectively together. The key to optimizing the system is continuous feedback, the right tools and practices, and empowering teams to take ownership of their processes.

Chapter 7 – What Now?

The final chapter of the book addresses what happens after a team or organization has implemented Agile practices and has begun seeing the benefits. It’s one thing to adopt Agile and start delivering value—it’s another to maintain that momentum and continue improving over time. This chapter is all about sustaining Agile success and ensuring that the positive changes brought by Agile are long-lasting.

Agile as a Journey, Not a Destination

The author begins by reiterating that Agile is not a one-time transformation; it’s an ongoing journey. The mindset shift required to become Agile doesn’t happen overnight, and it’s not a simple, linear process. Rather, it’s about continually learning, adapting, and improving. The key is to view Agile as an ongoing evolution of how work gets done, not a fixed destination.

This chapter emphasizes that organizations and teams must be prepared for continuous change. As the business environment evolves, so too must the Agile practices. The world of technology, customer needs, and market dynamics are always shifting, and Agile teams need to be ready to adapt and adjust their practices to stay relevant. The chapter argues that this flexibility is one of the main strengths of Agile.

Sustaining a Culture of Continuous Improvement

A significant portion of the chapter focuses on maintaining a culture of continuous improvement. The author stresses that Agile teams should never become complacent, even after they’ve achieved fluency in Agile practices. Continuous improvement is at the heart of Agile; it’s a mindset that needs to be ingrained into the organization’s culture. Leaders and teams must remain focused on improving their processes, tools, and practices to keep delivering the best possible value.

The author encourages teams to regularly reflect on their work—through retrospectives, feedback loops, and performance metrics. These reflection sessions should not only focus on problems and obstacles but also on identifying areas for further optimization. By making improvement a regular part of the workflow, teams can maintain their agility and responsiveness in the face of new challenges.

The Importance of Agile Champions

The chapter also introduces the idea of Agile champions—individuals who are passionate about Agile and committed to spreading and maintaining Agile principles throughout the organization. These champions are often team members or leaders who are enthusiastic about Agile’s benefits and take on the responsibility of mentoring others, leading training, and supporting the overall Agile transformation.

Agile champions play a critical role in keeping the momentum going, ensuring that the Agile mindset continues to thrive, even in the face of obstacles. The author suggests that organizations should invest in these champions, give them the tools and resources they need, and encourage them to drive the Agile transformation forward.

Scaling Agile Across the Organization

Another important point the author makes in this chapter is the scaling of Agile. While many teams start with Agile practices at a small scale, the goal is to scale those practices across the entire organization. The chapter talks about the need for alignment across departments and teams, ensuring that everyone is working toward the same business goals and using Agile principles to get there. This involves breaking down silos, improving communication between teams, and aligning processes so that value can be delivered smoothly and efficiently across the organization.

Scaling Agile requires an organization to adapt its structure and culture. Traditional hierarchical structures may not be well-suited to an Agile environment, so leaders must work to create an organizational culture that encourages autonomy, cross-functional collaboration, and decentralized decision-making. In this way, Agile practices can be applied to the organization as a whole, improving coordination and maximizing the delivery of value across all departments.

Overcoming Common Obstacles

The author acknowledges that challenges will always arise during the journey. No organization is perfect, and adopting Agile isn’t a cure-all. Some of the most common obstacles teams face include resistance to change, insufficient leadership support, and difficulties in adjusting to new ways of working. The chapter offers advice on overcoming these challenges:

• Overcome resistance to change: Leaders need to emphasize the benefits of Agile and create a safe space for experimentation and learning. It’s crucial that employees feel supported and empowered to make mistakes and learn from them.
• Leadership support: Agile requires strong support from leadership, especially when it comes to making structural or cultural changes. Leaders should lead by example, demonstrating commitment to Agile principles and ensuring resources and training are available to teams.
• Adjusting to new practices: It’s easy for teams to fall back into old habits, especially when they face difficulties. The author stresses that Agile requires ongoing effort and a willingness to adapt, and teams must continue to evolve their practices based on feedback and results.

The Future of Agile

The chapter wraps up by looking ahead to the future of Agile. The author highlights that Agile will continue to evolve as new technologies, practices, and challenges emerge. The future of Agile lies in its flexibility—its ability to adapt to new conditions and provide value in diverse and rapidly changing environments.

The author encourages organizations to keep an eye on trends in the broader tech and business world, such as automation, AI, and digital transformation, and adapt Agile practices to leverage these changes. Agile’s future success will depend on how well it can integrate with new technologies and continue to deliver value in an increasingly complex world.

Chapter 7 brings the book to a close with a focus on the long-term success and sustainability of Agile practices. The key takeaway is that Agile is a journey, not a destination. Teams and organizations must be committed to continuous learning, improvement, and adaptation. By sustaining a culture of improvement, investing in Agile champions, and scaling practices across the organization, Agile can continue to provide value for the long term. Leaders must support the transformation, empower teams, and guide them through obstacles, ensuring that Agile principles remain relevant and effective as the organization grows and changes.

4 Key Ideas from Agile

6 Main Lessons from Agile

My Book Highlights & Quotes

“… Scrum is one of the most popular agile methods today and has a greater focus on the managerial aspects of software development. In it, each iteration is called a sprint. Generally, each sprint has a month period that can vary from a few days to a few weeks. The people involved in the development process are divided in Scrum into three main roles: the Scrum Master, the Product Owner, and the team…”

“… Unlike most agile methods, Kanban does not require iterations. Instead, it decouples planning, prioritization, development, and delivery so that each activity has its own cadence based on the reality and needs of the process. At regular intervals, repetitions succeed each other in a cadence. The Kanban method sets the pace for a certain type of event. It is possible to have a different cadence for prioritization, deliverables, retrospectives, and any recurring events…”

“… Each time a new team is formed, a process of maturation takes place. Newly formed teams are not as productive and dynamic as those whose members have already gotten to know each other, their strengths and challenges…”

“… In “Your Path to Agile Fluency,” Diana Larsey and James Shore claim that “turnover is the main cause of lost fluency in an agile team, and that when a team gains or loses members, it faces difficulties sustaining what it already knows…”

“… The Broken Window Theory states that a broken window, if not fixed for a while, gives people a sense that no one cares about the building. Before long, the building is so damaged that the owner is no longer able to repair it, so what was once just a sense of abandonment becomes a reality. When a developer leaves a code without testing coverage, for example, the next developer feels that the code wasn’t cared for, and creates a new method that’s untested…”

“… The results of metrics on individual work are corrupted when people believe they will be affected by them. In addition, measuring individual performance can undermine teamwork, since helping another team member may improve the teamwork performance metric while hurting yours. As collaboration tends to improve the performance of the team as a whole, the collaboration between people will be more encouraged when the team is measured rather than the individual…”

Conclusion

This isn’t a book that teaches you how to do Agile—it teaches you how to be Agile.

And that’s a big difference. André Faria Gomes shows that agility is less about what you do and more about how you think.

Whether you’re a developer, leader, or just someone who wants to work smarter, this book invites you to rethink how you define success—and how to build things that truly matter.

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 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 #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
• Book Notes #122: The First 20 Hours by Josh Kaufman2024-05-02

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: