Cuando llego a un cliente que cree que apostando por scrum le va a salvar la vida y lo implantan en modo "free style" hay sintomas que vaticinan el desatre (dentro hilo...)
Se traen "expertos" con sueldos abultados y su plantila de desarrolladores tiene sueldos bajos
Planificar, tomar requerimientos es importante pero los que implementan el producto son los desarrolladores, te hace falta tener un buen equipo
Te encuentras que ya han planifcado un año de sprints... Es síntoma de no han que no han entendido que los requisitos cambian, aún cuando el cliente lo tuviera claro y lo clavaras, harias 100% lo que te pide el cliente pero no lo que necesita
Desarrollar software no es algo pasivo, trabajas con el cliente, no para el cliente, debes pulir y proponer cambios en los requerimientos, el desarrollador puede aportar una visión muy importante que muchas veces se desprecia
Cuando el conocimiento funcional se concentra en el product owner haciendo de embudo. Esta bien tener a alguien que sirva de referencia en un momento dado, pero los desarrolladores deben de tener un conocimiento funcional y de negocio del producto bastante bueno
Cuando los sprints van "a fuego", parece que alguien grita ¡¡EEEEJJJPPRIIIINT!! Y hay que entregar si o si lo que se haya dicho, sea como sea
Cuando se acerca la fecha de fin de sprint y se baja la calidad de revisiones y expectativas para cumplir y decir que se ha entregado
Cuando son más importantes las métricas que el avance real del producto
Como anecdota, recuerdo el scrum master de una empresa internacional muy top en esto que me dijo "Oye cambia esto de issue a change request que si no, no me salen las lineas como me gustan en las graficas" daba igual que fuera un bug.. Lo importante era mostrar un grafico cuco...
Cuando te tiras medio sprint reunido de ceremonias (reuniones), yo he llegado a ver como en una reunion de mejora, detectaron que hacían demasiadas reuniones y pusieron una reunión adicional para ver como hacían menos reuniones
Las reuniones son muy importantes, pero las justas, con agenda de valor, invitando a las personas que tengan sentido, con limite de tiempo, y resumen de lo acordado al salir de la misma
Cuando las dailys se alargan y se habla de todo menos de que hiciste ayer, que vas a hacer hoy y que impedimentos tienes.
El objetivo de una daily no es justificar tu trabajo, es que de forma rapida ver como va todo el equipo, identificar donde hay que echar cable o desatascar algo, y fuera ya de la reunión trabajar sobre ello
El tema de las reuniones suele ser un cancer cuando tienes jefes que tienen que justificar su sueldo de esa manera.
Cuando no se respeta el trabajo acordado en un sprint y se van metiendo cambios de por medio... Eso quiere decir que en la fase de definición del Sprint no se hizo bien el trabajo
Otro tema es el de por ejemplo aplicaciones en producción que puedan salir problemas criticos, aqui se puede guardar un buffer de horas para imponderables (a eso creo que lo llaman scrumban)
Cuando no se asume que en el arranque de un proyecto hay que emplear tiempo en montar las cosas bien, en hacer pruebas de concepto, en que habra que tirar para atras en ocasiones, para despues ir en firme y a velocidad crucero, que el equipo necesita tiempo para engrasarse.
Es decir que ademas del trabajo de entrega de funciinalidades hay uno técnico muy importante: los cimientos del edificio
Cuando no se hace peer programming para arrancar tareas, en muchos casos es importante que nos sentemos con otro compañero y ver como enfocar una implementación... programandola
Cuando las pull request o no se hacen o son un tramite. Las pull request sirven para que todo el equipo aprenda, para que el codigo sea del equipo, y para evitar que se lleve codigo a máster que podría destrozar un proyecto
Cuando se decide no implementar pruebas unitarias (ni de por lo menos las piezas fundamentales del proyecto) por ganar velocidad. Ya cuando una una pieza de negocio tenga un error tonto de parseo de decimales y se haga una transferencia de un millón de euros por equivocación...
... como muestra de realidad el caso de Buen Menu, negocio de éxito: cincodias.elpais.com/cincodias/2012…
Todo esto no quiere decir que seguir Scrum sea malo, si no que hay que saber que no es la solución milagrosa, y que debes tener antes ciertos pasos dados. En mi humilde opinión, antes de certificarte en scrum o traer a superfichajes expertos:
Preocupate de contar con un equipo de desarrolladores que sean buenos compañeros, que hagan que los demas aprendan y que tengan buenos conocimientos.
Preocupate de que el codigo tenga calidad, de que no se puede ir al cipotazo, haz peer programming cuando toque (no solo cuando hay un fallo en producción que ahi lo hacemos todos y funciona muy bien).
Que nadie trabaje en master, crea una rama por caso y revisiones de codigo, asi ademas de ganar calidad evitas aquello de "ese codigo lo hizo pepito, hasta que no vuelva de vacaciones no se toca",.... No, si esta en master ese codigo es del equipo y todo el equipo lo entiende
Definir una carga de trabajo realista para dos o tres semanas, y si algo se cae porque no da tiempo, mejor que se caiga a entregar una porqueria (eso que llaman muy finamente Technical Debt que significa a Chapuza)
Tener una reunion de todo el equipo diaria duración entre 5 y 15 minutos (no mas, de hecho que se haga de pie) en el que cada miembro enumere que hizo ayer, que va a hacer hoy, y que impedimentos tiene (si los hay, identificar quien va a trabajar con esa persona fuera reunión)
Meter al cliente coml parte activa del proyecto, ademas de planificar demos cada 2/3 semanas, que forme parte del equipo en el día a día
En mi humilde opinión, si arrancas con este mínimo y lo dominas, te puedes plantear luego si abrazar por completo scrum.
Para terminar una cosa que me enseño @elbruno, mas importante que las metodologias y las tecnologias: el equipo humano con el que trabajes, rodeate de buenos técnicos y mejores personas
Muchas gracias por haber llegado hasta aquí, ¿Que añadiríais vosotros?
