Agile Project Management

Week 1
Fundamental of Agile

The waterfall is a popular project management methodology that refers to the sequential or linear ordering of
phases. complete one phase at a time, not proceeding to the next until it is done. Then you move down the line
like a waterfall, starting at the top of the mountain and traveling to the bottom.

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. Projects that adopt Agile project
management take an iterative approach, which means the project processes are repeated often many times
during the life cycle of the project.

In this case, the team operates within many shorter blocks of time, called iterations. Individual iterations might
get repeated depending on the feedback received. During each iteration, the team takes a subset of all the
project's activities and does all the work required to complete that subset of activities.

You can think of it as a lot of mini waterfalls for each activity. This 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.

So in very basic terms, 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.
Difference Between Agile and Waterfall Project management

Waterfall Agile
While Waterfall aims for predictability and tries to Agile was created in response to the strict linear
avoid change process of Waterfall.

Need a product requirements document, There's usually an initial set of requirements or

which lists the scope and requirements of the feature ideas when the project kicks off,
project. but that list of requirements and features is
continuously growing and changing throughout the
project.

Because the work is done in bigger chunks, you'll
need to leave behind more pieces of documentation
at each stage in the project as are lots of handoffs
between phases and handoffs among different
teams within the project.
Instead of big, formal documents with rigorous
change management and
approval process, there are shorter documents that
have just enough detail to achieve their purpose.
These documents are much more focused on what
the reader needs to know to get
the job is done and are written only as needed.

You often don't release the deliverable until the very Agile is just as exciting but has smaller more
end. The final product release feels like a big event, frequent releases. So, each release has a less
a major announcement, lots of hoopla, and is often formal celebration, but it builds up to be just as
super fun and exciting. exciting.

Three differences between these two project management approaches are the way
each one deals with requirements, documentation, and deliverables.

Four Values of the Agile Manifesto

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 also values individual perspectives and creativity. This does not mean that every team is chaotic;
the value just means that processes and tools should be used to facilitate and drive good project management
and improved collaboration within the team and should never be used as a barrier to teams working well with
each other.

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. it's more
important to deliver the product the customer wants than to comprehensively document the process that you
used.

Customer collaboration over contract negotiation

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.
Responding to change over following a plan
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. For many projects, finalizing a well-
established plan at the beginning of the project will likely lead to an on-time delivery within budget but may run
the risk of not meeting customer needs or adding maximum value.

The 12 principles of Agile

These principles reinforce the message of the four values and provide some additional clarity.

Fig. The four themes of the Agile principles

1. Value Delivery (and the 5 principles)

 2. Business Collaboration

Customer collaboration during the values discussion,

and here we are again. Collaborating with your customers helps the team get critical business
information immediately by allowing them to adjust and adapt to any new information instantly.

3. Team Dynamics And Culture

The principles in this theme reflect that value. This theme emphasizes creating an effective team culture that
is inclusive, supportive, and empowering. Having an effective team culture is essential to a project's
success. 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.
Agile values and principles
In the last video, you explored the Agile Manifesto—the guiding force behind all Agile teams—in-depth.
You learned that Agile is a highly collaborative approach suited for very complex and competitive
projects. In this reading, we’ll briefly explore the four values and 12 principles of the Agile Manifesto.

The Agile values refer to the following four statements:

 Individuals and interactions over processes and tools

 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan
Agile experts see these values as important underpinnings of the highest performing teams, and every team
member should strive to live by these values to apply the full benefits of Agile.

The same is true for the 12 principles, which are at the core of every Agile project:

 “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.
 VUCA
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.

It was designed to help us factor in the forces of change and uncertainty in our projects and businesses.

Volatility
Refers to the rate of change and churn in a business or situation. In a volatile project, you would discuss how
the next disruption to your operations is always right around the corner. Or it feels like things never have
time to settle into a normal rhythm.

Uncertainty
Refers to the lack of predictability or high potential for surprise. In an uncertain environment, it would be
difficult to create plans for the future that we're not based on a large number of assumptions that could turn out
to be incorrect.

Complexity
Refers to the high number of interrelated forces, issues, organizations, and factors that would influence the
project. For example, if one product being worked on relied on diverse and global suppliers, that would add to
the complexity of the project.

Ambiguity
Refers to the possibility of misunderstanding the conditions and root causes of events or circumstances. A
project that suffered from ambiguity would have difficulty pinpointing the causes of project delays, making it
difficult to design mitigation plans to reduce the risks.

SCRUM
Scrum refers to a formation in rugby where all of the players on the team lean forward, lock their heads
together, and then work as one unit to try and gain precious yards towards the scoring line.

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.

Terms and concepts specific to Scrum.

 The Backlog
It is the central artifact in Scrum, where all possible ideas, deliverables, features, or tasks are captured
for the team to work on. It's prioritized and proactively managed by the team continuously throughout
the life of the project.

 The Sprint
It 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."

 Daily Scrum, also called the Stand-up

This is where the team meets for 15 minutes or less every day of the Sprint to inspect their progress
toward their goal.

Next are the roles,

 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 with 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.

 The Development Team is responsible for how a team will deliver that product.

KANBAN (カンバン)
 The Kanban name comes from two japanese words. "Kan" meaning "sign," and "ban" meaning "board."

Kanban boards or charts display the progress of a project as to do in progress and done.

XP takes this practice to the extreme by finding ways to test more and smaller features of the product to get
even more feedback.

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

Coding: code is the language that's used to write software programs. It's the instructions that tell the computer
what to do. In software development writing clear code is crucial.

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: like I described earlier means checking the product for flaws so they don't end up in the final product
The waterfall project life cycle is made up of the following phases:
 Initiation
 Planning
 Executing
 Completing tasks
 Closing out the project

All of the tasks within each of these phases, like identifying goals and scope, scheduling, budgeting, and risk
management.