documentacion scrum en el proyectoYo no usaría más documentación de proyecto que la extrictamente necesaria. Pero las organizaciones que empiezan a ser, o son grandes y usan scrum pueden necesitar: internamente institucionalizar los métodos empleados, y de cara al cliente incluir en la documentación del proyecto la descripción del ciclo de vida que se va a emplear, porque normalmente los clientes no saben de scrum y además porque se necesita su implicación como gestor o propietario de producto.

Si en vuestra empresa os hace falta alguna vez documentar para el cliente la descripción de scrum que váis a emplear en su proyecto, esta plantilla puede apuntar ideas o ser ejemplo de formato.
Si os sirve: no os cortéis, copiad y pegad  o modificad lo que queráis para ajustarla a vuestra forma de hacer.   ;-)

Safe Creative #1206241856508

comparativaJugueteando con las estadísticas de búsqueda de Google para ver qué resultados salen con "prima de riesgo" "crisis"... (eso lo pongo mejor en twitter o Google+ que aquí se queda un poco fuera de lugar) me ha dado también por ver dónde hay más interés por Scrum y Kanban (1).

Estos son los resultados:

comparativa 2 kanban scrum google 2012 600

comparativa kanban scrum google 2012 600

Consultas realizadas:

(1) Búsquedas ceñidas al área "informática y electrónica" para evitar la distorsión de scrum referido a rugby y kanban referido a manufactura industrial.

 

pinocho¿Dirías que los proyectos de tu empresa los gestionan profesionales experimentados, cuando en realidad son junior con ninguna o poca experiencia?.

Este es el brete en el que me puso hace ya algunos años un gestor de proyectos de la oficina técnica que entonces dirigía.
A las pocas semanas de entrar en la empresa (lo contraté deslumbrado por su impresionante currículum plagado de cursos y certificaciones) me preguntó si podía firmar una carta diciendo que había trabajado no sé cuantas horas en gestión de proyectos. Cosa que no era cierta.

- Es que quiero sacarme el certificado "patatín" de gestión de proyectos, que incluye la acreditación de experiencia profesional- me dijo con una sonrisa de complicidad.
- Lo más normal es que no lo comprueben, y si lo hicieran con eso basta. Es lo habitual: así me saco el certificado y la empresa puede presumir de que sus gestores de proyectos son "patatin certified".

A los pocos meses me di cuenta de en la selección de personal Pepe (digamos que se llamaba Pepe) me "metió un gol": No era tan bueno (ni de lejos) como las chapas de su curriculum insinuaban.

Calidad"He descubierto lagunas importantes entre aseguramiento de la calidad del software (SQA), control de calidad del software (SQC) y las metodologías de desarrollo ágil."
Es lo que afirma Abu Wahid Md. Masud Parvez, en el paper que acaba de publicar Advances in Information Tecnologiy and Management (Vol1, Nº3) "An effcient Approach to Interact between Agile Scrum and Quality Mamagement System".

 Es verdad que el conocimiento profesional en desarrollo ágil de software tiene una laguna importante en aseguramiento de calidad medianamente institucionalizable. Por eso son de agradecer propuestas como la de Masud.

En el informe Masud propone un proceso para desarrollo ágil de software, ligero sin sobredosis burocrática y fácil de implementar, basado en micro-ciclos paralelos a los sprints.

 

Scrum SQA

No sé si me termina de convencer esta propuesta. Quizá porque no le veo mucho encaje en el tipo de proyectos que conozco más de cerca, y prefiero usar los procedimientos sólo cuando son extriectamente necesarios,  pero hay organizaciones que bien por  el tamaño o distribución, o exigencias de procedimiento con el cliente pueden necesitar un procedimiento de de calidad institucionalizado y alineado con el hacer de equipos ágiles.
Y también, aunque tampoco te convenza una implementación "copy-paste" de este modelo, no sobra conocer el modelo y los formatos que propone.

Scrum SQA

 

 

laberintoLeo en el libro "Kanban y Scrum, obteniendo lo mejor de ambos de Henrik Kniberg y Mattias Skarin" o en "Kanban" de David J. Anderson, cosas como:

  • Scrum prescribe roles, kanban no. Scrum trabaja con iteraciones de tiempo fijo, kanban con cadencias (simples, múltiples o dirigidas por eventos).
  • Scrum limita el wip por iteración, kanban limita el wip por estado del flujo de trabajo, los equipos de scrum son multidisciplinares, en kanban pueden ser de especialistas.
  • Scrum no permite cambiar tareas del sprint, en kanban la tarea puede alterarse hasta entrar en flujo. En scrum la pila de producto debe tener la longitud de al menos un sprint. En kanban se debe atender al ritmo de arrastre de las tareas.
  • Es scrum se deben estimar las historias y las tareas, y calcular la velocidad Kanban no mide tareas ni velocidad.
  • Scrum necesita una pila de producto priorizada. Kanban la siguiente historia del cliente.
  • Scrum prescribe reuniones diarias, kanban no.
  • Scrum emplea diagramas burndown, kanban no.
  • Los tableros scrum se resetean al final de cada sprint.

etc.

La sensación de orientación con tanta sobrecarga informativa (y desinformativa) en artículos, foros, webinars, libros, posts... para cosas tan simples me recuerda a la que me quedaba de crio después de girar vueltas y vueltas mirando al cielo.

Y es que al final se nos va la atención de lo que tenemos que conseguir, y nos centramos en cómo lo tenemos que hacer, olvidándonos de que en agilidad el habíto no hace al monje, y el éxito no depende del principio de ingeniería de procesos “la calidad del resultado depende de la calidad del proceso”.

Con lo sencillas que son las cosas simples:

expertEn kanban, ¿hay que estimar las tareas?

¿En la reunión diaria hay que actualizar en las tarjetas kanban el esfuerzo pendiente?

¿Hay reunión diaria en kanban? ¿También se tienen que hacer las tres preguntas de scrum a cada miembro del equipo?

¿Con scrum puedes cambiar una historia del backlog por otra a mitad de sprint si aún no se ha empezado a programar? ¿O entonces eso sería kanban?

¿Puedes ajustar el flujo con otro criterio que no sea el WIP?

¿No estimar las tareas dilata la ejecución o reduce el efecto de la ley de Parkinson?

¿El rol de Scrum Master puede asumirlo el lider técnico?

¿Hace falta un Scrum Master en un equipo ágil maduro y experimentado?

¿Hay roles en Kanban?

¿Podemos llevar varias cadencias kanban solapadas?

¿La pila del sprint es en realidad un WIP?

¿Puedo hacer scrum si el equipo no es multidisciplinar?

En definitiva la cuestión es si deberíamos considerar que scrum, kanban u otro modelo ágil son métodos que hay que aplicar siguiendo las reglas definidas en cada caso.

Es normal adoptar métodos de reglas definidas para gestionar sistemas de producción relativamente simples o "complicados" pero de mecánica conocida y modelable1, pero sin embargo cuando se trata de sistemas "complejos" (no complicados) resuelve con mayor solvencia el conocimiento tácito de un gestor experimentado. Se trata de la misma diferencia que hay entre la producción industrial y la producción ágil, trasladada a la gerencia: “preferimos las personas a los métodos”.

Con este criterio, hay dos patrones de gestión: uno técnico, basado en la implantación del conocimiento explicitado en el proceso, y otro experto basado en el conocimiento tácito del propio gestor. 

Para la gerencia técnica el fin es conocer y aplicar perfectamente el método. 

Para la gerencia experta un método es un elemento más para enriquecer su inventario de conocimiento y criterio profesional con principios y prácticas que conforman las piezas con las que la persona es capaz de construir la solución de gestión más adecuada a cada realidad.

Un gestor técnico estimará las tareas de los sprints de un proyecto si usa el “método scrum” y no las estimará si usa el “método kanban”.

Un gestor experto conoce ambos métodos, ha adquirido conocimiento de la experiencia en diversos proyectos, con distintos equipos y personas, y sabe que según la combinación de tamaño del equipo, talento y motivación la estimación puede ser contraproducente y favorecer la ley de Parkinson, o por el contrario ser una buena práctica para combatir procrastinación o disipación. De igual forma un gestor técnico no contemplará la posibilidad de hacer sprints si usa kanban (y probablemente no comprenderá a quien lo haga).

(1) Definible con lenguajes y notaciones de modelado de procesos (UML, IDEF0, IDEF3, Diagrama de flujo...)

wise leaderFrónesis es la característica principal de los nuevos líderes, según afirman los autores que hace 30 años nos enseñaron el concepto de agilidad como avance en campos de scrum: Nonaka y Takeuchi; que comparto y me gusta tanto o más como en su momento me gustó Scrum.

Si en su artículo de entonces "The New New product development game" conceptualizaron los principios de scrum como un ecosistema para trabajo en equipo basado en principios entonces poco académicos, ahora en su artículo "The Wise Leader" presentan también nuevos principios, pero esta vez para los líderes.

Según Nonaka y Takeuchi los nuevos líderes no basan sus decisiones en conocimiento científico y técnico, propio de la formación tradicional de directivos, sino en la sabiduría obtenida de la práctica, que además de la capacidad para encontrar respuesta a un contexto particular incluye "virtud" en la toma de decisiones para que éstas sirvan al bien común.

Los mismos autores que conceptualizaron el marco de trabajo Scrum, las diferencias y relaciones entre conocimiento tático y explícito, y la evolución de éste en forma de espiral dialéctica, argumentan ahora que los líderes tradicionales gestionan con conocimiento explícito. Que a muchos les resulta difícil reinventar sus empresas al ritmo que hoy marca la tecnología, la demografía y el mercado. El liderazgo tradicional es incapaz de desarrollar organizaciones para operar en un escenario global, y sobre todo le resulta difícil transmitir a las personas valores éticos. Los CEO's ya desfasados, según esto, siguen creyendo que la codicia es buena y que el objetivo del negocio es el máximo beneficio.

"Los gerentes suelen basarse en el conocimiento explícito que puede ser medido, codificado y generalizado" dicen Takeuchi y Nonaka. Sin embargo este enfoque "supone un mundo independiente del contexto y busca respuestas universales y predictivas". "Todo el conocimiento explícito del mundo no ha evitado el colapso financiero mundial de hace tres años o la quiebra de Lehman Brothers"

Afectada por el engaño y la codicia, la gente está molesta por la ausencia de valores y ética en los negocios. Las empresas de Wall Street pensaron que podían manejar riegos mayores usando números, datos y fórmulas científicas en lugar de analizar con sabiduría la naturaleza de los préstamos.
Lo mismo ocurre con la industria del automóvil de EE.UU. que se basa en la oferta de incentivos financieros en lugar de comprender las necesidades del cliente. Depender sólo del conocimiento explícito impide conocer las dependencias del contexto y su análisis en el entorno social.

Nonaka y Takeuchi proponen en su artículo la frónesis aristotélica, síntesis del conocimiento científico y técnico, como clave del nuevo liderazgo, y la definen como "el conocimiento tácito adquirido por la experiencia que permite a las personas hacer juicios prudentes y actuar de forma adecuada a cada situación, guiadas por los valores y la moral".

Según los autores son seis los principios de los líderes sabios:

 

  • Los líderes sabios toman decisiones sólo despues de averiguar lo que es bueno para la organización y la sociedad.
  • Captan rápidamente la esencia de las situaciones y los problemas, comprendiendo la naturaleza y el significado de las personas, las cosas y los hechos
  • Crean contextos de trabajo basados en el diálogo y el consenso
  • Saben cómo elaborar metáforas e historias para transformar la esencia de su experiencia en el conocimiento tácito de los individuos y los grupos.
  • Tienen la capacidad política de reunir a personas con objetivos en conflicto y estimular a la acción.
  • Fomentan el desarrollo de la frónesis en otros.

 

Entrevista a Takeuchi y Nonaka sobre su artículo The Wise Leader