Hace un tiempo me contactó un directivo de una organización para que ayudara a mejorar cuestiones de calidad en sus equipos. Pero a mi parecer los equipos no estaban tan interesados en mejorar esos aspectos que me planteaba el directivo. Me pasó varias veces que luego de haber acordado reunirme con un equipo, me cancelaron a último momento. Es así que luego de un par de actividades (algunas de ellas fallidas) acordamos comenzar esta semana con un nuevo experimento: el consultorio.
La idea es simple: yo voy a estar recurrentemente una tarde por semana en las oficinas de este cliente para atender consultas de sus equipos. Esas horas recurrentes son take or pay, o sea: se cobran haya o no consultas. Esto pone “cierta carga” del lado del cliente en generar consultas/actividades para que esas horas efectivamente se utilicen. Por mi parte, este esquema me permite planificar mi tiempo sin correr el riesgo de “perder horas” por cancelaciones de último momento.
Si este esquema funciona ese espacio de consulta debería disparar acciones concretas dentro de cada equipo. Si la cuestión no puede resolverse en el tiempo de consulta entonces agendariamos sesiones adicionales.
Sinceramente no estoy muy convencido esto vaya a funcionar pero bueno, es un experimento, sino al cabo de un par de semanas no funciona, se ajusta o se cancela.
Cada vez que empiezo a trabajar con un nuevo cliente comienzo por compartir mis convenciones de trabajo. Luego de tanto repetirlas he decidido compartirlas abiertamente:
Dado que en general trabajo con “3 clientes” (mi trabajo académico + 2 clientes de la industria) siempre intento organizar mi trabajo con al menos 1 semana de anticipación.
Me suelo manejar por mail y/o teléfono, o si lo coordinamos podemos hablar por Skype/Hangouts (pero en general no estoy conectado todo el tiempo con estas herramientas).
No uso whatsapp para el trabajo, lo tengo reservado exclusivamente para cuestiones familiares.
Si me mandan mails, tendrán mi respuesta en un máximo de 24 horas hábiles, aunque en general es mucho menos (no suelo ver los mails los fines de semana).
Estoy disponible por teléfono todos los días hábiles entre las 8.30 y las 18.30. Si me llaman y no los puedo atender, les devuelvo la llamada apenas me libero.
Cuando estoy reuniones, dando cursos o programando me desconecto por completo para poder concentrarme.
Luego de cada reunión, envió un mail a modo de minuta para dejar registro de la hablado y de paso validar mi entendimiento de lo acordado.
Cuando agendo una reunión para una hora X, espero que la reunión comience a la hora X, lo cual implica que la gente esté en la sala disponible unos minutos antes. Esto es realmente problemático pues me cruzo constantemente gente con serias dificultades para respetar los horarios de reunión.
Creo que la primera ver que escuché el término coach fue viendo un partido de bastket de la NBA. Más aún estoy casi seguro que fue allá en los 90′ en un partido de Chicago Bulls donde el coach era Phil Jackson. En castellano el término es entrenador.
Años más tarde cuando me metí en el mundo de Extreme Programming (XP) me encontré con el término XP Coach. Al poco tiempo cuando conocí Scrum me encontré con el Scrum Master que es común considerarlo un Coach del equipo Scrum. Existe incluso bibliografía que menciona al Scrum Master como un análogo al XP Coach. En este sentido me parece relevante destacar un par de importantes diferencias:
El rol de Scrum Master es mandatorio en Scrum, mientras el XP Coach es opcional en XP. La bibliografía no dice que un equipo de XP deba tener un Coach, sino que en general se recomienda tener un XP Coach cuando el equipo está empezando a usar XP.
No se considera imprescindible que el Scrum Master tenga conocimientos técnicos, cosa que sí es requerida para un XP Coach.
En línea con este segundo punto y pensando en la analogía deportiva de coaches imagino al maestro Tabárez como Scrum Master y al Cholo Simeone como XP Coach. Ambos son coaches, pero da la sensación (por edad y estado físico) que de ser necesario el Cholo se pondría los botines y saltaría a la cancha junto a sus jugadores, cosa difícil de imaginar (al menos en la actualidad) del maestro Tabárez.
Hace un tiempo me contactó un cliente para pedirme que le de una mano acompañando a uno de sus equipos en un proyecto que estaban por empezar. Me adelanto algo de información por mail y agendamos una call. La información del mail ya me levanto algunos warnings: un proyecto de 3 meses con 12 personas en el equipo de desarrollo (demasiada gente apilada en para tan poco tiempo).
La idea del cliente era que yo colaborara haciendo coaching del equipo pues tenían la intención de realizar varios ajustes en la forma de llevar a cabo el proyecto incorporando prácticas ágiles. Ya en la call el cliente comentó que las fechas estaban fijas y que el alcance también estaba bastante fijo. A esta situación se sumaron dos factores importantes: el equipo de desarrollo estaría distribuido y el proyecto era de vital importancia porque era el primero con un nuevo cliente y el éxito de este proyecto definiría la realización o no de siguientes proyectos.
Si bien el proyecto parecía desafiante decidí no aceptarlo porque me pareció que no se daban las condiciones para hacer coaching (al menos como a mi me gusta hacerlo). Cuando acompaño a un equipo (no me gusta el término coaching, me gusta más hablar de acompañamiento) trabajo en la mejora del equipo y eso implica un proceso de aprendizaje que requiere tiempo para experimentar y posibilidad de equivocarse. Pero este proyecto que me proponía el cliente no contaba con un contexto favorable para experimentación y aprendizaje, había una presión muy fuerte para el éxito del proyecto y un conjunto de restricciones que limitaban mucho el margen de acción ante imprevistos y equivocaciones.
Recientemente en un charla con un estudiante surgió el tema de la “documentación oficial de Agile”. Con esto el alumno apuntaba a algo así como PMBoK o el SWEBoK pero de Agile. Esa consulta me motivo a escribir estas líneas.
En primer lugar lo que tenemos es el manifiesto ágil que dice y de forma bastante genérica (pero lo que dice es importante). Por otro lado tenemos libros sobre métodos y prácticas específicas escritos por sus propios autores (obviamente también hay libros escritos por terceros, pero el hecho de que estén escritos por los autores podría llegar a darle un peso diferente). Un ejemplos de esto son los libros de Beck sobre XP y TDD. En el caso de Scrum tenemos la Guía Oficial de Scrum escrita por Schwaber y Sutherland y avalada por varias “organizaciones de Scrum”.
Pero más allá de métodos en particular, existe la Agile Practice Guide, un libro de unas 180 páginas publicado hace un par de años. El mismo surgió de un esfuerzo conjunto del Project Management Institute y la Agile Alliance. Esta guía es de acceso gratuito para los suscriptores de la Agile Alliance (y estimo que también para los del PMI) pero también puede comprarse en Amazon.
Debo admitir que antes de leerla tenía cierto prejuicio sobre su utilidad y el nivel de “humo”. A pesar de eso, la leí y me sorprendí. Personalmente no me aportó mucho pero creo que puede ser un punto de partida intersante para gente que recién se acerca a agile. Más aún, en un punto creo que podría ser una lectura obligatoria. Me pareció muy sano que el primer capítulo es muy explícito sobre las limitaciones de agile en el sentido de que:
no es una bala de plata
no aplica a todos los contextos/proyectos
requiere de ciertas pre-condiciones
Por otro lado también debo decir que tiene un foco en temas de gestión. Apenas menciona a la pasada algunas prácticas técnicas y sin entrar en detalle en ninguna de ellas.
Algunos puntos interesantes que incluye esta guía y que me parece vale la pena destacar son:
Trata el tema métricas
Dedica una sección importante al modelo de equipo haciendo incapié en Servant Leadership y hablando incluso del rol de Project Manager
En el marco del Plan 2020 la Facultad de Ingeniería de la UBA está haciendo nuevos planes de estudio para todas las carreras entre las cuales están la Ingeniería en Informática y la Licenciatura en Análisis de Sistemas. El plan de la licenciatura es bastante nuevo (2015) pero el de la ingeniería no. Salvo algunas modificaciones menores el plan actual de la Ingeniería en Informática es el mismo plan con el que estudié yo a fines de los 90′.
Hace un par de semanas asistí una presentación que realizó la comisión curricular que está trabajando en el nuevo plan de Ingeniería en Informática.
En términos generales me gustó la forma que va tomando en nuevo plan. Comparto algunas observaciones al respecto.
Al comienzo de la presentación mencionaron algo así como que “los egresados de nuestra carrera están muy bien vistos en el mercado por su formación”. Comparto parcialmente: creo que efectivamente hay una muy buena percepción/desempeño de nuestros egresados, pero no estoy tan seguro que sea por la formación académica. Creo que esto es en gran parte por cuestiones “accidentales”, creo que nuestros egresados son en primer lugar gente perseverante, que está acostumbrada a lidiar con dificultades (materias con horarios que se superponen, docentes “dificultadores”, paros, recursos limitados y demás cuestiones extra académicas). Creo que esa capacidad de luchar y superar la adversidad contextual es lo que representa un diferencial en el egresado de fiuba. En cierto modo esto es lamentable, yo quisiera que nos destacaremos por la formación académica, pero me parece que actualmente no es así (vengo con esta idea desde hace ya varios años).
También se mencionaron los distintos factores que tuvieron presentes para la conformación del nuevo plan. Me resulto llamativo que no hayan mencionado el tema de las deserciones. Yo tengo la sensación de que el ratio ingresantes/egresados es muy malo y creo que también que hay una cantidad no menor que abandona cuando le falta solo la tesis/TP.
Respecto del esquema de materias me gustó y aunque parece que la parte de Ingeniería de Software (que es mi área) ha sido reducida, no me parece mal porque creo que ciertos temas de la ingeniería de software deben versen en forma transversal (por el ejemplo el tema testing y ciertos aspectos de planificación/organización).
Sentí cierta decepción al ver que la carga de materias de ciencia básica es todavía muy alta. Se eliminó Quimica 1, pero se agregó Matemática Discreta (que me parece bien) y se mantiene Análisis Matemático 3 (yo que la hubiera dejado como electiva). También se mantienen Fisica 1 y 2 (espero que al menos eliminen los contenidos repetidos entre Física del CBC y Física 1).
Entre las novedades que me resultaron más relevantes están:
La inclusión de Teoría de Algoritmos y Arquitectura de Software como materias obligatorias
La inclusión de contenidos de seguridad en forma transversal en varias materias
Una nueva materia llamada Infraestructura con foco en virtualización, cloud, etc.
Por otro lado tuve algunas charlas informales con miembros de la curricular que trabaja en el plan 2020 de la licenciatura y según me comentaron, el nuevo plan no tendrá modificaciones muy relevantes ya que el plan actual es bastante nuevo.
Con estos nuevos planes parece decantar que la Licenciatura en Análisis de Sistemas ofrecerá una sólida formación en cuestiones de Ingeniería de Software mientras que la Ingeniería en Informática formará gente con perfil más técnico. De todas formas hay que destacar que cada alumno tiene la posibilidad de armar su propio perfil a partir de la materias electiva que elija.
Tanto en la conferencia Agile, organizada anualmente por la Agile Alliance, como también en la XP, suele haber un espacio de “librería” donde se venden libros de los oradores de la conferencia y también clásicos de agile.
Me gustaría ver algo así en Agiles2019 pero con una vuelta de rosca.
Dado que en la comunidad Agile de Latam hay varios autores de libros de sobre agile y afines, planificaría una sesión (estableciendo de antemano día, horario y sala) para que cada autor presente su libro en 5 minutos (tipo lightning talk). Luego de la sesión cada autor podría vender o regalar sus libros.
Para que esto ocurra es necesario que la organización haga dos 2 cosas:
Difundir la idea ANTES de la conferencia para que cada autor pueda preparar su lightning talk y también para que pueda organizarse para llevar libros en formato físico o para subirlos a algún medio digital.
Reservar el espacio en cuestión (tanto físico como a nivel agenda)
Me parece que en términos de costo/beneficio esta iniciativa sería muy positiva:
El costo para los organizadores es mínimo (yo mismo me ofrecería a hacerlo si me dieran acceso a la lista de participantes).
Me parece que también es bueno para que los autores puedan difundir su obra
Creo que es un aporte de valor para los asistentes, ya que los libros en castellano sobre agile no tienen gran difusión y escuchar sobre un libro de la voz del propio autor creo que siempre suma.
Finalmente, si esta sesión se hiciera el primer día de la conferencia podría funcionar como disparador de otras sesiones en torno a alguno de los libros presentados.
Como realmente quisiera ver esto materializado, ya le escribí al grupo organizador de Agiles 2019 para ver si puedo conseguir su apoyo para llevar esto adelante.
