USMx: ENCE607.

1x Applied Scrum for Project Management

https://courses.edx.org/courses/course-v1:USMx+ENCE607.1x+3T2018/course/

Welcome to the Applied Scrum for Project Management course!

Applied Scrum for Project Management is focused on orienting you to Agile in the real
world, and it's base framework: Scrum.

In this course we start by learning the key project management processes, roles,
mechanics, and philosophies behind Scrum. This gives you the basic understanding you'll
need in the Mastering Agile Professional Certificate program to learn principles at the
heart of all Agile frameworks. This will provide the basis for understanding Agile in its
purest form over four weeks exploring Why, Who, How, and finally What Scrum looks like
applied in the real world.

What you'll learn

 Why Agile is taking over: history, case studies, and proof Agile works better
 Who uses Agile based on industry scale, stakeholders, and engineering
 How to run a successful Scrum team for speed, innovation, leadership, and control
 Scrum team makeup, user story writing, sprint planning, execution, and retro
tools
 What Scrum looks like at scale, its alternatives, and how to avoid pitfalls over time

..

Scrum aplicado para la gestión de

proyectos
ENCE 607.1X, sep 2018 - sep 2019

Descripción del catálogo

Scrum aplicado de ENCE 607.1X para gestión de proyectos : Scrum y Agile a menudo se
consideran sinónimos, y hay una buena razón.Scrum incorpora el enfoque más simple y
puro para administrar el trabajo de proyectos a nivel de equipo y es empleado por más de
la mitad de todos los profesionales de Agile en todas las industrias. Considere las
siguientes estadísticas:
  Hoy en día, casi el 100% de las organizaciones de TI utilizan Agile y
muchas otras industrias están siguiendo rápidamente
 La probabilidad de estar en un proyecto Scrum o similar a Scrum se está
acercando rápidamente a 50/50 o mejor con el tiempo.

En este curso, comenzaremos por aprender los procesos clave de gestión de proyectos,
roles, mecanismos y filosofías detrás de Scrum.Esto le brinda la comprensión básica que
necesitará en el programa Mastering Agile Professional Certificate para aprender los
principios en el corazón de todos los marcos de trabajo de Agile. Esto proporcionará la
base para comprender Agile en su forma más pura durante cuatro semanas explorando
por qué, quién, cómo y, finalmente, qué aspecto tiene Scrum aplicado en el mundo real.

Objetivo del curso

Conozca los procesos de administración de proyectos, roles, mecanismos y filosofías detrás de

Scrum, el enfoque más simple y puro para administrar el trabajo a nivel de equipo.

 Por qué Agile se está haciendo cargo: la historia, los estudios de caso y la prueba de que Agile
funciona mejor

 ¿Quién usa Agile en función de la escala de la industria, los interesados y la ingeniería?

 Cómo ejecutar un equipo Scrum exitoso para la velocidad, la innovación, el liderazgo y el control

 Maquillaje del equipo Scrum, escritura de historias de usuario, planificación de sprint, ejecución y
herramientas retro

 Cómo se ve Scrum a escala, sus alternativas y cómo evitar las trampas en el tiempo

Logística
Tiempo y Este curso es a su propio ritmo y se puede acceder a él en EdX en el siguiente
ubicación enlace:

https://www.edx.org/course/applied-scrum-for-project-management

Instructor John Johnson PMP CSM SPC, Profesor adjunto, UMD, Gestión de proyectos

Sistema de EdX es el Sistema de Gestión de Aprendizaje. Contiene todos los videos de conferencias con
subtítulos, los Puntos de resumen que sirven como notas de clase para cada video y las
Gestión de
comprobaciones de conocimiento para garantizar una síntesis continua del material.EdX
Aprendizaje también contiene los materiales disponibles solo para estudiantes verificados como materiales
(ELMS) complementarios para aprender e implementar estas lecciones en su lugar de
 trabajo. Finalmente, se incluyen los dos exámenes, uno para auditar a los estudiantes y otro
para estudiantes inscritos verificados.

Estándar Preparación (Preparación) : consideraciones antes de ver la conferencia en video (texto)

Video conferencia - video conferencia sobre el contenido del curso (video)

Contenido
semanal Puntos de resumen : captura los puntos esenciales necesarios para la retención de
conocimientos (texto)

Verificación de conocimientos : evalúa los conocimientos aprendidos de la conferencia y el

resumen (cuestionario)

Referencias - información adicional útil y relevante para el curso (texto)

Calificacion
Comprobaciones de conocimiento (64%): cada lección tiene una comprobación de
conocimiento; Usted puede enviar un número infinito de veces. Cada verificación de
conocimiento tiene tres preguntas. Esto es totalmente para ayudarle a comprender su
comprensión del material.

Final programado (30%): el curso tiene un examen programado con veinte (20)
preguntas que puede enviar solo una vez. Está destinado a probar su retención y ofrecer
un medio más rápido para aprobar el curso.

Final abierto (6%): el curso tiene una segunda final abierta con veinte (20) preguntas a
las que puede enviar respuestas a un número infinito de veces, al igual que un control de
conocimiento. Esto se puede usar como preparación para la final programada o puede
aprobar el curso respondiendo todas las preguntas en esta final abierta y las pruebas de
conocimiento correctamente.

Grado de aprobación: 70%

Prerrequisitos
No hay prerequisitos para este curso. Se espera que usted entienda los negocios
generales y algunos términos de ingeniería, ya que este es un curso de ingeniería
enfocado en entregar productos de trabajo para los clientes.

Derechos de autor y propiedad intelectual

 Los materiales de la clase son propiedad del instructor; no los venda ni publique en un
sitio web. Recuerde también que los materiales del curso no pueden reproducirse para
ningún otro uso que no sea personal sin el permiso del instructor del curso. Como
estudiante, usted es dueño del trabajo que crea como parte de sus actividades
académicas y de investigación de la Universidad.

Compromiso de tiempo

Como un curso a su propio ritmo, puede decidir cuándo tomar cada lección. Nuestra
recomendación es que siga el programa de estudios y realice cada sección dentro de una
semana. La carga de trabajo típica para una lección incluirá:

 Leer y considerar la introducción "Prep" (1 minuto).

 Viendo la video conferencia (5 a 12 minutos)
 Lectura de los puntos de resumen en la video conferencia (3 minutos)
 Tomando el Chequeo de Conocimiento para poner a prueba tu
aprendizaje (3 minutos)
 (Opcional) Referencias de lectura al final de cada lección (0-5 minutos o
más)

Esto significa que cada lección tomará de 15 a 20 minutos en completarse.

Hay cinco lecciones por semana, por lo que cada semana debería tomar
aproximadamente 1,5 horas para completar .

Al final de las cuatro semanas hay una final que cuenta para la calificación completa del
curso. Antes de elegir tomar la Final, le recomendamos que considere la Verificación del
curso. Los Estudiantes Verificados obtienen acceso a excelentes herramientas y
referencias que se encuentran en las secciones del folleto.

El examen final no debe tomar más de 60 minutos para completar.

En total, se necesitan al menos siete (7) horas para completar todas las lecciones y el
examen final. Aunque esperamos que la mayoría de los estudiantes necesiten más en el
orden de diez (10) horas para revisar y ver videos por segunda vez, así como para estudiar
para la Final.
 Nuevamente, este es un curso a su propio ritmo, por lo que recomendamos
encarecidamente que los estudiantes se tomen su tiempo y se dediquen a comprender
las conferencias en video y los conceptos que se presentan.

Código de Integridad Académica

La Universidad de Maryland (UMD) es una comunidad académica y su propósito
fundamental es la búsqueda de conocimiento. Como todas las demás comunidades, UMD
puede funcionar correctamente SOLAMENTE si sus miembros se adhieren a metas y
valores claramente establecidos. Esencial para este propósito fundamental es el
compromiso con los principios de verdad y honestidad académica. El Código de integridad
académica de UMD está diseñado para garantizar que se respete el principio de
honestidad académica. Si bien todos los miembros de la comunidad comparten esta
responsabilidad, el Código de Integridad Académica está diseñado de manera que la
responsabilidad especial de defender el principio de honestidad académica recae en los
estudiantes.

La integridad académica se refiere a un conjunto de valores, principios, comportamientos

y habilidades compartidos que se encuentran en el corazón del aprendizaje y la
erudición. Se espera que los estudiantes mantengan el más alto nivel de integridad a lo
largo de su búsqueda académica. El trabajo académico intelectualmente honesto
representa un análisis independiente y reconoce todas las fuentes de información que
contribuyen a las ideas que se exploran. La falta de apoyo académico.

La integridad incluye: falsificación de datos; asignación indebida de crédito; y cualquier

representación de las ideas, palabras o trabajos de otros como propios. Cuando los
estudiantes tergiversan su trabajo, el profesorado no puede evaluar con precisión su
desempeño o proporcionar los comentarios que los estudiantes necesitan para
aprender. Los estudiantes que se plagian o se engañan se dañan a sí mismos y, en última
instancia, dañan el valor y la reputación de la educación para todos.

Cualquier violación de la integridad académica resultará en que el certificado profesional

no sea otorgado, asumiendo que el estudiante se encuentra en la ruta de
certificación. Las violaciones de integridad académica en este curso incluirían: compartir
respuestas a los controles de conocimiento y el examen final en cualquier forma
electrónica. Las violaciones resultarán en que el estudiante sea retirado de la clase.

Resumen del horario de clases

Semana Descripción de alto nivel
1 La primera semana comienza con ¿Por qué se usan los métodos ágiles? Basados en estudios
 de caso que demuestran su efectividad y la historia de llegar a Scrum.

2 La segunda semana explora Quién usa Agile en todas las industrias, explorando los tipos de
gestión del trabajo y cómo Scrum Agile encaja en el mundo del trabajo.

3 La tercera semana se mete en la mecánica de Scrum y cómo se realiza y ejecuta Scrum. Aquí
aprenderá la formación de equipos, la planificación y los juegos retro, y cómo gestionar
eficazmente el trabajo para cumplir los objetivos de Sprint.

4 La última semana gira para ver qué aspecto tiene Scrum en Scale, y en qué se diferencia de
otros marcos ágiles en términos de escala, gestión de programas y carteras, gestión de
riesgos y riesgos de Agile.

Detalles del horario de clases

Lección Semana Tema Verificación
de
conocimiento
Semana 1
1 1 Fundamentos ágiles X
2 1 Prueba de trabajos ágiles X
3 1 Evolución de ágil X
4 1 Estudio de caso de Netflix X
5 1 18F Estudio de caso X
Semana 2
6 2 Métodos simples de PM X
7 2 Acercándose a la restricción de costo simple X
8 2 Comparación de métodos en todas las industrias X
9 2 Comparación de métodos de gestión de clientes X
10 2 Comparación de métodos de gestión de X
 ingeniería
Semana 3
11 3 Formación Scrum Team X
12 3 Historia de usuario en tres partes X
13 3 Planificación de Sprint X
14 3 Desarrollo Sprint X
15 3 Sprint Retro y Revisión X
Semana 4
16 4 Scrum en el mundo de ágil X
17 4 Explorando el marco ágil escalado (SAFe) X
18 4 Explorando la entrega ágil disciplinada (DAD) X
19 4 Explorando Scrum a gran escala (LeSS) X
20 4 Escollos y X
20+ 4 Examen final

Contenido

1. Welcome!
1.
Welcome to Applied Scrum

1.

Welcome to the Course!

2.
 Updated Course Syllabus

3.

To Get Help with the Course

4.

Introduce Yourself

2.
Getting Started with Goals!

1.

Goal Sharing

2.

Nebulous Goals

3.

Who Are You? Where are You From?

 4.

Continue Your Education at UMD!

2.
Week 1: Why Agile?

1.0 Introduction to Week 1

1.0.0 Goals and Objectives of Week 1

1.0.1 Introduction to Week 1 Video

dramatic music)

- Hi, and welcome to the

Agile Project Management course series.

We're gonna start off with

Applied Scrum for Project Management in this first course.

In this course, you're gonna learn

all the basics that you need in order

to use Scrum in the workplace in order

to achieve greater productivity

and greater satisfaction as you execute your projects.

First, in Week 1, we're gonna give you

all the basics that you need

in order to understand Agile and its context.

 We're gonna talk about the basics of Agile.

We're gonna talk about proof that Agile works.

We're gonna show you a little bit

of the evolution of Agile as well

as a case study from Neflix and a case study

from the General Services Administration's 18F.

You can watch these in any order that you want.

They're gonna give you the context

and the foundation that you need

for the additional weeks in the remainder of the course.

We hope you enjoy them,

and I look forward to seeing you there.

(dramatic music)

1.1 Agile Basics

Knowledge Check Este contenido es calificable

1.1.0 Prep for Agile Basics

Are you ready to become Agile? Know what that means?

In this first week, consider what are the critical, fundamental differences between
Traditional, Lean, and Agile. What makes a team Agile at its core? Why has the world so
rapidly adopted this new, radical approach to management? Is it really new? What does
it really mean to use Agile Project Management?

To answer these questions you're going to need an understanding of the basics:

What are the core values?

What are the fundamental differences in managing work?

 Why would customers or companies choose to use Agile?

Enjoy your first dive into the the world of Agile!

1.1.1 Agile Basics Video

- Hi, and welcome to Agile Basics. In this lesson, we're going to show you the foundations
of Agile, so you understand what Agile's all about, valuable sprints, and then dispelled
myths.

First, let's talk about the manifesto. The manifesto was brought into being in 2001 with a
meeting of the minds in Snowbird.

Here you had experts from Scrum, XP, and DSDM come together, and what they did was
they put together 14 principles,

as well as a value statement,

which is the foundation of Agile that we know today.

The value statement simply says,

"While we find value in items on the right,

"we value items on the left more."

So let's take a look at the first one.

The first one is individuals and interactions

over processes and tools.

This is because people are the ones who get the work done,

and in the end, it's our interactions with each other

that can exchange the most information.

No tool or process can ever carry as much information,

or be able to convey the intent,

as much as a one-to-one conversation.

So we start with this belief that we want people to interact

and not to use processes and tools

to supplant that kind of productivity on a project.

Then we want to emphasis working software

over comprehensive documentation.

Working software is a goal.

It is not to deliver a document.

In the end, we want to build a system that is valuable,

and that can actually help the organization

achieve new capability, so we always want to make sure

that, when push comes to shove,

we're going to be building the system, not documenting it.

However, that doesn't mean that there isn't documentation,

and this is often a point on Agile

that is lost among new practitioners.

Documentation is critical, and in fact,

you'll get better documentation with Agile,

because we document as we go.

However, we'll never let it get in the way

of completing the project.

Next, customer collaboration over contract negotiation.

Customer collaboration is essential.

In the end, the customer is on your team in Agile,

and you only go to the contract when something goes wrong.

Contracts are for risk management,

but customer collaboration is how you create

a long-term relationship that's going to allow you

to have value in multiple projects.

Any contractor that's in it just for this project

is taking the short view,

and not going to end up being as successful in the long run.

And then finally, responding to change

over following a plan.

No plan survives first contact with the enemy,

in order to quote Eisenhower,

who made that famous back in World War Two.

However, we need to also understand

that plans allow us to predict what's coming,

and to coordinate our work, so we do still plan.

In fact, we continuously plan in Agile.

But we always emphasize responding to change

because of the fact that we know those plans

are going to change, and we're going to learn as we go.

If we were to follow the plan that we came up with

at the beginning of the project,

it would have been like we learned nothing

while we were building the product itself.

So these are the core values of Agile,

and if you understand them,

then you understand how Agile works,

and why we've built it the way it works today.

Now let's talk about sprint basics.

With sprint basics, you've got the planning,

the development, and the retro and review.

The planning begins where the product owner

has organized all the work into a backlog.

That backlog can have issue types,

which include features, bugs, and stories.

That work has been planned,

but hasn't yet been reviewed by the team,

and so in the next stage in sprint planning

the product owner will present the stories,

and the team will then select together

from the top of that list,

what work they think they can get done during the sprint.

The sprint is only two to four weeks,

so they have to be conservative

in terms of what they can get done,

and commit to getting the work done.

During this process the team will ask questions,

they'll elaborate on the requirements,

and by the end, they'll have a clear understanding

of what it's going to take to complete each story.

And when they do, now they can move forward

knowing not just what the story's going to take to develop,

but also what it's going to take to test and close.

Then, in development,

the development begins with a stand-up.

The stand-up is where everyone gets together,

and for five to 15 minutes at most,

they report on what they're going to be doing today

to advance the stories on the sprint.

Normally, this is done around a Kanban board.

The Kanban board provides a means

to understand what work is in progress,

and who's working on it.

During this time, the team will continue to work

throughout the two to four weeks,

and they'll be completing stories.

They'll be analyzing the requirements, developing the work,

and then testing and closing them.

They're going to be trying to work story by story

because you don't want to have too much open work at once.

And, by the end of it, they're going to have

a potentially shippable increment.

This potentially shippable, or releasable, increment

is going to be a piece of completed work

that includes documentation,

as well as a fully tested, working product

that the product owner can show.

And that's when the retro and review come in.

So the review is where the product owner

presents the great work that their team has done.

Oftentimes this product owner is the client,

or a client representative,

so this is a great opportunity for the client

to show off to their stakeholders and peers

how well their project is going.

At this point, the stakeholders give feedback,

and the team can learn what they need to do next.

In addition, the team will then go into a room

where they play a game in order to expose

all the things that went well, what didn't go well,

and what they need to improve on next time

so that they can make an even better sprint happen.

This is a very exciting process.

It happens very quickly, and within a couple of sprints

you're going to have a very high functioning team.

Now let's talk about the comparison

between Agile, Lean, and Traditional.

It all begins with the iron triangle.

The iron triangle is our constraints

between scope, schedule, and budget.

Normally, when you change one or two,

you have to change the other.

This push and pull effect is something that we understand

if we've every been to a restaurant,

where oftentimes they'll say,

"Quality, service, or speed, pick two."

Well, in this case, we understand that

as scope, schedule, and budget.

So we pick two to hold, and we vary another.

With Agile, what we're willing to vary is scope.

Now, it doesn't mean that we're going to vary the goal.

We're going to vary the technical scope.

In order to do this, your customer really has to trust you.

They have to believe that you know what you're doing,

especially from a technical level.

So trust is the primary thing that a customer looks for

when they're sourcing whatever contractor or team

is going to be doing the work.

And in the end, the goal is speed.

And the reason why scope adjustment

is so effective for speed,

is that there's no way to achieve a project faster

than figuring out what work you shouldn't do.

So by limiting the work that is focused on,

and only doing the important work, we can move quickly.

Then, in Traditional projects, what we're going for

is not speed, but we're actually going for predictability.

Here, what we're willing to vary is the budget.

So oftentimes this is,

"I know what I want, and then when I want it,

"but I want you to give me the best price."

This happens whenever, say, we're building a house,

or building a really large project,

and it needs to be delivered on a certain deadline.

In these cases, where predictability is the goal,

we're looking for efficiency in our contractors.

We want them to give us the best price possible,

or to be able to do it with the least amount of waste.

And then with Lean projects

we're willing to vary the schedule

in order to achieve some kind of problem-solving event.

Oftentimes this happens when we're doing customer service,

legal support, or research and development.

The scope is known.

The budget is already paid for, or it's a subscription fee.

And so what we're going for

is being able to solve the problem, some kind of innovation.

And in these cases, what we're sourcing for is expertise.

So, for example, if you have a piece of software

you're going to pay a certain service agreement

or a certain subscription in order to get support.

The reason why you're willing to pay that

is because those people are the experts in that software.

So this is the comparison.

We're going to talk a lot more about this

in other parts of the course.

Let's move on to the next slide.

Now, some false comparisons.

There are many false comparisons

when it comes to Agile, Traditional, and Lean,

and we wanted to make sure that you understand them clearly.

First, all of these projects have a charter.

There is no difference

when it comes to Agile, Lean, or Traditional,

in terms of having a charter.

Every project needs to know who are the players,

what is the goal, what are the constraints,

what are the risks.

That's true no matter what.

Then, a plan.
As we said before at the beginning of this lesson,

we always have a plan.

We also are willing to change that plan

as we learn more as we go,

but in Agile, it's continuous planning.

So we do plan, and we do predict,

and that's how we can coordinate.

Then there's documentation.

Documentation is one of the key factors

in terms of scalability, as well as sustainability.

If anyone leaves the project, oftentimes it is a document

that's going to allow you to backfill that position

with as minimal disruption as possible,

so documentation is done as we go.

Then there's design.

Design is essential for any kind of project,

and, in fact, the difference with Agile

is that we design as we open up each piece of work.

And then testing.

This is probably the area where Agile exceeds,

because there's testing all the time.

We're continuously integrating,

and continuously testing as we go.

That's the only way you can complete work in stages.

So, I'm going to start off with the little story here,

to kind of explain how varying scope

helps to address some of the typical problems

within a project.

Imagine that you have a customer,

and that customer wants to build a tree swing.

The way they explain it to you

is they talk about a three level tree swing with ropes.

And then the project leaders hears this, and he says,

"Oh, a tree swing.

"So it's going to be two ropes with a plank in between it,

"and it's not really going anywhere."

Then the engineer takes a look at it and realizes,

"Hey, we need a space for you to swing in between,

"so let's prop up the tree on either side."

Which doesn't make so much sense.

Followed by the business consultant

who hears about this tree swing and describes it as

the second coming of tree swings all around.

Of course, the project will never be documented.

The customer's going to be billed

like it's a roller coaster.

It's going to be supported like the giving tree.

And in the end, all the customer really needed

was a tire swing.

This is the reason why we vary scope,

because we can quickly avoid a lot of these issues

by putting the whole team together,

and limiting the amount of work done.

So let's just do a quick review.

What is Agile?

Agile is a methodology, it's not a framework,

and the key aspect to it is that we need to have

a shared vision that is robust to change.

This allows us to vary scope as a team.

We also need to have whole teams.

We have to have the customer on the team,

as well as the designers, the testers, and the developers.

Only this way can we close work as we go.

We also want to make sure that we're building in increments.

This allows us to learn, and get fast feedback.

And then finally, continuous integration and testing.

This allows us to know that we are completing the product

in a way that will work in the future,

and as we go, we can always deliver, or stop the project

and say here's value.

You don't have a whole bunch of work in progress

that isn't complete.

 When we compare this to Scrum, XP, or SAFe,

these tenants that we just gave you are the method.

Scrum is a framework, it is the basic framework.

It's the framework that most other frameworks are built on,

but it is not the core values of Agile.

So now that you have the Agile Basics,

we can talk about Scrum in a little bit more detail,

and understand it as a framework.

We hope that you've enjoyed this lesson,

and we look forward to seeing you next time.

(electronica flourish)

1.1.2 Agile Basics Summary Points

Agile Manifesto was codified in 2001 in Snowbird by Scrum, XP, and DSDM practitioners.
Agile Manifesto includes:

 Individuals and Interactions OVER processes and tools

 Working software (systems) OVER comprehensive documentation
 Customer collaboration OVER contract negotiation
 Responding to change OVER following a plan

These values are at the core of why agile works and continues to be used on projects with
high uncertainty today.

Sprint basics include the three parts of a Sprint:

 Sprint Planning
 Sprint Development
 Sprint Retro & Review
A Sprint is a time box, or a period that is used to contain the time allowed for work to be
completed. It can be anywhere from two weeks to a month (although shorter is
becoming more popular among advanced practitioners).

Sprint Planning starts with the Product Owner selecting the work to be done from the
Product's Backlog. The Product Backlog is the list of work that is prioritized by its
importance, either for ongoing improvement or the completion of a new product. The
Team reviews the stories and then selects what work they will be able to complete during
the sprint. This process is facilitated by the Scrum Master who does not participate in the
doing of work, but instead is focuses on enabling the team to move quickly with good
processes and best practices. The final set of stories should form a cohesive "product
increment" that the team can demonstrate by the end of the sprint.

 Input: Product Backlog of stories prioritized by the Product Owner

 Process: Review and select stories for the sprint
 Output: Sprint Backlog of stories the team commits to complete by the end of the
Sprint

Sprint Development begins with the daily standup. Daily standups are self-reporting of
the team on what work they will get done that day. This is usually done around a Kanban
board, or other big visual information radiator (BVIR). The team opens only a few stories
at a time and work story-by-story to analyze, build, and test the work. The result by the
end of the Sprint is a shippable increment that can be demonstrated to the product
owner. Meetings are facilitated by the Scrum Master, and the Product Owner determines
if a Story is complete to meet the stakeholder needs.

 Input: Sprint Backlog of stories the team commits to complete by the end of the
Sprint
 Process: Daily reporting and execution against a few stories at a time: designing,
building, testing and closing
 Output: A shippable product increment that can be demonstrated

Sprint Retro and Review are ceremonies to gain feedback and drive continuous
improvement into the team. The first step is the Sprint Review, where the Product Owner
demonstrates the product increment from the Sprint to Stakeholders. This is an
opportunity to gain stakeholder buy-in and feedback, so the team knows its on track with
the product direction. The Product Owner can also get feedback on what should be in the
next Sprint. The Sprint Retrospective or "Retro" is the second ceremony used to close a
sprint. The Retro involves the team going into a room to evaluate how the sprint went,
and identify opportunities for improvement in the next sprint. The best Sprint Retros are
run as games to facilitate input from the whole team and quickly identify improvements.

 Input: Shippable product increment that can be demonstrated

 Process: Demonstrations and games to facilitate feedback on the product and team
processes
  Output: Feedback on the product's direction and actions to improve the next sprint

Iron Triangle helps to explain how the different project management methods align. The
Iron Triangle includes:

 Scope - the technical work to be done

 Schedule - the total calendar time to execute the work
 Budget - the total cost of the project in dollars

All aspects of the Iron Triangle are constraints and costs to the organization. More
schedule means a delay of project benefits and tie-up of capital. More budget means
more dollars or capital invested. More scope means a larger product to support or
maintain for the organization. These are all forms of cost and constrain how the work can
be accomplished when they are fixed.

The three types of project management are Agile, Traditional, and Lean.

 Agile - varies scope against fixed budget and schedule

 Traditional - varies budget against fixed scope and schedule
 Lean - varies schedule (or solution time) against fixed scope and budget

The goals and requirements of each method are essential for understanding the place of
each method in the project manager's arsenal:

 Agile - goal is speed (deliver early versions fast), and requires trust to minimize
scope for fast value delivery
 Traditional - goal is efficiency (best price), and requires efficiency to deliver lowest
cost on time and budget
 Lean - goal is to innovate (solve problems), and requires expertise to minimize time
of delivery

False comparisons across types of projects abound. Many times the objections one hears
about using Agile is that it's missing critical elements, such as design, testing, or
documentation. These are all wrong. In fact, every project must have the following to be
successful:

 Charter
 Plan
 Documentation
 Design
 Testing

Remember that we vary scope to target just what the customer needs, so we don't waste
time or money in the process. That's the power of varying scope. It's fast and limits waste
by reducing the work to a minimum viable product (MVP) that meets the project
objectives (in the charter). To do this, every Agile project needs:

 Shared Vision Robust to Change (can vary scope and stay on target)
 Whole Teams (customer + cross-functional team)
 Incremental Delivery (learn by doing and using small "sprints")
 Continuous Integration & Testing (teams test increments to ensure they work)

Scrum, SAFe, or Disciplined Agile are all frameworks that help define roles and processes
to scale and implement the methodology of Agile. They provide a shared language. But
the method remains the same.

1.1.3 Agile Basics Knowledge Check

Question 1
1/1 punto (calificable)

Which of the following belong to the cornerstones of the Agile manifesto (choose 4 of 6)?

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Management and process over tools and people

Customer collaboration over contract negotiation

Responding to change over following a plan

Incremental delivery over large releases

correcto

Correcto (1/1 punto)

Revisión

Question 2
1/1 punto (calificable)

Which of the following main roles are defined by Scrum process (choose 3 of 5)
 Development Team

Scrum Tester

Scrum Master

Product Owner

Project Manager

correcto

Correcto (1/1 punto)

Revisión

Question 3
1/1 punto (calificable)

Which of the following is the correct sequence of events in a Scrum process?

Sprint Planning, Sprint Development, Sprint Retrospective, and Sprint Review

Sprint Planning, Sprint Development, Sprint Review, and Sprint Retrospective correcto

Sprint Development, Sprint Planning, Sprint Review, and Sprint Retrospective

Sprint Development, Sprint Planning, Sprint Retrospective, and Sprint Review

Correcto (1/1 punto)

Revisión

Question 4
1/1 punto (calificable)

The Agile project should______________ to facilitate good communication.

Use the same communication tool

Operate with one team exactly less than 10 people

Keep all the team members in a single location

Break the project into smaller and cross-functional teams correcto

Correcto (1/1 punto)

1.1.4 Agile Basics References

Additional References and Reading:

Agile Manifesto: http://agilemanifesto.org/

 The first document that almost EVERY agile course will start with - because it is the
most important

 Foundational online document capturing the beliefs of Agilists culminating in 2001

 A key reference for this course and the principles that underly the courses in the Agile
Project Management Program

Agile Manifesto Principles: http://agilemanifesto.org/principles.html

 Often overlooked, these fourteen principles exemplify the details needed to make
Agile work

 Example principle:

The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.

Wikipedia's definition of
Scrum: https://en.wikipedia.org/wiki/Scrum_(software_development)

 We're not above referencing Wikipedia - especially an article that has so much great
information in one location!

 This is also the source of our key graphic on Scrum that we use throughout the course

1.2 Proof Agile Works

Knowledge Check Este contenido es calificable
 1.2.0 Prep for Proof Agile Works

You want proof that Agile Works? Is it worth learning? Why change? Why Agile?

The proof that Agile Works at all scales and across time is written in our nation's history in
WWII, in our modern green energy movement, and the launching of spacecraft that
literally caught stars and brought them down to earth.

Agile methods built brand new cutting, edge aircraft in less than half a year, developed
super computers at 10% the normal cost, and delivered returns on investment
magnitudes higher through better decision support systems.

In this lesson we'll take you from Aircraft to Software, to Supercomputers, and back to
Space. You'll see the long history of success Agile approaches have had in shaping our
world today.

1.2.1 Proof Agile Works Video

- Hi, and welcome to Proof That Agile Works, From Spacecraft to Supercomputers.

So the first story that we're gonna talk about in terms that proof that Agile works is
Skunkworks.

Skunkworks was the program that produced the P-80 Shooting Star, the first jet fighter.

This was a program that was developed under Lockheed Martin in World War II.

Kelly Johnson, the chief architect for this new aircraft, was given the task of building the
first jet fighter in 1943 and this had never been done before.

So in order to do this, he took his whole team and he put them into a tent and they came
out with a working prototype within 143 days, the first working model.

The idea that we could produce an aircraft

of a brand new quality that could be a jet fighter

that could go into battle within less than half a year

is crazy.
But it was done back in World War II,

using Kelly Johnson's approach.

And when we look at the key success factors,

what we see is that a lot of these success factors

actually match what we propose

is the right way to do work in Agile.

In fact, when we take a look at the key tenets,

we see that he had strong, self-directed,

cross-functional teams,

that he had owners and vendors on the same team,

and they trusted each other, they emphasized that.

They were willing to manage and respond to change

because, remember, they had never done this before.

They had never built a jet fighter.

And as a result, they would have to minimize their reports

but still record the important work.

This is because so much work was being done concurrently

that everyone in the tent was allowed to come in

and adjust the architecture

as learning and improving occurred.

And finally, with this incremental development

and self-testing approach, they were able to quickly

identify if they were getting a working product.

This required enormous amount of trust

between the Air Force and Lockheed Martin

and Kelly Johnson's team.

And if we take a look at how this compares

to the tenets of Agile, we see that it matches very well.

A shared robust vision that is able to adapt to change

with whole teams that are doing incremental delivery

and continuous testing and integration.

They mirror exactly the principles

that were in Kelly Johnson's Skunkworks program

and Skunkworks continues to deliver with success today.

Now in this next program is actually one that I was on

and I ran this program for about four years

when I was at working for Booz Allen Hamilton at CNIC.

CNIC is the Commander Navy Installations Command

for the Navy.

It's kinda funny, it's got Navy in the name twice.

This is a branch of the Navy that invests in its facilities

in order to reduce the energy use and

also to switch from brown power to green power.

Now, this program was all about picking the best projects,

so the way that this worked is that first,

projects were sent to the headquarters inside of templates.

Those templates would then evaluate the projects

based upon a hierarchy of criteria that would produce scores

like net present value, energy savings,

the production of new enabling infrastructure

for future projects.

And after it went through our optimization formula,

we would come up with which projects were good

and should go ahead and get funded,

which projects needed to be taken a look at again,

and then which projects were just bad

and they were never gonna get funded.

The output was a selection of the best projects

and the rejection of those that didn't meet muster.

And of course, only the best projects would get the money.

Now, in terms of the basics of this program

and what you should know, this was a program

for the Navy and it was run as a contract

with Booz Allen Hamilton when I was a project manager.

The scope was to help invest half a billion dollars a year

in terms of investments in the shore.

Much of that money was through third-party investment

and about a third of it was through direct investment

by the Navy with tax-funded dollars.

The cost of the program that we were running,

the decision support program,

was just five million dollars over the course of four years,
so about 1.25 million dollars per year.

We had two cross-functional teams

of developers and analysts,

which included eight BAH personnel and five Navy personnel.

So, this was a small team.

But in the end, we were able to produce

incredible return on investment.

For every dollar they put into our program,

the Navy got back $50 in exchange.

And the way that we did that was first,

we made the data better and we were able

to save $20 million in bad projects.

Followed by we were then able

to improve the selection of projects,

so that we were able to gain an additional $30 million

in revenue in terms of saving energy costs.

And from there, we were then able to identify

and continue to improve the cycle of investment

with additional modeling to identify the next project

as well as to track the project success.

So now let's talk about another project I actually

worked on which was for the National Archives.

This project is a much bigger project

and it had to do with taking the National Archives,

which gathers all of the records from across the government

and then moving their record management

from eight servers stuffed inside the side

of a mountain in West Virginia and

putting them onto Amazon Web so that they could be scalable

and robust and meet the demands of the digital wave.

You have to understand that the internet

really got going about 1996 with Netscape

and then 20 years later is when all those records

from email and electronic documents

were now hitting the National Archives.

So back in 2015 and even today,

this is a real challenge for the National Archives

to scale up and meet all the electronic records

they have to manage.

So they were taking, the first thing I wanna show you

is they were taking the old system,

which has all of the different applications in one,

and we broke it apart into the scheduling,

the business object management, the search,

the digital object repository,

and the processing of records,

the digital processing environment.

These three applications were gonna go one at a time

into the cloud and the archives knew

that the biggest scalability issues

were gonna be processing and search.

So those two went first.

The result is what you see there on the bottom,

in terms of an architecture.

It looks pretty complicated, but in fact,

this was a very robust Agile architecture

that allowed us to build and deliver incrementally

from the beginning of the project to the end

and in fact finish within six months

a state of the art of the system

that had never been done before.

So let's take a look at some of the stats.

First off, this was a contracted project

between the National Archives and IBM.

I was the senior Agile project manager on that project.

The scope was to pilot a web-based system

for electronic records processing

and these electronic records processing were gonna

have to scale up to hundreds of petabytes of records.

So then the total cost was $20 million over one year

and in terms of what that broke down to

from a team perspective, we had six fully cross-functional

teams with 35 IBM employees as well as 15 NARA employees,

all working together to try to deliver this product.

In the end, this was an extremely profitable product

that came in on time and on budget

and we actually made a 40% profit on this.

We delivered a working model within six months

for the search engine, using technologies

that had never been done before.

We used an approach that had never been done before,

setting up the new Center of Excellence in West Virginia

called Near-Site Agile and the result was that

this actually won IBM's Project of the Year in 2016.

Now let's talk about projects that are even greater scale.

We're gonna go from the Air Force

with supercomputers to NASA and its spacecraft.

First off, the Air Force built one of the most powerful

high-performance computers, the Condor Cluster.

This Condor Cluster strung together PS3s

with over two million miles of cable.

As a result, it was extremely efficient and very powerful,

able to be flexibly put together in a lab,

and it could even be put on a plane.

This allowed for the real-time processing

of imagery for operators in the field

that never had been provided before.

In fact, they were able to go from days of processing time to seconds and so that actual
intelligence was given to operators so they could use it in real time.

Then there's the NASA missions under the Faster, Better, Cheaper initiative. In total,
there were about 10 successful missions during this time.

But two that really stand out are first, the Stardust mission, a mission which slung shot a
spacecraft around the Earth and then around the sun so that it could trail and catch the
stardust coming off of a comet, as well as Shoemaker, which was actually a spacecraft
that was intended to fly by an asteroid but it landed on the asteroid instead, taking high-
density readings that had never been thought possible.

Both of these missions were done under budget for a tenth of what it cost to do a
mission today, using Agile principles.

And because of the reuse and because of the ability to limit scope during development,
NASA was able to produce many working missions, 10 working missions, for the cost of
one that it costs today.

So I hope that these examples have inspired you and given you some good food for
thought that should be able to allow you to talk about Agile and its success in any
context.

P-80 Shooting Star: https://en.wikipedia.org/wiki/Lockheed_P-80_Shooting_Star

eROI Process Diagram: https://image1.slideserve.com/1599299/slide3-n.jpg

Condor Cluster Rack Image: https://www.zdnet.com/article/what-the-dods-

playstation-powered-condor-cluster-means-for-the-future-of-supercomputing/

Condor Cluster Quotes and Additional Images: https://www.youtube.com/watch?

v=oumrKPLTMnk

NASA Shoemaker Spacecraft: https://www.youtube.com/watch?v=BZASB7RLhG8

NASA Stardust Mission: https://stardust.jpl.nasa.gov/home/index.html

1.2.3 Proof Agile Works Summary Points

Hay muchas historias que capturan por qué y cómo funciona Agile. Uno de los más
convincentes es el P-80 Shooting Star, el primer caza a reacción, desarrollado por el
equipo Skunkworks de Lockheed Martin:

P-80 Shooting Star fue el primer Jet Fighter

Desarrollado en 1943 para su uso en la Segunda Guerra Mundial.

Dirigido por Kelly Johnson usando un equipo colocado en una tienda de campaña

Terminado en 143 días

Esta es una velocidad sin precedentes en la innovación y la entrega. Hoy una innovación
similar llevaría muchos años, si no una década. Kelly Johnson hizo esto usando principios
que se alinean estrechamente con Agile:

Equipos pequeños, fuertes, autodirigidos y multifuncionales

Los propietarios y vendedores tuvieron que colaborar y confiar entre sí.

Gestionado y respondido al cambio; Cualquier equipo podría actualizar los diseños.

Minimiza los informes, pero registra lo que era importante

Desarrollo incremental por equipos que podrían probar su propio trabajo.

Esto coincide con los inquilinos principales de Agile de cerca:

Visión compartida, pero sin alcance fijo (¡nunca lo construyeron antes!)

Equipos integrales (cliente, constructores, probadores).

Entrega incremental (según lo indicado, tenían que identificar y resolver problemas uno
por uno)

Integración continua y pruebas (los equipos prueban los incrementos temprano y con
frecuencia)

Ejemplo 2: Retorno de la inversión de la Marina de Energía

Objetivo: seleccionar proyectos para reducir los costos de energía y el uso de la "potencia
marrón"
Proceso: evalúe y seleccione los mejores proyectos que ofrezcan el mejor "bang for the
buck"

Proyecto: construir una herramienta de soporte de decisiones rápidamente para permitir

el soporte para la selección

El alcance de este proyecto fue construir sistemas de apoyo a las decisiones para que los
proyectos identifiquen y seleccionen $ 500M en inversiones en energía. Este proyecto se
ejecutó de forma iterativa durante cuatro años por unos cinco millones de dólares. El
equipo de maquillaje incluía:

2 equipos multifuncionales

8 personas contratadas por Booz Allen Hamilton (BAH)

5 clientes de la Armada.

Los resultados incluyeron un retorno de la inversión de cincuenta dólares por dólar (ROI:
50). Eso significa que la Armada ganó $ 50 millones por año debido a este proyecto y sus
sistemas de apoyo a las decisiones que desarrolló. Esto se logró mediante la
identificación iterativa y la creación del alcance necesario en varias versiones:

Se obtuvieron $ 20M por año en ahorros, al construir una herramienta de gestión de

calidad para proyectos

Se ganaron $ 30 millones por año en beneficios, al construir sistemas para seleccionar

mejor los proyectos.

La sostenibilidad se mejoró al modelar los próximos mejores proyectos con el 95% de

precisión.

Esto permitió a BAH ganar $ 10 millones por año en nuevos contratos en la Armada para
la gestión de energía renovable

Ejemplos ágiles a gran escala:

Condor Cluster: resultado de grandes cantidades de reutilización y arquitecturas

modulares (ejemplo de ingeniería ágil)

Una de las super computadoras mas potentes.

Se conectaron 2 millones de millas de cable para conectar las consolas de juegos

PlayStation 3 (PS3)

Suficientemente modular para ser cargado en un avión espía para procesar imágenes en
vuelo
Reducción del procesamiento de imágenes aéreas de días a segundos.

La Iniciativa Faster Better Cheaper de la NASA: alcance y tamaño reducidos de las naves
espaciales (Lean / Agile Release Designs)

Gran iniciativa en los años 90.

Los costos fueron una décima parte del costo actual de producción de la nave espacial.

Logrado resultados inéditos al reutilizar antiguos diseños de naves espaciales

Stardust Mission: tiro colgado alrededor de la tierra y el sol para ponerse al día y capturar
el polvo de un cometa.

Shoemaker : misión de vigilancia de asteroides que aterrizó en el asteroide para

recuperar lecturas de alta densidad.

Las misiones se lograron de acuerdo con el presupuesto y según lo programado,

devolviendo 10 veces el valor de los proyectos tradicionales de la NASA.

///// Texto original

There are many stories that capture why and how Agile works. One of the most
compelling is the P-80 Shooting Star, the first jet fighter, developed by Lockheed Martin's
Skunkworks team:

P-80 Shooting Star was the first Jet Fighter

Developed in 1943 for use in WWII

Led by Kelly Johnson using a colocated team in a tent

Completed in 143 days

This is unheard of speed in innovation and delivery. Today similar innovation would take
many years, if not a decade. Kelly Johnson did this using principles that align closely with
Agile:

Small, Strong, Self-Directed and Cross-Functional Teams

Owners and Vendors had to collaborate and trust each other

Managed and responded to change; any team could update the designs
Minimize reports, but record what was important

Incremental development by teams that could test their own work

This matches the core tenants of Agile closely:

Shared Vision, but no fixed scope (they never built it before!)

Whole teams (customer, builders, testers)

Incremental delivery (as stated, they had to identify and solve problems one at a time)

Continuous integration and testing (teams test increments early and often)

Example 2: Navy Energy Return on Investment

Goal: select projects to reduce energy costs and use of "brown power"

Process: evaluate and select the best projects delivering the highest "bang for the buck"

Project: build a decision support tool quickly to enable support for selection

The scope of this project was to build decisions support systems for projects to identify
and select $500M in energy investments. This project was executed iteratively over four
years for about five million dollars. The team makeup included:

2 cross-functional teams

8 contract personnel from Booz Allen Hamilton (BAH)

5 customer personnel from the Navy

Outcomes included a fifty dollars per dollar return on investment (ROI: 50). That means
the Navy gained $50M per year because of this project and its decisions support systems
it developed. This was achieved through iteratively identifying and building the scope
needed in multiple releases:

$20M were gained per year in savings, by building a quality management tool for
projects

$30M were gained per year in benefits, by building systems to better select projects

Sustainability was improved by modeling where the next best projects would be with
95% accuracy
 This enabled BAH to win $10M per year in new contracts at the Navy for renewable
energy management

Large Scale Agile Examples:

Condor Cluster - result of large amounts of reuse and modular architectures (Agile
Engineering Example)

One of the most powerful super computers

Strung 2 million miles of cable to connect PlayStation 3 gaming consoles (PS3s)

Modular enough to be loaded into a spy plane to process images in-flight

Reduced aerial imagery processing from days to seconds

NASA's Faster Better Cheaper Initiative - reduced scope and size of spacecraft (Lean/Agile
Release Designs)

Major initiative in the 1990s

Costs were one-tenth the current cost of producing spacecraft

Achieved unheard of results by reusing old spacecraft designs

Stardust Mission - slung shot around the earth and sun to catchup and capture dust from
a comet

Shoemaker - asteroid surveillance mission that landed on the asteroid to retrieve high-
density readings

Missions were achieved under budget and on schedule, returning 10X the value of
traditional NASA projects

1.2.3 Proof Agile Works Knowledge Check

Question 1
1/1 punto (calificable)

Based on this lesson, what do you think that all Agile approaches should have in common?

A prescribed and fixed iteration length that enabled iterative development

A strict focus on technical scope delivery and meeting performance measures

 A large set of clearly defined roles and outcomes for its team members

Each example delivered high-value products with relatively small budgets correcto

Question 2
1/1 punto (calificable)

One of the most compelling stories that capture why and how Agile works is the P-80 Shooting
Star, the first jet fighter developed by Lockheed Martin's Skunkworks team. The success of this
project exemplifies the core tenants of Agile. What is not a core tenant of Agile?

Shared vision with fixed scope correcto

Cross-functional teams

Incremental delivery

Continuous integration

Question 3
1/1 punto (calificable)

In the project of Navy Energy, the scope was to build decisions support systems for projects to
identify and select $500M in energy investments. As a result, this project brought a
fifty-dollar/dollar return on investment (ROI 50) to Navy. What is the key to success of this
project?

A specific and fixed scope for better decisions

A large release with all major fixes completed in the first release

Comprehensive documentation and strict rule enforcement

Iterative improvement of the business process for making decisions correcto

1.2.4 Proof Agile Works References

Some of the best examples of proof that Agile works come from the basis for these
books:
 Critical Chain

Author: Eliyahu Goldratt

Publication date: 4 September 1997

ISBN 0-88427-153-6 (first edition, paperback)

Critical Chain explores the basis for delays that have historically plagued the delivery of
projects using traditional management methods. The basis for examination in the book is
the success of Skunkworks and their ability to deliver new, ground-breaking technology
in less than a year. This book focuses on U-2 instead of the P-80 shooting star, but the
ideas are the same. We can do better, and Skunkworks shows us a repeatable method to
emulate.

F.I.R.E - How Fast, Inexpensive, Restrained, and Elegant Methods Ignite Innovation

Author: Dan Ward

Publisher: HarperBusiness; 1 edition (April 29, 2014)

Publication Date: April 29, 2014

ASIN: B00FJ3A6FC

F.I.R.E is a wonderful book that captures many ideas, stories, and principles. It's one of
the books that shows how throughout history, from WWII to the turn of the 21st century
there are standout projects and methods that emphasize the reduction of scope. This
book focuses on all aspects of systems development, from Portfolio Management to
Program and Project Management.

One of the crucial examples of this book are the Faster, Better, Cheaper (FBC) initiatives
that we discuss in this lesson. It's incredible to learn their details through Dan Ward's fun,
engaging style. Filled with amazing Sci-Fi and unbelievable real-life examples - it's a must
read (just not required for this course).

1.3 Evolution of Agile

Knowledge Check Este contenido es calificable
 1.3.0 Prep for Evolution of Agile

Many people believe that Agile is a new approach born of software that is taking the
world by storm quickly, out of nowhere. However, like many overnight successes the real
work to develop Agile goes even farther back than you might expect!

Agile's roots are as deep as Traditional Management, with the origins strongly rooted in
WWII. However, modern history of management offers some great stories and insights
into why Agile is culminating in today's fast-paced, information-driven world.

So, Why Agile? The answers are its origins, and you probably know a few of these
techniques already.

Get ready to open yourself up to the idea that Agile is not new, it's society's pressure for
performance forcing us to take a new look at how we govern our work and ourselves!

1.3.1 Evolution of Agile Video

- Hi, and welcome to the Evolution of Agile.

Today we're gonna be talking about,

Spiraling Away from Waterfall, A Total Quality Revolution.

So, we're gonna start with Total Quality Management,

because the heart of agile today, really is in TQM.

And of course TQM was developed by Edward Deming.

He is the father of TQM,

he developed it for Japan

and then brought it here to the US

and in the end we still follow his principles today

as we continue to evolve our purchase.

What he said was that,

improving quality actually decreases costs.

Decreasing costs is something that was

a huge emphasis in the 1950s

with the management revolution of the time

but, what a lot of people thought was that

quality was in competition with cost.

What Deming proved is that it wasn't.

He said that every system

must be in a state of continuous improvement

in order to succeed,

and that an organization can survive

based upon the pride of the work

that was being done by its people.

That a knowledge worker, was especially different

from other types of workers

because they knew more than their boss did

about the work they were doing.

And he of course emphasized what has become infamous today

as the PDCA cycle, a Plan-Do-Check-Act.

So when you think about Plan-Do-Check-Act,

this is an approach of continuous improvement.

It's something that is applied in lean,

it's applied in agile

and it's a great approach to understanding something,

a system that you can't necessarily

easily model from the outside.

You have to test it.

And the proof that he actually was successful

with his approach is,

it was back in the 1980s where,

he actually turned around Ford.

Ford was losing money hand over fist.

And in 1986, he actually took them

from billion dollars of losses

to their first profits in years.

And they've been a great company ever since.

Now let's talk about the Toyota Production System.

The Toyota Production System is actually an evolution of TQM

which started in Japan.

And it was designed and architected by Taichii Ohno.

And of course he learned a lot of the techniques

by observing systems both in Japan and here in the US

and identifying areas to eliminate waste.

And so, the waste that Taichii Ohno really focused on

were seven types of waste.

He talked about movement,

the movement of materials between two locations.

He talked about inventory, the build-up of inventory

which cost money for having to store it and stack it,

the motion that it takes to actually complete a task

and wanting to limit that

so that he can be as efficient as possible.

The waiting on work, the waiting for work to be done

from an upstream process to a downstream process

was a huge source of issue and a huge source of waste

followed by overproduction, producing too much of a thing,

over-processing, working on something too much

and then creating defects

which of course would have to be fixed later.

So in order to identify where these wastes existed,

he used a system that we call Kanban.

And Kanban actually just means billboard in Japanese

and the way that it works is that,

you simply use a board in order to identify

when a process needs more material or needs more work.

It's a pull system for getting work done.

And so the simplest form, is to have a to-do column,

a doing column and a done column.

So, when work is no longer existing in the doing column,

you can pull from the to-do column

and once work is done in the doing column,

it moves over to done.

This allows for a system to know

when something upstream or downstream is ready for work.

And then finally, continuous improvement and testing

was a key part of the lean movement.

It involved developing key performance indicators

which had a time bound performance metric.

So if you ever use KPIs in your workplace,

you can thank Taichii Ohno for that.

Proof that this works

is the fact that Toyota was actually and has been

a top three manufacturer for years.

Ever since the introduction of the Toyota Production System.

And their employee satisfaction rating is 70%

which is more than double what we see here in the US today.

So, not just being a top three manufacturer

but also having really happy employees

was great outcomes from the system.

Then let's talk about the Theory of Constraints.

This is the last of the lean movements

that had a great impact on agile today.

This was a system that was developed by Eli Goldratt,

who is the father of the Theory of Constraints

and of course his famous book

that almost MBA has to read, is The Goal

where they talk about how a system is going to be managed

usually by just one process,

or if it's on a team, just one person on a team.

And that person or that one process becomes a bottleneck.

So, when we think about bottlenecks

the way that that works,

is kind of like the diagram you see up here

where you have one process,

in this case Process C,

is going slower than all the other processes in the system.

As a result, material is being built up behind Process C.

And so, whenever you see a system like this,

you need to address it using the Five Focusing Steps

of continuous on-going improvement.

So, the process of continuous on-going improvement

starts with first, you've gotta identify the constraint.

Then, you exploit it

and the way you exploit it is that,

you identify the best way to raise it you can

without making any changes to the system itself.

Then, you subordinate all other processes,

you only run A and B when C needs more material.

Finally, four, you try to eliminate the constraint

which means improving the speed of C.

And then five,

you prevent inertia from becoming the constraint,

which is, you don't wanna stop there

because eventually the bottleneck will move.

There will always be a part of your system

that is the slowest moving.

Proof that this works is actually

this was a system that was used intently

with the clean up of the BP oil spill.

And as a result of implementing TOC

they believe that they were able to save over $200 million.
It's quite a lot of money

and they used this in order to orchestrate and plan

and deploy over 10,000 boats

cleaning up The Gulf of Mexico.

Now let's talk about The Waterfall Mistake.

The Waterfall Mistake is a history of

having misinterpreted a model from the 1976 paper by Royce

which identifies a way of producing IT systems.

And what it says is that

all work can be modeled as being linear,

where you start with requirements

and then you go to design,

then implementation, testing and maintenance.

However, the issue with this approach is that

there is no opportunity to go back.

As a result, by the 1980s we saw that

Waterfall was a predominant model.

It had been picked up by the DoD

and it resulted in,

what we call today the Ninety-Ninety rule

according to Tom Cargill from Bell Labs.

And the Ninety-Ninety rule said,

that the first 90% of development

accounts for the first 90% of time.

And the last 10% of coding in development

accounts for the other 90% of development time.

Essentially, every project was taking at least 1.8 X

times the original development time estimate.

What we saw was that only 10% of projects

during the 1970s and 80s were actually succeeding

in meeting their goals.

And this is because of the fact that,

the Waterfall model was never intended,

even in its original design, to be used this way.

In fact, if you take a look at what Royce proposed

as being the correct method,

it looks a lot more like an iterative approach.

Much more complicated,

but if you look to the right side of this diagram

you'll actually see that it shows a feedback loop

from testing to development to requirements,

just like what we talked about with lean.

So, perhaps the most costly mistake in the world

was the adoption of The Waterfall Approach

that continues to reverberate today.

But you'll hear lean and agile

so you'll be able to do it better.

Now let's talk about Spiraling to Scrum.

Spiraling to Scrum starts with RAD.

RAD is the Rapid Application Development approach,

that was popular in the 1970s to 1980s.

Here as an alternative to The Waterfall Approach.

RAD believed that you could start with upfront requirements,

but then you would have to iterate

in terms of the design and testing it with users.

And as this iterative approach would go on,

you'd finally find a workable solution and then cut over.

So as a basic alternative, slightly iterative

like what we were learning from in lean.

Then with Dynamic System Design Models or Design Method,

this approach was developed in the 1980s.

It became very popular because,

it didn't just believe

that you should iterate on design and development,

that you should also iterate on requirements.

And so, it had a feedback loop for requirements as well.

But then finally, all these iterative approaches

coalesced into Extreme Programming.

And so Extreme Programming actually believed

that you should have feedback loops at every level,

be it from pair programming to unit testing

to stand up meetings, acceptance testing et cetera

all the way up to the release.

By having this continuous feedback loop

you could learn if what you were doing was right

using a test driven approach.

So, the key tenets here was that

at first there was Consolidated Up-Front Planning

and that eventually went away

in terms of XP moving into more of an iterative approach.

The approach would always be iterative

in design and development.

There was a use of Timeboxes

in order to get these feedback loops.

They used actually User Stories in XP

because they wanted people to explain

in terms of the business requirement

and then finally Test-Driven Development

to get that learning and development.

If we look at the results today,

in terms of what we are achieving with agile,

according to the 2013 Cross-Industry Study,

we see that agile is not just more successful

but extremely more successful by 15% more.

Traditional is still failing half the time

but in agile you see a success rate of 64% or better.

In terms of challenge projects,

traditional has about 1/3 of their projects are challenged,

with agile, it's less.

And then finally, with traditional

you see a much higher failure rate.

In fact over two times as many projects are failing.

So, these approaches were very successful

addressing a lot of the issues,

but we are continuing to get better

in terms of what agile can do.

I hope that this evolution of agile was useful for you

and that now that you understand the history,

you can explain a little better to others

when they ask you where does this all come from.
Hopefully you are enjoying the course so far,

I look forward to seeing you next time.

////

Edward Deming
Image: https://i.pinimg.com/736x/98/bc/1f/98bc1f7c7ce266dd7e2fe796be001285--
teacher-w-edwards-deming.jpg

PDCA Cycle: http://texample.net/tikz/examples/pdca-cycle/

Taichii Ohno: https://c1.staticflickr.com/9/8110/8472007819_485415e875_b.jpg

Kanban Board: https://www.flickr.com/photos/kanban_tool/15817131058

Eli Goldratt Image: https://en.wikipedia.org/wiki/Eliyahu_M._Goldratt

Bottleneck Image: https://commons.wikimedia.org/wiki/File:Jam-before-Bottleneck.png

Five Focusing Steps (e.g. POOGI): https://www.tocinstitute.org/five-focusing-steps.htm

1.3.2 Evolution of Agile Summary Points

TQM: The story of Agile as we know it today begins with Total Quality Management or "TQM,"
developed by Edward Deming. This was also the origin of the Lean movement that pushed for
continuous improvement and appreciation of workers. The core tenants of TQM include:
 Improving Quality Decreases Costs - lowers costly defects, customer support, and recalls
 Continuous Improvement - for the systems and people in the systems
 Pride of Workmanship - the primary driver of knowledge workers and source of quality is
joy in good work
 Plan-Do-Check-Act (PDCA) - this cycle allows for testing a complex system that can't be
modeled easily

One of the famous beliefs was that the Knowledge Worker is different from the Manual Laborer,
because the Knowledge Worker knows more about the work than their boss does.

Proof that TQM Works: Edward Deming turned around Ford Motor Company in 1986 from billions
of dollars in losses to its first profits in years using the TQM approach.
TPS: The Toyota Production System (TPS) was developed by Taichii Ohno that was the first true
Lean system. Focus was on reducing waste, based on lessons from TQM. The focus was on
reducing the wastes in a system:
 Eliminate 7 Wastes - Movement, Inventory, Motion, Waiting, Overproduction, Over-
Processing, Defects
 Small Batches - exposes errors and minimizes waste in the system, by using a "Pull System"
using Kanban
 Kanban - means "billboard" and it is a system to tell upstream processes to send
work downstream
 Kanban boards have at least three columns: To-Do, Doing, Done
 Kanban boards limit work-in-progress (WIP) by limiting the number of items in the
"Doing" column and only pulling in more work once the current work in progress is
done
 Continuous Improvement with Key Performance Indicators (KPIs)

Proof that TPS Works: Toyota is a top three (3) manufacturer of cars, with a 70% employee
satisfaction rating - that's more than double the satisfaction rating of employees in the USA,
which stands at 30%.

TOC: The Theory of Constraints (TOC) was developed by Eli Goldratt. It emphasizes that the
system is always governed by a bottleneck and there is a competition between local optimization
and system (global) optimization. The theory states that Throughput of the system should be the
focus of managers, not "Cost Centers" that drive local optimization. His ideas are captured in the
famous book The Goal which is read widely and cited as critical to the revolution of management
in the 1980s.
 Throughput drives cost and revenue
 Throughput is constrained by one process in any system, the constraint
 To improve the System Throughput one must focus on optimizing around the Constraint
 To do this, use the 5 Focusing Steps for the Process of Ongoing Improvement (POOGI)
1. Identify the Constraint - figure out which process is limiting
2. Exploit the Constraint - try to optimize with existing capacity
3. Subordinate everything to the Constraint - reduce processes to match capacity of the
constraint
4. Elevate the Constraint - add capacity to the constraint process
5. Prevent inertia from becoming the Constraint - be vigilant and check if there's a new
constraint!

Proof that TOC Works: TOC was used by the BP Oil Spill Cleanup initiative to save over $200M and
rapidly deploy 10,000 boats after the Gulf Oil Spill to skim and clean oil from the surface.

The Waterfall Mistake

 Waterfall was never intended to be linear in its design
 Royce, who proposed waterfall as a simple starting point for modeling work, stated all
projects should iterate
 Typical waterfall design:
  Requirements - product requirements as output
 Design - architecture as output
 Implementation - system is produced
 Verification - testing is conducted to fix the system where needed
 Maintenance - support for product in use
 The actual design had at least one iteration going back from verification to implementation
to design

Only 10% of software projects were successful in the 1970s, and using waterfall we still see that
half of those projects fail today.

By 1980s the Waterfall Method was being used by DoD (and continued until 1996), which
resulted in the Ninety-Ninety Rule:
"The first 90 percent of coding accounts for the first 90 percent of development time,
The last 10 percent of coding accounts for the other 90 percent of development time" - Tom
Cargill, Bell Labs

Important reference: Waterfall Model Probably the Most Costly Mistake in the World:
http://valueatwork.se/waterfall-model-probably-the-most-costly-mistake-in-the-world/?lang=en

The original paper from Winston Royce on Waterfall Methodology:

Winston W. Royce (1970). "Managing the Development of Large Software Systems" in:
Technical Papers of Western Electronic Show and Convention (WesCon) August 25–28, 1970, Los
Angeles, USA
Iterative Methods
 Rapid Application Development (RAD) - popular during 1970s and 1980s
 Upfront requirements
 Iterate on Design and Development
 System Cutover
 Dynamic System Design Methodology (DSDM) - popular in 1980s and 1990s
 Introduced iteration of requirements (foundation)
 Included going back to design and development as well
 Still had a "Feasibility Stage" upfront
 Extreme Programming (XP) - popular from 1990s to 2000s
 Iterative across all levels (Pair programming, unit testing, standups, testing, and
planning)
 Required heavy iterations and redundancy in resources to manage risk
 Continues to be used today

Key Tenants of Iterative:

 Consolidated Up-Front Planning - RAD and DSDM did not refine, but XP does
 Iterate on Designs - design, build, test, refine
 Timeboxes - to ensure continuous, on-time delivery
 User Stories - to describe requirements (introduced as standards in XP)
  Test-Driven Development (TDD) - enables exploration of designs and refinement before
release

2013 Cross-industry Study by Ambysoft shows the following (see the details of the survey
here http://www.ambysoft.com/surveys/success2013.html):

 Agile is more successful than Traditional

 Agile is less challenged than Traditional

 Agile fails less than half as often as Traditional

Project Measure Agile Traditional

Successful 64% 49%

Challenged 28% 33%

Failing 8% 18%

Note: This table is reproduced from the summary graphics of Ambysoft's survey found
here: https://clearcode.cc/blog/agile-vs-waterfall-method/

Españ ol

TQM
la historia de Agile como la conocemos hoy comienza con Total Quality Management o "TQM",
desarrollada por Edward Deming. Este fue también el origen del movimiento Lean que impulsó la
mejora continua y la apreciación de los trabajadores. Los inquilinos principales de TQM incluyen:
 Mejorar la calidad reduce los costos: reduce los defectos costosos, la atención al cliente y
los retiros
 Mejora continua - para los sistemas y personas en los sistemas
 Orgullo de mano de obra: el principal impulsor de los trabajadores del conocimiento y la
fuente de calidad es la alegría en el buen trabajo
 Planificar-Hacer-Verificar-Actuar (PDCA): este ciclo permite probar un sistema complejo
que no se puede modelar fácilmente

Una de las creencias famosas era que el Trabajador del conocimiento es diferente del Trabajador
manual, porque el Trabajador del conocimiento sabe más sobre el trabajo que su jefe.

Prueba de que TQM funciona: Edward Deming convirtió a Ford Motor Company en 1986 de miles
de millones de dólares en pérdidas a sus primeras ganancias en años utilizando el enfoque TQM.

TPS
El sistema de producción de Toyota (TPS) fue desarrollado por Taichii Ohno, que fue el primer
sistema Lean verdadero. El enfoque se centró en reducir el desperdicio, en base a las lecciones de
TQM. El foco estaba en reducir los desechos en un sistema:
  Elimine 7 desechos: movimiento, inventario, movimiento, espera, sobreproducción, sobre
procesamiento, defectos
 Lotes pequeños: expone los errores y minimiza el desperdicio en el sistema, utilizando un
"Sistema de extracción" utilizando Kanban
 Kanban significa "cartelera" y es un sistema para indicar a los procesos anteriores que
envíen el trabajo hacia abajo
 Los tableros Kanban tienen al menos tres columnas: para hacer, hacer, hacer
 Los tableros Kanban limitan el trabajo en progreso (WIP) al limitar el número de
elementos en la columna "Haciendo" y solo obtener más trabajo una vez que se
realiza el trabajo en curso actual
 Mejora continua con indicadores clave de rendimiento (KPI)

Prueba de que TPS funciona: Toyota es uno de los tres (3) mayores fabricantes de automóviles,
con un 70% de satisfacción de los empleados, lo que equivale a más del doble que los empleados
en los EE. UU., Que es del 30%.

TOC
La teoría de las restricciones (TOC) fue desarrollada por Eli Goldratt. Enfatiza que el sistema
siempre está gobernado por un cuello de botella y existe una competencia entre la optimización
local y la optimización del sistema (global). La teoría establece que el rendimiento del sistema
debe ser el foco de los gerentes, no los "centros de costos" que impulsan la optimización
local. Sus ideas están plasmadas en el famoso libro The Goal, que se lee ampliamente y se cita
como crítico para la revolución de la administración en los años ochenta.
 El rendimiento impulsa los costos y los ingresos
 El rendimiento está restringido por un proceso en cualquier sistema, la restricción
 Para mejorar el rendimiento del sistema, uno debe centrarse en optimizar alrededor de la
restricción
 Para hacer esto, use los 5 pasos de enfoque para el proceso de mejora continua (POOGI)
1. Identifique la restricción - determine qué proceso es limitante
2. Explote la restricción - intente optimizar con la capacidad existente
3. Subordine todo a la restricción : reduzca los procesos para que coincidan con la
capacidad de la restricción
4. Elevar la restricción : agregar capacidad al proceso de restricción
5. Evite que la inercia se convierta en la restricción - esté atento y verifique si hay una
nueva restricción.

Prueba de que TOC funciona: TOC fue utilizado por la iniciativa de limpieza de derrames de
petróleo de BP para ahorrar más de $ 200 millones y desplegar rápidamente 10,000 botes
después del derrame de petróleo del Golfo para remover y limpiar el petróleo de la superficie.

El error de la cascada
 La cascada nunca tuvo la intención de ser lineal en su diseño.
  Royce, quien propuso la cascada como un punto de partida simple para el trabajo de
modelado, declaró que todos los proyectos deberían iterar
 Diseño típico de cascada:
 Requisitos - requisitos del producto como salida
 Diseño - arquitectura como salida
 Implementación - se produce el sistema
 Verificación: se realizan pruebas para arreglar el sistema donde sea necesario
 Mantenimiento - soporte para producto en uso
 El diseño real tenía al menos una iteración que iba desde la verificación hasta la
implementación y el diseño.

Solo el 10% de los proyectos de software tuvieron éxito en la década de 1970, y al usar Waterfall
aún vemos que la mitad de esos proyectos fracasan hoy.

Para la década de 1980, el método de cascada estaba siendo utilizado por el DoD (y continuó
hasta 1996), lo que dio lugar a la regla de los noventa y noventa:
"El primer 90 por ciento de la codificación representa el primer 90 por ciento del tiempo de
desarrollo.
El último 10 por ciento de la codificación representa el otro 90 por ciento del tiempo de
desarrollo" - Tom Cargill, Bell Labs

Referencia importante: Modelo de cascada Probablemente el error más costoso del mundo:
http://valueatwork.se/waterfall-model-probably-the-most-costly-mistake-in-the-world/?lang=en

El artículo original de Winston Royce sobre Metodología de la cascada:

Winston W. Royce (1970). "Administración del desarrollo de grandes sistemas de software" en:
Documentos técnicos de Western Electronic Show and Convention (WesCon) del 25 al 28 de
agosto de 1970, Los Ángeles, EE. UU.

Métodos iterativos
 Desarrollo rápido de aplicaciones (RAD): popular durante los años 70 y 80
 Requisitos iníciales
 Iterar en Diseño y Desarrollo
 Corte del sistema
 Metodología de diseño de sistemas dinámicos (DSDM): popular en los años 80 y 90
 Se introdujo la iteración de requisitos (fundación)
 Incluido volver al diseño y desarrollo también.
 Todavía tenía una "etapa de viabilidad" por adelantado
 Programación extrema (XP): popular entre los años 1990 y 2000
 Iterativo en todos los niveles (programación de pares, pruebas de unidad, standups,
pruebas y planificación)
 Requerimientos de iteraciones pesadas y redundancia en los recursos para gestionar
el riesgo.
 Se sigue utilizando hoy.
Principales inquilinos de la iterativa:
 Planificación anticipada consolidada: RAD y DSDM no se refinaron, pero XP sí lo hace
 Iterar en diseños: diseñar, construir, probar, refinar
 Timeboxes: para garantizar una entrega continua y puntual
 Historias de usuarios: para describir los requisitos (introducidos como estándares en XP)
 Test-Driven Development (TDD): permite la exploración de diseños y refinamientos antes
del lanzamiento

El estudio de 2013 de múltiples sectores realizado por Ambysoft muestra lo siguiente (consulte los
detalles de la encuesta aquí http://www.ambysoft.com/surveys/success2013.html) :

 Ágil es más exitoso que el tradicional.

 Agile es menos desafiante que el tradicional.

 Ágil falla menos de la mitad de las veces que el tradicional

Medida del proyecto Ágil Tradicional

Exitoso 64% 49%

Desafiado 28% 33%

Defecto 8% 18%

1.3.3 Evolution of Agile Knowledge Check

Pregunta 1
1/1 punto (calificable)

La historia de Agile es una revolución de calidad total. ¿Cuáles son las

tres revoluciones de gestión que llevaron a la evolución de Agile?

Cascada, espiral y iterativa.

Ciclo PDCA, Kanban y Teoría de las Restricciones

Gestión de calidad total, sistema de producción de Toyota y teoría

de restricciones correcto

Desarrollo rápido de aplicaciones, Metodología de desarrollo

dinámico de sistemas y Programación extrema
Pregunta 2
______________ más tarde se convirtió en el corazón del movimiento Lean
y trajo una de las herramientas Agile más importantes, el tablero
Kanban, que utilizamos hoy.

Gestión de calidad total

Sistema de producción Toyota correcto

Teoría de las Restricciones

Desarrollo rápido de aplicaciones

Pregunta 3
Según la conferencia, ¿cuáles son los inquilinos clave del desarrollo
iterativo (elija 4 de 6)?

Planificación anticipada consolidada

Desarrollo iterativo

Documentación frecuente

Enfatizado en la entrega a tiempo

Desarrollo guiado por pruebas

Especificaciones técnicas enfatizadas

1.3.4 Evolution of Agile References

Cada uno de estos sitios ofrece información adicional sobre los métodos mencionados en esta
clase:

 Programación extrema (XP): https://en.wikipedia.org/wiki/Extreme_programming

 Desarrollo rápido de aplicaciones

(RAD): https://en.wikipedia.org/wiki/Rapid_application_development
 Metodología de desarrollo de sistemas dinámicos
(DSDM): https://en.wikipedia.org/wiki/Dynamic_systems_development_method

La base para el desempeño comparativo de Agile y Traditional proviene de estas fuentes:

 http://www.se-rwth.de/~rumpe/publications/Quantitative-Survey-on-Extreme-Programming-
Projects.pdf

 http://www.drdobbs.com/architecture-and-design/2010-it-project-success-rates/226500046

 http://clearcode.cc/2014/12/agile-vs-waterfall-method/

 http://www.ambysoft.com/surveys/success2007.html

Referencias para la "Revolución Lean" en la gestión de la Gestión de la Calidad Total (TQM), el

Sistema de Producción Toyota (TPS) y la Teoría de las Restricciones (TOC):

 https://en.wikipedia.org/wiki/Lean_manufacturing

 http://www.leanproduction.com/theory-of-constraints.html

 https://en.wikipedia.org/wiki/Toyota_Production_System

 http://www.industryweek.com/companies-amp-executives/theory-constraints-tapped-
accelerate-bps-gulf-mexico-cleanup

 http://www.manufacturingglobal.com/top10/38/Top-10:-Lean-manufacturing-companies-
in-the-world

 http://www.forwardfocusinc.com/jumpstart-change/the-importance-of-empowering-
employees/

 https://www.bloomberg.com/news/articles/2013-09-19/forget-employee-engagement-u-
dot-s-dot-companies-need-passionate-workers

 http://www.skymark.com/resources/leaders/deming.asp

 https://en.wikipedia.org/wiki/W._Edwards_Deming

 Womack, James P .; Daniel T. Jones (2003). Pensamiento magro Prensa Libre. pag. 352.

1.4 Netflix Case Study

 1.4.0 Prep for Netflix Case Study

The Netflix Case Study is an example of how speed, innovation, and leadership all drove a new
form of controlling success at scale.

Netflix was smart enough to know that there was no guarantee in the new world of online
streaming video when it came to infrastructure or applications. The needs were changing fast and
the demand was growing faster.

As a result, Netflix underwent a dramatic transformation to become a new beacon for the Cloud-
Based Software-as-a-Service (SaaS) company. The following case study dives into their
transformation to become truly democratized and Agile in their approach to engineering software
at scale.

Even today, most companies are still striving to achieve what Netflix accomplished almost have a
decade ago.

Enjoy the lesson !

1.4.1 Netflix Case Study Video

Welcome to the commercial case study.

We're going to show you how Netflix wins by being agile at scale.

First, Netflix was not always a video streaming company.

And in fact, in a keynote speech by its chief architect Adrian Cockcroft, Adrian talks about
the challenges of moving from a company that delivers movies, delivers DVD's in the
mail, to one that was ctually delivering movies as a service online.

And in this discussion he talked about the competition

between going with a volume-based approach

or a velocity approach and in the end

what he said was speed wins.

In order to make this transition,

he identified four critical items

that must be applied within the Netflix culture

in order to achieve this new foundational paradigm.

And this is something that people

are trying to do still today.

The first was a cultural of innovation.

This is the idea that as opportunities evolve,

as new platforms were developed,

that Netflix should be able to take advantage of them

to be able to jump into those opportunities

to stay competitive.

Second, was about data analytics.

This is the idea that you need to be able to,

not just observe and orient, but to be able to understand

what's going on within your system

and then be able to make choices

based on real data as a test driven approach.

As a result decisions needed to be decentralized.

The system that they were developing was too complicated,

and you needed to be able to very quickly assign resources

to the parts of the system as needed.

With that quick realignment of resources,

Netflix could be come very scalable

and meet the demands of a very rapidly growing user base.

And finally this also required

a culture of responsibility and freedom.

You are free to take action, you are free to make changes

but in the end as a coder, if you built something

and it had a bug, they were gonna wake you up

at two in the morning and have you fix it.

So this idea of an agile self-service mechanism

for deploying new code changes was critical.

You can learn about this and all the approaches

that they implemented, which were years ahead

of their time, because we're still today

in many organizations, trying to get to

what the Netflix paradigm achieved almost five years ago.

By going to the link that we're providing to you here

on the course page, and taking a look at this on YouTube.

It's a great speech and I hope

you enjoy it and learn a lot.

Thanks a lot, and look forward to seeing you next time.

All images, references, and key pieces of information for this lecture are found here:

KEYNOTE: Velocity and Volume (or Speed Wins) by Adrian Cockcroft

https://www.youtube.com/watch?v=wyWI3gLpB8o

GET THE SLIDES!

Link to the slides that Adrian Cockroft used at Flowcon:

http://flowcon.org/dl/flowcon-sanfran-2013/slides/
AdrianCockcroft_VelocityAndVolumeorSpeedWins.pdf
 1.4.2 Netflix Case Study Summary Points

Netflix Case Study

Netflix was not always a streaming company. It moved from mail-based delivery of movies to one
of streaming videos online. In order to achieve the foundational paradigm that would deliver
seamless video streaming. These ideas are still aspirational for many companies today, trying to
catchup to this modern model of management:

 Culture of Innovation - ability to respond to opportunities as they presented themselves

 Data Analytics - this allows for comparing changes and determining if it works through real
data (truth)

 Decentralized Decisions - the empowerment of employees to procure resources on-

demand as needed

 Agile and Self-Service Deployment - the ability for developers to deploy but also be
responsible for their code

This led to what was called a culture of "Freedom and Responsibility." By empowering employees
and holding them responsible, and through incredible innovations in cloud and deployment
technologies, Netflix was able to achieve unheard of responsiveness to customers. As a result,
Netflix continues to be a market driver and the standard in movie streaming experiences.

What all of these ideas have at their core is an understanding of one core belief: Speed Wins!

When comparing the efficiency of managing the volume of material and delivery of content, or
the velocity of delivering changes to those systems at scale - Speed always wins because at scale
you can't expect efficient, perfect solutions. Things will always break at scale and you'll need to
respond quickly to fix and correct those issues in your system. Therefore, all best efforts for
perfect designs up-front and efficiency models in delivery lose, and only speed (for
responsiveness to customers and infrastructure issues) can drive sustainability into the system.

You can learn the details of this concept here:

KEYNOTE: Velocity and Volume (or Speed Wins) by Adrian Cockcroft

https://www.youtube.com/watch?v=wyWI3gLpB8o

1.4.3 Netflix Case Study Knowledge Check

Question 1
1/1 punto (calificable)
What is the most important lesson learned from Netflix case study?

Speed wins correcto

Innovation wins

Efficiency wins

Predictability wins

Question 2
1/1 punto (calificable)

In the Netflix case study, Adrian Cockroft points out four things required to turn Netflix from a
manufacturing company into a web-centric large-scale business. What are these four important
aspects (choose 4 of 6)?

Large team and clear defined roles

Culture of innovation

Data and analytics

Well-defined requirements

Decentralized decisions

Agile and self-service deploy

correcto

1.5 18F Case Study

Knowledge Check Este contenido es calificable
https://courses.edx.org/courses/course-
v1:USMx+ENCE607.1x+3T2018/
courseware/
eacf1c65220b48bdaa22de2734fc2bf5/68d1f
7dbfe0e4a8b87cacd36a3b12200/?
child=first

1.5.0 Prep for 18F Case Study

The 18F Case Study is a shining example of how Agile can drag you from the dredges totally stuck
Waterfall process.

Imagine spending a decade in a paper design process. Now imagine the system stuck in design is
one that will enable better case management for children in need of social services.

This example of government agencies adopting Agile to benefit society shows how even the
government is seeing the need to ditch the documents, and start delivering with Agile

1.5.1 18F Case Study Video

1.5.2 18F Case Study Summary Points

 1.5.3 18F Case Study Knowledge Check

1.6 Week 1 Takeaways & Feedback

Week 1 Takeaways Cloud

Week 1 Feedback Survey

Tailored Lesson Opportunity

Week 2: Who Uses Agile?

2.0 Introduction to Week 2

1.

2.0.0 Goals and Objectives of Week 2

2.

2.0.1 Week 2 Introduction Video

 2.1 Simple PM Methods
Knowledge Check Este contenido es calificable

2.1.0 Prep for Simple PM Methods

2.1.1 Simple PM Methods Video

2.1.2 Simple PM Methods Summary Points

2.1.3 Simple PM Methods Knowledge Check

2.1.4 Simple PM Methods Reference

2.2 Approaching the Triple Cost Constraint

Knowledge Check Este contenido es calificable

2.2.0 Prep for Approaching the Triple Cost Constraint

 2.2.1 Approaching the Triple Cost Constraint Video

2.2.2 Approaching the Triple Cost Constraint Summary Points

2.2.3 Approaching the Triple Cost Constraint Knowledge Checks

2.2.4 Approaching the Triple Cost Constraint References

2.3 Comparing Methods Across Industries

Knowledge Check Este contenido es calificable

2.3.0 Prep for Comparing Methods Across Industries

2.3.1 Comparing Methods Across Industries Video

2.3.2 Comparing Methods Across Industries Summary Points

 2.3.3 Comparing Methods Across Industries Knowledge Check

2.3.4 Comparing Industry Methods References

2.4 Comparing Methods of Customer Management

Knowledge Check Este contenido es calificable

2.4.0 Prep for Comparing Methods of Customer Management

2.4.1 Comparing Methods of Customer Management Video

2.4.2 Comparing Methods of Customer Management Summary Points

2.4.3 Comparing Methods of Customer Management Knowledge Check

 2.4.4 Comparing Methods of Customer Management References

2.5 Comparing Methods of Engineering Management

Knowledge Check Este contenido es calificable

2.5.0 Comparing Methods of Engineering Management

2.5.1 Comparing Methods of Engineering Management Video

2.5.2 Comparing Methods of Engineering Summary Points

2.5.3 Comparing Methods of Engineering Management Knowledge Check

2.5.4 Comparing Methods of Engineering References

2.6 Week 2 Takeaways & Feedback

Week 2 Takeaways Cloud

 Week 2 Feedback Survey

Tailored Lesson Opportunity Reminder

Week 3: How to Scrum And Be Agile?

3.0 Introduction to How to Scrum and Be Agile?

3.

3.0.0 Goals and Objectives of Week 3

4.

3.0.1 Introduction to Week 3 Video

2.
3.1 Scrum Team Formation
Knowledge Check Este contenido es calificable

1.

3.1.0 Prep for Scrum Team Formation

 2.

3.1.1 Scrum Team Formation Video

3.

3.1.2 Scrum Team Formation Summary Points

4.

3.1.3 Scrum Team Formation Knowledge Check

5.

3.1.4 Scrum Team Formation References

3.
3.2 Three-Part User Story
Knowledge Check Este contenido es calificable

1.

3.2.0 Prep for Three Part User Story

2.

3.2.1 Three-Part User Story Video

 3.

3.2.2 Three-Part User Story Summary Points

4.

3.2.3 Three-Part User Story Knowledge Check

5.

3.2.4 Three-Part User Story References

4.
3.3 Sprint Planning
Knowledge Check Este contenido es calificable

1.

3.3.0 Prep for Sprint Planning

2.

3.3.1 Sprint Planning Video

3.
 3.3.2 Sprint Planning Summary Points

4.

3.3.3 Sprint Planning Knowledge Check

5.

3.3.4 Spring Planning References

5.
3.4 Sprint Development
Knowledge Check Este contenido es calificable

1.

3.4.0 Prep for Sprint Development

2.

3.4.1 Sprint Development Video

3.

3.4.2 Sprint Development Summary Points

 4.

3.4.3 Sprint Development Knowledge Check

5.

3.4.4 Sprint Development References

6.
3.5 Sprint Retro & Review
Knowledge Check Este contenido es calificable

1.

3.5.0 Prep for Sprint Retro & Review

2.

3.5.1 Sprint Retro & Review Video

3.

3.5.2 Sprint Retro & Review Summary Points

4.

3.5.3 Sprint Retro & Review Knowledge Check

 5.

3.5.4 Sprint Retro & Review References

7.
3.6 Week 3 Takeaways & Feedback

1.

Week 3 Takeaways Cloud

2.

Week 3 Feedback Survey

3.

Tailored Lesson Opportunity Reminder

3.
Week 4: What Scrum Framework Fits Best?
1.
4.0 Introduction to What Scrum Framework Fits Best?

1.

4.0.0 Goals and Objectives of Week 4

 2.

4.0.1 Introduction to Week 4 Video

2.
4.1 Scrum in the World of Agile
Knowledge Check Este contenido es calificable

1.

4.1.0 Prep for Scrim in the World of Agile

2.

4.1.1 Scrum in the World of Agile Video

3.

4.1.2 Scrum in the World of Agile Summary Points

4.

4.1.3 Scrum in the World of Agile Knowledge Check

5.

4.1.4 Scrum in the World of Agile References

3.
4.2 Exploring the Scaled Agile Framework (SAFe)
Knowledge Check Este contenido es calificable

1.

4.2.0 Prep for Exploring the Scaled Agile Framework

2.

4.2.1 Exploring the Scaled Agile Framework (SAFe) Video

3.

4.2.2 Exploring the Scaled Agile Framework (SAFe) Summary Porints

4.

4.2.3 Exploring the Scaled Agile Framework (SAFe) Knowledge Check

5.

4.2.4 Exploring the Scaled Agile Framework (SAFe) References

4.
 4.3 Exploring Disciplined Agile Delivery (DAD)
Knowledge Check Este contenido es calificable

1.

4.3.0 Prep for Exploring Disciplined Agile Delivery (DAD)

2.

4.3.1 Exploring Disciplined Agile Delivery (DAD) Video

3.

4.3.2 Exploring Disciplined Agile Delivery (DAD) Summary Points

4.

4.3.3 Exploring Disciplined Agile Delivery (DAD) Knowledge Check

5.

4.3.4 Exploring Disciplined Agile Delivery (DAD) References

5.
4.4 Exploring Large Scale Scrum (LeSS)
Knowledge Check Este contenido es calificable
 1.

4.4.0 Prep for Exploring Large Scale Scrum (LeSS)

2.

4.4.1 Exploring the Large Scale Scrum (LeSS) Framework Video

3.

4.4.2 Exploring Large Sale Scrum (LeSS) Summary Points

4.

4.4.3 Exploring Large-Scale Scrum (LeSS) Knowledge Check

5.

4.4.4 Exploring Large-Scale Scrum (LeSS) References

6.
4.5 Pitfalls and Benefits of Agile at Scale
Knowledge Check Este contenido es calificable

1.

4.5.0 Prep for Pitfalls for Agile at Scale

 2.

4.5.1 Pitfalls and Benefits of Agile at Scale Video

3.

4.5.2 Pitfalls and Benefits of Agile at Scale Summary

4.

4.5.3 Pitfalls and Benefits of Agile Knowledge Check

5.

4.5.4 Pitfalls and Benefits of Agile References

7.
4.6 Week 4 Takeaways & Feedback

1.

Week 4 Takeaways Cloud

2.
 Week 4 Feedback Survey

3.

Tailored Lesson Opportunity Reminder

4.
Course Final for Auditing Students
1.
Course Final for Auditing Students
Final Exam Este contenido es calificable

1.

Before You Test - Last Chance to Verify

2.

Audit Final

5.
Course Final for Verified Students
1.
Course Final for Verified Students
Final Exam Este contenido es calificable

2.
Open Final
Open Final Este contenido es calificable

6.
Congratulations! Now Keep Going!
1.
Thank You! Now Will you Continue?

1.

Thank You!

2.

Course Takeaway Cloud

3.

Give It To Us Straight!

4.

Continue Your Education at UMD!

5.

Last Feedback Before You Go!

Herramientas del Curso

 Actualizaciones
 Marcadores
 Optar por el Certificado Verificado
Obtenga un certificado verificado

Mejora($125)
Aprender más
Fechas importantes del curso
Hoy es 15 de nov. de 2018 12:14 -03

Cambiar a la opción con Certificado Verificado

antes del 6 de dic. de 2018

No pierdas la oportunidad de resaltar tus nuevos conocimientos y habilidades mediante

un certificado verificado.
Cambiar a la opción con Certificado Verificado

Finalización del curso

Dentro de 1 año - 18 de oct. de 2019

..