MODULE 1

1. INTRODUCTION TO AGILE
1.1. A BRIEF HISTORY OF AGILE
The term "agile" refers to being able to move quickly and easily. It also refers to
flexibility and the willingness and ability to change and adapt.
Agile’s iterative approach enables the project to move quickly, as well as making it much
more adaptive to change.
Agile project management is an approach to project and team management based on the
Agile Manifesto. The manifesto is a collection of four values and 12 principles that define
the mindset that all Agile teams should strive for.
Waterfall is linear and sequential and does not encourage changing up the process once it
is started. Agile, on the other hand, is iterative, flexible, and incorporates necessary
changes throughout the process.
Agile methodologies emerged organically during the 1990s as the software industry was
booming.

In 2001, the thought leaders and creators of some of these new processes, also called
methodologies, came together to find common ground between their methods and solve a
problem. The problem, they agreed, was that companies were so focused on planning and
documenting their project that they lost sight of what really mattered: pleasing their
customers.
1.2. DISTINGUISHING AGILE FROM WATERFALL
 - Agile was created in response to the strict linear process of Waterfall. While
Waterfall aims for predictability and tries to avoid change, Agile embraces the
reality that the world, markets, and users are uncertain and unpredictable.
- Agile aims to solve that problem by getting customer feedback more quickly to
make sure that the team is building what the customer really wants.
- Part of working with an Agile mindset is always seeking out ways to work more
efficiently. We do this by finding ways to streamline processes without reducing
product quality or value.
Three important aspects of a project are requirements, documentation, and deliverables:
- Requirements are conditions that must be met or tasks that must be finished to
ensure the successful completion of the project.
- Waterfall projects use lots of documentation because there are lots of handoffs
between phases and handoffs among different teams within the project. But in
Agile, there's an emphasis on real- time, person-to-person conversations. Instead
of big, formal documents with a rigorous change management and approval
process, there are shorter documents that have just enough detail to achieve their
purpose.
- A deliverable is a tangible outcome from a project. In Waterfall projects, you
often don't release the deliverable until the very end. The final product release
feels like a big event, major announcement, lots of hoopla, and is often super fun
and exciting. Agile is just as exciting, but has smaller more frequent releases. So
each release has a less formal celebration, but it builds up to be just as exciting.

1.3. THE FOUR VALUES OF THE AGILE MANIFESTO

From the four values, a set of 12 principles were developed that reinforced the message
of the Manifesto. These values and principles inform the why, how, and what of Agile
project management planning and processes.
- First, the Manifesto emphasizes individuals and interactions over processes and
tools. At its core, this value stresses people communicating with each other over
using lots of processes and tools to force things to happen in a certain way. Agile
wants to ensure that teams work together, collaborate, and help each other achieve
the best outcomes they can. Agile also values individual perspectives and
creativity.
- The second value emphasizes working software over comprehensive
documentation, meaning that teams should prioritize spending time working on
things that actually create value and avoid spending any more time than they really
need on debating, writing, and reviewing documents. In other words, it's more
important to deliver the product the customer wants than to comprehensively
document the process that you used.
- On to the third value: customer collaboration over contract negotiation. In Agile
projects, the customer's satisfaction is considered the highest priority of building a
high quality and valuable product. When the Manifesto discusses contracts, it
refers to the official documents that require sign off and formal agreement with the
customer, such as those huge requirement documents or formal change requests.
Agile values having the freedom to collaborate with customers early and often. In
doing so, teams can quickly react and adapt to what customers need, rather than
waiting out the process of negotiating contract terms just to make a few changes or
request resources. Agile teams are encouraged to seek out every opportunity to
include the customer or stakeholder during project execution. This could be
 presenting early prototypes, asking questions, or bringing them in to do some
initial product testing.
- And finally, we have the fourth value: responding to change over following a plan.
This last value is crucial to an Agile project. As a result, this value stresses that
every Agile team needs to acknowledge that change is inevitable. The larger or
longer and more complex your project is, the more uncertainty there is. As a
project manager, the key takeaway to remember here is that the most successful
projects are the ones that are able to smoothly integrate change.
1.4. THE 12 PRINCIPLES OF THE AGILE MANIFESTO
Value delivery delivering the work as quickly as possible and mitigate the risk.
Simplicity allows a team to focus and work on the things that matter the most.

Business people refers to collaborating with your customers helps the team get critical
business information immediately by allowing them to adjust and adapt to any new
information instantly.

This theme emphasizes creating an effective team culture that is inclusive, supportive,
and empowering.
These principles really boil down to making sure your team is motivated to do the right
thing, feels trusted to do the right thing, has the resources and space to work closely
together on their goals, and works at a sustainable pace.
Retrospectives and continuous learning strive to continuously learn and adapt to what's
working and what's not.
In these sessions, the team can step back and consider questions like: How is the team
doing? Are the customers happy? Are there processes we could optimize? Are our tools
working for us? Are we following the values? Are we accumulating any debt?
1.5. ADOPTING AN AGILE MINDSET: THE AGILE MANIFESTO
“Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.”
Whether you are working to create a product for your company or for a customer,
chances are that someone is awaiting its delivery. If that delivery is delayed, the result is
that the customer, user, or organization is left waiting for that added value to their lives
and workflows. Agile emphasizes that delivering value to users early and often creates a
steady value stream, increasing you and your customer’s success. This will build trust and
confidence through continuous feedback as well as early business value realization.
“Welcome changing requirements, even late in development. Agile processes harness
change for the customer’s competitive advantage.”
When working in Agile, it’s important to be agile. That means being able to move swiftly,
shifting direction whenever necessary. That also means that you and your team are
constantly scanning your environment to make sure necessary changes are factored into
the plans. Acknowledging and embracing that your plans may change (once, twice, or
several times) ensures that you and your customers are maximizing your success.
“Deliver working software frequently, from a couple of weeks to a couple of months,
with a preference to the shorter timescale.”
Delivering your product in small, frequent increments is important because it allows time
and regular opportunities for stakeholders—including customers—to give feedback on its
progress. This ensures that the team never spends too much time going down the wrong
path.
“Business people and developers must work together daily throughout the project.”
Removing barriers between developers and people focused on the business side of the
project, builds trust and understanding and ensures that the developers, or those building
the solution, are in tune with the needs of the users.
“Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.”
A successful Agile team includes team members that not only trust each other to get the
work done but are also trusted by their sponsors and executives to get the work done.
Teams build better solutions when they are empowered and motivated to deliver difficult
projects.
“The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.”
There isn’t anything quite like face-to-face communication. Face-to-face communication
allows us to catch certain cues, body language, and facial expressions that are sometimes
lost when using forms of communication like email, chat, or the phone. However, we
can’t always be face-to-face. Establishing effective communication norms—no matter the
format—is essential to effective teams.
“Working software is the primary measure of progress.”
In Agile teams, the main way to demonstrate meaningful completion of work is to show a
working piece of the solution. In software teams, that might mean a functional piece of
software. In non-software teams, that might mean a critical portion of the solution that is
ready to be demonstrated to users or their representatives in order to collect feedback.
This is in contrast to traditional or Waterfall projects, where the completion of project
documents could be used to measure progress. In Agile project management, it is not
enough to say that the team is 80% done with an activity if there is no working,
demonstrable artifact available to review.
“Agile processes promote sustainable development. The sponsors, developers, and
users should be able to maintain a constant pace indefinitely.”
Maintaining a steady but careful pace will prevent errors along the way. Also, you never
want your team to feel overworked or overwhelmed. On the flip side, a team that is
underutilized may become bored and lose the creative spark to innovate. The Agile ideal
is to achieve a steady pace of effort for the team that avoids overtime and burnout.
“Continuous attention to technical excellence and good design enhances agility.”
This principle conveys that just because the team is working fast doesn’t mean they
sacrifice quality. By emphasizing quality and design throughout the project development
phase, the agility, efficiency, and speed of the team will be increased. When a team
delivers a well-built solution, they can quickly respond to user feedback and new
information. However, if the product is low quality, implementing changes can become
problematic, complex, and slow down the entire team.
“Simplicity—the art of maximizing the amount of work not done—is essential.”
The team should avoid implementing extra features into the solution that weren’t
explicitly requested by the user or product owner. This includes removing procedures that
are no longer necessary, and reducing unnecessary documentation.
“The best architectures, requirements, and designs emerge from self-organizing
teams.”
Team members should be able to get their work done by designing their own work
processes and practices, without a manager dictating how they operate. Team members
should also feel empowered to speak up with questions, concerns, or feedback.
“At regular intervals, the team reflects on how to become more effective, then tunes
and adjusts its behavior accordingly.”
In Agile, it is important to acknowledge that learning from successes and failures is
continuous. No team is perfect. There will be mistakes, challenges, trials, and triumphs.
Teams should reflect on all of these different aspects of their activities so that they can
make necessary adjustments.
1.6. ADOPTING AN AGILE MINDSET
Agile is about delivering value in a world with high degrees of uncertainty, risk, and
competition.
Agile works best in industries or projects that are susceptible to or that encourage change
and uncertainty.
Industry example:
The US military War College developed a concept called VUCA, spelled V-U-C-A.
VUCA is an acronym that defines the conditions that affect organizations in a changing
and complex world.
VUCA stands for volatility, uncertainty, complexity, and ambiguity:
- Volatility (Biến động) refers to the rate of change and churn in a business or
situation.
- Uncertainty refers to the lack of predictability or high potential for surprise.
- Complexity refers to the high number of interrelated forces, issues, organizations,
and factors that would influence the project.
- Ambiguity (sự mơ hồ) refers to the possibility of misunderstanding the conditions
and root causes of events or circumstances.
VUCA is a concept that was developed to deal with these forces in a changing and
uncertain world. Businesses can apply the concept of VUCA as a tool for determining
how best to approach projects.
1.7. APPLYING AGILE IN A VUCA ENVIRONMENT
- When we get started on a new project, it's helpful to examine the environment and
conditions in which the project exists before we decide the best approach to use.
- If your project environment has high levels of volatility, uncertainty, complexity,
and ambiguity, then it's a good sign that you should consider an Agile approach.
- While an Agile approach is not a perfect solution that will get rid of VUCA, it will
lead to better outcomes by giving you and your team tools and systems to mitigate
the risks that VUCA presents.
2. POPULAR AGILE FRAMEWORKS
2.1. INTRODUCTION TO SCRUM
When you use Scrum for project management, you form a team that will work together to
quickly develop and test a deliverable. The work is completed in short cycles, and the
team meets daily to discuss current tasks and clear up anything that's blocking their
progress.
The Product Backlog is the central artifact in Scrum, where all possible ideas,
deliverables, features, or tasks are captured for the team to work on.
The Sprint is the name of the time-boxed period in Scrum where work is done. This
Sprint can be between one and four weeks long, but most Sprints are around two weeks.
This is often called the "iteration." (sự lặp lại)
Daily Scrum, also called the Stand-up, where the team meets for 15 minutes or less
every day of the Sprint to inspect their progress toward their goal.
Scrum Master. This role is responsible for ensuring that the team lives Agile values and
principles, follows the processes and practices that the team agreed to, sharing
information to the larger project team, and they also help the team focus on doing their
best work.
Product Owner, who is responsible for maximizing the value of the product and the
work of the team. The Product Owner owns the inventory of work and has the final say
on how to prioritize the work.
Development Team is responsible for how a team will deliver that product.
Scrum is popular for many reasons.:
- Clear roles and responsibilities for the folks on the team while continuously
emphasizing the power of the team as a whole.
- Regular and predictable meetings and delivery schedules with predefined agendas
and outcomes for the meetings, making it easy to teach new team members.
- It supports and reinforces the Agile values and principles while adding some
structure and foundations that help new Agile teams get started and more
experienced teams get better, and it's all free and open for all to use.
- It's all free and open for all to use. Since it's the most commonly-used Agile
delivery framework, there's also a huge amount of guidance and support online, as
well as Scrum-specific training and certifications.
Ideally, a Scrum team should be cross-functional, with around three to nine team
members. Lastly, Scrum works best for projects where the team and management are
open-minded, adaptable, and value continuously learning how to be a better team.
2.2. THE FOUNDING PRINCIPLES OF SCRUM
Characteristics of a team help to move the Scrum downfield. Those are:
Built-in instability: In the Scrum world, teams are given the freedom to achieve
important outcomes with “challenging requirements.” Takeuchi and Nonaka explain that
this gives teams “an element of tension” necessary to “carry out a project of strategic
importance to the company.”
Self-organizing teams: Scrum Teams were intended to operate like their own start-up,
with a unique order that lacks true hierarchy. These teams are considered self-organizing
when they exhibit autonomy, continuous growth, and collaboration.
Overlapping development phases: Individuals on a Scrum Team must “work toward
synchronizing their pace to meet deadlines.” At some point throughout the process, each
individual’s pace starts to overlap with others, and eventually, a collective pace is formed
within the team.
Multi-learning: Scrum is a framework that relies heavily on trial and error. Scrum Team
members also aim to stay up-to-date with changing market conditions and can then
respond quickly to those conditions.
Subtle control: As we mentioned, Scrum Teams are self-organizing and operate like a
start-up, but that doesn’t mean there is no structure at all. By creating checkpoints
throughout the project to analyze team interactions and progress, Scrum Teams maintain
control without hindering creativity.
Organizational transfer of learning: On Scrum Teams, everyone is encouraged to learn
skills that may be new to them as they support other team members.
2.3. INTRODUCTION TO KANBAN, XP, AND LEAN
The Kanban name comes from two japanese words. "Kan" meaning "sign," and "ban"
meaning "board."
The reason Kanban is so popular is that:
- It provides transparent visual feedback to everyone who might be interested about
the status of work in progress.
- The Kanban method ensures that the project team only accepts a sustainable
amount of in progress work.
Work-in-progress limit, or WIP limit: tasks are limited to what the team can actually
handle during a certain amount of time.
This goal of trying to maximize efficiency is called flow, and is a core principle of
Kanban.
The extreme programming (XP) methodology aims to improve product quality and the
ability to respond to changing customer needs. It does this by taking best practices for the
development process to extreme levels.
There are four basic activities that are performed during the product development process
that the XP method tries to enhance:
- Designing: in software development, this is where you write a design document
describing the parts of the code or instructions for the product and how it will
function. In non-software environments, this would be describing the various
pieces and parts for whatever it is you're trying to deliver. XP wants to ensure that
all of the pieces of the product will fit together properly. So it stresses simplicity.
- Coding: In software development writing clear code is crucial. XP demands clear
and concise code, so that others can easily read and understand the program. This
makes it easier to troubleshoot problems and come up with solutions. In non
software environments, code would be similar to writing clear and concise
processes or instructions for how to build or use your product.
- Testing: means checking the product for flaws so they don't end up in the final
product. In XP, more is better. So if a little bit of testing can eliminate a few flaws,
lots of testing will eliminate even more. The goal is to test for and eliminate any
flaws in a feature before building it and continuing on. Testing also means
checking to make sure the product features, meet the customer's requirements.
- Listening: Which is about listening to the customer and ensuring that the
requirements are integrated into the product.
XP Innovative Practises:
- Pair programming, which is when two team members Work together at the same
time on one task.
- Continuous integration and continuous refactoring. This is the practice of
merging product changes into a shared version several times a day in order to get
quick feedback on the quality of the code or product.
- Avoid big design up front. This relates to designing and means the design should
be just enough to get started and should be continuously improved as the product
evolves.
- Write tests, not requirements. This means that instead of writing a product
requirements document and then later writing a test plan.
Lean methodology consists of five principles that serve as a recipe for improving project
outcomes:
- Define value means identifying and focusing on what the customer wants and
including the customer in the process.
- Map value stream, means mapping out the process or stream, including all the
steps involved in producing value for the customer.
 - Create flow, means ensuring the product flows through the value stream
efficiently, continuing to eliminate waste throughout the cycle.
- Establish pull: think of asking someone to pull something off the shelf. You want
to make sure the customer is pulling on the product or asking for it throughout the
value stream.
- Pursue perfection. This means pushing your team to continuously improve the
first four process steps.
2.4. BLENDING PROJECT MANAGEMENT APPROACHES
Agile is a mindset—a way of thinking about the project delivery process through the
values and principles outlined in the Agile Manifesto.
Agile values and principles can be achieved through certain frameworks and delivery
methods like Scrum, Kanban, XP, and Lean.
Here are some reasons you might want to blend Agile and Waterfall styles:
- Your stakeholders, customers, or sponsors are more comfortable with traditional
approaches and using workflows, or delivering traditional work products is easier
for them to understand and follow, but your project team is already established in
Scrum and they wish to continue.
- Regulatory requirements that insist on certain traditional work processes.
- One of the vendors involved in a large project is already following a traditional
approach and the integration between the teams require some blending of methods.
2.5. THE SPOTIFY MODEL
The Spotify model encourages innovation, collaboration, and productivity while
maintaining autonomy, quality, and necessary communication. It does so by using a
unique organization system that features Squads, Tribes, Chapters, and Guilds.
- A Squad is like a Scrum Team and is supposed to feel like its own start-up within
the company. Squads are self-organizing and collocated. They work together to
achieve a long-term mission.
- Tribes are collections of squads that work in a specific area and are meant to have
less than 100 people.
- Chapters are small groups of people across a tribe that have similar skills and
work in the same general competency area.
- Guilds are the largest group, comprised of people across the organization who
want to share knowledge, tools, code, and practices.
Key takeaways
- You must always be able to adapt based on your team’s preferences and goals.
The Spotify team started in Squads, but as they scaled, they added new types of
groups within the organization—without disrupting the existing Squads. They
continued to do so until they found the perfect balance of collaboration and
ownership.
- Always examine the needs of your project and organization. What works for
Spotify may not be an exact fit for your team. If you are on a team that needs
scaling, be inspired by this model, but use the aspects that work best for your
organization.
- Don’t be afraid of trial and error. If you try something and it doesn’t feel quite
right, you can easily adjust.
- You should never consider yourself done improving. There are always changes
that can be made for the better.