Scrum ManagerScrum Manager es una visión de scrum amplia y flexible:  la original de Nonaka y Takeuchi,  diferente a la implantación concreta de la Scrum Alliance.

Scrum Manager y Scrum Alliance no son lo mismo. Las características de flexibilidad,  globalidad, y síntesis entre la agilidad y el conocimiento anterior (CMMI, 15504…) así como la difusión abierta, y condicionada a la calidad son aportaciones de Scrum Manager, o cuando menos, otra forma de interpretar los entornos de trabajo que Nonaka y Takeuchi llamaron “campos de scrum(1)” hace 25 años, y de compartirlo y difundirlo.

Convencidos de que es un error monopolizar el concepto de campo de scrum. De que se encorseta y se empobrece al trocar los principios básicos(2) por prácticas determinadas de sprints, backlogs y reuniones; y de que se podían aportar mejoras sustanciales a lo carísimo del modelo “comercial” de formación scrum, y al criticado certificado scrum master, Claudia y el que suscribre nos decidimos a no sólo hablar de alternativas, sino a construirlas.

Y como, “¿Cuál es la diferencia con Scrum Alliance?” o “¿Qué aporta?”,  son preguntas frecuentes, cuando no críticas, :-( estas son, contadas con brevedad y objetividad, las razones y mejoras aportadas con  Scrum Manager:
1.- MEJORABLE: El enfoque de Scrum en el área de gestión de proyectos está bien, pero un “campo de scrum” implica también al área de programación o desarrollo de producto y también a la gerencia y dirección de la organización.

APORTACIÓN: Scrum Manager contempla tres áreas de conocimiento: Proyecto, Producto y Gerencia.

2.- MEJORABLE: La formación de Scrum Master sólo muestra las prácticas scrum de la Scrum Alliance.

APORTACIÓN: Scrum Manager presenta una síntesis de conocimiento entre procesos y agilidad: un enfoque objetivo mostrando la agilidad como antítesis de los procesos y las posibilidades que la síntesis de los dos conocimientos da a un gestor: como “criterios de gestión” en lugar de “recetas de actuación”.

3.- MEJORABLE: La formación de Scrum Alliance tiende a hacer olvidar el concepto original de campo de scrum y monopolizar scrum como las prácticas que ella misma define,  empobreciendo las posibilidades de implementación de cada campo de scrum de la forma más adecuada a cada organización.

APORTACIÓN: Flexibilidad. Es un principio de Scrum Manager: adecuar las prácticas ágiles a la empresa, y no al revés.

4.- MEJORABLE: Los certificados de la Scrum Alliance se obtienen sólo por pagar los 1.000€ o más que vale el curso de 2 días. Puede acudir una persona sin entender inglés a un curso scrum manager dictado en inglés, no entender nada y sin ningún examen ni comprobación lograr la certificación  Scrum Master.

APORTACIÓN: Un modelo enfocado en la formación, que permita incluso lo contrario: poder aprender y obtener un certificado acreditando que se sabe, de forma gratuita. (http://www.scrummanager.net/ok). Los certificados de Scrum Manager requieren un examen y actualmente un 20% de los presentados los suspenden y no obtienen la certificación.

5.-MEJORABLE : Servicios profesionales presenciales (franquiciados) centrados en el negocio, que exigen una tasa de franquicia para dar formación, generando como consecuencias: a)encarecimiento de los costes normales de un curso presencial, b) formadores más centrados en el negocio que en los resultados de los alumnos.

APORTACIÓN: modelo partnership de Scrum Manager sin canon de entrada ni cuota de mantenimiento. Concesión otorgada y mantenida por la valoración de calidad de los cursos (http://scrummanager.net/qa). Consecuencia: los formadores tienen como principal interés ofrecer formación de calidad, (la valoración media de los cursos presenciales actualmente es > 8 ) y el modelo garantiza que un formador que no ofrece calidad no puede trabajar con Scrum Manager.

6.-MEJORABLE:  Modelo de certificación “parco”. Me explico: con dos días de formación, (aun suponiendo que sea de calidad y con examen) ya se es “ágil certificado” (?), sin marcar ningua apreciación de grado. Un profesional puede, además de conocer del scrum rígido de la Scrum Alliance,  saber también de gestión de equipos, producto, recursos humanos, cultura ágil, o de prácticas de programación ágiles: integración continua, TDD, etc… Decir que una persona es Scrum Master, no es decir mucho de cuánto sabe de agilidad.

APORTACIÓN: Modelo de certificación con puntos de autoridad. La certificación Scrum Manager va vinculada a un grado de autoridad, que es proporcional a las áreas de conocimiento acreditadas.

He intentado sintetizar, y escribiendo un poco a vuela pluma. Seguro que me dejo cosas, pero creo que en conjunto este es el mapa general de razones y diferencias entre Scrum Alliance y Scrum Manager.

 

Este artículo fue publicado originalmente en scrummanager.net el 11 de agosto de 2010

(1) “Moving the Scrum Downfield” – The New New Product Development Game. (Hirotaka Takeuchi and Ikujiro Nonaka. 1986)
(2) Built-in instability – Self-organizing project teams – Overlapping development phases – Multilearning – Subtle control – Organizational transfer or learnig.

 

scrum 4 software originalScrum es el término dado por Nonaka y Takeuchi al método de desarrollo de nuevos productos realizado con equipos reducidos, multidisciplinares, trabajando con comunicación directa y empleando ingeniería concurrente, en lugar de ciclos o fases secuenciales.

Este marco de de trabajo logra niveles de eficiencia y valor en el producto superiores a los obtenidos con ingeniería secuencial y producción basada en procesos. En los 80, Nonaka y Takeuchi analizaron esta forma de producción, observando a los equipos de empresas tecnológicas que lograban mayores niveles de eficiencia y valor en sus productos ("New New Product Development Game"): Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox y Hewlett-Packard.

Diez años más tarde Ken Schwaber presentó en OOPSLA (1995) la descripción de un marco para implementar Scrum en el desarrollo de Delphi, en el que él trabajaba.

Las prácticas para aplicar Scrum en proyectos de software se vienen enriquecendo desde entonces, y poco tienen que ver las implementaciones actuales con la original de Ken. Ahora es muy raro que un equipo use Scrum con los controles originales (paquetes, cambios, riesgos, soluciones...) el Backlog único ha evolucionado a Backlog de producto y Backlog de Sprint. También es habitual usar un backlog estratégico o "Epics" de producto. La evolución añadió a la reunión de revisión de sprint, otra de inicio; y más tarde otra de retrospectiva. Tampoco se suele usar la fase de cierre, etc.

También la prácticas se han enriquecido. En 2001 apareció el gráfico burndown, más tarde empezó a ser habitual el uso de estimación de póker, luego tableros de control visual kanban...

Para tener una visión de retrospectiva, este es el "paper" de Ken Schwaber presentado en 1995 su implementación de Scrum en OOPSLA: "SCRUM Development Process " y este otro su artículo del mismo año "Living on the Edge" en el que describía su implementación de Scrum para Software.

Un adelanto de la "metodología" y su fases:

Los primeros en observar diferentes implementaciones de SCRUM para el desarrollo de nuevos productos con alto rendimiento fueron Takeuchi y Nonaka (1) en Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox, y Hewlett-Packard.
Coplien ha seguido y documentado un enfoque similar para el desarrollo de software en Borland, logrando la mayor productividad con C++ (1). Recientemente, Jeff Sutherland ha aplicado un enfoque más refinado de SCRUM en Smaltalk, y Schwaber en el desarrollo de Delphi.
...
Llamamos a este enfoque metodología SCRUM (véase Takeuchi y Nonaka, 1986) por el uso del término SCRUM en rugby –la formación cerrada que forman los delanteros para realizar el avance-
...
Scrum es una metodología para mejora y mantenimiento de un sistema existente o la producción de un prototipo. Se asume la existencia de diseño y código en su mayor parte orientado a objetos, basado en librerías y clases. SCRUM gestionará la reingeniería completa posterior de sistemas heredados.
.....

FASES DE SCRUM

SCRUM comprende las siguientes fases:

1.- Pre-juego

Planificación: Definición de una nueva versión basada en la pila actual, junto con una estimación de coste y agenda. Si se trata de un nuevo sistema, esta fase abarca tanto la visión como el análisis. Si se trata de la mejora de un sistema existente comprende un análisis de alcance más limitado.
Arquitectura: Diseño de la implementación de las funcionalidades de la pila. Esta fase incluye la modificación de la arquitectura y diseño generales.

2.- Juego

Desarrollo de sprints: Desarrollo de la funcionalidad de la nueva versión con respeto continuo a las variables de tiempo, requisitos, costo y competencia. La interacción con estas variables define el final de esta fase. El sistema va evolucionando a través de múltiples iteraciones de desarrollo o sprints.

3.- Post-juego

Preparación para el lanzamiento de la versión, incluyendo la documentación final y pruebas antes del lanzamiento de la versión.

 

scrum 4 software original 1

 

herramienta scrumLa agilidad sólo tiene un factor imprescindible; uno sin el cual no es agilidad, y sin embargo es muy habitual centrar la atención y la formación en lo accesorio.

 

personas sobre procesos y herramientas

(Publicado originalmente en navegapolis.net el 26 de sept. de 2010)

 

huiAlgunas empresas deben a los procesos y la tecnología su "saber hacer". La maquinaria y los procedimientos se encargan de elaborar los productos con el menor número de operarios posible, y que aquellos sean de buena calidad, a pesar de estos.

La cultura empresarial no preocupa mucho, porque a los procedimientos y a las máquinas no les afecta, y como de las personas sólo interesa que las atiendan siguiendo los procedimientos, basta con que la cultura garantice la ausencia de huelgas y sabotajes.

Sin embargo, otras empresas deben su "saber hacer" a las personas. En ellas las máquinas y los procedimientos ayudan a los humanos, y no al revés; y como las personas son de sicología complicadas, resulta que el talento, aunque lo tengan, no lo pueden desarrollar si no se encuentran motivados. En estas empresas la cultura es una variable muy relevante, porque las culturas tóxicas atrofian o espantan al talento.

 

cultura

 

Resulta visual y acertada la simplificación de las posibles culturas de empresa posibles del artículo What Holds the Mordern Company Toghether (Rob Goffee, Gareth Jones, 1996). Desde su perspectiva, éstas son resultado de la combinación en mayor o menor medida de dos dimensiones: sociabilidad y solidaridad.

Tomando a la sociabilidad como el grado de relación emocional y no insturmental (que no es un simple medio de satisfacer las propias necesidades) que existe entre las personas. Las relaciones de amistad son relaciones de sociabilidad elevada.
Y tomando por solidaridad a la actitud del equipo en el que prima el enfoque estratégico, la reacción contra la amenaza de los competidores y la intolerancia al bajo rendimiento.

Con estas premisas, la cultura ideal es la comunal al combina ambas dimensiones, porque aunque podría parecer que con dosis elevadas de sociabilidad bastaría, la sociabilidad alta, con ausencia de solidaridad tiene inconvenientes, porque el predominio de la amistad puede tolerar rendimientos bajos.

Cuando el nivel de sociabilidad es mucho mayor que el de solidaridad, el trabajo se resuelve con el mejor "compromiso" no con la mejor "solución"; y también es frecuente el desarrollo de camarillas y redes informales que burlan y pueden socavar la institucionalización de procedimientos en la empresa.

 

cultura

 

"Estamos poniendo al descubierto mejores métodos para desarrollar software, haciendo y ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar:

A los individuos y su interacción, por encima de los procesos y las herramientas."

2001, Manifiesto Ágil

 

Este artículo se publico originalmente en navegapolis.net el 23 de septiembre de 2007

errorLos modelos de evaluación y mejora de procesos se basan en el principio "La calidad del sistema, o del producto depende principalmente de la calidad de los procesos empleados para su desarrollo".

Por ejemplo, CMMI identifica 25 áreas clave de procesos con objetivos y prácticas que determinan cómo de bien se está haciendo el producto: el software.

De esta forma, garantizar la integridad de los fuentes, y controlar adecuadamente las versiones de todos los documentos, librerías y demás elementos de la configuración es una de las 25 áreas de procesos.

Sin duda se pueden diseñar procesos y tecnología que garanticen la calidad cuando de producción industrial se trata, pero ¿también para construir diseños de arquitecturas ingeniosos e implementaciones inteligentes?

Cuando la eficiencia no consiste en producir más líneas de código en menos tiempo, sino en diseñar arquitecturas simples, robustas y escalables, ¿también se puede mejorar la eficiencia mejorando los procesos?

La innovación, los diseños de las arquitecturas y las estrategias de solución deben su valor a las personas, no a los procesos.

Las organizaciones que desarrollan software para sistemas novedosos o para sectores de mercado de cambios rápidos o bases tecnológicas inestables pueden mejorar su valor y eficiencia a través de los procesos en el porcentaje que sea, pero si buscan la excelencia, no en los procesos sino en el talento de personas motivadas, dispararán esos mismos valores.

Las organizaciones de software que dan soluciones a entornos de problemas bien conocidos, que necesitan poca innovación, que desarrollan sistemas con niveles altos de integridad, que trabajan en sistemas que pueden definirse con detalle desde el primer día, y sobre bases tecnológicas más contrastadas y estables, pueden aprovechar mucho mejor las ventajas de mejora, repetibilidad y escalabilidad que dan los modelos de mejora basados en procesos.

(publicado el 3.08.2006 en navegapolis.net)

 

 

 

agua aceiteCombinar la agilidad con un modelo de procesos puede ser una estrategia o un contrasentido; una táctica razonada y razonable, o el disparate de un gestor engañado.

Los modelos de procesos como CMMI, ISO 15504, o Spice (que fue la versión beta de éste último) se fundamentan en la teoría sobre calidad y eficiencia desarrollada en la manufactura industrial, donde los protagonistas y responsables del saber hacer y de la calidad son los procesos; y donde las personas son recursos necesarios para asistir a éstos.

"La industria manufacturera ha reconocido la importancia de la efectividad de los procesos y la eficiencia. Hoy en día, muchas organizaciones en el sector manufacturero y de servicios a reconocer la importancia de los procesos de calidad"...

En la década de 1930, Walter Shewhart comenzó a trabajar en la mejora de procesos con sus principios de control estadístico de calidad [Shewhart 1931]. Estos principios fueron refinados por W. Edwards Deming [Deming 1986], Philip Crosby [Crosby 1979], y Joseph Juran [Juran, 1988]. Watts Humphrey, Ron Radice, y otros extendido estos principios aún más y comenzó a aplicar a software en su trabajo en IBM y el SEI [Humphrey, 1989].
SEI ha tomado la premisa de la gestión sobre procesos, "la calidad de un sistema o producto es sobre todo consecuencia de de la calidad del proceso utilizado para su desarrollo y mantenimiento", y CMM se desarrolla sobre esta premisa. La creencia en esta premisa es compartida en todo el mundo por los movimientos de calidad, como lo demuestra la Comisión Electrotécnica Internacional (ISO / IEC) de la Organización Internacional de Normalización ISO..."

CMMI DEV 1.2, pág. 16


Las prácticas ágiles son exactamente lo contrario: métodos de trabajo que ayudan a los personas, que son quienes tienen el  know how y los responsables de la calidad.

"Preferimos el valor de las personas y su interacción al de los procesos y las herramientas"

Manifiesto ágil.

Hay empresas o departamentos que integran o mantienen sistemas, o que realizan tareas en las que quizá se puede explicitar en procesos el conocimiento necesario en un... ¿60, 70, 80%?.

En otros casos ocurre lo contrario.

Para no disparatar el modelo de producción conviene saber en qué caso se está, y no caer en la tentación de mezclar agua y aceite. Los dos principios a la vez, no son posibles. Sí lo es sin embargo una síntesis del conocimiento de ambos; y cuando se trata de una empresa ágil, que no busca también una evaluacion CMMI sino el conocimiento útil que de él puede emplear, este quizá sea un buen consejo:

Tomar las metas y prácticas globales de CMMI, pero olvidarse de aplicarlas a las áreas de procesos, y aplicarlas a las prácticas ágiles que emplean, porque CMMI cubre algo que las prácticas ágiles no abordan: la institucionalización y homogeneización de la forma de trabajo. Algo que llevan a cabo las metas y prácticas globales.

Se trataría de aplicar procesos para la homogeneidad en organización, la formación de las personas y la mejora de las prácticas y agilidad para la producción.

(Publicado el 29 del 11 de 2009 en navegapolis.net)

 

 

envejecido"La empresa empieza a contratar MBAs y ejecutivos con marchamo blue-chip. Empiezan a brotar, como las malas hierbas, los procesos, procedimientos, listas de control, etc. Sobre el inicial entorno igualitario se va construyendo una rígida jerarquia. Se crea orden en el caos, pero también se mata el espíritu emprendedor. Nace la burocracia para compensar la incompetencia y establecer la disciplina".

Jim Highsmith, Agile Project Management

 

(Publicado el 16.05.2008) en navegapolis.net