En esta sesión de solo 30 minutos veréis algunas ideas, técnicas y herramientas para como ayudar a equipos que hacen un Scrum mecánico a entregar productos de mayor valor a sus clientes.
Contenidos de la sesión
Feature Factories
Product Mindset
GO Roadmap
Métricas de valor
OKR y EBM
Metas de Producto y Sprint
Dual Track Agile
Como introducir UX en Scrum
Fecha | Ciudad | Curso |
---|---|---|
13/01 | Curso virtual | Professional Scrum Master (PSM) |
14/01 | Curso virtual | Professional Scrum Product Owner (PSPO) |
10/03 | Curso virtual | Professional Agile Leadership (PAL-E) |
¿Quieres recibir más información y recursos de calidad?
¡Suscríbete a nuestra newsletter mensual!
Cada mes enviamos una newsletter a más de 1.200 personas con contenidos, recursos y ofertas especiales de nuestros cursos. Queremos ofrecer contenido de calidad y sin spam.
Transcripción de la sesión
Hola, me gustaría compartir con vosotros esta presentación sobre unas cuantas ideas acerca de cómo ayudar a los equipos a convertirse en más excéntricos en el usuario y más orientados a resultados. Vamos a ello.
Lo que vamos a ver en esta sesión es bien lugar porque hemos llegado a este punto en el mundo de Agile, y cómo podemos ayudar a los equipos y Scrum a convertirse más céntricos en el usuario y orientarse a marc a dar más resultados para los clientes en lugar vamos a ver por qué porque
hemos llegado aquí en la historia de la agilidad porque a la actividad x pueden ser los mejores amigos a la hora de convertir a los equipos en centrados en el usuario y en la orientación y el resultado podemos ver cómo utilizar las métricas como una palanca para incorporar la agilidad y la centralidad del usuario
lo mismo podemos hacer pues también con las dietas de Scrum y bueno pues una serie de cambios y mejoras que podemos hacer en la manera de concebir los sprints el backlog etcétera en ese sentido vale vamos a ello en primer lugar porque
estamos aquí pues hablando no de cómo ayudar a los equipos a saltar hacia más centralidad del usuario y más resultados porque esto ya no es algo que sea lo normal también lugar pues porque la
agilidad no está llena de buenas ideas pero he encontrado un terreno hay donde cual crecer en las organizaciones tradicionales en el manifiesto y muchos de vosotros lo conoceréis se describió en 2001 por
pioneros del mundo del software básicamente eran consultores que tenían experiencia transformando los proyectos transaccionales con planificación pesada
muchísimas partes involucradas etcétera en poseer
iniciativas más ágiles y más capaces de adaptarse a las necesidades del usuario
probablemente conocéis muchos los cuatro valores y los principios que escribieron estos autores en el año 2001 pero uno de
sus pecados originales es que el el objetivo ya lo han cumplido en
muchos casos agilizar proyectos ahora no se tenían en cuenta movimiento está
yendo surgiendo a lo largo del tiempo como un diseño centrado en el usuario como the box como el iii y otra serie
corrientes no que han ido ayudando a que los proyectos y las iniciativas mejor
dicho cada vez sean más céntricas y orientadas al valor aún así por supuesto todos los valores y principios son
manifiestos y siguen estando plenamente vigentes en la mayoría
como decíamos bueno pues la idea es interpretado normalmente en muchas
organizaciones como una aceleración en la entrega de soluciones como algo que era para los
ingenieros para los equipos y que no suponía repensar la organización
y lo que ha conducido en muchas ocasiones es a tener equipos que se llaman ciclos factoring son fábricas de
funcionalidades de equipos que no se les ha permitido tener una misión orientada a la solución
de los problemas de los usuarios que a los que muchas veces se les ha aislado
de estos y a los que se les ha facilitado requisitos que desarrollar en código y
en ocasiones esto ha conducido a que el objetivo de la afinidad ya no ha sido tanto entregar más valor a los usuarios
sino producir más y más rápido donde se ha medido a los desarrolladores por su
velocidad y no tanto por el valor pues que entregados y esto pues es una cosa
que yo observando muchas organizaciones en las cuales he podido colaborar
y otro aspecto que es relevante el estado actual de la actividad es la
mentalidad que tienen las organizaciones en muchas organizaciones la manera de hacer los presupuestos la manera en que
se concibe la planificación de la estrategia nos conduce a continuar presupuestando y planificando proyectos
y en esto se hagan internamente o se hagan a través de proveedores externos suele primar la mentalidad de proyecto y
es que el éxito de la iniciativa es cumplir la planificación tanto entregar el alcance entregarlo a tiempo y con el
presupuesto adecuado y conservando la calidad esto si bien
esto ya es un objetivo cumplido y la entrega interactiva e incrementarlo facilita no nos garantiza de por sí que
logremos uno de los objetivos que debería ser de cualquier iniciativa cuando se invierte en un producto y es
ser y dar valor a los usuarios que un enfoque y que esté activo incremental donde se vayan viviendo en cada stream
en cada momento variables que tienen que ver con el valor entregado a los usuarios y esto sirva para dirigir el la
iniciativa pues de manera continua que sería más una mentalidad de producto donde yo invierto y guido el retorno de
la inversión que estoy teniendo sería una manera más adecuada de centrarnos en
el usuario y de maximizar los retornos para el usuario que le ofrecemos igual
una de las cosas que deberíamos intentar es la orientación y la vitalidad sobre todo de la
dirección que quiero al final tomar las grandes decisiones otro aspecto que es importante las
organizaciones es cómo se conciben las gaunas incluso si pasamos a yale el roadmap muchas veces no deja de
convertirse en un nuevo plan de proyecto entregado a través de interacciones esto
pasa pues cuando las funcionalidades se han definido cuando es para llegar en las versiones y se espera que se
ejecuten según una hoja de ruta basada en estimaciones iniciales
lo que también debemos plantearnos es de qué manera si de griega o si la dirección se comunica con los equipos en
vez de ofrecer normas o proyectos cerrados puede ser
mejor enfocar las iniciativas como los más pasados en metas como este ejemplo que
veis con el oriente de robo de roman picture donde se pueden estimar y se
pueden calendarizar versiones pero ya se deja claro que lo más importante de cada
versión son los objetivos de negocio alcanzar y las métricas
con los cuales vamos a medir si se ha logrado este objetivo y no menos
importante pero secundarios son las funcionalidades que vamos a incluir en cada versión esto nos permite dejar
claro entre la dirección el negocio y los equipos de trabajo cuál es el
objetivo en europa se espera como si no válida es el objetivo del negocio nos obligan a pensar muchas veces en el
impacto hacia los usuarios y las funcionalidades ya no se convierte en la piedra angular de la zonificación sino
que son importantes como una hipótesis de partida el nacional elemento fundamental
otro punto que queríamos tocar y es porque la alineación entre ya en wikis
puede ser una herramienta fundamental para dar mayor retorno mayor valor a las
inversiones en software en una cita que me gusta mucho en un autor llamado medicaid and autor de
libros muy importantes de columnas y le convine bayern y es que a los equipos se
les debería dar objetivos de negocio y solución de problemas de usuario como misión y no tanto la entrega de
funcionalidades darle la autonomía la responsabilidad de buscar cómo lograr
esos objetivos de negocio y esto pues también mucho más la manera en las
cuales pues el ritmo que está trabajando está más cerca de los clientes y tiene clara cuál es su misión
otra de los aspectos a tener en cuenta es que la centralidad del cliente está
muy alineada de consigo la actividad y el hecho de que algunas buenas
prácticas en esto sea empoderar a la línea de la línea frontal los que están
en contacto con el cliente para ser autónomos ida de entrega de soluciones se parece mucho a lo que pide la finalidad de romper silos entre quien
hace los sistemas que nos van a consumir escoger métricas de valor lo vamos a ver en la siguiente página nos va a ayudar a
orientar los equipos a la entrega de valor como no les es fácil de ver el
feedback continuo también está alineado con la actividad la
dirección el liderazgo centrado en el valor del cliente les
hacemos sensibilizarse y apostar más por y entregar lo que necesita al usuario y
luego el diseño de las experiencias de usuario con técnicas como el caso horner
service group inc pueden ser muy útiles para dar contexto a los equipos
centrando tanto el gráfico de los objetivos de las iniciativas decíamos que en las métricas
es aquello que se gestiona y pues esto
es así como puede aprovecharse como una palanca para cambiar la atención de la
gerencia del negocio hacia aquellas cosas que nos interesa y que se pasen a
gestionar en este modelo el modelo de lógico de métricas pues se ve con una serie de
soluciones el hecho de nosotros resupuesta el trabajo de un equipo nos permite que este equipo pues pueda
realizar estas actividades de manera efectiva otras funciones que el hecho de que el equipo trabaje con calidad
produce un producto de calidad esto sería la planificación del trabajo
pero luego una vez que nosotros hemos producido el producto vienen aquí a ser
resultados que estamos esperando obtener en primer lugar los resultados de output de producto se pueden medir pues formas
como por ejemplo las métricas de uso del producto los defectos la disponibilidad
etcétera producto sobre el producto una vez entregado al usuario medi cosas como
esta nos ayuda evolucionar y maximizar el valor del producto
por otro lado los out comes que son aquellos resultados para el usuario también son muy útiles a la hora de
tomar decisiones en cuanto a la gestión del desarrollo del producto saber en el caso menor las encuestas de satisfacción
del usuario nos pueden guiar respecto a qué funcionalidades mejorar cuáles dejar
tal como están en base de datos pero si además podemos medir atributos duros
dentro por ejemplo el ahorro del tiempo en la realización de las operaciones o la
cantidad de veces que se usan las funcionalidades nos puede dar pistas muy interesantes para seguir evolucionando
el producto en una dirección u otra por otro lado el impacto organizativo la
reducción de costes la mayor ganancia mayor fidelidad el cliente sea lo que sea el objetivo de la organización no
siempre se consigue desde entregar una actitud y automáticamente tendremos otro haciendo este salto en los resultados
para el cliente con lo cual tener no lo que vamos a hacer de trabajar y entender
bien cuáles son las necesidades del cliente para que aquello que producimos encajen con esas necesidades y validar
vía métricas o evidencia es todo esto para seguir realimentando pues es una de
las cosas que nos gustaría hacer y pues ayudando a los equipos y al management a
tener más atención hacer este tipo de métricas podemos cambiar no a la
humanidad en que se desarrollan las soluciones ideas organizar planes
otra cosa queríamos comentarles a dentro de equis pues hay técnicas que nos
ayudan a definir aquellos trabajos que queremos hacer
como hipótesis no cómo serían las cestas que tenemos aquí porque es importante
definir hipótesis porque nos pone en un plano de humildad nos ponen un plan donde querer entender si aquello que
vamos a entregar va o no va a entregar el valor que quiere el usuario aquello
que necesita el usuario es necesario definir hipótesis para todos no no habrán funcionalidades que estén muy
claras que el usuario las necesita las dos valoran quizás para eso lo tenemos que definir ninguna hipótesis pero habrá
otras de un riesgo mayor de negocio una inversión mayor hacer y nos puede ayudar a plantearnos
cuál es el objetivo que estamos buscando y que cómo vamos a experimentar si ese
objetivo de una manera más barata que desarrollando la funcionalidad se va a cumplir o no y en cualquier caso pues el
desarrollo incremental de esta funcionalidad geométrica es también tenemos quiero que metro no y esto
enlaza pues con el siguiente punto y es que la agilidad de negocio la centralidad del usuario se puede
impulsar mediante bueno en utilizar métricas que sean más
asociadas para esto de uno de los elementos que nos ayudará en la fijación
de américa si posiblemente os haya sonado el
término objectivo sanción es una evolución de la gestión por objetivos más tradicional que tiene una serie de
diferencias el liderazgo asigna objetivos a managemen ya los equipos
pero estos objetivos pues son divididos entre el objetivo más cualitativo en el objetivo y el crisol
del resultado clave que son cosas tangibles y medibles que esos
tipos pueden negociar con dirección como contribuir a ese objetivo
de una manera que les permita enlazarlo con el trabajo que van a hacer con lo
cual esto es una duda no crea un mayor alineamiento mayor
entendimiento de cuáles son los objetivos y por otro lado diferencias que tienen los hogares son que el
periodo de asignación y medición se pueden haber objetivos organizativos
anuales pero hay muchísima incertidumbre y cultura no para conseguir ese objetivo con lo cual partiendo los objetivos más
pequeños subido habitualmente son objetivos intermedios trimestrales
pues trabaja en el ciclo y uno de 12 semanas normalmente ofrece menos incertidumbre y
permite definir mejor cómo queremos alcanzar esos objetivos y esto por si puede alinear bastante bien por lo que
serían metas del producto que vamos a verlo más tarde otra herramienta para
dirigirnos los equipos hacia la creación de valor y las organizaciones sm
management tiene dos grupos
métricas unos orientados a entender el valor que queremos ser los productos y otros orientados a entender el motor de
creación de valores de nuestra organización y lo vamos a ver ahora en primer lugar el valor actual nos ayuda a
de entender a esforzarnos por medir como ofrecemos valor a nuestros clientes y
esto quiere decir que vamos a tener que pensar en el cliente en sus resultados en el uso que están haciendo del
producto y estas métricas nos pueden ayudar a tomar decisiones y además estas métricas pueden evolucionar porque con
el tiempo podemos ver que algo que estamos viviendo por ejemplo pues la métrica del nps a lo mejor no está mejor
métrica para vivir en nuestro caso la satisfacción del cliente a lo mejor nos conviene más medir el uso
de las funcionalidades o el feedback que recibimos etcétera con lo cual estamos obligados a hacer una poner en una
investigación continua no de entender cómo la ofrecemos para los clientes nos hace poner
el valor potencial son aquellas métricas que nos ayudan a medir cómo ofrecer más
valor a los clientes y aquí pues podemos entender pues con un conocimiento que no
tenemos identificarlo para dar valor a los clientes o viejas nos puedan ayudar
a entender el humo podemos
entender mejor y entregar los fabuladores clientes o servicios que no estamos ofreciendo y que realmente los
clientes necesitan con lo cual de nuevo nos vemos obligados a entender y refinar
continuamente las métricas que nos pueden ayudar a evolucionar hacia dónde queremos ir para entregar más dolor en
la parte de la organizativa pues las métricas en time to market nos ayudan a
identificar cómo podemos acelerar los ciclos de aprendizaje los ciclos de entrega de
valor utilizar medidas de flujo de campo podemos
pedir cosas como por ejemplo cuánto tardamos en entregar una oferta comercial a un cliente o cuánto tiempo
tardamos en tener feedback en las encuestas al final de nuestros cursos con lo cual la cola la cantidad de
trabajo y debido haber ido demasiado rápido incluso entregando cosas en el
lado de la habilidad por innovar en innovar pues es muy interesante en el foco en aquellas cosas que aportan valor
al cliente que es una de las máximas débiles de la acción social y podemos entenderlo contar ejemplos
como pues cuánto tiempo dedicamos en las funcionalidades versos solución de defectos o cuánto tiempo reservamos el
aprendizaje y además de interno para seguir ofreciendo cosas nuevas
con lo cual esto nos da un marco de trabajo para una vez que tenemos métricas y metas
y tan estratégicas tácticas de medias nos puede ayudar a medir cómo llegar a
complementar esto está muy bien explicado dentro del anime continuando volátil como usar las
piedras en screen pues en la guía 2020 apareció la meta de producto como un
estado intermedio definido del producto que nos ayuda a a
pues avanzando hacia la visión a largo plazo del producto hacerlo cada pocos
meses y a lo mejor tres meses un período adecuado porque no es migración cierto y
demasiado poco tiempo para hacer algo significativo pues puede ser un plazo
intermedio en cualquier caso cada contexto nos marcará pues cuál es el tiempo ideal y podremos irlo refinando e
inspeccionando y adaptando con la práctica como ejemplo podemos decir pues que en un comercio electrónico podemos
haber identificado que estratégicamente uno de los objetivos que queremos atacar son los carritos de la compra
abandonados que lo llegan a realizar la compra y que podemos decir en un periodo relativamente
asequible que sería en tres meses podemos intención es rebajar un 20 por
ciento la los carritos abandonados para esto tendremos que ver cómo hacerlo podemos tener una serie de picasso de
ideas a experimentar para llegar a ello y algunas de ellas pueden convertirse en
sus objetivos de espn por ser suficientemente grandes otras pueden requerir entregarse a lo largo de varios
speed dentro de estos elementos pues pueden haber paquetes de trabajo basados en el
recherche en la investigación de necesidades del usuario esto lo veremos más tarde
cuando decimos que nos ofrece poco en la mitad del producto pues aquí podemos ver un ejemplo si nos proponen en medio del
desarrollo de una meta de producto como la que hemos visto que es muy importante
muy prioritario pues ponen en marcha una nueva landing page commerce pues bueno aquí podemos
decidir si merece la pena continuar hasta en esta meta de producto
pagamos y nos volcamos en una iniciativa sólo si tiene que ver pero nos debería
ayudar a poder retrasar y dejar fuera del alcance cosas que básicamente lo que van a hacer
es alargar nos las fechas de entrega o quitarnos foco en la meta que tenemos en
marcha lo mismo pasa con la meta de spins que ya estaba mucho tiempo en el día Scrum y
nos dice pues soy el otro con el objetivo de llevar igual que antes olga no lo he visto anteriormente debemos
mantener foco en el que él va claudio producto ya no sea un cajón de sastre con todas las cosas presiones ocurre
sino que contenga aquellas cosas únicamente o principalmente que vayan a dirigirse a la meta de producto pues en
el caso del sprint y luego de despedir no debería ser porque foshan sino que fundamentalmente nuevo cien por cien
piezas necesito fundamentalmente debería centrarse en conseguir un objetivo a corto plazo en pocas semanas en el caso
de una de las épicas anteriormente el express checkout porque podemos
convertir en una meta sprint identificar nosotros cualquier test de trabajo más pequeños incluso tareas que nos puede
que podemos necesitar para construir se exprese está en el sprint el objetivo es
definir al cien por cien una lista de funcionalidades y tareas y entregarlas tal cual pues no
en un espíritu podemos tener bastante claro que necesitamos hoteles y porque estamos hablando de pocas semanas ahora
deberíamos dejar las propiedades la un tiempo para poder incorporar cosas nuevas que salgan por el camino y luego
pues alguna urgencia que venga pero que no pueda esperar pero el principal foco
no de nuestro sprint debería ser esto y en la planificación y en la red premium
pues deberíamos centrarnos en la meta no también el número de ítems que vamos a hacer
igual que veíamos antes el ejemplo de una petición de cambio aquí añadir un
informe de fraude vamos a alzar cómo hacer ese gran
central en el usuario bueno pues las historias de usuario era una de las una
de las cosas que me habitualmente se asocia es que no son elementos prescindibles Scrum lo existen en el
backlog pues pueden ser el usuario o muchas otras cosas paquete de trabajo que ofrezca un valor
ahora que sí vamos a obtener el utilizar exteriores usuario que utilicemos
también las historias de usuario no sean requisitos que se tienen que ejecutar y
ni siquiera esperamos que el producto de las detalles funcionalmente a esta última como sirven para fijar cuál es el
problema del usuario que queremos solucionar entender cuál es el valor que le aporta y a partir de aquí
estableciendo una conversación que nos permita priorizar las desglosa más en paquetes más pequeños y delegar a los
equipos la realización de estas historias teniendo en cuenta que sabemos cuál es el objetivo de negocio que queremos
conseguir colocarla en una de ellas cualquier frustración de que queremos quitar el usuario qué necesidad le
queremos proporcionar pero no son especificaciones que se escriban y se les pasa en el programador
lo haga un analista o lo haga el productor se entiende que son elementos que le
sirven al propio desarrollador para llegar a las especificaciones o
documentación es de qué es lo que se va a hacer junto con el usuario y es una
historia de usuario indefinida la necesidad del usuario que sea con este formato de como usuario quiero cubrir
una necesidad para lograr un objetivo pues puede ser bueno origen para empezarlo refinamiento y la
investigación de lo que quiere el usuario y móvil si nos seguimos moviendo y dj
spot en que validar las necesidades del usuario con código entregado en
producción la calidad requerida es la manera más cara que existe y tiene razón hay muchas otras maneras de descartar
que una necesidad es real y que la funcionalidad que va a cubrir la
necesidad y además no va a hacer una manera deseable para el usuario en este sentido pues en técnicas como un doble
de diamante que vemos aquí nos permite dividir la parte de investigación de entender cuál es el problema
y decir que tiene el usuario y cuales merece las posibles problemas con aquellos que merecen la pena
solucionarse y cuáles son más prioritario y por otro lado el segundo diamante de diseño pues entiende que
vamos a ver múltiples opciones que puede solucionar un problema del
usuario y que posteriormente vamos a validar cuál es la mejor solución y cómo
debe ser esta solución este doble diamantes y lo vemos dentro de Scrum no tiene que ser
todo hecho en espn es posible que la parte debe ser se haga antes de los espinos o se haga varios spins antes de
desarrollar sus habilidades necesarias tenemos que tener en cuenta porque
incluso si tenemos un diseñador de wikis dentro del equipo pues el ritmo que va a
estar no va a ser siempre dentro del sprint sino que puede que trabajé varios sprints adelantado al resto del equipo
al menos lo que es la parte más de investigación estratégica y por otro lado la curva de la verdad nosotros dice
que deberíamos invertir en las funcionalidades en el desarrollo de una
manera proporcional a la certeza que tengamos que son necesarias y hay muchas técnicas de experimentación baratas que
nos permiten entender sin necesidad se utiliza pero una
funcionalidad su bici como debe ser sin tener que llegar a desarrollar software esto debería de ser solo cuando lo
tenemos bastante claro que esta funcionalidad es necesario ver cuál eran
yale tenemos que intentar eliminar el desperdicio de dar funcionalidades que
no se necesitan o darlas de una manera en que no se necesita moviéndonos
ya veremos este concepto detuvo al track a yale por si no lo conocéis se puso
signo popular hace unos años y lo que suponía que habían dos corrientes de
trabajo dentro de los tipos de producto una corriente del descubrimiento del producto donde se entienden los
problemas del usuario se buscan soluciones
este en estas soluciones y todo esto es un tipo de trabajo que tiene un ritmo
diferente al del desarrollo una vez que estas soluciones hemos quedado no hemos entrenado a todas
aquellas problemas que no merece la pena solucionarse hemos centrado aquellas soluciones que son a priori viables
mediante de usuario ya las podemos pasar a la kobryn de delivery de desarrollo donde
vamos a hacer un ciclo de vida de los requisitos modificar testear entregar
de nuevo no interactivo en sí mismo pero habiendo sido entrado y habiendo descartado la mayoría de funcionalidades
que no son necesarias uno de los problemas que ha habido
el actual track es que en ocasiones ha considerado que eran dos equipos separados con dos bloques separados un
equipo debe ser orientado a la investigación por parte de los
recherche es el product manager líder técnico mixtas de clic para definir
filtra funcionalidades desde el punto de vista de negocio de mucha habilidad y de
la necesidad técnico y ha habido otro tipo de programadores que se encargaba
de llevarlas a cabo si bien esto es una mejora respecto ángulo de la cascada que no se filtra muchas cosas innecesarias
nos ayuda a entender mejor lo que vamos a hacer ya trabajar más eficientemente tanto los diseñadores y por managers
como desarrolladores supone tiene varios inconvenientes por ejemplo
experimentado trabajando con equipos pues tiene muchos desarrolladores que se sienten ajenos al contexto ya las
decisiones de producto que no pueden aportar su experiencia y su
[Música] en cuanto a proporcionar mejores
soluciones a las necesidades del usuario y que al perder el contexto también se
genera en ocasiones de trabajo debido a que los desarrolladores no tiene la información para poder tomar
suficientes decisiones con lo cual es una mejor implementación del track sería un equipo desarrollando
las funcionalidades aún bien el trabajo el flujo de wikis no tenga que seguir
exactamente el mismo patrón nuevo el mismo ciclo y la misma velocidad
y hacer las cosas en el mismo momento que los equipos aparte del equipo que hace el desarrollo de la ingeniería
por otro lado otra pregunta integrando xy la de yale es bueno si podemos pensar
que los sprints pues si atrás tareas de wikis pueden expandirse varios springs ya no tiene que ir exactamente es
sincronizar con el desarrollo cosa que puede ayudar a su x encontramos una manera de trabajar con
un poco de confort dentro del desarrollo pues podemos pensar hoy ahí el barrio cómo se
expresa desde punto este trabajo el wiki se trabajó en el desarrollo de una
opción que hemos dicho que es menos buena sobre el barrio separado sino para el trabajo de descubrimiento de producto y de wikis y otro para el trabajo de
delivery y optaremos pues por soluciones una mezcla de la central y la derecha
para que los puedan tener en la entrevista siendo gráficos
como cap son libros estilo que requieran pues trabajar uno más sprint en ellos y
luego pues que haya otras funcionalidades por ejemplo trabajar con sistema que entiendo tener un x social
pero que haya también funcionalidades dv tease y trabajo de desarrollo podría ser
pues la definición programación de una funcionalidad con
interfaz y frontera con lo cual todo esto nuevo
[Música] next pero debería ser natural para equipos
que trabajan en ambas disciplinas moviéndonos como resumen de las cruces que hemos visto
pues el liderazgo puede hacer o rompernos la posibilidad de que los
equipos sean ágiles en el causa cliente orientados entrega de valor lo cual
deberíamos ayudar y acompañar a los más los nadies y directivos en entender esto
conseguirlo que apoyen a los equipos
autonomía que estamos viendo para poder dedicarse a la solución de problemas de cliente
que también hemos visto que las metas estratégicas intermedias tácticas
sí sí expresan útiles para ayudar a que los equipos
estén orientados a 100 tentados a entrega de valor y resultados y luego
pues que cuando nosotros cogemos un trabajo de estudio inter el producto y lo vamos desarrollando de
manera conjunta con el desarrollo enormemente de los sprint los que es natural que
haya trabajos que vayan a velocidades desacopladas y que ponemos en el backlog
paquetes de trabajo que no van a servir exactamente aunque acaben en funcionalidades sino que pueden ser
trabajos de wikis aquí bueno estaré encantado de recibir
vuestras preguntas y respuestas
agradeceros vuestro tiempo de contacto y estaré encantado de
seguir esta conversación a través de las redes sociales [Música]