![Scrum con éxito Barcelona PHP Conference 2009 Jordi Salvat i Alabart +34 676 49 86 00 [email_address] http://jordionsoftware.blogspot.com/](https://image.slidesharecdn.com/scrumconexito-091031115959-phpapp01/85/Scrum-Con-Exito-1-320.jpg)
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a Scrum Con Exito
Similar a Scrum Con Exito (20)
Último
Último (13)
Scrum Con Exito
- 1. Scrum con éxito Barcelona PHP Conference 2009 Jordi Salvat i Alabart +34 676 49 86 00 [email_address] http://jordionsoftware.blogspot.com/
- 2. Introducción Esto no es una introducción.
- 3. Presentación Esto sí es una presentación.
- 5. Manifiesto por el Desarrollo Ágil de Software Estamos descubriendo mejores maneras de desarrollar software, a base de hacerlo y ayudar a otros a hacerlo. Con este trabajo hemos llegado a valorar: Los individuos y las interacciones más que los procesos y las herramientas. El software en funcionamiento más que la documentación exhaustiva. La colaboración con el cliente más que la negociación de contratos. Responder al cambio más que seguir un plan. Eso es: aunque hay valor en los ítems abajo, valoramos más los ítems de arriba.
- 6. 1ª Parte Algunos Conceptos Esenciales
- 7. No silver bullet “There is no silver bullet but agile methods come very close.” Jim Johnson Chairman of The Standish Group
- 8. Scrum es sencillo PMBOK Guide: 390 pág. Scrum Guide: 14 pág.
- 9. Inspecciona y adapta Planificar entregas Planificar el día Planificar Sprints Retros- pectiva Demo
- 10. Bibliografía Schwaber, Ken; Beedle, Mike (2002) Agile Software Development with Scrum W.E. Deming (1986) Out of the Crisis
- 11. Facultación
- 12. Facultación Confianza Paciencia Coraje
- 13. Bibliografía Kenneth Blanchard, Spencer Johnson (1982) The One Minute Manager Peter Drucker (1966) The Effective Executive
- 14. Formación de un equipo
- 15. Formación de un equipo
- 16. Formación de un equipo
- 17. Formación de un equipo
- 18. Bibliografía Tom DeMarco, Timothy Lister (1987) Peopleware: Productive Projects and Teams
- 19. El rol del Scrum Master Facilitar
- 20. ¿Preguntas?
- 21. 2ª Parte Recomendaciones Prácticas
- 22. No te mires el ombligo “ La colaboración con el cliente más que la negociación de contratos.”
- 23. La política importa “no aún” vs. “descoped” “retrospectiva” vs. “post-mortem” “2004.40” vs. “2004.4”
- 24. ¡O todo o nada! “Esto en mi empresa no se puede hacer.” “¿Se puede implementar Scrum paso a paso?”
- 26. Una sola zona horaria
- 27. Una sola cultura
- 30. Off-shore
- 34. KISS Los individuos y las interacciones más que los procesos y las herramientas.
- 35. KISS
- 36. KISS ¿Pero... y el repositorio histórico?
- 37. Entrega a menudo DoD = en producción
- 38. Un sombrero por cabeza
- 39. Quién mucho aprieta poco abarca
- 40. Bibliografía Henrik Kniberg (2007) Scrum and XP from the Trenches Ken Schwaber (2009) Scrum Guide
- 41. ¿Preguntas?
- 42. Muchas gracias Jordi Salvat i Alabart +34 676 49 86 00 [email_address] http://jordionsoftware.blogspot.com/
Notas del editor
- Buenos días. Gracias por madrugar. Me llamo Jordi y voy a daros una charla que muy pretenciosamente he titulado “Scrum con éxito”.
- * NO voy a hacer una introducción a Scrum. * NO voy a intentar venderos Scrum. * NO voy a hablar de como programar ágilmente (Lars cubrió esto en su conferencia de ayer). ¿Cuantos de vosotros sabéis qué es Scrum? ¿Cuantos lo estáis usando o lo habéis usado en el pasado? ¿De los que lo usáis o lo habéis usado, cuantos consideraríais la experiencia como exitosa? Vamos a hablar de algunos factores que he observado pueden hacer la diferencia entre Scrum con éxito o Scrum cancelado.
- * Me llamo Jordi. Llevo 26 años en el mundo del software. 6 “intentando” gestionar equipos de desarrollo con agilidad en *startups* haciendo *aplicaciones web* para *clientes internos*. Ahora ejerzo de CTO en Salir.com. Avisos: 1/ Si vuestro trabajo no encaja en esta descripción, puede que mis recomendaciones no os valgan para nada. 2/ Puede que no os valgan para nada de todos modos. 3/ NO ME GUSTA SCRUM. Pero a base de porrazos, he decidido adoptarlo.
- ¿Porque una presentación de Scrum en una conferencia de PHP? * Llevo 3 curros en PHP. * En todos el equipo estaba quemado. * En todos el código estaba “podrido”. * No quiero que me vuelva a pasar. * Las técnicas para evitar tanto el código podrido como la desmotivación son conocidas, pero los equipos del mundo PHP (y sus managers) parecen incapaces de organizarse para aplicarlas. * La razón esgrimida siempre es la misma “no tenemos tiempo”. Y eso no es verdad: todos tenemos una hora cada hora. * Scrum te ayuda a decidir qué hacer (y sobretodo qué NO hacer) con esa hora.
- Antes de empezar me gustaría recordar el “Agile Manifesto”, pues es probable que lo mencionemos varias veces hoy. Este “manifiesto” salió de una reunión de varios “agilistas” (Kent Beck, Alistair Cockburn, Martin Fowler, Ken Schwaber,...) que, viendo que cada uno proponía métodos distintos, pero que tenían mucho en común, intentaban ponerse de acuerdo en la definición de “ágil”. Tengámoslo presente, porque contiene respuestas a muchos dilemas que se nos presentarán durante nuestro trabajo diario – sobretodo si tenemos un rol de gestión.
- (Si tenéis preguntas: * Relacionadas: interrumpid. * No relacionadas: por favor al final.) Esta charla tiene dos partes: 1. Algunos Conceptos esenciales 2. Recomendaciones prácticas Los “Conceptos Esenciales” de los que voy a hablar son la “Inspección y Adaptación”, el “Empowerment”, el “Equipo Auto-Organizado”, y el “Coraje”. No pretendo explicar a fondo estos conceptos. Solo pretendo manifestar la dificultad y provocar vuestra curiosidad... para recordar esto inserto mis recomendaciones bibliográficas en la presentación.
- Como me pidieron que diese esta charla en castellano... “No existe la panacea universal, pero los métodos ágiles se le acercan mucho.” Scrum NO va a resolver tus problemas. Tus problemas los vas a resolver tu y tus compañeros de trabajo, trabajando duro e inteligentemente. (Mención a la conf. de Lars y las técnicas de XP y TDD) Es * esencial* entender esto: Scrum no resuelve problemas. Los problemas los resuelve la gente. Scrum proporciona mecanismos para identificar los problemas y construir un ambiente de trabajo que genere soluciones.
- El PMBOK resume los conocimientos “generalmente reconocidos como buena práctica en la mayoría de proyectos la mayoría de las veces”. Las metodologías de gestión de proyectos suelen apoyarse en estos conocimientos, incluyendo esas y otras prácticas menos consensuadas. Scrum es diferente. Es más sencillo. Se describe en 14 páginas! ¿Significa esto que es más fácil de implementar? SI: su mecánica es más fácil. NO: hacerlo BIEN es igual de difícil, si no más.
- Que sea sencillo – incluso que la mecánica sea fácil – no significa que dé poco trabajo! Los bucles de inspección y adaptación son estrechos: cada día, cada 1-3 semanas, cada release, tenemos que inspeccionar y adaptar. Scrum *necesita* mucha energía y muchas ganas de trabajar. Ideal para startups. Revulsivo en la gran empresa. Este es un buen argumento para “vender” scrum a un jefe muy controlador: “ como Scrum Master voy a estar día a día encima de lo que sucede en el proyecto. ” Pero Scrum requiere todo lo contrario de un jefe controlador...
- Bibliografía para “ Inspecciona y Adapta”: podéis ir a las fuentes teóricas del control de procesos, pero yo os recomiendo la lectura cuidadosa del libro que divulgó originalmente Scrum. Los que prefiráis un clásico, William E. Deming es el padre de la gestión moderna de la calidad (en occidente) y fue el primer proponente (occidental) del ciclo de mejora continua (“Plan-Do-Check-Act”).
- Scrum necesita que el equipo tenga plena capacidad para decidir *como* hacer el trabajo. (Fijaos que digo *como* hacer el trabajo. El *que* lo decide el Product Owner, en el mejor interés del cliente.) Facultar (“to Empower”) no significa poderse pedir una silla (aunque también, por supuesto!) Significa dar capacidad para * decidir* . Y eso implica la aceptación de la toma de riesgos asociada, y por lo tanto la aceptación del posible fracaso. “ Facultar”, “Empower”, significa *dar permiso para fracasar* (o “pá cagal'la”). Incluso varias veces.
- La mayoría de los directivos (y me incluyo) tenemos muchas dificultades para facultar a nuestros equipos. Esa es una tarea que requiere confianza, esfuerzo, y coraje. Hemos llegado a la dirección porque somos buenos en nuestro trabajo, y cuesta confiar en personas con menos experiencia que nosotros. Se nos pide que nos impliquemos en el proyecto y que seamos resolutivos – como podríamos tener paciencia? Pero lo más difícil es algo que se nos supone, pero que a la hora de la verdad pocas veces demostramos: CORAJE. Luego explicaré porqué.
- Sobre el “empowerment”, recomiendo este libro, ya clásico (del año 1982). Tiene la ventaja de que es pequeñísimo. Peter Drucker es unos de los grandes teóricos americanos del management, y “The Effective Executive” uno de sus best-sellers. Muy recomendable para cualquier persona con responsabilidades de liderazgo – y no solo por el concepto de “empowerment”.
- El mayor ejemplo de la necesidad de confianza, paciencia y coraje lo encontraremos en la formación del equipo como tal. Este gráfico representa el rendimiento típico de un equipo a lo largo del tiempo (podría ser su velocity en sucesivos sprints). Es bastante curioso como distintos equipos enfrentados a distintas tareas muestran frecuentemente un comportamiento similar. Bruce Tuckman estudió, en los años 60 del siglo pasado, la formación y comportamiento de los equipos, e introdujo el modelo “Forming Storming Norming Performing”.
- Las cuatro fases de formación del equipo definidas por Tuckman son aquí visibles: la de formación, en la que el equipo interacciona respetando las normas generales de relación humana (sociales y laborales). Tiene un rendimiento estable pero perceptiblemente bajo, que pone a prueba la confianza del directivo. Aquí vemos a Guardiola bien confiado...
- La de enfrentamientos, en la que el equipo sufre mientras define sus normas internas y cada uno encuentra su lugar en el. Los fracasos son frecuentes en esta fase, y aquí es donde se pone realmente a prueba la paciencia y el coraje del directivo. Guardiola está preocupado. Pero deja jugar. Muchos otros al llegar a esta fase dicen “Scrum no funciona” y prefieren intervenir, esencialmente condenando al equipo a una permanente fase de formación.
- Solo el manager que exhibe suficiente confianza, paciencia , y coraje – y, naturalmente, que conserva el apoyo de su dirección en el proceso (“a dead Scrum Master is a useless Scrum Master”) – supera esta fase y llega a la normalización: la formación de un equipo que realmente merece el nombre de tal. Si el equipo ha llegado hasta aquí y no sufre actos de “equipicidio”, seguirá mejorando indefinidamente. La teoría de Tuckman es que cada fase requiere un estilo de gestión diferente. Algunos discrepan, y proponen que es el equipo el que debe superar cada fase por sus propios medios. El manager solo debe evitar impedirlo.
- Peopleware es el mejor libro que he leído sobre formación de equipos. De hecho, el mejor libro que he leído sobre desarrollo de software. Lo recomiendo a todo el mundo, desde el desarrollador más novato al director general más empedernido.
- Ya para terminar esta primera parte de la presentación, hablemos del rol del S.M. en todo este proceso. Nos preguntaremos: si tengo que dejar que el equipo se auto-organice, como puedo “estar encima del proyecto”, inspeccionar y adaptar? La respuesta es que el Scrum Master debe ser un facilitador. Debe vigilar que el equipo inspeccione y adapte; que supere cada fase de su formación. Debe ayudar eliminando cualquier obstáculo que pueda impedirlo. Es fácil de decir, difícil de hacer y, probablemente, imposible de explicar.
- Y así llegamos al final de la primera parte de este presentación. Disponemos de 30-$m minutos para preguntas.
- Vamos a por la segunda parte de esta presentación, la de recomendaciones prácticas. No esperéis que sea muy ordenado. Es solo una colección de observaciones y experiencias bastante dispares. Naturalmente, cada una de estas recomendaciones puede funcionar o no para ti en tu circunstancia.
- Scrum pone mucho énfasis en dar VISIBILIDAD y CONTROL al cliente. El equipo de unos colegas implementó Scrum... sin Product Owner y sin Demo. Es decir: solo los aspectos internos al equipo de desarrollo. Ken Schwaber llamaría a esto un “scrumbut” [Explicar qué es un “scrumbut”?]. Lo abandonaron al 4º sprint. Hasta que se demuestre lo contrario, no es posible implementar Scrum sin visibilidad o sin apoyo del cliente y el management.
- Aún sin llegar al extremo de suprimir los elementos de comunicación hacia afuera, es fácil caer en el error de no dedicarle suficiente esfuerzo. Yo mismo coseché un fracaso importante por no dedicar suficiente esfuerzo a la comunicación hacia arriba: la comunicación de inicio de sprint (anunciando el objetivo), la demo (informando de su consecución), y todas las reuniones para definir y priorizar funcionalidades que mantiene el P.O. con el cliente son importantísimas. Dedícales esfuerzo. Como te expresas es también importante [anécdotas].
- La primera afirmación era la excusa del equipo que mencionaba antes. La segunda pregunta es frecuente. * Una empresa [recuerdo: startup, web, interno] donde no se puede usar Scrum tiene problemas que Scrum podría resolver. Pero para ello hay que tener la paciencia y el coraje de conseguir el apoyo necesario e implementarlo en serio. * En un trabajo anterior hice una implementación paso a paso. En Salir.com la he hecho de golpe. Mi conclusión es que llegas al mismo sitio, pero mucho más deprisa. [Explicar: Ken Schwaber's Scrumbut]
- Hace ya unos cuantos años, yo volaba en parapente (gané el campeonato de España del '92). Siempre decíamos: no acumules dificultades. Mucho tiempo sin practicar + dormido poco + ala nueva + lugar nuevo + meteorología complicada = accidente seguro. Es una perogrullada, pero para empezar, conviene ir a por lo fácil. En una ocasión cometí el error de permitir al equipo crecer excesivamente rápido, sin dar tiempo a formarse. La fase de “storming” se eternizó hasta que la dirección decidió liquidar el proceso. [Comentario de Mitch Lacey: adding a member resets the team to forming phase.]
- Muchos equipos empiezan su implementación de scrum buscando herramientas que lo soporten. Hay muchas. Me gustan Greenhopper (sobre Jira) y Banana Scrum. Pero después de haber visto a otros usarlas y de haber usado Jira yo mismo en mi equipo, decidí probar con una pizarra y post-its. La posibilidad de interaccionar moviendo y pegando papelitos, señalándolos, escribiendo en ellos,... compensa CON CRECES cualquier ventaja de las herramientas (básicamente que suman horas automáticamente).
- Esta es nuestra pizarra. Tenemos un código de colores MUY sencillo y mantenemos los elementos y su disposición de sprint en sprint. No la cambiaría por nada en el mundo. Incluso teniendo en cuenta que nuestro PO es remoto: le mandamos una foto cada día para que pueda seguir el scrum.
- He recomendado utilizar soluciones simples? [Enseñar mi “repositorio”]
- Los equipos que usan Scrum suelen luchar con la definición de “done” – su validación es muy elusiva. En las aplicaciones web, tenemos una ventaja: podemos definir “done” como “en producción”. Esto facilita la comunicación con los clientes y evita de cuajo el problema de “está al 90%”. Por supuesto esto requiere automatizar proceso prueba y release. Creo radicalmente en esta recomendación: hay que hacer CUALQUIER cosa para que haya release al final del sprint.
- La mayoría de los proponentes de Scrum indican que no es conveniente mezclar roles – especialmente el de Scrum Master y Product Owner, y sobretodo nunca los tres. Mi experiencia corrobora esta recomendación: me tengo por una persona bastante ecuánime, pero hasta que no conseguí transferir el rol de Product Owner, el equipo se sobrecargaba en cada planificación.
- No sobrecargues el Sprint. Meter presión NO FUNCIONA. O no se cumple o se paga caro más tarde con problemas de calidad. En mi equipo actual las cosas cambiaron radicalmente cuando empezamos a planificar POR DEBAJO de nuestro focus factor promedio [explicar focus factor?].
- El libro de Henrik Kniberg es tremendamente práctico y simplemente describe lo que ha funcionado y lo que no para él, sin más pretensiones – un poco al estilo de esta segunda parte de mi presentación (pero mucho más completo, claro!). Está disponible on-line. La Scrum Guide es lo más próximo que existe a una definición “oficial” de Scrum. Contiene todos los elementos, pero es enormemente breve (14 pág., como he dicho).
- Tenemos 60-$m minutos para preguntas.