Hola Juan! Antes que nada, quería felicitarte por tu magnífico blog. Confieso que lo he descubierto hace muy poco, pero ya lo tengo entre mis lecturas habituales. Es evidente que tenemos muchos intereses comunes, empezando por Scrum y el Agile Project Management, así que supongo que era cuestión de tiempo que nos encontráramos.

He leído la respuesta de Ken, con la que - como tú - estoy de acuerdo en lo fundamental, aunque haría alguna matización - joder, qué atrevimiento: "matizar" a Ken Schawber!! ;-D Sí que he tenido la impresión de que tú y yo no hemos interpretado de la misma manera este fragmento: "I commented at the time that Scrum and Agile were barely processes, more techniques for making change within the development and wider organization. This change is very similar to what any organization encounters when using lean techniques, and the implementation process takes years"

En mi opinión, lo que Ken dice es que Scrum y otros métodos Ágiles son a duras penas procesos - aquí discrepo con él, pero bueno -, sino más bien técnicas que, como el famoso Lean Toolbox, se utilizan para introducir cambios de amplio alcance en una organización... cambios que de hecho llevan años. Ken se lamenta de no haber podido hablar previamente con Randy para "to correct the impression he may have given others that Scrum and Agile aren't that hard, just a little twist". El problema del que habla Ken aquí es que tanto MicroSoft como IBM pretenden hacer creer a la comunidad de desarrolladores que introducir prácticas Ágiles es una bobada, super-facilito gracias a sus "Solution Frameworks" y demás ejercicios de marketing. Ken se lamenta de que esto no hará más que complicar aún más el trabajo de esa pequeña comunidad de desarrolladores en Microsoft que pretenden cambiar una cultura "hierarchical, command and control" desde dentro.

En resumen, Ken nos avisa de que no hay atajos fáciles a Scrum... y es una advertencia que merece la pena tomar en serio. Scrum, como cualquier método Ágil, requiere de un entorno - tanto físico como cultural - "amable" con los valores que asume como punto de partida. Un intento de introducir Scrum se puede ir al carajo porque el DG no comprenda "qué hacen las mismas ocho personas todos los días por la mañana alrededor de la máquina de café".
Otro día hablaremos de si Scrum es o no un proceso - que por supuesto lo es! ;-)
Ah y el propio Ken en su libro Agile Project Management explica cómo llevar un Product Backlog a un Gantt... Claro que eso no significa que le guste ;-)

Mario López de Ávila
nodos en la red

Hola Mario!
Muchas gracias por tu reconocimiento y por leer Navegapolis.
Efectivamente compartimos el interés por Scrum y por la gestión ágil, y es cierto que no resulta fácil ni afirmar, ni negar que Scrum sea un proceso.
¿Proceso o técnica?. ¿Es proceso cuando define QUÉ hacer, y técnica cuando detalla CÓMO hacerlo?.
Este podría ser un buen criterio, y con el riesgo de estar confundido, interpreto así a Ken: Scrum es una técnica, y coincido contigo en que Scrum tiene mucho de proceso. Porque como técnica, (una forma concreta de hacer), o tiene detrás, o está dibujando un proceso (qué es lo que se hace).
Prescribir cómo hacer las reuniones diarias, o la priorización de requisitos en un backlog, implica que se han formado procesos para definir y priorizar requisitos, para asignar responsabilildades, etc. (Aunque con ingeniería inversa).

Juan Palacio

Gracias por haber creado este punto de opinión. En lo personal disiento con ambos principalmente por que hay comentarios que hacen emblemático a un personaje en particular y por otro lado hay comentarios que detrimentan a otro, cuando en ambos casos hablamos de personas que administran gran cantidad de personas al rededor de múltiples proyectos concurrentes y se las han arreglado para posicionarse con sus ideas y principalmente por que las desarrollaron.
Ahora yendo a lo concreto, creo de algún modo que Scrum no sirve más que para Gestionar un proyecto, es decir a niveles administrativos para seguimiento y control, tanto como para la estimación del tiempo y los recursos para la construcción, es decir que puede ser utilizado como modelo para gerenciar y podría ser tremendamente útil en las PA Gerenciales. Instruye en buenas prácticas pero no representa un proceso completo en si mismo. Sin embargo Scrum no facilita las herramientas utilizadas para el desarrollo en si, con lo cual mínimamente debes utilizar un modelo de otro tipo como XP si prefieres seguir en lo Ágile.
Nosotros no nos hemos apartado de los gant por que nos dan gran visibilidad y en forma ágil podemos ver los corrimientos o reubicamos los recursos. Creo que la herramienta a utilizar e indistinta. Puedes tener todo tu Backlog en un Excel, en un aplicativo Access o una aplicación de construcción propia como nosotros (Lotus) y puedes tener cada uno de los Sprint en un MSProject o si prefieres el software libre en un OpenProj.
Siguen siendo los principios ágiles abiertos a múltiples interpretaciones, y las herramientas orientadas Ágiles tienden a ser cada día más complejas por que se ha dado cuenta el mundo que con pequeñeces no es posible generar inteligencia en la industria del software. Que usan para gestionar los riesgos? o para conocer la disponibilidad de los recursos IT? o para ponderar los costos? herramientas de cualquier tipo que sirvan al propósito.

Juan,
me gusta un poco más tu apreciación última. Aunque disponer de técnicas de elicitación de requerimientos, no son una peculiaridad de Scrum. CMMI enseña todas las técnicas necesarias para la toma de requerimientos y como priorizarlos. Me gusta de Scrum que tiende a ofrecer una herramienta sencilla en lugar de requerir herramientas automatizadas para esa práctica en particular.
Pero hay que ver cuando intentar luego de mucho rato, obtener rastreabilidad de requisitos a lo largo de proyectos que fueron mutando con el pedido de los clientes. Sobre todo cuando el mismo proyecto es aplicado en distintos países y cada uno tiene su propio estilo. Lo ágil de de serlo cuando se requiere esfuerzo para responder a preguntas que apuntan a la história de un artefacto.

Saludos,

Javo.