24MCA1.

3: AGILE DEVELOPMENT and DEVOPS

UNIT – 1 [13 Hours]

Improving Agility
What Is Agile?: Agile’s Genesis - Born Out of Crisis - The Agile Manifesto - The Essence of
Agile - Why Agile Won - Why Agile Works - Why Agile Fails. How to Be Agile: Practicing
Agile - The Road to Mastery - How to Begin. Choose Your Agility: The Agile Fluency
Model - Choose Your Zones. Invest in Agility: Make Time for Learning - Choose or Create
Agile Teams - Choose Agile Coaches - Delegate Authority and Responsibility to Teams -
Change Team Management Style - Create Team Rooms - Establish a Learning-Friendly
Purpose for Each Team - Replace Waterfall Governance Assumptions - Change Harmful HR
Policies - Address Security Concerns. Invest in Change: Understanding Change - Large-
Scale Change - Making Changes - Get Management Buy-In - Get Team Buy-In - Get
Stakeholder Buy-In. Scaling Agility: Scaling Fluency - Scaling Products and Portfolios.

Agile’s Genesis
In the 1990s, software development faced a crisis, with many projects being over budget, late,
failing to meet requirements, or even cancelled, as highlighted by the CHAOS Report.
In response, organizations implemented rigid, highly detailed processes for creating software,
aiming to avoid mistakes.
This approach involved a linear sequence: business analysts gathering requirements,
architects creating detailed designs, programmers coding, and testers following specific plans
to check for defects.
This process was often viewed as a mechanical task, with each phase carefully documented
and reviewed.
Agile development, which emerged later, was a reaction to these overly controlled, process-
heavy methods.
Meanwhile, test leads would use the same documents to generate test plans, and when coding
was done, armies of QA personnel would manually follow those test plans and report
variances as defects.
After each phase, everything would be carefully documented, reviewed, and signed off.
These phase-based approaches came to be called “waterfall development,” or “phase-gate
development”.

Born Out of Crisis

In response to the challenges of software development in the 1990s, large companies created
highly detailed and rigid processes, defining every aspect of development, from roles to
documentation to approvals.
However, these processes were often ineffective, as only a small fraction of projects
succeeded.
When projects failed, the common belief was that the process just needed more detail and
documentation.
This led to an overwhelming amount of paperwork, which became known as "The Almighty
Thud" by Martin Fowler, symbolizing the weight of all the documentation.
This approach was criticized for being bureaucratic, dehumanizing, and discouraging
creativity or skill.
Programmers felt like replaceable parts in a machine rather than skilled professionals.
Ultimately, this rigid approach didn't work well in practice.
In response to these issues, a group of developers created simpler, more flexible "lightweight
methods" for software development.
These methods, including Adaptive Software Development, Crystal, Feature-Driven
Development, Extreme Programming, and Scrum, were designed to be less prescriptive and
more adaptable than traditional heavyweight processes.
These lightweight methods gained significant attention in the late 1990s, with Extreme
Programming, in particular, seeing widespread grassroots support among developers.
In 2001, a group of 17 people who supported these new methods met to discuss unifying their
efforts, which eventually led to the creation of the Agile Manifesto.

The Agile Manifesto

In the late 1990s, traditional software development methodologies faced challenges with
adapting to changing project requirements.
A group of visionary software developers, including Kent Beck, Martin Fowler, and Alistair
Cockburn gathered and collaborated in 2001, and formulated the Agile Manifesto.
The Agile Manifesto is a brief document built on 4 values and 12 principles for agile
software development.
The Agile Manifesto was published in February 2001 and is the work of 17 software
development practitioners who observed the increasing need for an alternative to
documentation-driven and heavyweight soft…
The Agile Manifesto is a document that sets out the key values and principles behind the
Agile philosophy and serves to help development teams work more efficiently and
sustainably.
The primary purpose of the Agile Manifesto is to provide a foundation for developing
software in a way that responds effectively to changing requirements and delivers value to
customers. It aims to shift the focus from rigid processes and extensive documentation to
individuals and interactions, working software, and customer collaboration.

4 Core Values of the tackle Agile Manifesto

 1. Individuals and Interactions over Processes and Tools: Focuses on the importance of
effective communication and collaboration among team members.
2. Working Software over Comprehensive Documentation: Prioritizes the delivery of
functional software as the primary measure of progress.
3. Customer Collaboration over Contract Negotiation: Encourages customers and
stakeholders to have active involvement throughout the development process.
4. Responding to Change over Following a Plan: On changing requirements, embracing
flexibility and ability to adapt even late in the development process.

12 Principles of Agile Manifesto

1. Customer Satisfaction through Early and Continuous Delivery: This principle

concentrates on the importance of customer satisfaction by providing information to
customers early on time and also with consistency throughout the development
process.
2. Welcome Changing Requirements, Even Late in Development: Agile processes
tackle change for the customer's competitive advantage. Even late in development,
changes in requirements are welcomed to ensure the delivered software meets the
evolving requirements of the customer.
3. Deliver Working Software Frequently: This principle encourages the regular release
of functional software increments in short iterations. This enables faster feedback and
adaptation to changing requirements.
4. Collaboration between Business Stakeholders and Developers: This says the
business people and developers must work together daily throughout the project.
There should be communication and collaboration between stakeholders and the
 development team regularly. This is crucial for understanding and prioritizing
requirements effectively.
5. Build Projects around Motivated Individuals: This promotes in giving developers the
environment and support they need and trusts them to complete the job successfully.
Motivated and empowered individuals are more likely to produce work with quality
and make valuable contributions to the project.
6. Face-to-face communication is the Most Effective: Face-to-face communication is
the most effective method of discussion and conveying information. This principle
depicts the importance of direct interaction which helps minimize misunderstandings,
and hence effective communication is achieved.
7. Working Software is the Primary Measure of Progress: This principle emphasizes
delivering functional and working software as the primary metric for project
advancement. It encourages teams to prioritize the continuous delivery of valuable
features, so it ensures that good progress is consistently achieved throughout the
process. The primary goal is to provide customers with incremental value and also
gather feedback early in the project life cycle.
8. Maintain a Sustainable Pace of Work: Agile promotes sustainable development. All
people involved: The sponsors, developers, and users should be able to maintain a
constant pace indefinitely. This principle depicts the need for a sustainable and
consistent development pace. This helps in avoiding burnout and ensures long-term
project success.
9. Continuous Attention to Technical Excellence and Good design: This principle is on
the importance of maintaining high standards of technical craft and design, so it
ensures the long-term ability in maintenance and adaptability of the software.
10. Simplicity—the Art of Maximizing the Amount of Work Not Done: Simplicity is
essential. The objective here is to concentrate on the most valuable features and tasks
and avoid unnecessary complexity as the art of maximizing the amount of work not
done is crucial.
11. Self-Organizing Teams: Self-organizing teams provide the best architectures,
requirements, and designs. These help in empowering teams to make decisions and
organize to optimize efficiency and creativity.
12. Regular Reflection on Team Effectiveness: This makes the team reflect on how to
become more effective at regular intervals and then adjust accordingly. Continuous
improvement is very crucial for adapting to changing circumstances and optimizing
the team's performance over time.

Why is the Agile Manifesto important?

 It is a revolutionized Software Development that focuses on a more flexible
and Adaptive approach rather than a rigid approach.
  It enhances Team collaboration where individuals can interact openly and freely, also
agile focuses on a collaborative work environment where team members can share
their ideas openly, communicate with each other and work efficiently.
 It helps in increasing customer satisfaction, Customers are also involved in the
process which ensures the product aligns with their needs and expectations, leading to
higher satisfaction and a better end product.
 Promote Flexibility and Adaptability, agile allows for 'responding to change', means
allows teams to adapt to evolving requirements and market dynamics and reduces the
risk of project failure.
 Accelerate Delivery, by focusing on working software, Agile encourages iterative
development and frequent releases, enabling faster delivery of valuable features to
customers.
How to use the Agile Manifesto?
Implementing an Agile Manifesto is not about only adopting the principles, it is also about
how an organization shifts its culture from a rigid one to a more flexible approach.
Here are some steps to use the Agile Manifesto
 Focuses on Agile Core Values first by encouraging your team, they can internalize and
prioritize the four core values in their daily work.
 Adopt Agile Frameworks Implement Agile frameworks like Scrum, Kanban, and
Extreme Programming that align with your team's needs and project requirements.
 Foster Open Communication, and, encourage regular communication among team
members and stakeholders freely, allowing them to share their ideas by creating an
environment where team members feel comfortable.
 Iterate and Improve, according to change in response, continuously assess your
process, and as per the feedback from the user make changes and adjustments. Agile
is about continuous improvement and learning.
 Engage with Customers Maintain ongoing collaboration with customers to gather
feedback and ensure the product aligns with their needs.

The Essence of Agile

Adaptive rather than predictive (Agile teams define success as delivering value, not
conforming to a plan):
The "CHAOS Report" defined success in software projects in a very specific way, based on
how closely a project adhered to its original plan. It categorized projects into three outcomes:
1. Success: A project was considered successful if it was completed on time, within
budget, and included all of the features and functions that were originally planned. In
other words, if the project stuck exactly to its initial goals and timelines, it was
deemed successful.
 2. Challenged: A project was considered "challenged" if it was completed and
functional, but didn’t meet the original plan. This meant the project went over budget,
took longer than expected, or had fewer features than initially specified.
3. Impaired: A project was classified as "impaired" if it was cancelled before
completion.
People-oriented rather than process-oriented (Agile says people are the most important
factor in software development success):

Heavyweight Processes: In the past, large organizations used very detailed and rigid
processes to manage software development. These processes focused on defining everything,
from roles to documents, in order to avoid mistakes. The idea was that by following these
processes exactly, you could produce consistent results regardless of the people involved. The
skill and creativity of individual developers were less important because the process itself
was supposed to ensure success. However, this approach often led to poor outcomes because
it ignored the human factors that make teams successful—like collaboration, motivation, and
the ability to adapt to changing situations.
Agile Approach: In contrast, Agile focuses on the people doing the work as the most
important factor for success. It's not just about their technical skills but also how well they
work together as a team, how motivated they are, and how safe they feel in expressing their
ideas. Agile recognizes that human factors—such as collaboration, trust, and a sense of
ownership—play a crucial role in creating great software.
In Agile, teams still have processes, but these processes are designed to support the people
doing the work, not control them. For example, if a team discovers a better way of working,
they have the freedom to change their process to make things more efficient or effective. The
goal is to create a work environment where people are empowered to make decisions and
improve how they work together.

Why Agile Won

In the early years after the Agile Manifesto was introduced, Agile was heavily criticized.
People thought it was "undisciplined" and doubted it could succeed. But over time, as more
teams adopted Agile, the criticism faded, and by the second decade, Agile had become
widespread. Traditional waterfall methods (which followed a strict, step-by-step process)
were largely abandoned. Some younger developers couldn’t even imagine how people used
those old methods.
The problem with waterfall processes wasn’t that they were completely broken, but that
large companies took them too far. These methods tried to control everything with extensive
documentation and detailed plans. They assumed that you could predict everything about the
software upfront, but in reality, it’s very hard to know exactly how a piece of software will
work or what it needs until you start using it. This made it difficult, especially for non-
technical stakeholders, to foresee all the requirements.
Agile addresses this by prioritizing working software early on. The goal is to get a
functional version of the software in front of real users quickly. This lets the team get
feedback right away on what’s missing or what needs to change, allowing them to adjust the
software as they go. In the Agile approach, working software is the most important measure
of progress, not detailed plans or documents.
In contrast, waterfall projects took years to develop working software, often only showing
results near the end. By then, it was too late or too costly to make changes. Additionally,
waterfall processes had "Change Control Boards" designed to reject change requests, which
made it harder to adapt to new information or requirements.
Agile focuses on making progress visible early, with working software being shown
continuously. This visibility lets stakeholders see the project’s progress and make adjustments
along the way. This ability to show tangible progress and adapt quickly was a major reason
for Agile’s success. While software projects still face challenges like being late or over
budget, Agile’s emphasis on delivering working software and being flexible to changes
solved many of the problems that led to the "Software Crisis."

Why Agile Fails

Initial Phase:
 Grassroots Movement: Agile started informally among programmers who wanted to
improve their work processes and achieve better outcomes. The focus was on
enhancing productivity, flexibility, and quality of life for individuals working on
software development.
 Core Ideas: The principles of Agile were centered around:
1. Delivering better results through iterative processes.
2. Adapting plans to changing circumstances.
3. Emphasizing collaboration, people, and customer needs over rigid processes.
Transition to Hype:
 Growing Success: As Agile proved effective, more organizations noticed its benefits,
and its popularity grew.
 Shift in Focus: The attention moved away from Agile's core values (like collaboration
and adaptability) to its reputation as a buzzword or trend.
 Superficial Adoption: Instead of truly understanding and implementing Agile
principles, organizational leaders began to adopt it as a status symbol, saying things
like, "Get me some Agile," without a deep commitment to the methodology's core
ideas.
a) Agile Is a Philosophy, Not a Product:
 Agile is a collection of ideas and principles, not a concrete tool or system you can
simply acquire or install.
  It’s about embracing a mindset focused on adaptability, collaboration, and
prioritizing people over rigid processes.
b) Agile Approaches Provide Guidance:
 Frameworks like Extreme Programming (XP) and Scrum offer specific practices and
methodologies to help teams work in an Agile way.
 However, following these frameworks mechanically won’t make an organization truly
Agile unless they also embrace the core philosophy.
c) The Underlying Philosophy:
 Agile’s core values emphasize adapting plans (being flexible and responsive to
change) and putting people first (valuing individuals and their interactions over strict
adherence to processes).
 These values require a fundamental shift in how an organization thinks and operates,
which can be challenging for many.
d) Cultural Mismatch in Organizations:
 For some organizations, this philosophy may feel "foreign" because they are
accustomed to traditional, hierarchical, and rigid ways of working.
 They may struggle to trust employees to self-organize, adapt plans dynamically, or
focus on people instead of strict rules or processes.
Agile success depends not just on adopting practices like Scrum or XP but on deeply
understanding and committing to Agile's philosophy. Organizations that fail to embrace
this mindset risk a shallow, ineffective implementation of Agile.

HOW TO BE AGILE

Practicing Agile
Adopting Agile successfully requires more than just superficial changes—it demands a
commitment to the philosophy and a willingness to change deeply ingrained habits. Starting
with a by-the-book approach ensures that the foundational principles and practices are
respected, even if they feel unfamiliar or

challenging at first. Over time, the value and interconnectedness of these practices become
apparent, enabling teams to truly embrace Agile.
1. Every Team Has a Process:
 Every team operates using a process, whether formalized or informal.
  This process is shaped by an implicit philosophy or set of beliefs about how software
development should be approached.
 However, this underlying philosophy is often unexamined or inconsistent.

2. To Be Agile, You Must Change Your Process:

 Adopting Agile means aligning your process with Agile’s philosophy: adaptability,
collaboration, and focus on delivering value.
 This can be both:
o Easy: You can start with a predefined Agile method, like Scrum or Extreme
Programming (XP), which provides a ready-made structure.
o Hard: Changing your way of working requires breaking old habits and
learning new ones, which can be uncomfortable and challenging.

3. Agile Practices as Habits:

 The Agile community calls these habits "practices", such as:
o Planning sessions.
o Automated builds.
o Stakeholder demos.
 These practices often serve multiple purposes and reinforce one another, creating a
cohesive and effective workflow.

4. Unique Combination of Practices:

 Agile methods combine practices in ways that align with its philosophy:
o They accentuate practices that reflect Agile values.
o They discard irrelevant practices.
o They introduce new ideas to enhance collaboration, adaptability, and delivery.

5. Start by Following Agile "By the Book":

 It’s tempting to modify or simplify Agile methods from the beginning, but this
approach often leads to failure.
 The least familiar practices (those that seem unnecessary or uncomfortable) are
usually the ones that bring the biggest shift in mindset.
 These unfamiliar practices are often critical for achieving true agility.
6. Understanding Comes with Experience:
 Agile methods and their interconnected practices can be difficult to fully understand
at first.
 Their benefits and underlying philosophy become clearer only after seeing them in
action and experiencing how they solve problems and reinforce each other.

The Road to Mastery

Mastering Agile requires discipline, patience, and a commitment to continuous learning.
Begin by rigorously following a proven method to build a strong foundation.
Over time, refine and adapt the method based on real-world experience.
The journey doesn’t end—Agile is about everlasting growth and evolution to meet changing
needs and challenges.
1. Start with a Well-Defined Agile Method:
 Why? Agile principles can be abstract, so using a specific, established method
provides clarity and guidance.
 By-the-Book Approach: Follow the method as it is designed, without skipping steps
or making modifications initially.

2. Practice First, Customize Later:

 Practice the Entire Method: Commit to practicing all the recommended practices as
a cohesive system for several months.
 Refine Your Understanding: As you use the method, you'll gain insight into why it
works and how its parts interact.
 Experiment Gradually: Only after mastering the basics should you start
experimenting with changes, focusing on improving specific areas.

3. Follow the Steps for Mastery:

Step 1: Choose a Focus Area
 Identify a subset of Agile ideas or goals to prioritize (e.g., improving collaboration,
enhancing adaptability, or delivering value faster). Use tools or guidance (like
Chapter 3) to narrow your focus.
Step 2: Implement Corresponding Practices
 Adopt as many of the related practices as possible, described in the book’s detailed
sections.
 Why this matters: Agile practices are self-reinforcing; they work best when used
together as a cohesive system.
Step 3: Apply Practices Rigorously
 Consistency: Stick to the method, even if it feels awkward or difficult initially.
 Adjustment Period: Expect 2–3 months to start feeling comfortable and 2–6 months
for the practices to become second nature.
 Common Pitfall: Teams often underapply practices, so if something isn’t working,
focus on doing it more rigorously.
Step 4: Experiment and Improve
 Once confident, start experimenting with changes:
o Make incremental changes to specific practices.
 o Observe the outcomes and refine further.
 Each practice includes guidance on why it works and suggestions for how it can be
adapted.
Step 5: Embrace Continuous Improvement
 There’s no end-point in Agile. It’s an ongoing journey of learning, experimenting, and
evolving.
 Mindset Shift: Agile is about continual adaptation to improve outcomes and
processes over time.

How to Begin
Journey of agile can be started in three ways:
1. Joining a new team
2. Introducing Agile to one or more teams
3. or improving the Agile teams you already have?

1. Joining a new team

If you’re planning to join a new Agile team, or just want to know more about how Agile works
in practice, “day in the life” story that describes what Agile can look like.
Every Agile team is different, so the team you join won’t be exactly the same, but the stories
will give you an idea of what to expect.
2. Introducing Agile
If you’re helping your organization create Agile teams, or you want to convince it to do. Use
the following checklists to stay organized.
 Choose an approach to Agile that your organization can support.
 Determine what your organization needs to do for Agile to be successful.
 Get buy-in to trying Agile.
 If you have multiple teams, decide how you’re going to scale.

In the weeks leading up to a team trying Agile:

 Determine who the team’s coach or coaches will be, and identify at least one person
who will act as the team’s product manager.
 Have the team’s product manager meet with the team’s executive sponsor and key
stakeholders to create a draft purpose.
 Ensure the team has a physical or virtual team room.
  Schedule and conduct the team’s chartering session.
 Ask the team to review its new practices.

3.Improving Existing Agile Teams

If you already have Agile teams and you want them to be better, your approach depends on
what kinds of improvements you want to make.
If you’re interested in fine-tuning your team’s existing process, and want to make bigger
improvements, the process is the same as introducing Agile to a team.

Applying Individual Agile Practices

1. Daily planning.
Instead of planning tasks for longer periods (e.g., a week), focus on planning and
completing tasks within a single day.
Benefits:
 Shorter, focused cycles reduce the impact of interruptions.
 Helps break work into smaller, more manageable chunks.
A collaborative activity can be conducted where the team decides on which tasks to
prioritize for the day.
 It encourages team involvement and ensures alignment on daily goals.
 It helps prevent scope creep and confusion about priorities.
 Conducting a joint planning session at the beginning of each day involving the
entire team.
 The goal is to agree on tasks, roles, and deliverables for that day.
 Ensures everyone is aligned and focused on the same objectives.
Any interruptions or new requests should be deferred until the next day’s planning meeting.
 Benefits:
 Keeps focus on the current work.
 Prevents the disruption of the day's plan and ensures that new tasks are evaluated
with proper context.
Encourage team-driven task estimation for greater ownership and realistic planning.

2. Iterations.
 Weekly iterations provide a structured approach to planning without the pressure of
frequent interruptions.
 Daily stand-up meetings ensure ongoing communication and quick problem-solving.
 Stakeholder demos give visibility and feedback throughout the iteration cycle.
 Visual planning tools like index cards and charts make work transparent and organized.

3. Retrospectives
Retrospectives are a critical practice in Agile that allows teams to reflect on their processes,
identify areas for improvement, and make adjustments.
Conducting frequent retrospectives helps teams adapt and continuously improve by
reflecting on what went well and what can be better.
4. Feedback
 A fast, automated build significantly improves the quality of life for developers by
providing quick feedback and automating repetitive tasks.
 It enhances productivity and quality by catching errors early, reducing integration
problems, and enabling faster iterations.
5. Continuous Integration
Continuous Integration (CI) is a software development practice where code changes are
integrated into a shared repository frequently (often multiple times a day), and automated
builds and tests are run to ensure the code works correctly.
6. Test-driven development.
Although test-driven isn’t as easy to adopt as the other practices, it’s very powerful. Test-
driven development is the basis for reducing bugs, increasing development speed, improving
your ability to refactor, and decreasing technical debt. It can take some time to master, so be
patient.

Choose Your Agility

What Do Organizations Value?

 Improving financial results: profit, revenue growth, shareholder value, cost savings
• Achieving organizational goals: strategic objectives, original research, charitable causes
• Improving market position: brand projection, competitive differentiation, customer loyalty,
attracting
new customers
• Gaining understanding: strategic information, analytics, customer feedback
• Reducing risk: security, regulatory requirements, auditing
• Increasing capacity: hiring, retention, morale, skill development, automation

Agile Fluency Model

The Agile Fluency Model is a framework that helps organizations measure their Agile
practices' effectiveness and maturity. It outlines four distinct zones of fluency:
1. Focusing Zone - Teams learn to deliver value by improving their technical practices
and team dynamics.
2. Delivering Zone - Teams focus on delivering high-quality products quickly and
adaptively.
3. Optimizing Zone - Teams learn to improving their development process and manage
risks effectively.
4. Strengthening Zone - Teams expand their capabilities and improve their work by
leveraging market solutions and innovation.

Each zone has several levels of maturity:

1. Learning. The team is learning the skills.
2. Proficient. The team is able to exhibit the skills when it concentrates on them.
3. Fluent. The team exhibits the skills automatically, without conscious effort, as long as it
has a coach as part of the team.
4. Independently Fluent. The team exhibits the skills automatically without needing a coach
or any one team member.
Focusing:
• Main benefit: Focus on business priorities; visibility into teams’ work; ability to change
direction
• Investments: Team structure; management; work environment
• Approximate timing: 1-4 month performance dip; 2-6 months until fluency
Delivering:
• Main benefit: Low defects and high productivity; technical longevity
• Investments: Development skills; integrating testing and operations
• Approximate timing: 2-6 month performance dip; 3-24 months until fluency
Optimizing:
• Main benefit: Higher-value releases and better product decisions
• Investments: Embedded product management; team ownership of budgets and plans
• Approximate timing: 1-3 month performance dip; 3-9 months until fluency

Choose Your Zones

It depends on which zones your organization can support.
In a vacuum, Focusing, Delivering, and Optimizing, all together, are your best choice.
The combination of all three provides the best results and purest realization of Agile ideas.
But choosing all three zones also takes the most investment.
If you can’t justify those investments, you’re likely to have trouble getting the support you
need.
And without sufficient investment, your teams will have trouble reaching fluency.

Focusing Fluency: The Foundation of Agile

 What it is: This fluency ensures teams can effectively collaborate, prioritize work, and
maintain clear goals. It’s about establishing a solid foundation for Agile practices.
 Why it matters: Without Focusing fluency, Agile principles won’t work effectively.
Teams might struggle with communication, alignment, and delivering value.
 If you can’t invest: If an organization isn’t ready to support Focusing fluency, Agile
may not be the right fit. However, in some cases, starting with Delivering fluency can
help build momentum toward adopting Focusing fluency later.
Delivering Fluency: Improving Speed and Reducing Costs
  What it is: This fluency emphasizes practices like high code quality, efficient
workflows, and managing technical debt. It’s aimed at delivering consistent value
quickly and sustainably.
 Why it matters: Without Delivering fluency, teams may face rising technical debt,
leading to slower development, higher costs, and reduced quality over time. This
fluency helps maintain long-term efficiency and effectiveness.
 Challenges: Achieving this fluency requires significant investment in learning,
training, and quality practices, which can be a barrier for some organizations.
Practical Approach:
 If your organization isn’t ready for the large investments required for Delivering
fluency, start with Focusing fluency first.
 By succeeding at Focusing fluency, teams can demonstrate tangible benefits, which
can help justify further investments in Delivering fluency to stakeholders.

Optimizing Fluency: Agile at Its Best

 What it is: Optimizing fluency focuses on continuous improvement, innovation, and
maximizing business value. Teams in this zone are empowered to take full ownership
of decisions and processes, driving the organization toward peak agility.
 Why it matters: This fluency showcases Agile's true potential by delivering high-
impact results and fostering innovation. It allows teams to adapt swiftly to changes
while aligning closely with business goals.
Challenges:
 Achieving Optimizing fluency is demanding. It requires:
o A culture of trust.
o Delegation of decision-making authority to cross-functional teams.
o Significant organizational and cultural shifts, which can be daunting for
traditional or hierarchical companies.
Building Toward Optimizing Fluency:
 Start with the Basics: Most organizations should first demonstrate success in
Focusing fluency (team alignment and clarity) and Delivering fluency (speed and
quality). These foundational zones build trust and credibility within the organization.
 Gradual Transition: Once Focusing and Delivering fluencies are well-established,
the organization can take on the added responsibilities and cultural changes required
for Optimizing fluency.
Organizations Ready for Optimizing Fluency:
  Companies like startups or those with a culture that already values decentralized
decision-making and cross-functional collaboration are better positioned to adopt
this fluency early. These organizations can reap significant benefits because their
culture naturally aligns with Agile principles.

Invest in Agility
 Agile isn’t just about adopting new practices or frameworks (e.g., Scrum, Kanban).
It’s about addressing the underlying limitations or barriers that hinder team
performance.
 These constraints might include lack of collaboration, unclear goals, outdated tools,
or rigid hierarchies.
 Simply following Agile practices without addressing the environment in which teams
operate is insufficient. For example, having daily standups or sprints won’t help if
team members lack clarity on their roles or don’t have the tools they need.
 Teams may follow the motions of Agile but won’t see meaningful improvements unless
the root causes of inefficiency are addressed.
 By investing in changing constraints—like improving communication, removing
bottlenecks, or giving teams more autonomy—you create conditions where teams can
thrive.
 Even if teams don’t perfectly follow Agile practices, they are more likely to improve
because the environment supports their success.
All Agile teams:
☐ Obtain buy-in from managers, teams, and key stakeholders
☐ Create long-lived, cross-functional teams, and allocate people solely to their teams.
☐ Ensure each team has a coach who can help team members learn to be an effective, jelled
team.
☐ Assign work to teams, not individuals. Expect teams to choose their own approach to day-
to-day planning and task assignments.
☐ Focus team-level managers on managing their work system rather than individuals and
tasks.
☐ Create a physical or virtual team room for each team.
☐ For each team’s first effort, choose a valuable but nonurgent purpose that’s good for
learning Agile.
☐ Replace waterfall governance policies with Agile governance policies.
☐ Remove, revise, or work around HR policies that impede effective teamwork
Focusing teams:
☐ Account for a 1–4 month performance dip on each team.
☐ Include people with user and customer skills on each team.
☐ Ensure each team includes, or has regular access to, someone who decides what it should
work on.
☐ Ensure each team includes a coach who can teach Focusing practices.
☐ Ensure each team has access to stakeholders or their representatives.

Delivering teams:
☐ Account for a 2–6 month performance dip on each team.
☐ Integrate all needed development skills, such as testing and operations, into each team.
☐ Ensure each team includes a coach who can teach Delivering practices.
 Ensure each team has control over its development, build, test, and release processes.
 For each team’s first effort, choose a purpose that involves a green-field codebase,
unless the team’s coach doesn’t think it’s necessary.
 Address security concerns that prevent collaborative development.
Optimizing teams:
☐ Account for a 1–3 month performance dip on each team.
☐ Ensure each team includes people who have business, market, and product expertise.
☐ Ensure each team includes a coach who can teach Optimizing practices.
☐ Give each team responsibility for its budget, plans, and results.

Make Time for Learning

Adopting Agile involves learning new skills, frameworks, and mindsets, which takes time and
effort.
During this adjustment period, teams may struggle to adapt, leading to a 10–20% temporary
performance dip as they learn the ropes of Agile.
This is a natural part of the learning process when adopting any significant change.
As they become proficient with Agile skills, their performance will increase.
It will continue to increase until they achieve fluency, and then the increase will gradually
level off, as Figure 4-1 illustrates. This is called the J-curve.
The time investment will typically pay for itself in the first year. The length of the initial dip
depends on the fluency zones each team is pursuing.
• Focusing: 1–4 months
• Delivering: 2–6 months
• Optimizing: 1–3 months

These periods overlap, so a team learning Focusing and Delivering skills together will have
a performance dip that lasts about 2–6 months.
In contrast, a team that learns Focusing skills first and moves to Delivering later will have
two dips: a 1–4 month dip when it learns Focusing skills and another 2–6 month dip when it
learns Delivering skills.
The net result is that stakeholders can be frustrated by the pace of Agile development,
particularly in the first year, when they’re dealing with three hits all at once: a real delay
from learning, a perceived delay from a focus on getting things done, and the cost of finishing
pre-Agile work that was declared “done” without actually being done.
This frustration can lead to teams being redirected away from learning Agile, and solely
focused on delivering software, before they’ve finished learning.
This is counterproductive for everyone: teams will feel yanked around and frustrated, and the
organization will have wasted the investments they’ve made so far.
Before teams begin their Agile journey, make sure managers and stakeholders are on board
with the first-year performance dip.
If there's no time for learning:
 To avoid a noticeable slowdown in performance, start small by focusing only on a key part
of Agile, such as prioritizing tasks and completing them efficiently (Focusing zone).
 This minimizes disruption but takes longer and costs more to fully adopt Agile.
 If your organization refuses any decrease in productivity, then now is not the right time to
implement Agile.
 Agile requires an initial investment of time and effort, so if your team cannot afford even a
small slowdown, it's better to wait.
 If your organization is always too busy and never makes time for improvements, that’s a
red flag.
 It shows deeper issues, like being stuck in a cycle of constant pressure or resistance to
growth.
 Convince management to make time for change. Explain that:
 Without change, the team may burn out or fall behind competitors.
 Agile will deliver long-term benefits that outweigh the short-term slowdown.
 Suggest starting with small, low-risk Agile practices to build confidence.
If there’s no budget for help…
The many free resources available online, and a dedication to learning, your teams can
teach themselves everything they need to know.
Outside help is, well, helpful, but it’s not required.

Choose or Create Agile Teams

Each team needs a coach to help team members learn how to be an effective Agile team.
• Every team needs someone who can help team members learn how to be an effective, jelled
team.
• Focusing teams need someone who can teach them the planning practices
• Delivering teams need someone who can teach them the technical practices
• Optimizing teams need someone who can teach them the business development practices
If you can’t hire the coaches you need…
You can grow your own Agile coaches. Choose senior practitioners who team members
respect and trust— if they’re not immediately obvious, ask your teams for recommendations—
and ask them to take on the challenge.

Delegate Authority and Responsibility to Teams

 Respect for People’s Abilities: Agile emphasizes that the individuals doing the actual
work—such as developers, designers, and testers—have the deepest understanding of the
tasks at hand. They are closest to the details and therefore better equipped to make informed
decisions.
 Authority and Responsibility: In Agile, authority is not about one person at the top
making all the decisions. Instead, responsibility and decision-making are distributed. The
team members are trusted to make choices related to their areas of expertise.
 Details Matter: Successful execution comes down to getting the small things right. Since
team members are involved in the day-to-day work, they are better positioned to address
nuances and complexities.
 Guidance by a Leader: Agile recognizes the importance of leadership, but the role of the
leader is to guide, support, and remove obstacles—not micromanage. This approach enables
the team to focus on their strengths while fostering innovation and accountability.
Work is assigned to teams, not individuals: Teams decide for themselves how to break their
work down into tasks, and who on the team will perform those tasks. You may need to change
ticketing systems and other workflow processes to fit this approach.
If work must be assigned to individuals…
If your organization isn’t comfortable with teams making their own task assignment
decisions, your organization lacks the trust that Agile requires. You might be able to convince
people to change their thinking by trying team-based work with a pilot Agile team, but
proceed with caution.

Teams decide their own processes: In particular, teams need to be free to use their own
lightweight, tool-free approach to planning rather than being tied to a corporate tool.
Management can put constraints on teams’ processes, but they must ensure each constraint
has a clearly articulated reason.
If tools don’t support team-based work…
If your company has existing work assignment systems that are difficult to change, a short-
term solution is to create a “phantom” person for each team who receives the team
assignments. Alternatively, team members can choose to treat individual assignments as team
assignments.

Focusing teams work with stakeholders to understand business needs and priorities:
The organization needs to make sure teams have easy access to stakeholders or their
representatives.
If teams don’t have access to stakeholders…
Unlike waterfall processes, which use an up-front requirements and business analysis phase,
Agile teams work with stakeholders throughout development to refine plans and gather
feedback. Without access to stakeholders, they won’t build the right thing.

Delivering teams control their development, build, test, and release processes: Again,
management can put constraints on those processes, such as mandating the use of a
corporate release pipeline, but make sure teams have the ability to develop and release on
their own without waiting for other teams.
If Delivering teams don’t have control over their release processes…
You won’t see the full benefit of Delivering fluency until your teams have control over their
release processes.

Optimizing teams control their own budget and product plans: Management defines each
team’s purpose, determines overall strategy, and sets the teams’ budgets. They also provide
oversight in the form of reviewing business indicators. Within that framework, the
organization needs to allow individual teams to decide for themselves how to achieve their
purpose and spend their budget.
If Optimizing teams don’t have control over their product plans and spending…
Optimizing teams need the ability to conduct experiments and adapt their plans, and that
requires them to control their plans and spending. Without it, they won’t reach Optimizing
fluency.

Change Team Management Style

In Agile, where teams design their own processes, assign their own tasks, and manage
stakeholder interactions, team-level managers might feel that their role becomes
unnecessary.
To avoid this, engage with managers to help them understand their new role and provide any
necessary training. Ensure that their leaders' expectations are also adjusted to align with
these changes.
Micromanagement is a management style where a manager closely observes, controls, or
tries to overly influence the work of their team. Instead of focusing on the big picture or
trusting employees to handle their tasks independently, micromanagers often get involved in
every small detail of a project.
Micromanagement (when managers control every little detail) can be irritating but not a
huge problem at first. However, it prevents team members from learning and growing because
they don't get to make decisions themselves. This slows down progress and makes Agile
adoption take more time and money.
Managers often micromanage because:
 They don’t know what they’re supposed to do.
 They’re worried they won’t have a role in Agile teams.
The solution is to:
 Reassure them that their role is still important.
 Help them understand their new responsibilities by providing training or guidance
from an Agile expert.

Create Team Rooms

Agile teams thrive on collaboration and continuous communication, which requires a team
room tailored to their needs—whether physical or virtual. For in-person teams, setting up a
physical team room can be a significant investment, but it’s also highly beneficial.
If a team is remote…
You can create a virtual team room.
If you can’t create a physical team room for an in-person team…
in-person teams can use virtual team rooms. But this approach combines the limitations of
both: the inflexibility and commute of working in person, along with the communication
issues that come with remote work.

Establish a Learning-Friendly Purpose for Each Team

Every team has a purpose: its place in the organization’s big-picture strategy. When a team is
learning Agile for the first time, it’s important to choose a purpose that will help team
members learn.
A purpose that’s valuable, but not time-sensitive: When the team is under significant time
pressure, members will struggle to learn. They’ll rely on familiar methods instead of taking
the time to explore new approaches.

A purpose that’s self-contained:

The more a team depends on other teams, the more coordination issues it will likely face.
While some challenges are normal, having too many can distract the team from learning.

A green-field (brand-new) codebase.

Teams learning Delivering practices have a lot to learn, and it’s easier to do with green-field
code. That said, they’ll need to learn how to work with existing code eventually. Teams that
have an experienced Delivering coach can ignore this requirement, if the coach agrees.

If there’s an important deadline…

Each team requires sufficient time to learn. If the deadline allows flexibility, you're fine.
However, if it doesn’t, it’s often better to postpone adopting Agile until after the deadline or to
select different teams.
If there’s no valuable green-field work to do…
It’s more important for teams to do valuable work than to have a green-field codebase.
Without an experienced coach, though, teams learning Delivering practices for the first time
are likely to have difficulty with pre-existing code. Expect a longer performance dip, more
time needed to reach fluency, and more frustration from programmers on the team.

Replace Waterfall Governance Assumptions

Governance refers to how work is authorized, monitored, and managed at a high level. In
many organizations, governance policies are based on a waterfall development model, which
may involve upfront documentation or phase gates, and typically follows a predictive
planning approach.
For optimal outcomes, governance policies should be adjusted to align with Agile practices.
This includes eliminating phase gates and adopting an adaptive planning approach.
If waterfall governance is required…
While adhering to waterfall governance policies can be wasteful and hinder your teams'
agility, it is possible to follow them if necessary. This approach can work for a few pilot
teams, but it’s important to switch to Agile governance before scaling Agile further.
A common governance requirement is to produce a fixed plan and budget upfront. The easiest
way to meet this is by using your current approach to create the plan and budget, then starting
the Agile process after project approval. Alternatively, for teams experienced in both the
Focusing and Delivering phases, you can allocate 4–8 weeks for "planning," begin work as
usual, and then refine a high-quality roadmap.

Change Harmful HR Policies

Agile thrives on teamwork and collaboration, but many organizational policies
unintentionally discourage this by promoting competition, valuing only tangible outputs, or
fostering a blame culture.
Examples include stack ranking, where employees are ranked against each other, and
environments that punish mistakes rather than treating them as learning opportunities. These
issues conflict with Agile’s emphasis on collaboration, learning, and shared success.
Cultural problems are often reflected in HR policies related to promotions and rewards,
which may prioritize individual achievements over team performance.
While cultural change takes time, progress can begin by revising HR policies, encouraging
managers to treat teams differently, and seeking support from senior leadership.
Instead of removing policies entirely, it can be more effective to creatively reinterpret and
apply them in ways that align with Agile principles.
Starting early and involving leadership is key to successfully addressing these challenges.
If HR policies are set in stone…
If changing problematic HR policies isn't an option, managers must shield their teams from
their effects. Make sure managers are well-versed in Agile principles and adept at navigating
corporate bureaucracy.
In organizations with many teams, prioritize Agile pilots with teams led by competent
managers. Their experiences can help build a case for implementing the necessary policy
changes.

Address Security Concerns

This investment is rarely an issue, but when it does become a problem, it can completely halt
progress. Therefore, make sure to address it, especially if you work in a security-sensitive
industry.
When in-person teams use practices like Pair Programming or Mob Programming, they often
work together at the same computer.
From a security standpoint, this can raise concerns because the person logged in to the
computer isn’t always the one at the keyboard.
In fact, the logged-in user might step away briefly, making it impractical to log out and back
in every time someone new takes over, as people switch frequently—sometimes every few
minutes.
If your teams plan to use these practices, involve your company’s security team early and
collaborate to address their concerns.
Creative solutions often allow Agile practices while maintaining security. For example, you
could use a locked-down, shared development account, combined with dedicated
development workstations or shared server-based virtual machines. Individual tasks like
email can still be handled on personal laptops.
Another related challenge is traceability. Some companies require every code commit to be
linked to its original authors.
You can address this by adding authors’ initials or email addresses in the commit comment.
Git, for instance, supports a "Co-authored-by" convention for commit messages.
Additionally, some companies mandate that all code undergo review before release. Pair and
mob programming inherently satisfy this requirement, but you might need to adjust your tools
to release code without a separate review phase.
If eliminating this requirement isn’t an option, consider modifying the tool to skip commits
that already have coauthors.
If there’s no flexibility around security requirements…
You can require the person logged in to stay at the computer. If they need to step away
briefly, they either switch logins or pause work until they return.
However, this approach creates more disruption than you might anticipate, so it's better to
explore solutions that let work continue seamlessly.
Another option is for teams to use tools designed for collaborative remote work instead of
sharing the same computer.
While this might work for remote teams, it introduces significant friction for in-person teams,
even when members are sitting next to each other, so it’s not recommended unless the team is
already remote.

Understanding Change
You have determined that Agile will increase the success of your teams. You are aware of the
zones with the optimum trade-offs between cost and benefit. You have determined which
investments are necessary for your business.
Agile introduction is not a break to the rule that change is difficult.
How many teams are impacted and how effectively you handle the change will determine
how difficult it is. It doesn't have to be a huge concern if one team is ready to implement
Agile with the full support of your company.
It's a huge concern if you're attempting to transform fifty teams in a company that is
inexperienced with Agile concepts.
Virginia Satir's Change Model, which is displayed below, is one tool for understanding how
people react to change. A transformation goes through five stages, as the graphic illustrates.
They relate to Agile in the following ways:
Late Status Quo:
This is how things were done before Agile. It feels familiar and comfortable. Everyone is
aware of their responsibilities and how to carry them out. However, some people aren't
entirely satisfied and believe Agile will help. They fight for change.
Resistance
As the change-seekers gain momentum, Agile change of some kind is more likely to occur.
We refer to this as a foreign element. Individuals begin reacting to the prospect of change.
Many people are against it. They claim that Agile is pointless, unproven, or a waste of time.
Some people are upset. Resistance increases with the number of impacted individuals.
Chaos.
After approval of the Agile change, teams begin implementing Agile methods. Conventional
expectations and methods of operation are no longer relevant. Moods are unstable, and
people feel lost and confused. There are good days and horrible days. Sometimes people act
like children again.
Integration.
People begin to get used to their new working methods with practice. They find an element of
Agile that particularly appeals to them, known as a transformational notion.They begin
making a sincere attempt to make Agile work and embrace the opportunities it offers.
Performance increases, morale rises, and chaotic feelings diminish.
New Status Quo
Individuals have successfully navigated the transition and emerged on the other side. They
feel confident enough to keep making minor adjustments because their new Agile methods of
working are familiar and comfortable. As people try out more little adjustments, performance
has steadily improved and is now higher than it was prior to the alteration.
You can decrease (but not eliminate!) the chaos by using the following techniques:
Support.
Help people understand how to do their job in the changed environment. Provide training,
coaching, and other ways for people to get help without feeling judged.
Make the investments.
Make sure everyone has someone they can talk to, either at work or in their personal life,
when they’re feeling overwhelmed.
Information.
Be transparent about what’s happening, what’s known, and what’s yet to be determined.
Address people’s career concerns. If you can do so honestly, make an explicit promise that no
one’s getting fired as a result of the change.
Communicate more than you think should be needed
Structure.
People need ground to stand on, so provide a roadmap for the change.
When things are uncertain, describe what you need to do to make them certain, and when you
expect that to happen.
If there’s an interim step, such as temporary teams, be clear that it’s temporary, and describe
what’s going to happen next.

Large-Scale Change
Don’t underestimate the importance of change management.
Large organizational changes affecting 30-70+ people can cause widespread disruption,
including rumours, job insecurity, and resistance.
Leaders frequently fail to see that these changes require expert change management. Leaders
who already believe that the change is necessary could underestimate the opposition that
others would encounter, which could result in pushback and the initiative's failure.
Effective change management reduces interruption and guarantees more seamless transitions
by enlisting HR or Agile experts with the necessary experience. Implementing Agile
improvements gradually, beginning with a limited number of teams, is advised for smaller
firms or those without professional assistance.

Making Changes
Kaizen, meaning "continuous improvement," is a core concept in Agile. However, it is best
suited for refining existing practices rather than making transformative changes.
For example, in a document-or blame-oriented culture, kaizen may optimize current
behaviours but won't help transition to Agile. Making the leap to Agile often requires a more
significant shift than gradual improvement can achieve.
To shift to Agile effectively, organizations should embrace kaikaku (transformative change)
rather than relying solely on kaizen (incremental improvement).
Kaizen works for refining existing practices but is insufficient for the fundamental changes
Agile demands. Great Agile teams start with kaikaku, making a focused, all-in investment to
adopt Agile practices fully.
Mediocre teams often attempt to kaizen their way to Agile, leading to stalled progress,
burnout, and change fatigue. This gradual approach causes longer-lasting disruption than
kaikaku.
For large organizations, gradual adoption of Agile is safest, but kaikaku should still be used
within smaller increments, such as starting with one team or specific fluency zones.
Established Agile teams can use kaizen for improvement but should use kaikaku to adopt new
zones requiring significant changes. Effective kaikaku requires discipline, clear focus, and
proper investment.

Get Management Buy-In

Support from management is necessary for agile. Without it, there would be ongoing conflict
between the non-Agile culture of your company and the Agile practices of your teams.
Even if you are a manager, you still need your boss's support, and it's even better if your peers
do the same.
1. Start with a Conversation
It starts with a discussion. One-on-one is usually the easiest, and face-to-face or at least video
talks will yield the best results. Begin by enlisting the support of a powerful manager you
admire. They will assist you in determining who else you should speak with and how to do
so.
Discuss the difficulties the company encounters with software development in your
discussions, beginning with that initial manager. Discuss how you believe software
development could be improved in your organization based on the advantages outlined
Engage your audience rather than controlling the conversation. Ask them which zones they
believe are most significant after briefly outlining each zone's advantages. Find out why.
Spend more time listening than talking.
Instead of promoting Agile for its own sake, put a greater focus on what they have to gain and
what they will lose if they do nothing.

2. Get the Economic Buyer’s Approval

An ultimate goal is to speak to the person who has the authority to make the investments
which is required by the teams. This individual is referred to as “the economic buyer" in
sales.
Gatekeepers, who see their role as protecting the economic buyer's time, are often positioned
around economic buyers.
They will want to hear your key selling point to determine if it's worth presenting to the
buyer.
Their goal is to save the buyer's time, not to take your idea. At times, they may claim to be
the decision-maker, even though they lack the authority to make the purchase.
Don’t be misinformed. While gaining the support of gatekeepers is useful and often essential,
it’s not sufficient.
Gatekeepers don’t have the authority to approve the investments by the teams. The teams
need to engage directly with the actual economic buyer.
In your conversation with the economic buyer, talk to them about what they want from their
organization
and how Agile will help. This works even better if a manager they trust speaks informally on
your behalf.
Before speaking with the economic buyer, focus the conversations on the advantages of Agile
and the relevant issues.
Don't focus too much on the investments because it could distract or worry people who don't
have the power to approve them.
When you do meet with the economic buyer, your primary objective is to secure their
agreement to invest in Agile.
Time will likely be limited, so keep the focus on the big picture. In many cases, it’s more
effective to treat the meeting as a conversation rather than a formal slide-based presentation.
After the buyer has accepted Agile's advantages, discuss the costs. Just list the main
investments required for each zone, explain how those zones relate to their goals, and ask
them which investment-benefit trade-offs seem most appropriate.
Don't go into too much detail. Offering multiple choices instead of requesting a yes/no
response lowers the likelihood that they will flatly reject you.
Lastly, get their consent to contact them again.
3. Make a Formal Proposal
Now it’s time to create a proposal. Its formality will vary based on your organization, so work
with your sponsor and allies to refine and promote it to the economic buyer. Be prompt,
polite, and persistent.
Your proposal should clearly outline the expected benefits for your organization and the
required investments. Be specific and tailor Agile’s general benefits
While some compromises may be necessary, avoid compromising too much, as the
investments are key to realizing Agile’s benefits.
If this sounds like too much work…
This careful buy-in process is meant for situations where support is uncertain—such as when
working with multiple teams, seeking significant investments, or navigating a bureaucratic
organization hesitant about Agile ideas (even if they frequently reference the term).
However, if that’s not the case and you’re simply helping a small team become more Agile,
and you and your manager already have the authority to make the necessary investments, go
ahead and act on it!
If management thinks they’re already Agile…
Many organizations today believe they’re already Agile—some even claim to be “post-Agile”
or “little-a agile, not big-A Agile.”
Arguing about terminology isn’t productive. Instead, focus on the actual challenges your
teams are facing, the benefits Agile could bring, and the investments required to achieve
those benefits. Let the organization call itself whatever it wants while you address the real
issues.
If management isn’t supportive…
If managers are unresponsive, try understanding their perspective—how Agile can help them
achieve their goals. If it’s not a fit, consider alternative approaches like. Seek guidance from a
trusted manager or conduct informational interviews with experienced Agile practitioners for
advice,
While early Agile teams often adopted Extreme Programming without approval, this
approach frequently left project managers burdened with bridging cultural gaps, leading to
burnout. It’s not recommended.
Some people use the Kanban method to motivate organizational change. Kanban wraps
around existing ways of working to highlight work-in-process bottlenecks and the cost of
delay. It’s easy to put in place and can motivate a more Agile approach to your work.
Kanban is a kaizen approach to change, so it’s slow and can only go so far, but it’s very
effective and can lead to permission for kaikaku.

Get Team Buy-In

To foster honest communication, it suggests meeting with teams individually, without
managers present, to create a safe space for team members to express their thoughts.
Managers should express support but allow the team to decide.
The process involves explaining why Agile is being considered, its benefits, potential
challenges (including a period of chaos lasting up to three months), and the structured trial
approach: teams commit to a by-the-book Agile practice for three months, evaluate progress,
and decide after six months whether to continue or revert.
Crucially, teams must have the genuine option to decline. Offering the ability to refuse and
reevaluate later makes it safe for teams to try Agile.
Ensure plenty time is given to answer all team members' questions, as the meeting typically
lasts about an hour but may take longer. After addressing all concerns, emphasize that there
will be no consequences for voting against Agile—this must be genuine. Finally, ask the team
to vote.
Get Stakeholder Buy-In
To successfully implement Agile, it’s crucial to gain buy-in from key stakeholders, especially
those with political influence, as their resistance could undermine progress.
The most resistant stakeholders are often business partners like product management,
marketing, and sales, who are accustomed to a predictive approach with fixed commitments.
Agile’s emphasis on adaptability, continuous feedback, and frequent value delivery can seem
like an excuse to avoid promises, leading some to resist it.
Engage stakeholders in one-on-one discussions, ideally led by trusted managers or allies, to
address concerns and demonstrate that Agile provides visibility and control rather than rigid
predictability.
Treat stakeholders as partners, emphasizing your commitment to making their jobs easier and
ensuring their success.
If concrete commitments are required…
Agile uses adaptive planning, adjusting plans as needed to achieve the best results. While
teams can commit to specific dates, they can’t guarantee which features will be completed by
then. If fixed-date, fixed-scope plans are necessary, a waterfall governance approach can be
used, though accuracy isn’t guaranteed. If this level of flexibility is unacceptable, Agile may
not be the right fit.
If stakeholders don’t buy in…
Some software teams have a difficult relationship with stakeholders, especially in product
management and sales, leading to resistance against Agile. Stakeholders may object due to
distrust or concerns about the initial learning slowdown.
If only a few stakeholders resist, Agile can be introduced in teams they don’t work with. If
resistance is widespread, a pilot team with influential, open-minded stakeholders can help
demonstrate Agile’s benefits over time. However, forcing Agile on unwilling stakeholders can
cause long-term backlash. If opposition is too strong, Agile may not be a good fit for the
organization.

Scaling Agility
Scaling Fluency
Many organizations attempt to scale Agile without first developing true agility. They invest in
large-scale Agile frameworks without building team fluency or organizational capability,
leading to failure. Successful scaling requires enhancing organizational capability, coaching
capability, and team capability.
Organizational Capability
A common mistake in adopting Agile is failing to make necessary investments. Even with
proper investment, hidden challenges may arise.
Before scaling Agile, resolve organizational issues by starting with a pilot team or a small
group (no more than five teams). If working with an expert, follow their guidance; if not, let
pilot teams identify recurring roadblocks. While these issues don’t need organization-wide
solutions, they must be addressed for each team adopting Agile.
Before scaling Agile, ensure your organization can support fluent Agile teams. Resist the urge
to push Agile aggressively—until fluency is established, only pilot teams should adopt the
approach while others continue with the existing method.
Coaching Capability
To successfully scale Agile, organizations need experienced coaches for both big-picture
strategy and team-level fluency. While books and training can help develop in-house coaches,
hiring experienced coaches accelerates the process. Each team requires a dedicated coach,
and skilled team-level coaches are the primary constraint on scaling. A homegrown approach
involves providing resources and enabling experienced coaches to rotate between teams as
fluency improves. Coaching skills differ from development skills, so additional coaching for
new coaches may be necessary. Less-experienced coaches should focus on one team, while
seasoned coaches may support two.

Team Capability
The coaches will help the teams gain fluency. Hiring a big consultancy to rapidly scale Agile
by staffing teams with experienced Agile developers (50% or more) can create instant fluency
—if organizational capability is already in place. However, this approach is expensive and
risky, as many firms lack true Agile expertise. Choosing the right people is crucial, as many
so-called Agile developers have limited skills, often only reaching the Focusing zone.
Staff augmentation for Agile scaling has a major risk: even if external hires create fluency,
they often lack coaching skills, causing Agile changes to fade once they leave. To succeed,
organizations must also develop in-house coaches. Large firms may not provide coaching
expertise, so smaller, specialized consultancies are a better choice for Agile transformation
and coaching-the-coaches. The right people matter more than the vendor.

Scaling Products and Portfolios

Fluency is essential for scaling Agile, but coordination between teams is also crucial to
manage dependencies and avoid bottlenecks. There are two main strategies: vertical scaling,
which increases the number of teams that can collaborate smoothly, and horizontal scaling,
which minimizes dependencies by isolating team responsibilities. Both strategies can be
combined for effective scaling.
Scaling Vertically
Vertical scaling increases the number of teams that share ownership of a product or portfolio,
meaning any team can work on any part of the product or code.
Two approaches to vertical scaling are LeSS and FAST, which will be discussed using this
book’s terminology, with original terms in parentheses for clarity.

LeSS
LeSS (Large-Scale Scrum) is an Agile scaling framework created by Craig Larman and Bas
Vodde in 2005.
Key Features of LeSS:
 Team Structure: Supports 2–8 teams (up to 8 people each) working from a shared
product backlog. A larger version, LeSS Huge, scales further.
 Leadership: Guided by a product manager (called "product owner" in LeSS) who
sets product direction.
 Iterations: Fixed-length sprints (typically 2 weeks), where teams select the highest-
priority stories.
 Feature Teams: Teams own entire stories, working across the codebase and
collaborating with customers and stakeholders. No team-level code ownership exists.
 Coordination: Ad hoc, peer-to-peer coordination to prevent conflicts, since multiple
teams may touch the same code.
 Continuous Integration: Developers merge code frequently (at least every few
hours) to maintain collective code ownership and ensure smooth collaboration.
LeSS also includes mechanisms for coordination, mentoring, and continuous learning.

Adopting LeSS
With the exception of the fact that most team ownership-related items are owned by the LeSS
teams collectively rather than by a single team,

The teams share ownership of product management and code rather than assigning it to
specific teams. Some terminology differs but can be found in the index.
Key Considerations for LeSS:
 Continuous integration (CI) is crucial, and commit builds must be fast.
 Multistage builds may need to be used more aggressively than recommended in this
book.
 Secondary builds may handle more tests, despite the risk of breaking the build.

If you’re looking for an established, well-tested approach to scaling Agile, start with LeSS.
You’ll need to develop fluency in the Focusing and Delivering zones.
The Focusing zone is fundamental and the Delivering zone is necessary for teams to share
ownership of their code. At a minimum, you’ll need collective code ownership, test-driven
development, and continuous integration.
FAST
FAST (Fluid Scaling Technology), created by Ron Quartel, is a promising but less proven
Agile scaling approach. It’s more fluid compared to LeSS, with a focus on continuous work
flow and dynamic team formation.
Key Features of FAST:
 Tribes: A group of developers and product managers (called "product directors") up
to 150 people.
 FAST Meetings: Held every two days, where product managers outline priorities, and
individuals volunteer to lead teams (called "team stewards"). These stewards are
temporary and change at each meeting.
 Self-Organization: Team members self-select to work on tasks and projects based on
interest.
 Discovery Tree: Teams create a hierarchical breakdown of work (a “discovery tree”)
for each valuable increment, which can be released independently.
Unlike LeSS, FAST does not emphasize team-level ownership, and teams form and evolve
frequently.
In FAST, teams work in short cycles (usually two days), focusing on making progress rather
than completing specific tasks. Discovery trees help track progress, and a feature steward
may be assigned to ensure continuity for a specific discovery tree.
Coordination between teams happens informally, on a peer-to-peer basis, similar to LeSS.
After each cycle, the tribe holds a FAST Meeting to recap progress, then the cycle repeats.
It’s designed to be fast, fluid, and low ceremony.

Adopting FAST
FAST is less compatible with the practices in this book compared to LeSS, especially in the
Focusing zone. Some key differences include:
 Team: The concept of a "team" in this book applies to the entire FAST tribe.
 Team room needs: Additional space may be required, especially for remote teams.
 Alignment chartering and retrospectives: These need adjustment for larger groups
and more facilitation experience, particularly remotely.
 Visual planning: Applies, but only for valuable increments.
 Planning practices: No need for task planning, capacity, or the planning game.
 Slack: Needs to be introduced differently.
 Meetings: FAST Meeting replaces stand-ups.
 Forecasting: Much simpler, though less accurate.
 Team dynamics: More complex due to the lack of stable teams.
Despite its challenges, Delivering and Optimizing practices work well with FAST, and the
speed of continuous integration is crucial.
Though FAST is less proven than LeSS, it’s promising. For those with Agile experience, a
pilot team of 10–30 people is recommended. Experienced coaches, including XP coaches,
are essential for success in FAST.

Challenges and benefits of vertical scaling

The weakness/challenge of vertical scaling is shared ownership. While it allows teams to
take responsibility for the entire codebase, it can lead to a lack of individual accountability,
where no one feels responsible for improving the code.
This is particularly challenging in large teams, requiring extra coaching to ensure follow-
through on responsibilities.
However, vertical scaling helps address the issue of cross-functional teams. In smaller
teams, specialized skills like UX design or security are hard to include due to size limitations.
With vertical scaling, these specialists can be allocated efficiently across teams:
 In FAST, specialists self-allocate to teams as needed.
 In LeSS, specialists join specific teams and work on relevant tasks.
Scaling Horizontally
In horizontal scaling, teams work in isolation, each owning a specific part of the product or
portfolio, rather than sharing ownership.
The challenge is defining team responsibilities in a way that minimizes dependencies
between teams, which can be difficult and doesn’t always adapt well to changes in priorities.
Ideally, each team owns an end-to-end slice of the product, but in practice, teams are often
too small to fully own a slice, leading to shared code between teams, which contradicts the
isolation principle.
Team Topologies categorizes teams in horizontal scaling into:
1. Stream-aligned teams: Focused on a product or customer-facing slice of the product.
2. Complicated-subsystem teams: Specialized teams dealing with complex
components, like machine learning, that require deep expertise.
3. Enabling teams: These teams provide specialized expertise (e.g., UX, operations,
security) to help other teams improve their skills and solve problems themselves.
They avoid becoming bottlenecks by offering resources like checklists or guidelines.

4. Platform teams: Similar to enabling teams, but they focus on providing tools rather
than direct help. Their tools enable other teams to address their own challenges, such
as providing deployment tools for software.
Successful horizontal scaling relies on effectively allocating team responsibilities to
minimize cross-team dependencies, which is influenced by the system's architecture (known
as the Inverse Conway Maneuver).

Horizontal scaling works best with a small number of teams (5-10), as coordination is easier
and teams can resolve issues together.

However, as the number of teams grows (30-100), coordination becomes harder, with
frequent changes and increased complexity in managing responsibilities.

While horizontal scaling can continue, it becomes increasingly difficult to manage as teams
increase. Vertical scaling is more flexible, but doesn't scale as far. A hybrid approach,
combining both methods, can offer the best balance.

Scaling Vertically and Horizontally

A startup with around 300 product development team members faced challenges due to
excessive cross-team dependencies.
By restructuring their team responsibilities from a horizontal scaling perspective, they
reduced dependencies and improved team independence.
This allowed them to operate with 40 teams and resume growth, reaching 80 teams before
hitting new roadblocks.
However, the author suggests that integrating vertical scaling could have been more effective.
By forming six 50-person groups, coordination would have been simpler and would have
facilitated even greater growth, with horizontal scaling techniques enabling further
expansion.
It suggests that vertically scaled groups, being large, could be stream-aligned, which would
have simplified the design compared to using enabling and platform teams, some of which
struggled with their roles.
They point out that as the company expanded to 80 teams, the team responsibilities were not
kept updated, despite having a review mechanism in place.
Vertically scaled groups are easier to adapt to changing business needs and require less
maintenance. Therefore, combining horizontal and vertical scaling by viewing vertically
scaled groups as one unit from a horizontal scaling perspective allows most teams to be
stream-aligned, except possibly the operations platform team.