HSBC - Agile Workshop

APERTURA
Caso de estudio
Caso de estudio
Caso de estudio

"Esta es una característica de cambio

adaptativo: No sólo llevar a cabo pequeñas
mejoras, sino que a menudo da lugar a saltos
sorprendentes, que cambian el juego a
nuevas soluciones
Delivery Framework
We aim to improve and enhance the traditional development paradigm. Conversely, we foresee to avoid its common drawbacks.

Our team players will rely Two heads are better than

DELIVERY FRAMEWORK
on planned work, one… hmm not in all the
preventing the classic “hero cases, two heroes will not
of the day” setup. make much difference if a
goal and priority are not
properly set.

A software development and

design thinking process provide
value only in the extent that we
are able to include the rest of the
stakeholders.
Delivery Framework

We truly believe that new necessities demand novel ways of thinking.

Maturity

DELIVERY FRAMEWORK
Integrated PODs +
Agile process +
Continuous improvement +
Proper metrics +
Happy Minded stakeholders
_______________________________

Digital Journey

Impact / Velocity / Quality

Autonomy Relationship
POD = Multi disciplinary team

Governance POD: Globant POD:

1. hbo´s roles GOV TEAM GLB TEAM
1. Project Manager
2. Delivery Director 2. Lead Software Dev
(GLB) 3. Front end team
3. Account Manager 4. Back end team
 Delivery Framework Dealing with business and priorities changes.
RELEASE CYCLE

Release Planning: The objective of this activity is to

have a roadmap that guarantees the fast delivery of the Incremental development to support
minimum viable product. a rapid time to market.

Iteration Stand up
development meeting
Faster inspection and adaptability.
Iteration Planning: ITERATION CYCLE
Iteration
choose which Review
features will be
Release Iteration Iteration Release
developed Iteration 0
(time-box between planning planning Backlog closing
2 and 4 weeks),
taking into account
the release planning Single or several
and the amount of Iteration releases, taking into
work a POD can Products account the
handle without
retrospective
(1 to N business value, date
increasing technical
Iteration releases) of marketing
debt, this set of Backlog refinement
features are named closing campaigns , viability
Iteration Backlog. as final product in
Product Product increment the market.
backlog (1 a N Iterations)

● Agile iterative and incremental methodology for project development

Iteration management methodology.
Per previous section walkthrough, this is how a sequence of iterations could look like once the POD is set up and the
communication plan is done. Let us have a look into a sample iteration, week one...
Iteration management methodology.
… shall we continue with the second week of the execution iteration? ...
Iteration management methodology.
… now, we are able to engage into a new iteration, which in turn could have a release planning matching the beginning of it
and some additional checkpoints (monthly deck session, for instance)...
Iteration management methodology.
… then, we start a new iteration with some other important cadences, such as the team building or the release
closing (our product is done, we mean, really DONE), and we start all over again.
 Management Tools
Issue tracking, workflow tool.
Team communications For scope, tasks, efforts, bugs.

Project calls.

Project documentation,
file repository. Code reviews.

Source Code
Management
Continuous integration and
Continuous Deployment +
Quality Code

Communication platform:
instant messaging, video chat,
SMS and VOIP features. Test Management

Globant Proprietary | Confidential Information

AGENDA

1. Manifiesto ágil
2. Principios ágiles
3. ¿Por qué tenemos que ser ágiles?
4. El corazón de la agilidad
5. Scrum
6. Roles
7. Artefactos
8. Ceremonias
9. Taller ágil
10. Conclusiones
El manifiesto ágil
MANIFIESTO ÁGIL

“Estamos descubriendo formas mejores de desarrollar software tanto por nuestra

propia experiencia como ayudando a terceros. A través de este trabajo hemos
aprendido a valorar:

Individuos e interacciones sobre procesos y herramientas

Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la
izquierda.”
MANIFIESTO ÁGIL
PRINCIPIOS ÁGILES

● Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y

continua de software con valor.
● Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los
procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al
cliente.
● Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con
preferencia al periodo de tiempo más corto posible.
● Los responsables de negocio y los desarrolladores trabajamos juntos de forma
cotidiana durante todo el proyecto.
PRINCIPIOS ÁGILES

● Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el

entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
● El método más eficiente y efectivo de comunicar información al equipo de desarrollo y
entre sus miembros es la conversación cara a cara.
● Los procesos Ágiles promueven el desarrollo sostenible. Los promotores,
desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de
forma indefinida.
● El software funcionando es la medida principal de progreso.
PRINCIPIOS ÁGILES

● La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.

● La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
● Las mejores arquitecturas, requisitos y diseños emergen de equipos
auto-organizados.
● A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a
continuación ajustar y perfeccionar su comportamiento en consecuencia.
¿POR QUÉ TENEMOS QUE SER ÁGILES?
¿POR QUÉ TENEMOS QUE SER ÁGILES?

• Debido a la rápida evolución de los mercados y la tecnología

• Necesidad de ser vanguardista
• Flexibilidad al cambio de las necesidades del negocio a lo largo del tiempo
• Proactividad
• Interacción con el equipo
¿POR QUÉ TENEMOS QUE SER ÁGILES?
SCRUM
SCRUM

Es un marco de trabajo por el cual las personas pueden acometer problemas

complejos adaptativos, a la vez que pueden entregar productos del máximo valor
posible, productiva y creativamente. Se basa en la teoría de control de procesos
empírica o empirismo (El conocimiento procede de la experiencia) Scrum es:

● Ligero
● Fácil de entender
● Extremadamente difícil de llegar a dominar
SCRUM

Scrum emplea un enfoque iterativo e incremental para optimizar la predictibilidad y el

control del riesgo.

Tres pilares soportan toda la implementación del control de procesos empírico:

● Transparencia
● Inspección
● Adaptación
SCRUM

Dinámica: Hablemos de valores

SCRUM

Globant Proprietary | Confidential Information

SCRUM

• Valentía - Valor: Los miembros del equipo de scrum tienen el valor de hacer
lo correcto y trabajar en problemas difíciles.
• Enfoque - atención: Todo el mundo se centra en el trabajo de la iteración y
los objetivos del equipo Scrum.
• Compromiso: La gente personalmente se compromete a lograr los objetivos
del Equipo.
• Respeto: Los miembros del equipo de scrum deben respetarse entre sí para
ser personas capaces e independientes.
• Sinceridad: El Equipo Scrum y sus partes interesadas están de acuerdo en
ser abiertos acerca de todo el trabajo y los retos para la realización del
mismo.
ROLES - Scrum Master

El papel del scrum master: Facilitador

• Enseña scrum
• Facilita eventos
• Guía para que el equipo sea autoorganizado y
Autogestionado
• Elimina impedimentos
• Coordina
ROLES - Product Owner

El papel del product owner: Maximizar el valor del producto

entregado

- Es la persona que conoce el negocio

- Es responsable de gestionar la lista del
producto (Product Backlog)
- Al decidir sobre qué debe hacer y Qué
posponer el equipo de desarrollo, toma las
decisiones de alcance versus la fecha que
llevan al mejor producto posible
ROLES - Development Team

El papel de los desarrolladores: Creadores del producto

Los Equipos de Desarrollo son estructurados y
empoderados por la organización para organizar y
gestionar su propio trabajo.
➔ Definen sus propias tareas
➔ Son auto-organizados.
➔ Multifuncionales
➔ Individualmente pueden tener habilidades
especializadas, pero la responsabilidad de la
entrega recae en el equipo de desarrollo como un
todo.
ARTEFACTOS

- Lista de Producto (Product Backlog):

Es una lista ordenada de todo lo que
podría ser necesario en el producto.

- Lista de Pendientes del Sprint (Sprint

Backlog): Es el conjunto de elementos
de la Lista de Producto seleccionados
para el Sprint.
ARTEFACTOS

- Incremento del producto (Product

increment): Es la suma de todos los
elementos de la Lista de Producto
completados durante un Sprint y el
valor de los incrementos de todos los
Sprints anteriores.
CEREMONIAS

Scrum prescribe cuatro eventos formales, contenidos dentro del Sprint o

iteración, para la inspección y adaptación:

● Reunión de Planificación de la iteración (Sprint Planning)

● Scrum Diario (Daily Scrum)
● Revisión de la iteración (Sprint Review)
● Retrospectiva de la iteración (Sprint Retrospective)

*Aunque no está agregada a la guía oficial, existe un evento llamado: Product

Backlog Refinement
FRAMEWORK