Simplifica
Las estructuras predefinidas de las empresas han de cambiar. Los departamentos y la estructura departamental ha de cambiar.
El equipo ha de estar unido en torno al cliente / producto / servicio. No tiene sentido que un cliente reciba comunicaciones de marketing que los de sistemas desconocen y que no se han aplicado o que los requisitos de la gente de producto sean una amenaza para los de operaciones y que las guerras internas entre departamentos pongan en riesgo desarrollos que tienen como objetivo hacer que la empresa sea mejor y que los clientes estén mejor atendidos.
Este concepto de "departamentos" que acaban generando reinados de taifas dentro de las empresas ha de cambiar. Los equipos de trabajo han de estar enfocados a generar una solución para el cliente. Cualquier otro foco (mis objetivos, mis resultados, mis…) hace que la empresa pierda energÃas en procesos internos que el cliente le son totalmente ajenos.
¿Qué sentido tienen los departamentos?
Esta claro que hay departamentos que tienen que existir y que pueden ser "independientes" al core de la empresa. Pero todos aquellos que tengan que ver con el "core" del negocio, tienen que estar unidos y trabajar como un equipo. El concepto de Scrum viene un poco de esa idea de melé de jugadores del rugby. Como una piña. Juntar las manos y decir "team work" no es suficiente. O estamos unidos o perdemos.
Equipo
Cuando se juzga un trabajo, no se juzga a las personas, se juzga al equipo. Si el equipo lo hace mal, el equipo tiene que solucionarlo. No hay que buscar a los culpables de los problemas por departamentos (en programación o en contenidos o en diseño). Si el producto falla, el equipo es culpable.
Evidentemente no se pide a un programador que diseñe o un diseñador que escriba, pero si se pide a todo el equipo que sea responsable del producto en su conjunto. No vale eso de "yo solo programo" o "yo solo diseño". Cada persona que se integra en el equipo ha de velar por el producto en su conjunto y es responsabilidad de todos que el producto salga bien.
Esto no es fácil y lleva tiempo, formación, pero es vital. Ya no vale el programador que solo programa o el diseñador que solo diseña. Todos han de tener en su visión el producto y el cliente.
Entregables y producción
Lo normal hoy en dÃa es el tÃpico documento de especificaciones donde se detalla todo lo que se necesita al detalle y cualquier cambio sobre ese documento genera reuniones y revisiones y nuevos plazos…
Este proceso lo hemos eliminado. Partimos de la idea que hay cambios y que esos cambios han de estar enfocados en la mejora del producto y en conseguri mejores resultados. Partimos de la idea que se definen unos mÃnismo pero no hay máximos.
Por lo general no hay objetivos o público objetivo. Hay metas. Esas metas suelen ser entregas. Esas entregas son productos reales que se pueden utilizar. No papeles.
Esos productos reales deben responder a unos criterios mÃnimos, pero los máximos están por definir y son cambiantes. El producto se ha de modificar, adaptar y crecer para acometer nuevos requisitos. Es parte del ciclo de vida del diseño.
Eso exige que el producto esté sujeto a una constante evolución y mejora. No hay entrega final. No hay documentación. La aplicación tiene que ser fácil de utilizar, estandar y compatible.
Este cambio de mentalidad es importante porque se adapta a la realidad del cliente. El cliente muchas veces desconoce las implicaciones de sus deciones y no podemos hacerle pagar por una decisión tomada sin tener toda la información. Es mejor acompañar al cliente y asesorarle de forma proactiva.
Las reuniones breves y operativas. Pero mejor, evÃtalas a toda costa
Como organizar reuniones operativas.
- Haz reuniones para resolver cosas. No para presentar cosas.
- EnvÃa todo lo que se vaya a tratar en la reunión por adelantado. Exige más trabajo, pero es necesario.
- En las reuniones ten conexión a internet y en lo posible corrige los documentos que puedas en ese mismo momento.
- Lleva un acta predefinida y tan solo escribe las conclusiones. Este documento debe estar a la vista de todo el mundo y todo el mundo debe estar de acuerdo con lo que pone antes de salir de la sala.
- En lo posible que la gente lleve un ordenador, no una libreta.
La comunicación tiene que ser más ágil. El correo es la vida. Los correos tienen que ser la herramienta. Hay que fomentar la seguridad en el equipo delegando y evitando el comité para decisiones que deben ser tomadas por cada uno. Evidentemente llegar a este punto requiere ajuste y formación, pero es necesario que el equipo sea autónomo el 80% del tiempo.
Scrum no es serio. No sirve para una gran empresa
Por lo general ante este tipo de filosofÃa, el rechazo suele ser frontal. No puede ser, no es posible. Pero esta filosofÃa de trabajo fue la que se aplicó en Japón y que dio lugar a su desarrollo en los 80-90. No estamos aplicando nada nuevo. Estamos aplicando una metodologÃa ya probado y que en la vieja Europa es más necesaria que nunca.
La vieja Europa lleva mucho tiempo sin pensar y sin renovar estructuras. Ahora toca. Toca definir empresas, procesos y metodologÃa. Si queremos salir de esta, el cambio es necesario. No vamos a salir de esta volviendo a hacer lo mismo de la misma forma.
No es estrictamente Scrum
Lo comentado en este artÃculo no es estrictamente Scrum pero es la filosofÃa de César y Justina y al escuchar la metodologÃa de Scrum vimos muchos puntos en común.