satisfaccion thumb"Un problema de los equipos de programación con importante impacto económico es la alta rotación de personal. La relación entre insatisfacción y rotación es una evidencia contrastada. El estudio (Comparative Analysis of Job Satisfaction in Agile and Non-Agile Software Development Teams) investiga si existe una relación entre la satisfacción laboral y el método de desarrollo empleado, y encuentra una correlación positiva moderada entre el nivel de satisfacción y el uso de metodologías ágiles..." (1)

satisfaccion laboral en equipos ágiles y no ágiles

 "El análisis comparativo entre equipos ágiles y la media general de profesionales TIC, ha revelado tasas significativamente más altas de satisfacción en los miembros de equipos ágiles. Además no sólo en los trabajadores, sino también en los administradores se da mayor satisfacción con sus empleos. Este es un claro indicador de que los métodos ágiles no son un movimiento orientado sólo a los programadores".

El informe completo y todas tablas comparativas del estudio en:

(1) Melnik, G., & Marurer, F. (2006). Comparative Analysis of Job Satisfaction in Agile and Non-agile Software Development Teams. Extreme Programming and Agile Processes in Sotware Engineering, 32-42.

motivandoEn otras profesiones no sé, pero si se trata de programadores, de gente apasionada por la tecnología y por la programación de nuevas soluciones, no se preocupe por motivarles. Son profesionales motivados por su trabajo mucho más de lo que usted lo está por el suyo.

La cuestión no es motivar, sino no desmotivar con "programas de motivación", planes de desempeño, control de horas de trabajo, recompensas y castigos, etc.
Quieren programar, son gente inteligente y los modelos de motivación de manual de recursos humanos, les resultan pueriles y denigrantes y les quitan las ganas que traían con ellos cuando llegaron a su empresa el primer día.

Estamos hablando de programadores, "programadores": personas a las que les gusta su profesión. Son un porcentaje escaso. Gente que cuando deja el equipo de la oficina, continúa, investigando y "jugando", que disfruta con retos intelectuales y a la que gusta estar en continuamente descubriendo y aprendiendo.

Si los programadores de su empresa no son de este tipo, si desde que dejan la oficina hasta que vuelven a la mañana o el lunes siguiente, no echan de menos un teclado... seguramente el consejo de este post no es bueno para usted, y es posible que sí que necesite las prácticas de motivación del manual de RR.HH. También es posible que no consiga nunca productos brillantes.

 

check

Estas son las variables que condicionan el nivel de los resultados que se pueden esperar con gestión ágil de proyectos, y el nivel de riesgo general del proyecto.

 

 

 

test viabilidad proyectos agiles

 

Safe Creative #1301274440493

puzzle

 

 

 

 

puzle empresario software

(Si el producto es "facturar lo que sea" con el menor coste, y procesos o talento son pamplinas, sobra este puzle)

 

Safe Creative #1301134336669

cambio"Tras algunos momentos difíciles, paramos la implantación de CMMI y retomamos técnicas ágiles, más colaborativas. Aquí describimos esta experiencia en la implantación de un marco Scrum distribuido y en la creación de una cultura kaizen".

"... La opinión de diferentes expertos y la experiencia en empresas veteranas resaltaban la importancia de establecer procesos compartidos que pudieran ser empleados por todos. Expertos en consultoría nos aconsejaron la implantación de CMMI en ambas ciudades. Se realizó un estudio inicial de viabilidad para lanzar la nueva empresa en Bangladesh e implementar CMMI con la ayuda de una consultora externa. Aunque veíamos muchos desafíos, parecía muy prometedor."

"... Encontramos un partner competente con el que firmamos un contrato por el que nos ayudaría a alcanzar un nivel 3 de CMMI certificado en año y medio ... Uno de los directores más experimentados de la organización se trasladó a Bangladesh durante dos años como director general."

 

De CMMI a Scrum

 

"Todos los nuevos empleados de Bangladesh vinieron durante un mes a Dinamarca, en otoño de 2005 para conocer y trabajar junto con el equipo local, comprender bien el dominio del negocio y establecer un entendimiento cultural entre las dos empresas ... En ese momento no éramos conscientes del impacto de poner el objetivo en la certificación para integrar las dos ciudades. En lugar de que nuestro objetivo fuera crear valor para el negocio y ofrececer soluciones eficientes a nuestros clientes, teníamos por meta estratégica establecer un proceso marco y cumplir una serie de prácticas clave para las áreas de proceso de CMMI ... "


path to agility 2012Para asistir en diferido a las sesiones sobre agilidad de la conferencia  "The Path to Agility 2012" que se celebró en mayo de este año organizada por The Central Ohio Agile Association: "Craftsmanship", "Clean Architecture and Design", "Reality in Software Development", "Scrum and Continuous Improvement", "Driving Real Business Value Thrugh Agile", etc.

  

Craftsmanship
Chet Hendrickson & Ron Jeffries
Clean Architecture and Design
Robert C Martin (Uncle Bob)

 

desenfocadoVanidad, culto al método o la tecnología, y aislamiento del cliente son actitudes que restan valor profesional a los programadores(1).

Vanidad.

Cuando importa más ser conocido y relevante en las redes sociales que diseñar y construir software para solucionar problemas... se está perdiendo el foco y valor profesional. Se puede estar mejorando la apariencia, pero cada vez será más sólo apariencia.

Por supuesto que hay quien no cae en la vanidad, sino que ha nacido con ella porque no tiene otra cosa que exhibir, pero este no es el caso de los buenos programadores ;-)  que al ver tanta actividad social de otros programadores, entran en el juego por conformidad con su grupo social profesional, o hartos ya de leer ramplonerías.

tres actitudes que minan buenos programadores

 

Culto al método o a la técnica.

Cuando el objetivo profesional pasa de diseñar y construir software para solucionar problemas a ser un experto practicante del métdodo para cumplirlo ortodoxamente, y además cumplir con el "método bueno", y no con los otros que son peores (sea CMMI o Scrum o TDD o Kanban o XP o Scrumdoro o Scrumban o...)

Cuando se defiende (o critica) fanáticamente Java o C# o PHP o Ruby o...

También estamos perdiendo el foco y autolimitándonos, dando más valor (y responsabilidad del resultado) al método que a la persona (a nosotros). 

Aislamiento del cliente.

Cuando uno no está para hablar con  aguantar al cliente y cree que para eso están los comerciales, o los gestores de proyectos, porque los clientes no saben lo que quieren y siempre están pidiendo la última ocurrencia para mañana.

Uno puede valer para programar, pero en factorías de software; no en equipos capaces de trabajar con el cliente para conocer su visión como él mismo y diseñar la mejor solución. 

 

(1) De producción artesanal de software, no ingenieros u operarios de producción industrial de software.