Agile Management | Google Project Management Certificate

Summary

The 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

00:00

😊 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.

05:02

😃 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.

10:03

😏 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.

15:04

🤓 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.

20:06

😎 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.

25:08

🤔 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.

30:08

📝 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.

35:10

👷‍♂️ 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.

40:12

💫 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.

45:12

🎉 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.

Keywords

💡Agile

Agile se refiere a un enfoque de gestión de proyectos que enfatiza la flexibilidad, adaptación al cambio y entrega de valor al cliente. En el video, Agile se presenta como una alternativa al enfoque tradicional de cascada (Waterfall) que es más secuencial y rígido.

💡Scrum

Scrum es un marco de trabajo específico dentro del enfoque Ágil que utiliza sprints (iteraciones cortas) y roles como el Scrum Master para entregar valor al cliente de forma incremental.

💡sprint

Un sprint es un periodo corto (usualmente de 2 semanas) en el cual el equipo Scrum trabaja para completar un conjunto de tareas y entregar un incremento de valor al producto.

💡backlog

El backlog es un artefacto central de Scrum que contiene todas las tareas pendientes priorizadas para que el equipo las complete en los sprints.

💡Daily Scrum

El Daily Scrum, también llamado stand-up, es una reunión diaria de 15 minutos para que el equipo Scrum inspeccione su progreso hacia la meta del sprint.

💡Scrum Master

El Scrum Master es el facilitador del equipo Scrum, ayuda a eliminar impedimentos, protege al equipo de interrupciones y asegura que sigan los valores y prácticas ágiles.

💡product owner

El product owner es el responsable de maximizar el valor del producto que entrega el equipo Scrum, prioriza los elementos en el backlog en base al valor para el negocio.

💡Kanban

Kanban es otro método ágil que utiliza un tablero visual para gestionar el flujo de trabajo y limitar el trabajo en progreso, promoviendo la entrega justo a tiempo.

💡VUCA

VUCA (volatilidad, incertidumbre, complejidad y ambigüedad) describe un entorno de negocios turbulento donde Ágil puede ayudar a adaptarse mejor a los cambios.

💡Manifesto Ágil

El Manifesto Ágil define 4 valores centrales y 12 principios que guían a los equipos ágiles, como priorizar individuos e interacciones sobre procesos y herramientas.

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