Leo 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:

Hay dos patrones en gestión de proyectos (por la forma de entrega del resultado): predictivo y evolutivo (que no ágil). Y la diferencia es simple: el predictivo conoce al principio todo lo que el cliente necesita, planifica la ejecución, predice cuando lo va a entregar y cuánto va a costar. Trabaja para cumplir la previsión y entregar el producto de forma completa.
El evolutivo comienza construyendo y entregando una parte mínima y útil para el cliente lo antes posible, y sobre ella desarrolla el producto de forma continua.

La gestión de un desarrollo evolutivo puede a su vez puede:

• Basar la calidad del resultado en ingeniería de procesos y organizar el trabajo con criterios técnicos de gestión (rol de gestor de proyecto).
• Basar la calidad del resultado en el conocimiento tácito de las personas que trabajan de forma auto-organizada.

En el segundo caso estamos hablando de aplicar agilidad, y en el primero ingeniería concurrente.

Por otra parte la gestión evolutiva (tanto si se basa en agilidad como en ingniería concurrente) puede:

• Emplear ciclos de entrega breves (time boxing, sprints o iteraciones) entre una semana y uno o dos meses. Para gestionar el avance continuo en pequeños ciclos se usan técnicas que estiman cuánto del trabajo que el cliente va definiendo se puede realizar en cada ciclo o sprint, evitanto así desfases largos y detectando rápidamente posibles problemas y retrasos.
• Regular un flujo de trabajo continuo sin tiempos muertos ni cuellos de botella, que permite recibir las descripciones de las partes del producto con la misma cadencia, e ir entregándo el resultado.

Si entramos en el laberinto de modelos, marcos y métodos definidos buscando agilidad (y no ingeniería concurrente) acabamos con más dudas que las soluciones.

"Si en mi equipo quiero usar kanban pero tengo que (o quiero) estimar las tareas para registrar la velocidad por razones organizativas de mi empresa, o porque se me ha ocurrido que..."

"Si mi empresa gestiona proyectos simultáneos con una organización de oficina de proyectos y encaja mejor el establecimiento de roles, pero sin embargo quiero trabajar con kanban en lugar de con scrum... ¿debería hacer scrumban?. Y eso ¿qué es lo que es? ¿O lo que voy a hacer es scrumbut y soy un mal gestor?."

Si hacemos "reset" a esta inercia de aprender modelos, para no pensar que ahora además de los de procesos y gestión predictiva (ISO 15504, Moprosoft, CMMI, PMI, Spice..-) hay otros que son para gestión ágil.

Si no consideramos scrum como método sino como prácticas para gestionar incrementos basados en "timeboxing".

Si consideramos que Kanban es lo que es (o lo que originalmente era): Aplicación de información o gestión visual en el propio en torno físico en el que se trabaja: una técnica desarrollada y empleada por la manufactura Lean.

Desaparecen las paredes del laberinto, y con ellas la búsqueda equivocada (para quien quiere agilidad y no ingeniería concurrente) del camino modelo correcto.

Se podría decir algo como que la ingeniería concurrente prefiere el conocimiento explícito de los modelos al tácito de las personas, y funciona lo de "implantando este método daré al cliente lo que necesita" y con la agilidad ocurre al contrario.

Con kanban, ¿hay que estimar las tareas?, ¿En la reunión diaria hay que poner en la tarjeta kanban el esfuerzo que le queda?
¿Hay reunión diaria en kanban?
¿Puedes hacer scrum y cambiar una historia del backlog por otra a mitad de sprint?
¿Puedes ajustar el flujo con otras variables que no sean 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 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?
¿El sprint backlog es en realidad un WIP?
¿Puedo hacer scrum si el equipo no es multidisciplinar?

En definitiva la cuestión es si deberíamos considerar o no a scrum, a kanban o a cualquier otro, como métodos definidos, y por tanto actuar en nuestros proyectos según establezca el que hayamos adoptado.

Pues bien, es normal adoptar métodos definidos para gestionar sistemas de producción relativamente simples o de complejidad conocida y modelable, y sin embargo en la gestión de sistemas complejos 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 posibles patrones de gestión: uno técnico, basado en la implantación del conocimiento profesional explícito, y otro experto, basado en el conocimiento tácito desarrollado con la experiencia profesional.

Para la gerencia técnica el fin es el método: conocerlo a fondo para implantarlo en la empresa.

Para la gerenica experta un método es un elemento más en su inventario de conocimiento 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).

Fró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

Al situar las técnicas y los métodos con los que trabajamos en el contexto de evolución del conocimiento profesional, además de "culturilla" adquirimos una perspectiva útil para comprender mejor cuáles son los problemas que solucionan, las diferencias y similitudes con otras técnicas, y las fortalezas o limitaciones en relación con ellas.

Para los que os pueda ser útil, esta es una visión somera, pero quizá suficientre para ver el camino recorrido desde la fabricación artesana a la producción lean, y para situar en perspectiva el concepto de producción lean, o a kanban como una técnica de apoyo.

De la artesanía a la producción lean

División del trabajo

“La riqueza de las naciones” es la obra más célebre de Adam Smith. Fue publicado en 1776 y se considera el primer libro moderno de economía. En él desarrolla la teoría económica sobre la división del trabajo.
Para Smith el principal factor para mejorar la productividad del trabajo es su división, que ilustra en su célebre ejemplo de la manufactura de alfileres, en el que compara la producción que puede alcanzar un herrero que acomete todas las tareas necesarias, con la obtenida en un sistema con división del trabajo entre obreros especializados en cada tipo de tarea (estirado del alambre, cortado, afilado,etc.).
En el ejemplo demuestra que la división del trabajo hace posible que en lugar de producir 50 alfileres diarios por obrero, se produzcan 5.000

Organización científica del trabajo.

Frederick W. Taylor fue el primero que analizó y estudió el trabajo de forma sistemática.
Taylorismo es el método de producción que aportó su conocimiento, cuyo fin es aumentar la productividad.
Al taylorismo se le denomina también “organización científica del trabajo” o “gestión científica del trabajo” por aplicar principios básicos del método científico en el diseño de los procesos de trabajo.

Taylor expuso su sistema de organización racional del trabajo en su obra “Principles of Scientific Management” (1912) que de forma somera se puede condensar en cuatro principios:

• Reemplazar los métodos artesanales por métodos basados en el análisis científico del trabajo.
• Seleccionar y formar a los empleados con criterios científicos, en lugar de dejar que aprendan de forma autónoma.
• Dividir el trabajo en gestión y trabajo, de forma que los gestores puedan gestionar los principios de planificación y ejecución del trabajo.
• Proporcionar instrucciones y supervisión detallada a cada trabajador.

Producción en cadena

La producción en cadena, también denominada fordismo, es el sistema de producción desarrollado por el fabricante de automóviles Henry Ford para la fabricación de los primeros automóviles de su factoría en la primera década del siglo XX.

Pone en práctica los principios de la división y la organización científica del trabajo, y ha sido ampliamente utilizado para la producción industrial hasta que en la década de los 70 comenzó a ser reemplazada por el “toyotismo”.

El fordismo hizo posible:

• Reducción significativa del coste de producción (El Ford T que valía $850 en 1908 cuando se empezó a producir, se vendía a $250 en 1927)
• Flujo constante de la producción.
• Ingeniería de procesos: la calidad del resultado depende de la calidad del proceso empleado en su fabricación.

Sistema de producción Toyota

El fundador de Toyota, Sakichi Toyoda, su hijo Kiichiro Yotoda y el ingeniero Taiichi Ohno, comenzaron a evolucionar los sistemas de producción de sus factorías evolucionando el fordismo hasta llegar a principios de los 70 en lo que acabaría siendo y denominándose “Sistema de Producción Toyota” o “Toyotismo”.

Cuando intentaron importar los sistemas de producción masiva americanos, para rehacer su industria tras la segunda guerra mundial, se dieron cuenta de que el fordismo no les valía, porque creaba empresas para producir grandes cantidades del mismo producto, pero no servía para producir pequeñas cantidades de productos diferentes.
El sistema fordista generaba muchas existencias del producto que acababa con sobreproducción y almacenes llenos por falta de clientes.
Necesitaban un sistema que produjera con costes reducidos, pero que no lograran la reducción por el incremento de la producción, puesto que no tenían gran demanda.

Estas circunstancias evolucionaron la producción fordista hacia un sistema que eliminara las existencias del proceso de producción y el “sobreefectivo” tanto de personal como de equipo para lograr la fábrica mínima capaz de producir lo necesario: lo que un cliente está esperando.

El sistema fordista es un sistema de empuje, (“push”) mientras que el toyotismo es un sistema de arrastre (“pull”).

En el fordismo cada puesto está empujando continuamente al siguiente, enviándole trabajo de forma continua. Sobre una estimación de mercado, se pone en marcha la cadena y se produce al ritmo previsto.
El toyotismo es un sistema de arrastre: un puesto no empuja al siguiente sino que tira del anterior, pidiéndole trabajo

Para lograr simplicidad organizativa y flexibilidad que permita al sistema adaptarse a variaciones del flujo de demanda y diferencias en el producto, el toyotismo emplea diversas técnicas de apoyo:

• Información y control visual KANBAN.
• Información y control visual ANDON.
• Sistemas de prevención de errores Poka-yoke.
• Herramientas polivalentes y de cambio rápido.

Calidad total

El concepto de “calidad total” está asociado a William Edwards Deming, profesor universitario y consultor que en los años 50 logró imbuir en la industria japonesa el concepto de calidad como arma estratégica.
Demostró los costes que se generan en las empresas que no tienen definidos procesos para gestionar la calidad. Costes originados por retrabajo, desperdicio de materiales o productos defectuosos y compensación a clientes.
Deming difundió el círculo de calidad propuesto por Shewart: “Planificar – Hacer – Verificar – Actuar”, y de hecho actualmente se le conoce como el círculo de Deming.

Las ideas de Deming se reflejan muy bien en los denominados “Catorce puntos de Deming” y las “Siete enfermedades de la gerencia de Deming”.

Los 14 puntos de Deming.

Son catorce principios definidos por Deming para gestionar la mejora de la competitividad.
Se publicaron en su libro “Out of the Crisis”.

1. Crear constancia en la mejora de productos y servicios, con el objetivo de ser competitivo y mantenerse en el negocio, además proporcionar puestos de trabajo.
2. Adoptar una nueva filosofía de cooperación en la cual todos se benefician, y ponerla en práctica enseñándola a los empleados, clientes y proveedores.
3. Desistir de la dependencia en la inspección en masa para lograr calidad. En lugar de esto, mejorar el proceso e incluir calidad en el producto desde el comienzo.
4. Terminar con la práctica de comprar a los más bajos precios. En lugar de esto, minimizar el costo total en el largo plazo. Buscar tener un solo proveedor para cada ítem, basándose en una relación de largo plazo de lealtad y confianza.
5. Mejorar constantemente y por siempre los sistemas de producción, servicio y planeamiento de cualquier actividad. Esto va a mejorar la calidad y la productividad, bajando los costos constantemente.
6. Establecer entrenamiento dentro del trabajo (capacitación).
7. Establecer líderes, reconociendo sus diferentes habilidades, capacidades y aspiraciones. El objetivo de la supervisión debería ser ayudar a la gente, máquinas y dispositivos a realizar su trabajo.
8. Eliminar el miedo y construir confianza, de esta manera todos podrán trabajar más eficientemente.
9. Borrar las barreras entre los departamentos. Abolir la competición y construir un sistema de cooperación basado en el mutuo beneficio que abarque toda la organización.
10. Eliminar eslóganes, exhortaciones y metas pidiendo cero defectos o nuevos niveles de productividad. Estas exhortaciones solo crean relaciones de rivalidad, la principal causa de la baja calidad y la baja productividad reside en el sistema y este va más allá del poder de la fuerza de trabajo.
11. Eliminar cuotas numéricas y la gestión por objetivos.
12. Remover barreras para apreciar la mano de obra y los elementos que privan a la gente de la alegría en su trabajo. Esto incluye eliminar las evaluaciones anuales o el sistema de méritos que da rangos a la gente y crean competición y conflictos.
13. Instituir un programa vigoroso de educación y auto mejora.
14. Poner a todos en la compañía a trabajar para llevar a cabo la transformación. La transformación es trabajo de todos.

Las 7 enfermedades mortales de la gerencia.

1. Falta de constancia en los propósitos.
2. Énfasis en las ganancias a corto plazo y los dividendos inmediatos.
3. Evaluación por rendimiento, clasificación de méritos o revisión anual de resultados.
4. Movilidad de los ejecutivos.
5. Gerencia de la compañía basándose solamente en las cifras visibles.
6. Costos médicos excesivos.
7. Costo excesivo de garantías.

Este artículo es una traducción autorizada del post "Why You Shouldn't Hire More Developers" de Ash Moran publicado el 3 de Febrero de 2012 en PatchSpace Blog, y al que desde aquí agradezco el permiso y la disposición para publicarlo en Navegápolis.

La situación latente

Eres el responsable de un equipo de cinco programadores, y estás completamente quemado. Pasáis los días en la oficina desde primera hora de la mañana hasta el final de la tarde, intentando hacer frente a una acumulación continua de trabajo.
De hecho empiezan a ser mejor las noches para trabajar, porque durante el día estáis inundados con interrupciones, emergencias y errores que reclaman atención, por lo que cada vez tenéis menos tiempo para desarrollar funcionalidades nuevas.
Casi no puedes atender a los clientes actuales, y los de comercial acaban de cerrar el acuerdo con un nuevo cliente, que tiene un montón de peticiones. Cada vez pierdes más tiempo en reuniones tratando de mantener la situación bajo control. Probablemente ya te estás tirándo de los pelos, pensando que no tienes tiempo para todo y que tienes que tomar una determinación.

Así que esbozas la situación en una hoja: Cada programador dedica al menos 60 horas a la semana, así que tienes unas 300 horas/programador por semana, de las que estimas que unas 50 se les van en corregir errores, otras 30 en atender la operativa del sistema y 20 en reuniones. En total 100 horas: ¡una tercera parte del tiempo! antes de poder atender las funcionalidades nuevas que están en un backlog que no para de crecer. ¡Y ahora para colmo un nuevo cliente!.

La conclusión es obvia: hay demasiado trabajo, y tienes desbordado todo el tiempo disponible, así que necesitas más gente. Si tuvieras dos programadores nuevos se podrían dedicar a la corrección de errores, a las cuestiones operativas e incluso podrían pellizcar algunas de las funcionalidades nuevas. Sólo tendrías que pagar por 40 horas semanales de cada uno, y como siempre, en cuanto asuman la cultura de la empresa acabarán dedicando más. Así que la solución es obvia, y vas a tu jefe para que autorice una selección de personal.

Mal. Lo último que deberías hacer en una situación como esta es contratar nuevos programadores.

Nuevos programadores avivan el incendio.

La nueva programadora, Alicia, empieza el lunes, día que hipoteca por completo a otro programado para ir instalando su equipo. El martes por la mañana Alicia continúa por su cuenta, porque estáis todos reunidos, pero al final tiene que estar también toda la tarde para rehacer lo que había hecho porque no sabía que usábais un sistema propio de integración continua, que Bob no pudo documentar en su momento porque asistió a una reunión imprevista. El miércoles dejásteis a Alicia revisando unos errores sencillos. Dedicó todo el día, porque al mismo tiempo se iba desenvolviendo con el código. El jueves y el viernes intentó programar una de las tareas fáciles del backlog, de la lista de nuevas funcionalidades, pero estuvo más de la mitad del tiempo con otro programador porque se tropezó con un viejo bug. (Seguramente debía estar registrado en el "bug-tracker", pero desde que alcanzásteis los 200 bugs abiertos, ya no le hace caso nadie.) Al final terminó la semana y desplegásteis una nueva versión el viernes por la tarde.

Empieza el fin de semana, y todos desconectáis los fines de semana, porque aún no los han invadido el exceso de trabajo.

El lunes es un caos. Al arreglar su primer bug, Alicia cambió lo que creía que era un error, y que en realidad era una regla de negocio extremadamente rara. Nadie lo revisó porque todos le habían dedicado ya bastante ayuda, y sabían que era una tarea fácil. Así que tenéis que echar atrás el deploy del viernes. Os dáis cuenta rápidamente de que Alicia programó la nueva funcionalidad sin comprender las reglas de negocio del sistema, así que alguien del equipo tendrá que revisar el código. Y lo de menos es el tiempo que le pueda costar este arreglo, porque está claro que Alicia se encuentra a mucha distancia del equipo, por todo el volumen de código que ya hay desplegado, así que esta situación va a ir para largo.

¿Es culpa de Alicia? ¿Debería haberse esforzado más? ¿Es culpa del sistema?

El cuello de botella

¿Qué es lo que estrangula el funcionamiento de esta empresa.? Está claro que no es el departamento comercial, que trae clientes a más velocidad de la que producís el software. Tampoco es el análisis. Los requisitos también se van construyendo a más velocidad de la que pueden codificar los programadores. (Supondremos por ahora que los requisitos son realmente adecuados). Tampoco es la operativa de trabajo, porque las tareas previstas para la semana estuvieron desplegadas el viernes por la tarde, aunque el deploy rompiera las reglas de negocio. Así que si el cuello de botella es el área de desarrollo, ¿por qué está mal contratar más gente para aumentar la capacidad del área sobrecargada?.

Presunciones de la contratación

Para explicar esta situación vamos a analizar las suposiciones tácitas por las que se contrata personal para un equipo con exceso de trabajo. Este análisis es crucial para descubrir y poner de manifiesto lugares comunes en la forma de actuar muchas empresas de software. Es comparable a la diferencia entre el trabajo invisible y el visualizado y puesto de manifiesto sobre un tablero kanban. (Ten en cuenta que incluso las organizaciones que emplean tarjetas kanban suelen quedar ocultas muchas tareas.)
La siguiente no es una lista exhaustiva, pero sirve de referencia.
Muchos equipos actuan como si esto fuera cierto:

• Los programadores son recursos.
• La productividad es proporcional a las horas de desarrollo.
• La corrección de errores es una actividad que aporta valor al producto.
• Todos los requisitos son necesarios.

Los programadores son recursos

Tom DeMarco lo denomina "The Myth of the Fungible Resource" en su libro Slack: En la producción industrial, para muchos puestos de trabajo hay una relación directa entre horas/recurso y productividad. Sin embargo esta es una hipótesis errónea para desarrollar software, en donde un nuevo empleado, aun en el caso de que conozca el lenguaje de programación y el marco técnico de trabajo, tarda mucho tiempo en aprehender el conocimiento tácito del proyecto.

No creo que los programadores se consideren recursos (al menos no se considera así ninguno de los que yo conozco) pero sin embargo he visto trabajar con la hipótesis del "programador=recurso" a muchos departamentos de personal.
Cada vez que contratas a un nuevo programador para incrementar de forma inmediata la productividad del equipo, estás considerando táticamente al trabajo de programación al revés de como lo hacen la mayoría de los programadores, y en toda contradicción sólo es cierto uno de los extremos.

La productividad es proporcional a las horas de desarrollo

Esta hipótesis se puede materializar de dos formas: La primera suponiendo que un programador que trabaja 10 horas es un 25% más productivo que el que trabaja 8, y la segunda suponiendo que un equipo de 10 programadores es un 25% más productivo que uno de 8.

Se puede entender el error en la primera suposición, comprendiendo que el desarrollo de software es en esencia el desarrollo de nuevo conocimiento, como expongo en el post "Why can't developers estimate time".

El desarrollo de software es una actividad creativa cuyas tareas exigen un ejercicio continuo de toma de decisiones lógicas. (Por ejemplo: ¿Convendría dividir ya este largo bloque de código? ¿Uso XML o JSON? ¿No sería mejor reemplazar el marco de la aplicación?)

Como se explica en el artículo "Do you suffer from decision fatigue?" (The New York Times Magazine) el cerebro humano tiene una capacidad limitada para hacer este tipo de elecciones, y cuando se encuentra cansado opta por tomar atajos.

Seguir trabajando después de alcanzar la sensación de "por favor, me quiero ir a casa" puede ser la causa de errores. El mito del programador heroico no es cierto: emplear horas extras como consecuencia de la baja capacidad del equipo es un error demostrado numerosos estudios científicos.

La segunda suposición: creer que la productividad y el tamaño del equipo mantienen una relación proporcional directa, tampoco es cierta, por la sencilla razón de que aunque la complejidad en la gestión de las personas no se incrementa sustancialmente por el número de éstas, sí lo hace la complejidad de la comunicación. Compara por ejemplo lo fácil que resulta que 50 personas alineadas se pasen una pelota, con lo difícil que resulta a 5 llegar a un acuerdo sobre el menú que van a comer en un restaurante chino.

La corrección de errores es una actividad que aporta valor al producto.

Por definición, un error es un funcionamiento inadecuado del sistema. Hay situaciones en las que no se sabe si una idea funcionará (es el campo del emprendimiento ágil). Sin embargo este no es el caso de la mayoría de los defectos, que se introducen en el código a pesar de que el programador podría determinar que lo que está haciendo es un error y producirá un malfuncionamiento del sistema, y sin embargo por alguna razón no se da cuenta.
Imagínate que estás estrenando los flamantes frenos que acabas de instalar en tu aumóvil, y al accionarlos descubres que se desvía hacia un lado. ¿Cuál es el valor adicional que le aporta a tu coche el ir a repararlos? aunque la reparación sea gratis.
Corregir este tipo de errores no es un trabajo, sino un re-trabajo. El programador tiene que volver a "sumergirse" intelectualmente en ese trozo de código, incluyendo los requisitos, su funcionamiento y las dependencias con el resto del sistema, y cambiarlo. Aunque al final no tenga que cambiar el código existente, sino simplemente añadir código nuevo, tiene que aprender desde el principio toda un área de código, junto con las presunciones y conocimiento tácito que implique, y luego cruzar los dedos para no romper nada (en el caso de que la batería de pruebas pueda capturar un posible error, por tratarse éste de un conocimiento que está explicitado en los tests) porque si la corrección de errores es un gasto, la corrección de los producidos al arreglar un error previo es un gasto doble. Es lo que llamo "programación wack-a-mole" un término que lamentableme aún no ha cuajado.
Si tu equipo dedica mucho tiempo a corregir errores, tiene bastante más capacidad de la que crees. Lo cual no quiere decir que sea fácil aprovechar esa capacidad de la que no eres consciente, pero que está ahí. La creencia de que los errores son inevitables es perjudicial, porque tiene como consecuencia considerar que corregirlos es una tarea que genera producto.

Todos los requisitos son necesarios

He dejado ésta suposición errónea para el final, porque es de naturaleza diferente al resto de las hipótesis, en cuanto que implica decisiones ajenas al equipo de programación. A menos que el equipo esté construyendo su propio software, habrá otra persona involucrada para especificar el trabajo que se debe realizar. Si al final el 30% de las funcionalidades del software no se usan nunca, o son innecesarias, habremos perdido al menos el 30% del esfuerzo de trabajo. (Que puede ser más al tener que gestionar una base de código mayor, y depurar los errores del código innecesario).
Pero esta suele ser una causa de ineficiencia dificil de solucionar, porque normalmente los equipos están contractualmente obligados a entregar especificaciones de requisitos que no incluyen valoraciones individualizadas o prioridades de cada funcionalidad.

La realidad del equipo ocupado

Recuerda que hemos llegado hasta aquí por analizar la contratación de Alicia para aumentar la capacidad de un equipo con "exceso de trabajo". Pero hemos visto que las razones que supuestamente hacían necesaria su contratación son faltas:

• El equipo no está funcionando a plena capacidad. Consume al menos un 25% del tiempo en un retrabajo y mantenimieno evitable, incluso considerando las horas de exceso de trabajo.
• Los errores introducidos por el estrés están reduciendo el nivel de calidad que el equipo puede proporcionar.
• La incorporación de Alicia no puede aportar un alivio inmediato, porque en el corto plazo incrementa el tiempo de información y comunicación con todo el equipo, reduciendo su productividad.

Una nota sobre el tamaño de los equipos

Es posible que tengas tengas alguna objeción a mi consejo de no contratar más programadores, porque mejorar la capacidad del equipo no es la única razon para contratar. Una razón muy válida es para tener redundancia, porque los equipos pequeños son muy sensibles a la ley de Murphy: Si un autobús atropeya a tu único programador, el proyecto entra en peligro inminente (en realidad ya estaba en peligro, pero ha hecho falta un autobús para demostrarlo).

Este interesante artículo de Christopher Allen explica algunas consecuencias de los distintos tamaños de equipos en su articulo "The Dunbar Number as a Limit to Group Sizes".

De todas formas el riesgo que supone contar con equipos pequeños es menor de lo que pudiera parecer. Yo no conozco casos de programadores atropellados por autobuses, y son raros los casos de los que dejan el trabajo por el sueldo, comparados por el que es el principal riesgo de pérdida de programadores: condiciones de trabajo insatisfactorias.

También hay otra razón por la que quizá quieras aumentar el tamaño del equipo: Para incorporar a una persona con experiencia y conocimiento útiles para transmitir a los demás. Pero en este caso su responsabilidad irá más alla del puro desarrollo.

Qué hacer

Antes de nada da un paso atrás y comprueba que no estás tratando de solucionar perdidas sistemáticas de esfuerzo, aportando más esfuerzo. Sería similar a poner más marineros para achicar agua, en lugar de trabajar en cerrar la vía. Fred Brooks enunció la Ley de Brooks hace más de 30 años: "Incorporar más mano de obra a un proyecto de software retrasado, lo retrasa más". Ignorando la experienca sólo coseguirás repetirla en tu empresa. Personalmente hay quien me ha confirmado "Tenemos un gráfico que muestra perfectamente cómo baja la velocidad a medida que añadimos personas al proyecto".

La mejora de la productividad de un equipo es difícil. Se trata de entender el negocio, el equipo, la trayectoria, los obstáculos que bloquean el progreso. Se trata de un problema complejo y sensible al contexto. Como este post está empezando a tomar un tamaño suficiente para ser aburrido, baste con apuntar la dirección del área de conocimiento adecuada, y sugerir "La Meta" como lectura.

Vemos el mundo a través de metáforas. Eli Goldratt, en La meta, muestra cómo al afrontar los problemas diarios, las suposiciones comunes nos impiden ver las causas reales. Es un libro que ha vendido millones de copias, que se ha utilizado en miles de empresas y se enseña en cientos de colegios y universidades. La meta es el típico libro que muestra cuáles son los fundamentos importantes. Se puede leer en un par de días, y te ayudará a ver la fuente real de los cuellos de botella en tu empresa (este no es un post patrocinado).

Voy a terminar con una regla general: al lidiar con una situación como la descrita, trata de aprovechar lo que ya tienes antes de abordar el problema con más recursos. Te darás cuenta que muchas veces puedes ser más eficaz con las personas y los recursos que ya tienes, si descubres las verdaderas causas del problema.

Gracias por leer este artículo.
Mi nombre es Ash Moran, soy desarrollador de software, y asesor de agilidad, propietario de PatchSpace Ltd (twitter). Si tienes algún comentario, pregunta o si deseas información sobre mis servicios, no dudes en contactar conmigo en ash.moran@patchspace.co.uk.

Hace tiempo anduve pensando que podría poner un pequeño precio al libro de scrum que regalo, y enviar el dinero a un proyecto solidario; porque no parece lógico que las iniciativas que comparten y regalan desperdicien el posible beneficio que podrían generar, cuando en su mismo mundo hay millones de personas en extrema pobreza.

Me acordaba de aquello que nos decían de pequeños: "Te lo tienes que comer todo. ¿No ves que hay niños que se mueren de hambre?". ?????

Y me produce el mismo sentimiento de impotencia: No me lo como porque no tengo hambre, y lo tengo que tirar porque no se lo puedo dar a los que tienen hambre.

Pero... ¿Qué vas a hacer? ¿Cobrar y explicar que vas a entregar todo o la parte que sea a una ONG? ¿Y cómo se lo cuentas a Hacienda?... Y además a fin de cuentas, sólo sería una gota: unos pocos libros y unos pocos euros. Menudo follón para 4 euros.

Y este es el origen de la idea de PayCommons: una plataforma de pago electrónico que pueda canalizar muchas "gotas" de forma transparente y fácil. Abriría además posibilidades a quienes, con ganas de ayudar, quizá no andan sobrados de medios pero derrochan talento.

No soy el más objetivo para valorar si esta idea tiene sentido o es una quimera, pero lo que no tiene ningún sentido es dejarla en un cajón por no poder atenderla.

Así que para todos a los que pueda interesar fundar un proyecto para darle forma, dirigirlo, participar o invertir... o si sabéis de gente a la que puede interesar y a la que se lo podéis pasar, aquí la he resumido en un "Elevator pitch" en formato PPT (Un "PPT elevator" ? :-)

Elevator pitch - English version .

"A aquellas personas que venden talento cada vez les irá mejor y ganarán mas, a aquellas personas que venden horas cada vez les irá peor.... Si el mileurismo nos parece duro, preparémonos porque lo más probable es que venga el sub-mileurismo"

"En EE.UU. el 65% de los jóvenes se autoemplea, en Europa es un 40% la gente joven que se autoemplea, aquí en España es un 3%.... Si sólo hay un 3% de personas que se autoemplean quiere decir que hay unas creencias detrás que están sustentando todo eso. La creencia básica es "Un trabajo por cuenta ajena me da estabilidad, me da seguridad, me permite pagar la hipoteca etc."

Mucho mejor oirlo directamente de su autor... Sergio Fernández en la entrevista con Beatrice Pieper , directora y fundadora de la revista digital Uakix .

Vía:  vía @EvergreenPM  / @deimer   

Enseñar competencias clave para desarrollar proyectos TIC en un mercado global, con equipos dispersados en distintos países, es el objetivo del proyecto GSD de la Univerisidad de Pace de Nueva York.

Cada año pone en marcha, en colaboración con otras universidades (Tailandia, India, Camboya, Senegal...) el desarrollo de un proyecto de software con equipos distribuidos.

Son proyectos que sirven de aprendizaje para los estudiantes y profesionales que participan, y de material de análisis con el que están construyendo y depurando un fondo de conocimiento específico para desarrollo global de software.

En 2009 decidieron por primera vez emplear un marco ágil (Scrum) para gestionar el desarrollo de una aplicación para dispositivos móviles, con equipos separados  (Universidad de Pace - Universidad de Delhi y Escuela Superior Politécnica de Dakar).

El mes pasado de publicó el informe del proyecto: "Some Management Principles Learned from Scrum Practices within a Global Software Development Project " que incluye las

6 lecciones aprendidas para la gestión de Scrum distribuido:

Lección 1: Se empieza con mucha voluntad...

Pero es dífícil mantener la motivación y el compromiso con los rituales ágiles previstos.
Sugerencia de gestión: Escribir las motivaciones y compromisos individuales para tenerlos presentes y visibles como banderas a lo largo del proyecto.

Lección 2: No caer en el principio de pareto

Trabajar por separado acentúa la tendencia a enfatizar y consumir mucho esfuerzo en tareas de preparación, aplicando esfuerzo ineficiente (80% de esfuerzo en un 20% del resultado).
Sugerencia de gestión: Conocimiento previo de los conceptos de Scrum, y aplicar pautas y artefactos de gestión simples.

Lección 3: Asignatura difícil: Gestión individual del tiempo

El trabajo distribuido reduce la visibilidad de problemas en miembros del equipo por una mala autogestión del tiempo. Los miembros de equipos separados deben conocer y aplicar de forma disciplinada los principios para la buena gestión del tiempo. Las prácticas de Scrum  para priorizar y estimar las tareas y seguir su evolución de forma cercana y con compromiso de equipo, son especialmente útiles, pero más difíciles de poner en práctica entre personas geográficamente dispersas.
Prácticas aconsejadas:
1.- Periodo de práctica y aprendizaje previo para poner a prueba las habilidades de gestión del tiempo, realizando prácticas de estimación y ejecución de tareas.
2.- Asesoramiento en el análisis y priorización de las tareas pendientes.
3.- Mostrar a los "perfeccionistas" que la perfección es imposible e innecesaria.
4.- Recordar que el tiempo es un recurso valioso.

Lección 4: Ser impasible... ¡mantener un ritmo de trabajo constante!

No olvidar el principio ágil de mantener una velocidad equilibrada, sin fluctuaciones. Sin momentos de estres que queman y desmotivan, ni periodos de procrastinación.

Lección 5: El fin justifica los medios.

El foco del trabajo no es la eficacia o la estética de la codificación. Son puntos técnicos que no deben consumir más foco que el necesario para garantizar el objetivo real: entregar una aplicación operativa.

Lección 6: La capacidad del barril depende de su tabla más corta.

Cada miembro tiene sus debilidades, o tablas más cortas, y sus fortalezas, o tablas largas. La organización del equipo debe conseguir la distribución del trabajo y el resultado combinando y sumando las fortalezas, no las debilidades.


Otros informes del proyecto GSD.

GSD 2007 GSD 2008 GSD 2009 GSD 2010

¡Feliz Navidad amigos, y los mejores deseos para 2012!

El 24% de los usuarios de redes sociales en España se consideran saturados mientras que el 30% dice que le sabe a poco y que quiere participar más; y el 20% afirma que se dio de alta alta por seguir la moda o probar la novedad pero no se ha "enganchado".

A Facebook la prefieren más ellas que ellos (81% frente a 75%) mientras pasa lo contrario con Twitter (11% frente a 17%).

Estos datos y otros más serios ;-)  están en el estudio sobre conocimiento y uso de las redes sociales , que acaba de publicar el Obserbatorio Nacional de las Telecomunicaciones (red.es). 173 páginas con mucho grano y poca paja para los interesados en las redes sociales, acompañadas además de una presentación-resumen.

• Página de información y descarga del esutio y la presentación.