Tag Archives | agile

Me voy a la AOS2012

Este fin de semana, me voy a Zaragoza donde, además de visitar a mis ahijados y amigos del amazing Cachirulo Valley, asistiré a la aún más amazing Agile Open Space 2012, o AOS2012 para los amigos.

La AOS es una des-conferencia sobre metodologías ágiles con formato open space. ¿Qué significa eso? Que no existe una agenda fija, sino que cualquiera puede proponer los temas que le parezcan interesantes para debatir y son los propios asistentes los que deciden, con sus votos, sobre qué se hablará durante el evento.

Puede sonar un poco raruno para aquellos que nunca han asistido a un open space, por eso, la organización pidió ayuda para intentar explicar qué se puede encontrar en una AOS y tratar de convencer a los indecisos. Después de ver como mastuerzos de la calaña de Yeray Darias, “el loco Loire” o Jose Manuel Beas grabaran vídeos espeluznantes, me dije a mi mismo que, podría superarlos creando un vídeo AÚN PEOR:

Ahora en serio, la AOS2012 es una buena oportunidad para empezar a aprender metodologías ágiles o aumentar tus conocimientos sobre las mismas. Pero, sobre todo, es una magnífica ocasión para que conozcas una Comunidad de gente preocupada por ser cada día un mejores profesionales.

Tradicionalmente, los eventos de metodologías ágiles han contado con un alto porcentaje de técnicos y desarrolladores, pero afortunadamente, la cosa está empezando a cambiar. Todo el mundo es bienvenido en una AOS y nadie se sentirá fuera de lugar: desarrolladores, diseñadores, expertos en UX, gente de marketing, emprendedores o técnicos de Recursos Humanos, todos podréis aprender y contribuir.

Además, la organización se ha preocupado de proponer planes alternativos para todos aquellos que viajéis con familia. ¿De verdad te lo vas a perder? ¡Anímate y ven este fin de semana a Zaragoza!

Bola Extra

Comments { 0 }

Small Improvements

Small ImprovementsDurante toda mi vida profesional he tenido que lidiar, desde ambos lados de la barrera, con las evaluaciones de personal. Normalmente, son una autentica pesadilla. No sólo porque sea difícil evaluar con objetividad a las personas que tienes a tu cargo, sino porque, en demasiadas ocasiones, estas evaluaciones pierden su razón de ser -motivar al trabajador y ayudarle a mejorar- para convertirse en un auténtico punto de conflicto.

Extrapolando la filosofía de las metodologías ágiles, si el equipo es el más adecuado para evaluar el tiempo de desarrollo de una tarea concreta, por ser el que más conocimientos tiene de la implementación, parece coherente que sea el propio equipo el que evalúe a cada uno de sus miembros.

Bajo está premisa nació Small Improvements, una compañía y aplicación creada por antiguos empleados de Atlassian, que se convirtió en su primer cliente.

creo que no hay nada mejor para demostraros como funciona el sistema que copiar directamente algunas de mis evaluaciones

El ciclo de evaluación es continuo, constante y, lo que es más importante, bidireccional. Cualquiera puede pedir a otro que lo evalúe. De hecho, los responsable son evaluados a su vez por su equipo y hay gente que pide feedback incluso a… ¡clientes y proveedores!

Es gratuito para equipos de hasta 10 personas, así que, podéis probarlo en vuestro propio equipo o en un proyecto antes de proponerlo para toda la organización. Y, si vuestra empresa se decide a usarlo, no se arruinará con el precio (desde 2€ por empleado y mes).

De todas formas, creo que no hay nada mejor para demostraros como funciona el sistema que copiar directamente algunas de mis evaluaciones en Atlassian. He recibido bastantes ¡algunas incluso anónimas! Pero os copio las dos a las que he dado más importancia, las de mis dos compañeros: John Stevenson -embajador inglés- y Sven Peters, el alemán.

Curiosamente, me han dado estopa, por… trabajar demasiado y “dormir poco”. Algo que, probablemente, pocos jefes te dirían. Desde luego, me conocen bien… y por supuesto son los que más me van a ayudar a mejorar.

John

I have learnt a great deal about online marketing from Ben and yourself, its good to have that added dimension on the team. Please be aware though that you will bore the pants of Sven and I if you talk about online marketing for more than an hour :-)

You are a cool dude and your only flaw is that you try and do too much sometimes! Try not to work yourself to an early grave and push back on some of the crazy ideas that Ben gets us all excited about. There is so much we can do, we occasionally have to be realistic in what we can achieve and its too easy to push ourselves too hard.

You are doing an amazing job and you add a great deal of character to the team. I am learning a lot from you.

Thank you.

Sven

1. What things have I done over the last six months that you have appreciated or admired?

I like your enthusiasm and your feedback about blogging, tweeting and “ambassadoring”. Looks like you are doing your job with ease and you are living the Atlassian Ambassador. I really like to discuss with you what things work and what doesn’t work for our job.

2. What 1 or 2 actionable suggestions do you have for me to improve on? Please help me understand why I should work on them.

Don’t set the bar too high for you. I feel sometimes you are not sleeping too much and doing 10 things at a time. I guess you should better prioritize things and work from the most important to the least. There is a life outside social media!

3. Any other comments:

You are not only a work buddy but also a friend for me. Really like your style, David. Keep on rockin!

Comments { 3 }

CAS 2011

Durante el 20 y el 21 de octubre, se celebró en Castellón la Conferencia Agile Spain 2011, el evento más importante a nivel nacional sobre metodologías ágiles, al que tuve el placer de asistir con una triple faceta: asistente, ponente y patrocinador.

He trabajado durante el fin de semana para que tuvierais disponible cuanto antes el video del evento en BonillaTV y además, he reunido una lista de recursos relacionados con la CAS 2011, algunos de ellos -como el juego del Jeroclo- en rigurosa exclusiva :) ¡Espero que los disfrutéis!

Reportaje de BonillaTV

Las keynotes, las sesiones, la Paella Ágil de Atlassian y la retrospectiva y más de 7 minutos de metraje ¡Incluido un minuto y medio de tomas falsas al final!

Presentación sobre Gamification

Aunque el pasado viernes ya escribí un articulo sobre la charla, con acceso a un PDF con la misma. Ya he conseguido subir la presentación a Slideshare, donde -además de descargarla si lo deseáis- podréis comentarla o compartirla.

El Juego del Jeroclo

Jerónimo ha retocado el juego para que sea mínimamente reutilizable por vosotros si así lo decidís. Ni siquiera hace falta bajárserlo. Para utilizarlo, simplemente usar esta URL:

http://gamification.funius.com/play/TERMINO?eventLogo=URL_AL_LOGO

Donde, el parámetro TERMINO (obligatorio) sirve para indicar las palabras de búsqueda que filtraran la consulta. Así por ejemplo, la URL que usamos durante la presentación para hacer el sorteo del Pomodoro y las camisetas fue:

http://gamification.funius.com/play/david_bonilla%20cas_2011?eventLogo=http://gamification.funius.com/public/images/CAS20112.003.png

Enlaces a crónicas del evento

Estás son algunas de las crónicas que han sido publicadas hasta el momento. Iré aumentado la lista con las nuevas aportaciones que me vayan haciendo llegar:

Enlaces a los slides de las charlas

Fotacas

Comments { 0 }

La pizarra SCRUM del futuro…

… o del presente (software y hardware disponibles hoy mismo).

¿Qué opináis? ¿Os veis cerrando tareas a lo Minority Report o creéis que esto es una tontuna que nunca jubilará a las pizarras manuales?

Comments { 13 }

Postmorten

No se puede dar por acabado un proyecto de software hasta que no se haya redactado su postmortem.

Gracias a los chicos de Vidaextra, he podido conocer la práctica del postmortem, una retrospectiva global y pública con el objetivo de aprender de los errores propios e intentar que otros no los cometan. Pura transparencia y altruismo.

El postmortem se ha limitado casi exclusivamente al sector de los videojuegos, donde se hacen algunos de los desarrollos más complicados y estresantes del mundo. Desarrollos con cientos de personas involucradas, continuos cambios de requisitos y backlogs inestables. Sin embargo, creo que sería muy sano para la industria en general que esta práctica se generalizara y se normalizara.

Journey. Un videojuego. Una obra de arte.

El postmortem es un documento en el que el equipo de desarrollo escribe las cinco decisiones o circunstancias que más ayudaron a concluir con éxito un proyecto informático y las cinco cosas que más lo perjudicaron.

Se diferencia de una retrospectiva normal en que produce un artefacto formal, un documento escrito, y en que este suele hacerse público para que otros desarrolladores puedan aprender de nuestros aciertos y errores, éxitos y fracasos.

Todos los que han estado involucrados en el proyecto pueden contribuir al documento: desarrolladores, diseñadores, equipo de QA, gestores, product owners y scrum masters.

¿No había suficiente presupuesto? ¿El equipo no tenía el conocimiento técnico necesario? ¿Existía una alternativa previa y más interesante en el mercado? No hay nada que no se pueda incluir y documentar.

No se puede dilatar la redacción del postmortem ya que los seres humanos tendemos a descartar los malos recuerdos y a recordar sólo los buenos. Un buen postmortem debe escribirse inmediatamente después de concluir el proyecto y sin verse afectado por el éxito o fracaso del mismo. Al fin y al cabo, estamos hablando de proceso, no de producto.

yo no quiero trabajar con los que luchan por ser los mejores, sino con los que intentan crear el mejor producto

Pero ¿por qué escribir un postmortem? ¿Por qué hacer públicos nuestros propios errores? Primero, como un ejercicio de catarsis interna del equipo de desarrollo, un grupo de personas que han estado trabajando, codo con codo, con un único fin: conseguir acabar con éxito un proyecto o un producto.

Segundo, como una inmejorable oportunidad para construir nuestro curriculum. Internet está lleno de casos de éxito. Pero, he descubierto que respeto mucho más a los desarrolladores que tienen la sabiduría necesaria para reconocer sus propios errores y la valentía suficiente para hacerlo en público.

No sé lo que buscan otras personas, pero yo no quiero trabajar con los que luchan por ser los mejores, sino con los que intentan crear el mejor producto.

Escribir un postmortem no es un proceso placentero. La autocrítica sincera nunca lo es.

No creo que escribir un postmortem sea un proceso placentero. La autocrítica sincera nunca lo es. Sin embargo, los más interesantes y de los que más se suele aprender son los que pertenecen a proyectos fallidos o sonados fracasos, como Tabula Rasa.

Cuando trabajaba en Sixservix, participé en el desarrollo de algunos de los proyectos de software más ambiciosos de este país. Hice algunas cosas buenas pero, sobre todo, hice muchas malas. Estoy seguro de que más de uno se hubiera ahorrado los mismos errores si hubiera podido leerlos.

A partir de ahora, intentaré escribir postmortems públicos de todos los proyectos en los que participe. ¿Y a vosotros? ¿Os gustaría hacer lo mismo?

BOLA EXTRA!

Comments { 5 }