aportacionesDoce años antes de que Ken Schwaber presentara la metodología scrum, el "modelo de desarrollo evolutivo" definía un ciclo de vida iterativo e incremental, que concretaba los requisitos de cada iteración...

 

evol1 evol2

Alan M. Davis "Software Life Cycle Models"

 

Artículo publicado originalmente en navegapolis.net el 2 de enero de 2009

rectificarLa Ingeniería del Software cumplió 40 años el pasado 7 de octubre,(*) porque 40 son los que han pasado ya desde la conferencia de la NATO(1) en la que así se bautizó a la nueva disciplina profesional, que nacía para solucionar los desplantes del software en los proyectos militares, a los que hacía perder millones de dólares porque siempre entregaba tarde mal y nunca.

La tesis con la que comenzaba la espiral de evolución del conocimiento de esta nueva disciplina profesional, tenía como premisas: rigor y precisión en los requisitos del producto, y gestión de los proyectos basada en la planificación y el control.

25 años más tarde, la agilidad planteó su antítesis, porque esas premisas estaban resultando inadecuadas para un nuevo tipo de proyectos que no necesitan previsibilidad, sino rapidez e innovación continua. 

Si errar es humano y rectificar de sabios, Tom DeMarco es de los segundos. Su obra es una de las principales contribuciones en el desarrollo de la Ingeniería del Software.

Es autor de uno de los principales trabajos sobre métricas en la gestión de proyectos de software, referente de temarios como PMBoK: Controlling Software Projects: Management, Measurement and Estimation, publicado en 1982 y que hizo famoso su principio "no puedes controlar lo que no puedes medir". Con motivo del 40 cumpleaños de la Ingeniería del Software , el número de julio/agosto de IEE SOFTWARE publilca un artículo de Tom DeMarco del que prefiero no comentar nada, y  usando el derecho de cita, copio litaralmente sus palabras:

Las métricas que inicialmente expuse en mi libro Controlling Software Projects: Management, Measurement and Estimation, han definido la forma en la que muchos ingenieros construian el software y planificaban el trabajo. Con un ánimo de estado reflexivo, ahora me pregunto: ¿Fué correcto el asesoramiento en métricas? ¿Sigue siendo pertinente? y ¿creo todavía que las métricas son una necesidad para el éxito de cualquier desarrollo de software?. Mis respuestas son no, no y no.

Tom DeMarco, que es el autor de la afirmación que ha sido axioma en los modelos de procesos y gestión: "Usted no puede controlar lo que no puede medir", afirma ahora que el control puede no ser importante en muchos proyectos de software:

"Muchos proyectos han avanzado sin centrar la gestión en el control, sino en la creación de productos maravillosos como GoogleEarth o Wikipedia.
Para entender la verdadera función del control, es necesario distinguir de manera drástica entre dos tipos diferentes de proyectos:

Un proyecto de tipo A, con un coste estimado de un millón de dólares y un cálculo de retorno aproximado de 1,1 millones.
Un proyecto de tipo B que con un coste estimado de un millón de dólares produce un valor de más de 50 millones de dólares.

Lo inmediatamente evidente es que el control resulta importante en el proyecto A, y sin embargo su importancia es mínima en el B. Esto nos lleva a la extraña conclusión de que el control estricto es importante en los proyectos poco importantes, y viceversa.

Al seguir leyendo en el artículo el paralelismo que hace con el tipo de control de un padre sobre su hijo, me acuerdo del principio de "control sutil" identificado por Nonaka y Takeuchi en el concepto original de Scrum. 

"Al aplicar el principio 'no se puede controlar lo que no se puede medir' a la educación en la adolescencia, la mayoría de las cosas realmente importantes, honor, dignidad, disciplina, personalidad, valores, ética, ingenio, lealtad, humor, bondad... no son medibles.
Tienes que formar a tu hijo lo mejor que puedas sin tener feedback de métricas. Es difícil, porque ser padre es difícil. Tienes unas ciertas métricas del tipo de las notas del colegio, e intuyes que la nota de matemáticas es más importante que la de español y que la nota de comportamiento quizá diga más del profesor que del alumno".

Para quienes creemos que el conocimiento está en continua evolución, y en la gestión de proyectos TIC hay mucho que cuestionar sobre lo enseñado en métricas, planificación y control, leer estas afirmaciones de Tom DeMarco reconforta, y da gusto ver que hay personas que con honestidad cuestionan depuran y mejoran de forma continua(2). Que a fin de cuentas, mejoran con los años de experiencia. 

Claro que esto es lo que me parece a mi. También habrá a quien le parezca que vaya pena con  Tom DeMarco. Con las buenas ideas que tenía, y al final se ha echado a perder. :-)

 

 

(1) Conference on Software Engineering. 1968 Garmisch, Alemania.
Informe de la conferencia   

(2) Desde sus Ideas iniciales en la línea de "No puedes controlar lo que no puedes medir" a las conclusiones actuales sobre métricas y gestión de proyectos (ágil, por qué no decirlo), pasando por las que a finales de los 80 resumía en su afirmación "La mayoría de los problemas de nuestro trabajo no son tecnológicos sino sociológicos" (Peopleware: Productive Projects and Teams 1987)

(*) Artículo publicado originalmente en navegapolis.net el 22 de julio de 2009

certificacionSi queremos cobrar estas cantidades empezamos mal si llamamos a las cosas por su nombre: ¿cursillo?

¿Cómo que cursillo? ¡Eso es cosa de academias!. Llamémosle curso de certificación profesional, y concedamos a los asistentes un título rimbombante, cual título nobiliario. Algo que impresione. Por ejemplo "Certified ScrumMaster" 


En Argentina se anuncia un cursillo curso de certificación profesional ScrumMaster por el que los asistentes deben pagar el equivalente a dos meses de sueldo por dos días de clase. ¿Es abusivo, o sólo me lo parece a mi?

Además resulta sorprendente que las víctimas del atropello, quienes deben hipotecar el salario de dos meses por este abuso, sean los que sustentan con su apostolado, y a veces veneración, el mantenimiento de estos modelos de formación.

No se si decir que "el emperador está desnudo" es valentía, inconscienca o sencillamente compartir con sinceridad lo que pienso. 

Y... no nos confundamos:  Scrum es una buena práctica de gestión sobre principios de desarrollo ágil, y todo gestor de proyectos TIC lo debería conocer.

No me gusta mucho (nada) alardear de experiencia, pero seguramente serán mas de 200 los proyectos de desarrollo de software los que he gestionado en los últimos 10 años, bien directamente o bien a través de gestores de mi equipo. Algunos de un par de meses de duración, y otros de más de dos años. En ese tiempo he asistido también a no sé cuántos cursillos seminarios y certificaciones (ISOs, CMM, EFQM, CMMI, gestión de proyectos, calidad, agilidad, métricas, dirección...), y esta vergonzante descripción os la hago sólo para que comprendáis mi escepticismo sobre las "balas de plata", porque tras 10 años de ver, estudiar y pasión por mi profesión, confieso mi condición de aprendiz y lo que me falta por aprender. De ahí mi escepticismo a las formaciones mágicas de 2 días.

Si además sumamos que hay que pagar un potosí, y que a todo el mundo le dan un título que "certifica" su conocimiento, aunque el conferenciante hable en inglés, y el asistente sólo sepa español... la desconfianza aumenta, ante un sistema de formación que anuncia y "garantiza" que en dos días podría hacer a mi madre "Certified ScrumMaster".

Esta es mi opinión, y seguro que algunos la compartiréis y otros, seguramente por esa sorprendente actitud que comento de veneración hacia estos cursos, os sentiréis en desacuerdo, o incluso ofendidos. 
De verdad, ninguna intención de ofender, sino de cuestionar: Estamos descubriendo la necesidad de cambiar los antiguos modelos de distribución y acceso a la información, el conocimiento y la cultura. Las ventajas del acceso y el intercambio libre. ¿Por qué al mismo tiempo mantenemos y apoyamos modelos de formación que van en la línea contraria?

Para mejorar el conocimiento y la calidad en los modos de desarrollar software, ¿no sería más lógico ir hacia modelos para ofrecer el conocimiento y la formación de Scrum, de CMMI o de lo que sea, que consigan la difusión al mayor número de personas al menor coste posible?; porque el modelo de seminario reducido de hotel es justo lo contrario.

Una cosa es desplazar a una autoridad en el tema para un día o dos a un hotel y oir su serminario, y otra la formación de profesionales;  y además si quien imparte estos cursos, que no lo son, lo hace porque también recibió un cursillo de dos días... ¿no es un sistema antieconómico, perverso y hueco?.
¿No es necesario cuestionar lo que no nos parece lógico, para que no se perpetuen mitos sin sentido?.

 

Este artículo se publicó originalmente en navegapolis.net el 22 de octubre de 2006 

Certified Scrum Master" suena bien. Suena muy bien. Tiene "Certified" y tiene "Master", y con estos términos tan pomposos uno supone que se debe tratar de una certificación de conocimiento o reconocimiento profesional, aunque no es mas que un engaño que cada vez despista a más personas.

Decir que el emperador está desnudo quizá no es muy inteligente, porque uno no gana simpatías ni de los emperadores que han pagado un buen dinero por un traje inexistente, ni de los sastres que hacen tantos trajes y entregan tan poca tela, pero alabar el traje que no se termina de ver no es profesionalmente honesto.

En su día ya hice de poco inteligente y me gané un puesto en la lista negra de la Scrum Alliance por dar mi opinión sobre los cursos de certificación ScrumMaster , por eso estas semanas pasadas me he sentido menos tonto al leer los comentarios de algunos "sastres" que empiezan a cuestionar la honestidad de vender estos trajes:

 

diplomascsm1

 

En grupo Industrial XP el pasado 15 de marzo, Joshua Kerievsky, fundador de Industrial XP abría una caja de truenos al atreverse a escribir "Actual Evidence of CSM Deception ". (la lectura de mensajes es solo para usuarios suscritos) en el que explica cómo el director de una empresa afirmaba con orgullo que ahora su proveedor de software contaba con personal "certified ScrumMaster".
Joshua afirma que este director ya había caído en el engaño, que al oir las palabras "certifided" y "master" daba por supuesto de que se trataba de una formación más o menos larga con una evaluación final, y que lo que no podía suponer es que para Certified ScrumMaster no va más allá del típico seminario de charla y comida en un hotel.

"Estoy muy disgustado con la comunidad Certified ScrumMaster y la gente que está empujando este engaño flagrante a todo el mundo."

En este grupo de noticias, que mueve una media de 15 mensajes al mes, esta afirmación ha generado más de 330 y el propio Ken Schweber (iniciador de la "certificación" Scrum Master) ha entrado a opinar.

También la semana pasada, en el grupo Latin America Agile Software Development se cuestionaba tener que pagar 1.200 dólares por dos días de formación, y al hilo de la discusión, Tobías Mayer, formador autorizado por la Scrum Alliance y que anteriormente había dado estos seminarios en Buenos Aires, afirmaba estar en desacuerdo con la filosofía de la formación centrada en la "certificación" y su decisión de no dar más estos cursos.

Kripanidhi hace el siguiente cálculo en su post "Credibility Crisis ": La Scrum Alliance ha certificado hasta la fecha a unos 10.000 ScrumMaster * 1.500 dólares cada certificación = Ha facturado 15 millones de dólares.
Afirma también que en los dos últimos años ha preguntado a 42 ScrumMaster la finalidad del curso, y el 95% confiesa que lo han realizado para dar lustre a sus currículums.

 Otro ScrumMaster "Certificado" afirma "Esta certificación no se basa en nada: no hay pre-requisitos antes del curso, y no hay ningún control después. Es posible que una persona que jamás haya practicado scrum sea un ScrumMaster certificado".

 

Este artículo fue publicado originalmente en navegapolis.net el 29 de marzo de 2007

 

 

colegioConfiar en los procesos, cuando habría que hacerlo en las personas, asienta una cultura de cumplimiento que hace a creer que el medio es el fin, y que puede haber gente competente con mala suerte, que realizan bien su trabajo pero a quienes los resultados no les acompañan.

La calidad de la arquitectura de un sistema (por ejemplo) no depende del proceso o de las herramientas con las que se ha desarrollado, sino del talento de sus autores, por eso en empresas del conocimiento, el principio "la calidad del resultado depende de la calidad de los procesos empleados", camufla la incompetencia. 

También es un error asentar una cultura de cumplimiento para gestores de sistemas complejos, que acaban convencidos de que su desempeño consiste en hacer bien su trabajo: el gantt, el presupuesto, etc.

Si la herramienta es el fin, y los procesos los responsables de los resultados, no importa mucho la aptitud de las personas. Los resultados serán buenos si cumplen con su jornada laboral, o mejor aún, si la exceden y “cumplen con el trabajo de su puesto”.

¿Si?.

(*) Este post fue publicado originalmente el 5 de octubre de 2016 en navegapolis.net

 

manzanaSrum, en su concepción original, definida por Nonaka y Takeuchi, es posiblemente el marco natural para el desarrollo de la agilidad.

El "Scrum" de la ScrumAlliance  y de los ScrumMaster: el  "Scrum" rígido y dgmatizado, donde nada se puede cambiar, además de ser un modelo de negocio piramidal sin escrúpulos para quienes lo definen, es una amenaza para SCRUM.

Esto no es muy nuevo en Navegápolis, por eso me ha parecido muy valiente el artículo, nada menos que de Scott Ambler.

Me he sentido menos solo al leer a alguien de su talla, decir también sin ambages queel emperador está desnudo

Scott, jugando con las palabras en Inglés: cambiando Scrum por Scum (escoria) y derivando de SCAM (Scum Certified Agile Master) a Scammer (estafadores) para referirse a los que toman esta certificación; se ha despachado a gusto en suartículo sobre la certificación ScrumMaster diciendo cosas como estas:

Puede conseguir el título de Maestro Certificado de la Escoria Ágil, o más coloquialmente Estafador, pasando dos días en nuestro curso de certificación. Queremos ser claros, lo que estamos certificando es la asistencia al curso (guiño, guiño, guiño, guiño). Usted decide si desea presentarse como un Estafador profesional. Si el 99,8% de los asistentes lo hacen. ¿Por qué va a asistir usted con otra intención?.

...

Este curso sólo lo puede impartir un Artista de la Escoria Ágil  Certificado. Para consultar un listado de los certificados como  Artistas de la Escoria, consulte nuestra lista.

El costo del curso de certificación de Escoria Ágil varía en función de cada Artista de la Escoria, pero normalmente oscila entre 1.395 y 1.995 dólares USA.

En primer lugar obtendrá un certificado que indica que asistió al curso, y también una estupenda carpeta de la Alianza de la Escoria con el material del curso... 
Pero ¡aún hay más! Terminado el curso le enviaremos por correo los logos y gráficos que podrá inclir en sus correos y tarjetas para indicar que es un Estafador...

Proximamente: Pruebas de Certificación.

A partir del 1 de julio de 2009 todos los "falsos" (?) tendrán que cumplimentar un test on-line, que ha sido cuidadosamente diseñado por los miembros del círculo de la Escoria... esperamos que haya un 98 o 99% de aprobados, siempre y cuando no hayan sido tan estúpidos de cuestionar a esta cofradía en un foro público como el de yahoo (controlado y administrado por la Alianza de la Escoria), o sean miembros de la facción disidente.

FAQ.

¿Estoy cualificado?... Si su cheque tiene fondos, usted será una Escoria Ágil Certificada.

¿Qué piensan los líderes ágiles de esto?. Varios de ellos no han podido resistir la tentación del dinero fácil y decidido certificarse como Artistas de la Escoria Ágil, por lo que ahora no pueden decir públicamente lo que piensan, por miedo a matar la gallina de los huevos de oro. El resto casi no tienen la integridad de levantarse y decir cualquier cosa. En lugar de eso albergan la esperanza privada de que la Alianza de la Escoria se autodestruirá a consecuencia de su codicia y su falta de ética. Pero creo que 7 años de funcionamiento que han demostrado que están equivodados.

 Actualización: Sept-2010

 Un año más tarde de la fecha de publicación de este post, Ken Schwaber, fundador del modelo de certificación ScrumMaster y de la Scrum Alliance, la abandona reconociendo que su foco es su propio negocio antes que la difusión y mejora de Scrum:

An organization can either be mission driven or money driven. Not both. When I started the Scrum Alliance, our mission was to improve the profession of software development. That later became “to transform the world of work.” By 2007, I believe that the quest for money had made the mission secondary at Scrum Alliance. I failed to see the effects that my initiatives would have on the money-making of the Scrum Alliance and its members. If I had mapped the money-making activities of the Scrum Alliance to these initiatives, it would have been obvious to me that the community would resist them. In 2008, Scrum Alliance revenues came largely from three sources (see Table 1). Individual CSTs taught an average of 200 students a year. Course fees ranged from $1,000 to $2,000 per student. This meant that the average trainer earned $300,000 per year just from training. 

 

Este artículo se publicó originalmente en navegapolis.net el 15 de agosto de 2009

 

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.