El dilema del Product Owner:    "Delivery vs Discovery"                 presentador:               Marcos N. Lilljedahl  T...
Agenda•   Motivación•   Delivery y Discovery•   Inicios Ágiles•   El rol y la misión del PO•   Siendo un PO efectivo•   Co...
Motivación"Un guardián para proteger a los Stakeholders de losincontrolables equipos de desarrollo"Yuriy Zubarev – Cynical...
Delivery y Discovery      Succesful software (producto):      (2001 – Comienzos de Agile)      "El software resulta exitos...
Lean Startup            Customer development model            Antes de desarrollar un producto, debemos desarrollar un mer...
Inicios Ágiles    Hype de XP cuando se firma el Manifesto Ágil.    El "cliente" como la persona detrás del programador (St...
Scrum framework                       24                       horasProduct      Sprint            2-4Backlog      Backlog...
Cómo aprovecharlo?Muchas veces lo que planeamos construir no es realmente lo quenecesita nuestro clienteSe tiene lo que se...
El rol y la misión del PO• The product owner decides what will be built and in which order• Defines the features of the pr...
Ok… y entonces?• Discovery y develiery como 2 términos complementarios• Disovery . El aprender a aprender sobre nuestros c...
Cómo mejoramos el delivery?• Hay muchas tácticas que pueden tomarse de LEAN• "Genba" (ir y estar en la escena del crimen)....
Business Value• Es el trabajo del PO especificar lo mejor posible qué es y qué no es  el BV.• En conclusión aquello que co...
Errores comúnes• Virtual product owner syndrome• The IT Product Owner• The bungee PO
Facultades de un PO• Saber tomar el control y sentarse en el  asiente del conductor• Tener las cualidades requeridas• Cono...
Siendo un PO efectivo (cont.)• Los 7 hábitos del PO efectivo (Ricardo Colusso)       o Maximizar la empatía y entender con...
Conclusiones• Saber diferenciar el delivery y discovery y actuar en consecuencia  de ello.• Colaborar con el equipo consta...
Próxima SlideShare
Cargando en…5
×

El dilema del product owner delivery vs disovery

675 visualizaciones

Publicado el

Presentación expuesta durante el Scrum Gathering 2012 los días 23 y 24 de Mayo.

Copyright Marcos Lilljedahl (c)

Publicado en: Tecnología
0 comentarios
2 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

Sin descargas
Visualizaciones
Visualizaciones totales
675
En SlideShare
0
De insertados
0
Número de insertados
18
Acciones
Compartido
0
Descargas
0
Comentarios
0
Recomendaciones
2
Insertados 0
No insertados

No hay notas en la diapositiva.
  • Compañías que usan un modelo de desarrollo de producto Dónde están los clientes?Foco puesto en el primer entregableÉnfasis en la ejecución en vez del aprendizaje y el discoveryEspiral de la muerte: El costo de lanzar incorrectamente un producto.
  • FourstepstoepiphanyCommon Sense Meets the Product Development ModelThe Customer Development model is not a replacement for the Product Development model, buta companionlean startup se focaliza en los clientes y usuarios y está construido sobre un ciclo de aprendizaje. Cuán rápido aprendemos?Cuán orgulloso se está de que se habla con clientes y usuarios todas las semanas y cuán frecuente lo hacen vs el feedback que se obtiene de agile (demos)
  • Software que se usa fuera de la organización.Thebuyersaren´ttheusers.La gente que elije el software es la que lo define.El antiguo concepto de XP donde el cliente habla con una sola voz. / El nuevo concepto de scrum donde el productowner nunca sale al mercado y al público.Entonces podemos decir realmente que las metodologías Ágiles profundizaron los aspectos del cliente?Colaboración efectiva entre personas que quieren software y aquellos que lo necesitan. Fasteffectivedelivery para medir si lo entregado es lo correcto. (notgivingtactics).
  • Solemos mirar el producto internamentePodemos o no ponerlo delante de las personas, pero al final tenemos un release, y es ahí donde aprendemos.
  • Uno se da cuenta demasiado tarde.Planear y pensar diferente sobre los productos. Planear cómo aprender y mostrar los productos a la gente para aprender si realmente los productos son correctos.
  • Discovery – el trabajoquehacemosparaentender lo queestamosdeberíamosestarentregando
  • Cómo productowners cómo somos realmente efectivos para agregar valor al cliente real y no interno.Output es lo que se construye y outcome es lo que viene después..Tener una visión de querer cambiar el mundo, no de hacer desarrollo de software.La única manera que tenemos de saber si el software funciona, no es si está a tiempo o si está underbudget o con todas las features. Sino si cuando se entrega, la gente usa esos features y se comporta diferente y si se encuentran satisfechos. (de esto son responsables los PO’s)
  • Nadie hace software para una persona (un cliente). No los traigas a tu ubicación, vaya al genba y miralos trabajarNo se puede fingir la empatía. Conocerlos y verlos y pensar desde su perspectivaStorymapping desde XP desde hace mucho tiempo. Idea super simple. Las historias tienen que ser escuchadas y no vistas (cómo escribimos stories efectivas?).Concepto de Agile development. StoryMap (lat-long / narrativeflow / experience):El concepto fue escribir muchas cosas para ordenarlas y después hablar de lo importante.Compartir un modelo mental sobre lo que se quiere construir y seguir adelante. (conversación) Desde el punto de vista ProductOwner (qué hay que hacer?). No es tan obvio (complitado)Y nadie hace software para uno mismo (siempre se representa a alguien más)
  • Basta de hablar del BV como algo genérico que está dando por el negocio. No se puede hablar de BV por sí mismo, es un término incompleto / ambiguo.Todo lo que pasa fuera del sprint es un punto ciego, y es tarea del PO pensar en el outcome.Algo que podemos poner en el mundo que haga las cosas mejor. El valor viene de ese MEJOR.La idea que se puede poner BV en storycards o priorizarlas y de saber qué es lo que es incorrecta.Super difícil decir qué se debe construir y no es un trabajo sencillo.
  • Dividir las tareas del productowner en muchas personas. (Product manager / Scrum Master). – Chiefproductowner.Se pierde la oportunidad de cambiar positivamente El management o el cliente no están dispuestos a cambiar y tomar las responsabilidades de un PO.El poder del rol se pierde, las necesidades del cliente no se transmiten por una sola persona.Las relaciones no se potencian, y se tiende a seguir trabajando en base a requerimientosUn PO que se encuentra ausente y que sólo se muestra en la planning y reviewmeetings. No puede tomar el asiente del conductor. El ScrumMaster es quien toma las decisiones.
  • Tener empowerment!. Tener la autoridad de tomar decisiones y ser responsable por sus resultados.Tomar decisiones relevantes rápidamenteSponsoreado por el Senior ManagementSetear el objetivo del release.Entender las necesidades del cliente y tener el conocimiento de trabajo Ágil.(Trabajar con el backlog / Armar las stories )Asegurarse que el seniormanagement entienda la importancia del rolY se le dedique el tiempo requerido. ChiefEngineer.
  • Inversores / Directores / Soporte / Operaciones / HR / Partners / Clientes / EquipoSocializar la visión / Definir el qué se va a hacer.Backlog como forma de comunicaciónFeedback y coaching recíproco. Admitir errores y emitir señalesQué necesitan los clientes? / Qué hacen los competidores? / Cómo cambia la tecnología?Prácticas que dinamicen a grupos e individuos / Teamwork con scrum masterValidar las userstories. Test de aceptación definidos. Sprints de releaseCD: Información sobre quién valoriza tu entregable y porquéValuePropositionHypothesis: Tu visión y tus assumpciones de valor para tu clienteMercado: Quiénes son tus clientes?Valuepropositionfeedback: Describir a tus clientes reales tu visión del producto para recibir feedbackROI
  • El dilema del product owner delivery vs disovery

    1. 1. El dilema del Product Owner: "Delivery vs Discovery" presentador: Marcos N. Lilljedahl Twitter: @marcosnils Email: macosnils@gmail.com Scrum Gathering Buenos Aires 23 y 24 de Mayo, 2012 Buenos Aires, Argentina
    2. 2. Agenda• Motivación• Delivery y Discovery• Inicios Ágiles• El rol y la misión del PO• Siendo un PO efectivo• Conclusiones
    3. 3. Motivación"Un guardián para proteger a los Stakeholders de losincontrolables equipos de desarrollo"Yuriy Zubarev – Cynical Agile and Scrum Dictionary
    4. 4. Delivery y Discovery Succesful software (producto): (2001 – Comienzos de Agile) "El software resulta exitoso cuando una vez entregado es aceptado en el mercado " (2012 - Hoy) "El software exitoso es entregado a tiempo y debajo del presupuesto."Concepto/ Desarrollo Alpha / Beta Pimer Semilla del producto Test release! Product development model
    5. 5. Lean Startup Customer development model Antes de desarrollar un producto, debemos desarrollar un mercado para ese producto y clientes para ese mercado Para entender a nuestros clientes debemos crear y ejecutar ideas para aprender de ellas y refinarlasCustomer Customer Customer Companydiscovery Validation creation Building Custom development model
    6. 6. Inicios Ágiles Hype de XP cuando se firma el Manifesto Ágil. El "cliente" como la persona detrás del programador (Stakeholder / BA / end user) Los clientes compran y los usuarios utilizan (users and choosers) Desarrollo Ágil enfocado en delivery (efectivo e incremental).Estamos produciendo realmente lo que se necesita?
    7. 7. Scrum framework 24 horasProduct Sprint 2-4Backlog Backlog Semanas PSPI APRENDER!
    8. 8. Cómo aprovecharlo?Muchas veces lo que planeamos construir no es realmente lo quenecesita nuestro clienteSe tiene lo que se quiere, pero no lo que se necesita.Proceso de aprendizaje vs proceso de deliveryEsperar algunos sprints para aprender algunas veces cuestademasiado.
    9. 9. El rol y la misión del PO• The product owner decides what will be built and in which order• Defines the features of the product or desired outcomes of the project• Chooses release date and content• Ensures profitability (ROI)• Order (not prioritizes) features/outcomes according to market value• Adjusts features/outcomes and priority as needed• Accepts or rejects work results• Facilitates scrum planning ceremony www.scrumalliance.org/pages/scrum_roles
    10. 10. Ok… y entonces?• Discovery y develiery como 2 términos complementarios• Disovery . El aprender a aprender sobre nuestros clientes• El Product Owner como responsable del outcome. (vs output)• Buscar cambiar el mundo.
    11. 11. Cómo mejoramos el delivery?• Hay muchas tácticas que pueden tomarse de LEAN• "Genba" (ir y estar en la escena del crimen). Ver los problemas• Story Mapping. "Historias y no tarjetas "• Flujo narrativo / experiencia. Patrón holístico de que aprendimos de nuestros usuarios Qué hay del ROI y el BV?
    12. 12. Business Value• Es el trabajo del PO especificar lo mejor posible qué es y qué no es el BV.• En conclusión aquello que consideramos valor de negocio, se traduce a generar un outcome positivo. El resultado de construir software, el beneficio que generamos luego de establecer un delivery.• No existe relación entre la cantidad de software que se construye y el beneficio que se obtiene por ello. El outcome siempre es especulativo. Y es extremadamente difícil!!
    13. 13. Errores comúnes• Virtual product owner syndrome• The IT Product Owner• The bungee PO
    14. 14. Facultades de un PO• Saber tomar el control y sentarse en el asiente del conductor• Tener las cualidades requeridas• Conocer la importancia de su rol
    15. 15. Siendo un PO efectivo (cont.)• Los 7 hábitos del PO efectivo (Ricardo Colusso) o Maximizar la empatía y entender contextos o Mantenerse en el asiento del conductor o Backlog Kaisen (mejora continua) o Maximizar sinergia con SM o Entender el dentro y fuera o Ayudar al SM con el equipo o Definir el concepto de LISTO• Conocer y desarrollar técnicas que creen valor. (MMFS / Effective Mapping / One at a Time / Release commitments / Adaptive planning )• Customer Discovery (salir del edificio)
    16. 16. Conclusiones• Saber diferenciar el delivery y discovery y actuar en consecuencia de ello.• Colaborar con el equipo constantemente y saber dirigir y guiar al mismo. (Llevar el backlog / contestar las preguntas que surgan, proveer feedback, y hacer sign off de los resultados)• Sentarse en el asiento del conductor. Definir el qué y el cuándo debe ser entregado• Conocer (superficialmente) cómo es construido el software. Mejora la comunicación con los equipos de desarrollo.

    ×