Agile Management | Google Project Management Certificate
Summary
TLDRThe video introduces the concept of Agile project management, explaining how it embraces change and flexibility unlike the linear Waterfall method. It covers the history and core values of Agile expressed in the Agile Manifesto, including key principles like frequent delivery, customer collaboration, and embracing change. Popular Agile frameworks like Scrum, XP, Kanban and Lean are explained. The video makes the case for using Agile methods or blending them with Waterfall depending on the project environment, especially when dealing with volatility, uncertainty, complexity and ambiguity.
Takeaways
- 😊 Agile es una filosofía que enfatiza la flexibilidad y la adaptabilidad en la gestión de proyectos
- 👍 El Manifiesto Ágil contiene 4 valores centrales: individuos e interacciones, software funcionando, colaboración con el cliente, responder al cambio
- 📈 Scrum es una de las metodologías ágiles más populares que utiliza sprints para entregar valor de forma iterativa
- 🔀 Hay ocasiones en que tiene sentido mezclar enfoques tradicionales como Cascada con metodologías ágiles como Scrum
Q & A
¿Cuándo se creó el Manifiesto Ágil?
-El Manifiesto Ágil fue escrito en 2001 y reúne la sabiduría colectiva de las personas que lo desarrollaron a partir de su vasta experiencia y liderazgo de pensamiento en la industria de la tecnología.
¿Cuáles son los cuatro valores del Manifiesto Ágil?
-Los cuatro valores del Manifiesto Ágil son: individuos e interacciones sobre procesos y herramientas, software funcional sobre documentación exhaustiva, colaboración con el cliente sobre negociación contractual, respuesta al cambio sobre seguimiento de un plan.
¿Qué es Scrum?
-Scrum es una metodología de gestión de proyectos Ágil que se basa en ciclos cortos de trabajo llamados sprints para desarrollar y probar rápidamente un entregable. Cuenta con roles claros como el Scrum Master y el Product Owner.
¿Cuáles son las diferencias clave entre metodologías Ágil y en Cascada?
-Las metodologías Ágil son iterativas, flexibles e incorporan cambios a lo largo del proceso, mientras que las metodologías en Cascada son lineales, secuenciales y no fomentan los cambios una vez que el proceso ha comenzado.
¿Qué significa VUCA?
-VUCA es un acrónimo que representa Volatilidad, Incertidumbre, Complejidad y Ambigüedad. Se desarrolló para categorizar y pensar sobre las fuerzas que dan forma a nuestro mundo y negocios, sin importar la industria.
¿Cuáles son algunos marcos y métodos Ágil?
-Algunos marcos y métodos Ágil populares son Scrum, Kanban, Programación Extrema (XP) y Lean.
¿Cuáles son los cuatro temas de los principios Ágil?
-Los cuatro temas de los principios Ágil son: entrega de valor, colaboración empresarial, cultura de equipo y retrospectivas.
¿Cuándo debería considerar mezclar metodologías Ágil y en Cascada?
-Debería considerar mezclar metodologías cuando los interesados o proveedores estén más cómodos con enfoques tradicionales, cuando haya requisitos regulatorios para ciertos procesos de trabajo o cuando uno de los proveedores ya esté siguiendo un enfoque tradicional.
¿Cuáles son algunos beneficios de Kanban?
-Algunos beneficios de Kanban son que proporciona una retroalimentación visual transparente sobre el estado del trabajo en progreso para todas las personas interesadas y garantiza que el equipo solo acepte una cantidad sostenible de trabajo en progreso.
¿Cuáles son algunas prácticas clave de Programación Extrema (XP)?
-Algunas prácticas clave de Programación Extrema son programación en parejas, integración continua, refactorización continua, diseño simple al comienzo y escribir pruebas en lugar de requisitos.
Outlines
😊 Introducción y resumen del contenido del vídeo
Sue da la bienvenida y presenta el tema del curso sobre gestión ágil de proyectos. Resume los contenidos previos sobre gestión de proyectos y explica que ahora cubrirán los fundamentos de la gestión ágil de proyectos, incluyendo Scrum.
😃 El origen y necesidad de los métodos ágiles
Se explica el contexto que llevó al surgimiento de los métodos ágiles en la década de 1990, debido a la necesidad de las empresas de software de desarrollar productos de forma más rápida e innovadora ante un mercado muy competitivo.
😏 El manifiesto ágil y sus 4 valores clave
Se presentan los 4 valores clave del manifiesto ágil: individuos e interacciones sobre procesos y herramientas, software funcional sobre documentación exhaustiva, colaboración con el cliente sobre negociación contractual, respuesta al cambio sobre seguir un plan.
🤓 Los 12 principios ágiles organizados en 4 temas
Los 12 principios del manifiesto ágil se organizan en 4 temas: entrega de valor, colaboración de negocio, cultura de equipo y retrospectivas; facilitando su comprensión y aplicación.
😎 Por qué la agilidad funciona bien en entornos VUCA
Se introduce el concepto VUCA que define la volatilidad, incertidumbre, complejidad y ambigüedad de los entornos actuales de negocio, y se explica por qué la agilidad es una buena resposta a estos desafíos.
🤔 Aplicación de conceptos ágiles según tipo de proyecto y contexto
Se plantean distintos casos y contextos de proyectos donde tiene sentido aplicar la gestión ágil, y se ejemplifica con el caso de Office Green queriendo expandir su negocio.
📝 Introducción a Scrum, marco ágil más popular
Se explican los orígenes del marco Scrum, los elementos clave como el backlog, los sprints y el daily scrum. También los roles del Scrum master y el product owner.
👷♂️ Otros métodos ágiles populares como Kanban y XP
Se resumen brevemente otros métodos ágiles conocidos, como Kanban que enfatiza la visualización, Extreme Programming centrado en las pruebas y perfeccionamiento, y Lean que elimina desperdicios.
💫 Cómo combinar métodos en waterfall y métodos ágiles
Se dan ejemplos de casos donde puede ser útil combinar elementos de gestión de proyectos tradicional y métodos ágiles, cuando diferentes partes se benefician de distintos enfoques.
🎉 Resumen de conceptos clave sobre gestión ágil de proyectos
Se resaltan los puntos más importantes sobre la gestión ágil: que es una mentalidad y forma de pensar, con marcos como Scrum para aplicarla; que se puede mezclar con waterfall; y el contexto determina la mejor estrategia.
Mindmap
Keywords
💡Agile
💡Scrum
💡sprint
💡backlog
💡Daily Scrum
💡Scrum Master
💡product owner
💡Kanban
💡VUCA
💡Manifesto Ágil
Highlights
Agile is not a project management methodology in and of itself but more of an overarching approach and philosophy
Agile values having the freedom to collaborate with customers early and often rather than waiting out the process of negotiating contract terms
VUCA stands for Volatility, Uncertainty, Complexity and Ambiguity - a concept to deal with forces in a changing world
Scrum has clear roles and responsibilities while continuously emphasizing the power of the team
Kanban provides transparent, visual feedback to everyone interested about the status of work in progress
Extreme Programming aims to improve product quality and respond to changing customer needs by taking best practices to extreme levels
Lean aims to capture principles that eliminate waste and deliver value to customers
Agile emerged after Lean, and Agile inventors were inspired to apply Lean manufacturing principles to software development
You can still get benefits from thinking in an Agile way and apply those values and principles even when using Waterfall
Reasons to blend Agile and Waterfall include stakeholder comfort, regulatory requirements, vendor constraints
Watch out for too much change in how you do things - teams work best when they can build consistency
Office Green needs to watch costs, so use traditional budget management controls
Agile is a mindset, a way of thinking about project delivery through Agile Manifesto values and principles
Agile values and principles can be achieved through frameworks like Scrum, Kanban, XP and Lean
Blend Agile and Waterfall when it adds value without negatively impacting the overall project
Transcripts
SUE: Hello, and welcome to Agile Project Management.
So far, this program has covered the foundations
of project management and what it
takes to be a project manager.
We've explored the phases of the project lifecycle--
initiation, planning, execution, and closing.
And we've reviewed lots of different tools and techniques
for managing and communicating your plans.
We've also discussed how to handle
various challenges, risks, and issues
that come up along the way.
If you've completed all the courses so far,
congratulations.
If you're just now joining, welcome.
Either way, you're on your way to a new
or maybe just improved career in project management.
Now that you have a solid foundation
on what it takes to manage a project,
I'm going to share with you one of the most popular approaches
to delivering projects, Agile.
In my opinion, Agile is also the most interesting and flexible
approach to project management.
Agile is not a project management methodology
in and of itself but more of an overarching approach
and philosophy to deliver value to customers, which
is the goal of most projects.
Despite not being a specific methodology,
there are lots of frameworks and methods
under the Agile umbrella.
In this course, I'll help prepare you
for a career in Agile project management.
I'll provide you with a history of Agile
and introduce you to a specific Agile delivery
framework called Scrum.
I'll teach you about the core roles
that make up a Scrum team.
And finally, I'll cover some best practices
and real-world scenarios where you
can use the Agile approach to lead your project to success.
Oh, and I should probably introduce myself.
My name is Sue, and I'm a senior technical program manager
with Google Support platform.
We build the products you use to get user support from nearly
all of Google's products.
I started at Google in 2014 and worked on product reliability,
making sure Google's products are up and running
all the time for billions of people across the world who
depend on them.
Before Google, I worked at many companies of different types
and sizes, where I ran and worked
on projects using Waterfall, Agile,
and everything in between.
I started my career as a software engineer working
on cell phone technology, but I didn't have
a degree in computer science.
Since then, I've had many different roles,
but program management is my passion
because it brings all of the disciplines together
to deliver amazing outcomes for the customers
and equally amazing results for the business.
I still remember the aha moment I had when I discovered Agile,
and I'm excited to share it with you.
I hope you're ready to discover Agile and experience
your own aha moment.
In the next video, we'll start learning the basics of Agile.
Meet you there.
[MUSIC PLAYING]
To quickly review, Waterfall is a popular project management
methodology that refers to the sequential or linear ordering
of phases.
You 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 a 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 lifecycle
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.
So the term "agile" means flexibility, repetition,
and openness to change.
But what do we mean by Agile Project Management?
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 has started.
Agile, on the other hand, is iterative, flexible,
and incorporates necessary changes throughout the process.
Now, a bit of a history lesson so you
can have a better sense of how and why Agile
has become such a popular approach to project management.
Agile methodologies emerged organically during the 1990s
as the software industry was booming.
Software startups like Google were
blazing a trail to get more software products built
in less time.
Meanwhile, the tech giants of the time
were experimenting with faster ways to build better software
and stay competitive.
And by the way, software isn't just the apps and websites
that we all use every day.
Software also includes the code behind innovations
in agriculture, medical devices, manufacturing, and more.
So in this competitive, growing environment,
companies couldn't just create new innovative products.
They also needed to innervate the very processes
they were using to develop those new products.
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.
So these leaders came up with the Agile Manifesto
to guide others on what they believed really matters when
developing software, which is keeping the process flexible
and focusing on people, both the team and the users,
over the end products or deliverables.
Now, here's where Agile gets even more interesting.
You can still use Agile even if you're not planning
to work on software projects.
Agile has been so successful in the software industry
that its values, principles, and frameworks have been applied
to nearly every industry.
In fact, the Agile methods that you're going to learn also
draw heavily on lean manufacturing principles
that originated in Toyota's car factories in the 1930s.
You'll also find Agile methods being
adopted in the aeronautical, health care, education, finance
industries, and even more.
Cool, right?
Agile is everywhere.
[MUSIC PLAYING]
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.
For example, your customer might say they want feature A,
but when the final result is delivered,
they realize they actually wanted feature B. 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.
The key to streamlining is to reduce waste.
For example, unnecessary documentation
is a form of waste.
Another form of waste is spending weeks or months
working on a feature only to find out
that the customers, who could also be users or stakeholders,
don't like the feature after all.
You could reduce or eliminate both of these forms of waste
by increasing team and stakeholder collaboration.
More collaboration means less documentation and earlier
feedback about the product.
Let's consider some more differences
between Waterfall and Agile.
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.
Think of these as the set of criteria
that fall within the scope of your project
or a list of specifications that must be met.
In a Waterfall project, you'll probably
need a product requirements document,
which lists the scope and requirements of the project.
You need to have several formally approved
project plans, and you might have
a team of people whose job it is just to write and approve
these plans.
You might also set up a change control board,
a formal and rigorous process to manage any changes
to requirements.
All this is designed to protect the team from building
something that the client or stakeholders don't want
and aims to minimize any changes that could lead to scope creep.
Formally approved project plans work
well when the desired end product
is known and understood.
An example of this might be leading
a project that has clear requirements and goals based
on mandated regulation.
But if that's not the case, a Waterfall team risks building
out an entire deliverable only to find out
later that the customer doesn't like the final result.
In Agile, requirements are treated as more dynamic
and expected to change as the team receives
feedback and new information.
There is usually an initial set of requirements or feature
ideas when the project kicks off.
But that list of requirements and features
is continuously growing and changing
throughout the project.
The team works with stakeholders to prioritize the requirements,
always moving the most urgent or valuable items
to the top of the list.
Then the team goes down the list,
working on the requirements in iterations.
By going down the list, the team is
able to get feedback on their work quickly and frequently.
At the end of each iteration, the team
gets feedback and can make necessary adjustments
to the requirements before continuing on.
OK, the second aspect is documentation.
All projects require documentation-- project plans,
stakeholder maps, schedules, charters, contracts.
The list goes on and on.
Waterfall projects use lots of documentation
because there are lots of hand-offs
between phases and hand-offs among different teams
within the project.
Also, because the work is done in bigger chunks,
you'll need to leave behind more pieces of documentation
at each stage in the project.
But in Agile, there's an emphasis
on real-time person-to-person conversations.
This doesn't mean that there's zero documentation.
It's just in a different form.
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.
These documents are much more focused
on what the reader needs to know to get the job done
and are written only as needed.
Finally, let's explore deliverables.
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.
When there's lots of uncertainty in a project,
such as in a new, emerging industry or market,
the steady release of project deliverables
enables an Agile team to get feedback and learn as they go.
Without regular feedback, the team
could end up delivering something
that the customer doesn't want.
So now you have a better idea of some key elements of Agile
that distinguish it from Waterfall.
Three differences between these two project management
approaches are the way each one deals
with requirements, documentation,
and deliverables.
[MUSIC PLAYING]
Now that you're more familiar with the history of Agile
and how it's applied to project management,
let's discuss the inspiration behind this Agile movement,
the Agile Manifesto.
In this video, I'll list the four values of Agile
and describe how each Agile team needs
to strike a balance between the four values.
Being familiar with the Agile Manifesto
will help you understand the core principles and values
of Agile Project Management so you can put them
into practice on a project.
The Agile Manifesto was written in 2001
and brings together the collective wisdom of the people
who developed it from their vast experience
and thought leadership in the tech industry.
If you'd like to find the Manifesto, it's easy.
Just type in agilemanifesto.org in your search browser.
We've made it available for you here in the course readings
as well.
Let's check it out.
The Manifesto for Agile software development states,
"We are uncovering better ways of developing software by doing
it and helping others do it.
Through this work, we have come to value individuals
and interactions over processes and tools,
working software over comprehensive documentation,
customer collaboration over contract negotiation,
responding to change over following a plan.
That is, while there is value in the items on the right,
we value the items on the left more."
There you have it, the Agile Manifesto
and the four values of Agile.
It's a short list, but it packs a punch.
The Manifesto is saying that it's helpful for every Agile
team to think about both sides of each statement
during the execution of a project
but should find ways to ensure that they're always
placing more value and emphasis on the things
on the left over the things on the right.
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.
Let's take it from the top.
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.
For example, have you ever emailed someone with a question
and ended up in a long back-and-forth exchange
due to simple follow-up questions or clarifications?
Chances are that you could have gotten the same information
in less time with a brief conversation.
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.
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.
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.
Now, this value might seem like it only
applies to software projects.
But just replace the term working software
with whatever your project is trying to deliver.
Maybe the project is writing a legal brief,
designing an office layout, or preparing a sales presentation.
Whatever your project is trying to deliver
is the thing that creates value.
In other words, it's more important to deliver
the product the customer wants than to comprehensively
document the process that you used.
Onto the third value, customer collaboration
over contract negotiation.
In Agile projects, the customer satisfaction
is considered the highest priority
of building a high-quality and valuable product.
After all, if it's not valuable to the customer,
then there's little point spending time on it.
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.
There will still be contracts with Agile Project Management,
but the focus is on identifying what's really needed
and leaving space for collaborative, customer-focused
work.
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 drug 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 I explained in the history overview,
agile grew out of a world that was changing
so fast that organizations couldn't adapt and struggle
to survive.
As a result, this value stresses that every Agile team
needs to acknowledge that change is inevitable.
The larger, 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.
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.
Agile project managers still create and value their plans,
but they can cope with and are able to adapt
if the plans need revising at any time during the project.
So there you have it, the four agile values--
individuals and interactions over processes and tools,
working software over comprehensive documentation,
customer collaboration over contract negotiation,
and responding to change over following a plan.
What's great about Agile is that it gives us these values
and also lets us find the right balance between the two sides.
You may have to fine tune your project style
to meet industry needs, team dynamics,
and organizational goals to find the healthy balance that
works for you and your team.
[MUSIC PLAYING]
For this course, I've grouped the 12 principles
into four themes.
These are different from the four values.
The four themes of the Agile principles are value delivery,
or how do Agile teams deliver highly valuable products
to their customers; business collaboration, or how
do Agile teams collaborate with their business partners
and stakeholders to create business
value to the organization and their users; team culture,
or how does a team create and maintain
the right interpersonal and team dynamics
to deliver value for the customers and the business;
and retrospectives, or how does the project learn
to continuously increase performance
of an organization in business.
As I said, I've grouped each of the 12 principles
under these themes so they're easier to learn and remember.
Let's dive in.
The first theme is value delivery
and includes five principles.
Take a few seconds to review them.
This theme is about delivering the work
as quickly as possible.
And remember why?
So that we can get feedback and mitigate
the risk that we spend too much time building the wrong thing.
Also, no one gets any value from your work,
including your company, until you deliver it.
So the longer you take to deliver,
the longer you wait to get revenue,
and maybe the more time the competition
has to get ahead of you.
These may look very software oriented.
But if you replace the word software
with deliverables or solutions, these
can apply to almost any project.
For example, deliver working solutions frequently.
See?
The value theme is also about simplicity.
How much time do you think it takes engineers
to add all the buttons and features to products
that ultimately end up confusing the user?
Simplicity allows a team to focus and work on the things
that matter the most.
An example of this theme in action
might be prioritizing getting feedback on a product prototype
so you know which features really matter.
Or it might mean ensuring the team only works
on approved features and doesn't spend time on unnecessary ones.
Another example might be reserving
10% of the team's time to work on bug fixing or polishing
a process, which should help you go faster in future iterations.
The next theme is business collaboration
and includes two more principles.
Quick note-- one of the principles
uses the term business people to refer to those involved
with things like sales, marketing, customer support,
and account management.
We'll use the term developers to refer
to those who are involved with making and creating products.
OK, so we discussed customer collaboration
during the values discussion.
And here we are again.
Collaborating with your customers
helps the team get critical business information
immediately, allowing them to adjust and adapt
to any new information instantly.
No matter if it's realized early or late in the project,
customers will get what they want to achieve their business
goals.
You could achieve collaboration by making sure
that business people work near the development team,
ideally in the same office or virtual space.
If that's not possible, maybe co-locating a day a week,
encouraging instant messaging, or blocking off
time on your team calendars each day or week to collaborate.
The goal is to enable easy access between business people
and developers.
Another example might be how you handle feedback and changes
in priorities.
Rather than trying to keep the customer away
from developers due to concerns about scope creep,
create a weekly huddle where customers and business
people can explore feedback and new ideas with the team.
This could be a great way to discover
that one really valuable feature is super easy to build,
whereas another feature of the user's thought would be easy
is actually really hard.
Our third theme is team dynamics and culture
and includes four more principles.
Remember, the first Agile values stresses
individuals and interactions over processes and tools.
Notice that 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.
An example of emphasizing effective team culture
would be to ask the team what kind of equipment
they need to do their job and then giving them those tools.
Another manifestation of this theme
is letting teams write their own processes and templates
rather than forcing them to use something from headquarters.
Teams work best when they feel like their input is valued.
So you as the project manager should
make space for your team to engage
and actively contribute to the team culture.
You'll build trust and empower them
to approach their work in a way that suits them
best, which in turn will allow them to work more productively.
Finally, the fourth theme is retrospectives and continuous
learning.
The last principle stands alone in this theme,
so I'll read it aloud.
"At regular intervals, the team reflects
on how to become more effective, then
tunes and adjusts its behavior accordingly."
This one sits on its own because I
want to draw attention to how important it is for Agile teams
to continuously learn and adapt to what's working
and what's not working for them.
Teams should always be figuring out better ways to work,
and it's really valuable to set this time aside
after each iteration to focus entirely on how to improve.
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?
And by debt, I mean processes or technology that slows us down.
We've officially finished discussing the Agile Manifesto.
It's amazing to think that these four values and 12 principles
are the foundations of so many advances in project management.
I'll come back to these values and principles
throughout the rest of this course
to demonstrate how these connect to the day-to-day activities
of an Agile project.
[MUSIC PLAYING]
Every project exists within organizations and settings
with different cultures, business objectives,
and industry dynamics.
In this video, we'll discuss some different scenarios
in which you'd want to adopt an Agile mindset.
I'll also introduce you to a concept called
VUCA that can help you decide which management approach is
best for your project.
Remember, Agile is about delivering value
in a world with high degrees of uncertainty, risk,
and competition.
It sets a team up to react as quickly as possible
to new information, new market opportunities, and even
new technologies.
Agile works best in industries or projects
that are susceptible to or that encourage
change and uncertainty.
What kinds of businesses or industries, besides software,
come to mind that deal with lots of change?
A few that I think of are biotechnology,
with emerging vaccines, treatments, and technologies;
media, with endless new ways to share content;
the food industry, with celebrity chefs and the latest
food craze; and fashion, an industry built on keeping up
with shifting trends.
Did any of these surprise you?
On the flip side, here are some industries
that you might think of as fairly stable--
agriculture, aerospace, manufacturing, and mining.
But even these industries with rigorous supply chains
and codes have to adapt to change
due to new laws and regulations, natural disasters,
and other unforeseen issues.
One thing that the year 2020 taught all of us
is that no industry is truly immune to change
and uncertainty.
We're going to explore a concept for categorizing and thinking
about these forces that shape our world,
no matter what industry we're in.
That concept is called VUCA, and it
can help you decide which project management approach is
best for you.
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.
VUCA stands for Volatility, Uncertainty, Complexity,
and Ambiguity.
I'll explain each one and what that could entail in projects
and business settings.
First up is Volatility.
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.
Next is Uncertainty.
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 were not
based on a large number of assumptions that could turn out
to be incorrect.
Then there's Complexity.
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.
And finally, we have Ambiguity.
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.
Let's recap.
VUCA stands for Volatility, Uncertainty, Complexity,
and Ambiguity.
It's 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.
Phew.
That's a lot of info, but it's all good stuff.
Having an understanding of these concepts
will help with decision making in all kinds of projects.
Adopting an Agile approach increases your chances
of success despite this uncertainty.
And these concepts apply to the business world
at large, not just projects.
[MUSIC PLAYING]
Now let's discuss why it's important to understand VUCA
as it relates to project management.
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.
When you consider Agile values and principles,
it's clear that Agile is a proven and well-documented
solution to the challenges VUCA presents to your project.
OK, let's revisit the Office Green scenario we introduced
earlier in the program.
We'll use this scenario throughout this course
as well to illustrate the power of an Agile approach
to project management.
If you're just joining us now, I'll give you a quick recap.
In previous courses, learners acted as the lead project
manager at Office Green, LLC, a commercial landscaping company
focused on interior plant design for offices, restaurants,
and hotels.
For this Agile course, we'll come back to Office Green
as they pursue a new business opportunity.
The Office Green market research team noticed a major shift
to more workers setting up and working from a home office.
They wanted to react fast to a potentially huge market
opportunity and not lose revenue if businesses
had less need for their previous office service.
Instead of offering indoor landscaping designs
for businesses, Office Green wants
to find a way to capture this new market full of home
offices.
I don't know about you all, but I have a hard time
keeping plants alive.
I can't keep a cactus alive.
But I love all those video conference backgrounds
that are so nicely decorated with beautiful live plants.
This shift to working from home came about suddenly,
so Office Green didn't have any project plans to start from.
They didn't have time to do a lot of prep work,
but they wanted to maximize this opportunity
before it was too late.
To do this, Office Green assigned
you to be the project manager of a scrappy, new Agile team.
Your goal is to deliver their new service
called Virtual Verde.
What environment did office green face?
Volatility, uncertainty, complexity, and ambiguity.
They experienced volatility in the form of a major disruptive
change to their business plans; uncertainty
through a lack of predictability, which
made it difficult to create concrete plans for the future;
a high level of complexity due to interrelated factors,
like suppliers and the economy.
And they experienced ambiguity by not
being able to determine or control what
might cause future changes.
By using an Agile approach to their project,
Office Green was able to address high VUCA factors that
were affecting their business.
Instead of business slowly or quickly eroding due to market
forces, Office Green embraced the changing market
and remained flexible in how they
approached their next project.
We'll follow along with Office Green and your work
as a project manager of Virtual Verde throughout this course
and find out how you do.
[MUSIC PLAYING]
So far, we've explored a little bit of Agile history,
the Agile Manifesto, and some of the types of projects that
benefit from an Agile approach.
Up next, I'll introduce you to some specific methodologies
under the Agile umbrella.
The most popular of these by far is Scrum.
In this video, I'll briefly recount the origins of Scrum
and discuss the basics of Scrum methodology.
So what the heck is Scrum?
Well, I'll tell you first that it's not an acronym.
If any of you have ever played or watched the sport of rugby,
you may recognize the term.
For those that aren't familiar with rugby,
it's similar to American football, a full-contact sport
played on a field with a similar-shaped ball.
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.
The originators of the Scrum methodology
saw their team as a heads-down group working very closely
together to get that ball down the field,
just like scrum in a rugby match.
So how does the Scrum methodology
work as a project management methodology?
I'll give you a brief overview here,
and we'll dive into it more throughout this course.
If you work in Agile Project Management,
it's highly likely that you'll use Scrum or an approach that
is based on Scrum.
In the 2019 State of Agile Report,
72% of teams using Agile methods were using Scrum or a hybrid.
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.
First, let's review some terms and concepts specific to Scrum.
The backlog 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 is the name of the time-boxed period in Scrum
where work is done.
The sprint can be between one and four weeks long,
but most sprints are around two weeks.
This is often called the iteration.
And then there's a practice called the 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 rolls, the first of which is the 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.
The other notable role in Scrum is the 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.
And the development team is responsible for how a team will
deliver that product.
Scrum is popular for many reasons.
First, it has clear roles and responsibilities
for the folks on the team while continuously emphasizing
the power of the team as a whole.
Scrum has a very regular and predictable meeting
and delivery schedule 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.
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.
Scrum lends itself best to the following
types of projects and teams.
Ideally, a Scrum team should be cross functional,
with around three to nine team members.
Some call this a pizza-sized team
because it has the same amount of people
who could share a large pizza.
If the team is too small, you might not
have the diversity of skills to get work done.
If the team is too large, it gets
hard to distribute information.
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.
Trying to force a team to do Scrum will almost always fail.
Note that in all of these examples,
I never once mentioned the word software.
Although Scrum emerged from software projects,
people have adapted Scrum to suit all kinds of projects
from wedding planning to house moves to building rockets.
[MUSIC PLAYING]
There are many popular Agile methodologies
that are still around from the '90s, when Agile was invented.
These methodologies share Agile values and principles
but have very specific practices and applications.
In this video, I'll touch on a few
of the most popular ones besides Scrum, which
we covered in the last video.
First, one of my personal favorites is Kanban.
This is a methodology that can be applied
in a very simple way, or it can be used
to drive the entire project.
The Kanban name comes from two Japanese words, kan, meaning
"sign," and ban, meaning "board."
You may have already used a Kanban board
because it's the most famous feature adopted by the majority
of Agile enthusiasts.
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.
Kanban boards or charts display the progress of a project
as to do, in progress, and done.
Also, just so you know, there are software tools
that create digital Kanban boards for you.
The Kanban method ensures that the project team only
accepts a sustainable amount of in-progress work.
This means the amount of in-progress tasks
are limited to what the team can actually
handle during a certain amount of time.
This is called the Work-In-Progress limit,
or WIP limit.
The WIP limit is decided on by the team.
This is a reflection of Agile in that teams
are both self-organizing and empowered,
and they're operating at a sustainable pace.
The team members add new tasks to be completed
only after they finish their previous task
and are below the WIP limit.
This approach means that once a task has started
to be worked on, it becomes a priority for the whole team
to get it to done.
By focusing on less work, the work gets done faster.
This goal of trying to maximize efficiency is called Flow
and is a core principle of Kanban.
Another Agile methodology is Extreme Programming, or XP.
It was named that because it took traditional software
development activities to an extreme level.
But I also believe it's because it emerged at the same time
as extreme sports, like snowboarding.
XP is another one of my personal favorites.
It was the first Agile methodology
I was introduced to back in my days,
working on some of the original cell
phones at Qualcomm, the company behind the radio technology
we all use in our phones today.
Since XP came out of the software industry,
it refers to specific software terms and activities,
like coding and programming.
But the XP method can be used in lots
of non-software environments as well.
The 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.
For example, one best practice is the idea
of test-first development.
This means testing out parts of the product
before building them in full.
Often, only the larger features get
tested, which is still good but means
some details might get missed.
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.
For example, if you're delivering an ad campaign,
maybe the main pieces are the artwork, the copy,
and the ad-buy plan.
XP wants to ensure that all of the pieces of the product
will fit together properly, so it stresses simplicity.
Start with a simple design to meet
the most basic and important requirements.
Simple designs also take less time to complete.
Once the basic model is designed and has been tested,
then you can think about adding on other features.
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, just like clear writing
is crucial in any situation where
you want to be understood.
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, like I described earlier,
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, which leads us
to listening, which is about listening to the customer
and ensuring that the requirements are
integrated into the product.
This relates to Agile in the way that it values
customer collaboration, frequent communication,
and regular feedback.
XP features some other innovative practices
that are used across many Agile teams
regardless of the specific methodology being used.
First, there's pair programming, which
is when two team members work together
at the same time on one task.
Usually, this is done in the same physical location.
But with the use of digital collaboration tools,
this can happen remotely, too.
Another practice is 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.
Then there's avoid big design upfront.
This relates to designing and means
the design should be just enough to get started
and should be continuously improved
as the product evolves.
And finally, there's write tests, not requirements.
This means that instead of writing a product requirements
document and then later writing a test plan, your test plan can
serve two purposes by, A, telling the team what to build,
and, B, comparing what they built to what
was supposed to be built.
OK, so we've got Scrum, Kanban, and XP.
Let's explore one more.
For those of you who took the earlier
courses in this program, you already learned a little bit
about this final methodology called Lean, in the context
of Lean Six Sigma.
Lean methodology consists of five principles
that serve as a recipe for improving project outcomes.
They are define value, map value stream,
create flow, establish pull, and pursue perfection.
Let's break these down.
Define value means identifying and focusing
on what the customer wants and including
the customer in the process.
A product's value is the sum of all the things
the customer wants.
Map value stream means mapping out the process, or stream,
including all the steps involved in producing value
for the customer.
It also means challenging any steps that can be considered
wasteful or unnecessary.
Create flow means ensuring the product flows through the value
stream efficiently, continuing to eliminate waste
throughout the cycle.
Work to remove interruptions, delays, and barriers
to the workstream.
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.
They might pull or ask for features
in incremental deliveries.
The idea is to make your process as smooth as possible
so that the customer can pull on the product at any time,
and you'll be able to present what you've been working on
or add a feature request.
Finally, there's pursue perfection.
This means pushing your team to continuously improve
the first four process steps.
So how does this relate to Agile?
Well, Agile emerged after Lean.
And the inventors of Agile were inspired
to apply Lean-manufacturing principles
to software development.
Like Agile, Lean is a set of principles and a value system.
Many of the differences are really just in the wording.
[MUSIC PLAYING]
In the last video, we reviewed a few of the more popular methods
for applying Agile values and principles to your projects.
We explored Kanban, which focuses on visualization
and managing flow; XP, which is concerned
with taking product development best
practices to an extreme degree; and Lean,
which actually predates Agile and aims
to capture core principles that eliminate waste
and deliver value to customers.
We've also compared Agile to Waterfall
to form a better understanding of what each approach values
or tries to accomplish and what kinds of projects
they work best with.
Throughout these videos, we've explored
Agile Project Management in a couple of different ways.
First, we explored Agile as a way
of thinking about the project delivery process
through the values and principles outlined
in the Agile Manifesto.
Second, we explored Agile through different project
delivery frameworks and methods, like Kanban, XP, and Lean,
and especially through Scrum.
These two ways of applying Agile demonstrate
that the real power of Agile comes from not only adopting
certain processes or strategies but also
from adopting a certain kind of mindset,
one that is necessarily different from the traditional
Waterfall models.
This means that you can still get some benefits from thinking
in an Agile way and seek to apply those Agile values
and principles from the Agile Manifesto
even when you need to use a waterfall delivery approach.
So with all this Agile stuff bubbling around your heads,
let's do a quick recap on some of the key tenets
of traditional Waterfall Project Management.
Then we'll explore some of the ways you can blend the methods
and approaches you've just learned about
to best fit the needs of a specific project.
As we learned in earlier courses,
a Waterfall project lifecycle is made up
of the following phases--
initiation, planning, executing and completing tasks,
and closing out the project--
and all of the tasks within each of these phases,
like identifying goals and scope, scheduling, budgeting,
and risk management.
Agile Project Management includes most
of the same phases and tasks.
They're just done in different ways.
So even though these two approaches
have clear differences, blending them might make a lot of sense,
depending on the type of project or project team
you're working with.
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.
Maybe there are regulatory requirements
that insist on certain traditional work
processes, such as large requirement
documents for certifications.
Or it could be that one of the vendors involved
in a large project is already following
a traditional approach, and the integration between the teams
requires some blending of methods.
In these cases, a project manager
might choose to blend aspects of Waterfall and Agile
so that different parts of the project
can be worked on in ways that meet project requirements
but don't negatively impact other parts of the project
or the project as a whole.
Let's explore some more examples of how to blend methods.
Let's say your project is to develop a software product.
During the retrospective for the last sprint,
a team member says, I need to implement a certain feature,
but I don't have much experience building
that particular feature.
Someone else on the team is an expert on that feature,
so you decide to pair them up so they
can work on building the feature together
during the next sprint.
You've just blended XP and Scrum.
XP provides the basis for working in pairs,
from pair programming.
And retrospectives are a key component of Scrum.
Here's another incredibly common example.
Most Scrum teams I know use a Kanban board
to track their progress through their sprint.
One word of warning, though-- watch out
for too much change in how you do things.
Teams work best when they can build up some consistency.
Let's come back to Office Green.
As project manager of Virtual Verde, what types of methods
might you want to use to get the project started?
Where would you blend some traditional methods and Agile
methods?
Here are some factors to consider.
The existing plant suppliers are used
to dealing with the original Plant Pals office delivery
team.
Some of them might be interested in experimenting
with an Agile approach but not all.
In this case, you'll want to include those vendors
in discussions early on to gain buy in
and address any concerns.
Office Green also needs to really watch their costs,
so you'll want to use traditional budget-management
controls to make sure they don't go over
budget on their program.
Well, that brings us to the end of this video.
Let's review the key points I want you to take with you.
First, Agile is a mindset, a way of thinking about the project
delivery process through the values and principles outlined
in the Agile Manifesto.
Second, Agile values and principles
can be achieved through certain frameworks and delivery
methods, like Scrum, Kanban, XP, and Lean.
And finally, Agile and Waterfall are both effective ways
of approaching project management that
add specific value.
There are times when blending these styles
will add even more value than sticking with just one.
So don't be afraid to mix things up.
As long as different parts of the project
can benefit from certain processes
without negatively impacting the project as a whole, go for it.
ROWENA: Congratulations on finishing this video
in the Google Project Management Certificate.
Access the full learning experience, including
job search help, and start to earn your official certificate
by clicking on the icon.
To view the next course.
In this video, click here.
And subscribe to our channel to learn more from Google Career
浏览更多相关视频
Lecture 14 : Agile Project Planning, Project Charter
Agile Project Management Tutorial | What Is Agile Project Management? | Simplilearn
MANPRO 2.0 Fase dalam Manajemen Proyek
What Is Agile Model In Software Engineering? | Agile Methodology Explained | Simplilearn
Da filosofia à prática: por dentro das metodologias ágeis
What is Product Management? Definition and Examples
5.0 / 5 (0 votes)