[agile-spain][Madrid] Reunión 10 de Febrero - Evangelizar en la empresa

[Alberto Peña]

¡Buenas!

¡Os recuerdo que este miércoles 10 de febrero nos reunimos! Como siempre, empezaremos a las 19:30 y el tema a tratar será "Evangelizar en la empresa".

ATENCIÓN: Al final nos reuniremos en las oficinas de IPSA. 

Podéis is apuntándoos en la página de la reunión:

http://sites.google.com/site/agilemadrid/reuniones/2010-02-10

(tenéis toda la información necesaria sobre como llegar a IPSA allí).

Un saludo.

--
Alberto Peña Abril

http://twitter.com/plagelao
http://plagelao.blogspot.com/

[Legnita]

No consigo actualizar la agenda, pero intentaré asistir.

Gracias por la comunicación,
Angel

[Raquel Laina]

Buenos días,

Intentaré actualizar hoy la página para incluir una descripción de cómo va a ser la sesión y algún enlace a lecturas recomendadas.

Un saludo,

Raquel

2010/2/9 Legnita <angel....@gmail.com>

No consigo actualizar la agenda, pero intentaré asistir.

Gracias por la comunicación,
Angel

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.

[amisai]

Buenos días,

llevo algún tiempo leyendoos (en silencio, para escuchar a los
maestros ;-) ), e igual tengo tiempo para ir a la reunión del
miercoles, pero no encuentro el botón para apuntarse ¿me podéis decir
que estoy haciendo mal?

Un saludo,
Abel.

On Feb 8, 10:37 am, Alberto Peña <plage...@gmail.com> wrote:
> ¡Buenas!
>

> ¡Os recuerdo que este *miércoles 10 de febrero* nos reunimos! Como siempre,

> empezaremos a las 19:30 y el tema a tratar será "Evangelizar en la empresa".
>

> *ATENCIÓN: Al final nos reuniremos en las oficinas de
> **IPSA*<http://www.ipsa.es>
> .

[Alberto Peña]

Para los que no podéis actualizar la página. Necesitáis que os invitemos a colaborar en el sitio de google (estoy en ello :D ). A todo el que le pase que me lo comunique y le doy de alta. Aún así, aunque no podáis añadiros a lista, las puertas están abiertas para todo el que quiera venir. No es un requisito imprescindible (aunque si deseable ;) ) apuntarse a la lista :D

Un saludo

[Raquel Laina]

Buenos días,

Recordad que nos vemos esta tarde a las 19:30 en IPSA.

http://sites.google.com/site/agilemadrid/reuniones/2010-02-10?pli=1

Un saludo,

Raquel

2010/2/9 Alberto Peña <plag...@gmail.com>

[Manuel Castro]

Buenos días.

De la reunión que tuvimos ayer el grupo de Madrid, después de la exposición de Raquel (muy clara), lo que más me preocupó es la cantidad de veces que salieron  las frases:
* Tu crees que estas haciendo scrum pero no lo haces.
* Esta de moda vender agilismo (mainstream?) pero muy pocos lo  hacen de verdad.

Ante estas frases, surge rápidamente la idea de hacer un checklist de cosas que cumplo de agilismo y cosas que no cumplo.

Y entonces vino Raquel y nos contó sus experiencias  que yo resumo así:
Cumplir un checklist de cosas que haces caminando hacia el agilismo, tampoco quiere decir que seas agil, solo que estas imponiendo los procesos relacionados con el agilismo.
Labor que ademas, consume al evangelista

Sobre esta estrategia, el grupo  corroboró contando alguna experiencia de 'no éxito' al respecto de meter a fuego los procesos/técnicas involucrados, incluso los extraídos a través de retrospectivas.
 
Con lo que me quedo finalmente es con la duda:
¿Como saber si realmente estoy avanzando en la implantación del agilismo en mi proyecto/organización ?.

Respuestas malas:
* Por que no documentas
* Por que hay buen rollo en el equipo.
* Por que NO hay sobreesfuerzos y todos trabajamos 40h/s.
Incluso me atrevería a agregar, ¡por que el cliente esta contento!,
...
¿cuales son las buenas respuestas?

un saludo.


Raquel Laina escribió:

--

	Manuel Castro
www.nayadegroup.com Cl. Corazón de María 6, Of. 24 ES28002 – Madrid – España	mca...@nayadegroup.com T: (+34) 913.563.087 F: (+34) 912.994.739 M: (+34) 657.824.003

 

[José Manuel Beas]

On 11/02/2010, Manuel Castro <mca...@nayadegroup.com> wrote:

Buenos días.

De la reunión que tuvimos ayer el grupo de Madrid, después de la exposición de Raquel (muy clara), lo que más me preocupó es la cantidad de veces que salieron  las frases:
* Tu crees que estas haciendo scrum pero no lo haces.
* Esta de moda vender agilismo (mainstream?) pero muy pocos lo  hacen de verdad.

Ante estas frases, surge rápidamente la idea de hacer un checklist de cosas que cumplo de agilismo y cosas que no cumplo.

 

 

¿El manifieso ágil no te vale?

 

Y entonces vino Raquel y nos contó sus experiencias  que yo resumo así:
Cumplir un checklist de cosas que haces caminando hacia el agilismo, tampoco quiere decir que seas agil, solo que estas imponiendo los procesos relacionados con el agilismo.
Labor que ademas, consume al evangelista

Sobre esta estrategia, el grupo  corroboró contando alguna experiencia de 'no éxito' al respecto de meter a fuego los procesos/técnicas involucrados, incluso los extraídos a través de retrospectivas.

 

 

Si te quedas con la parte de principios/valores que están en el manifiesto ágil y los asimilas (como organización), es decir, provocas el cambio cultural, entonces eres ágil (agilista más bien).

 

 
Con lo que me quedo finalmente es con la duda:
¿Como saber si realmente estoy avanzando en la implantación del agilismo en mi proyecto/organización ?.

Respuestas malas:
* Por que no documentas
* Por que hay buen rollo en el equipo.
* Por que NO hay sobreesfuerzos y todos trabajamos 40h/s.
Incluso me atrevería a agregar, ¡por que el cliente esta contento!,
...
¿cuales son las buenas respuestas?

un saludo.

 

 

Implantar métodos y prácticas ágiles no debería ser un fin en sí mismo, sino un medio para conseguir... buen rollo en el equipo, evitar sobreesfuerzos de manera habitual, que tu cliente esté contento (e incluso no documentar más de lo necesario).

 

¿Puedo reformular tu pregunta? ;-)

 

"¿Qué persigues tú cuando quieres introducir este cambio cultural en tu organización?"

 

Apostillando esta pregunta. Se suele decir que una buena definición de objetivo debe ser SMART (eSpecificos, Medibles, Alcanzables, Realistas, con un plazo de Tiempo). ;-)

 

Un saludo,

JMB

 

[Abel Muiño Vizcaino]

El 11/02/2010, a las 10:38, José Manuel Beas escribió:

¿El manifieso ágil no te vale?

El manifiesto es tan escueto y genérico que "todo cabe" (o nada, según el nivel de extremismo de cada uno). Deja tanto a la imaginación que puede ser hasta peligroso (y eso que hace tiempo que no oigo/leo la palabra "talibán" en las conversaciones sobre agilismo... ¡es un gran progreso! :-) )

Parece que estamos llegando a una situación como la del resto de metodologías... que se dice que se usa X, pero si preguntas al equipo, no están de acuerdo (y, muy probablemente, no se use nada). Por ello X acumula mala fama, hasta que alguien reinventa la rueda y volvemos a empezar.

Personalmente, considero el agilismo una llamada de atención hacia mejores formas de hacer las cosas. Scrum, Kanban, Lean... son sólo "recetas" (o "kits"... como un mueble de Ikea...). Para cada caso concreto puede que funcionen, puede que no.

Yo mediría los beneficios antes y después de intentar ser ágil. Si los beneficios son menores después, entonces lo has intentado pero no estás siendo ágil. Y uso beneficios de forma genérica, porque cada uno tiene su criterio... ¿desarrollar más rápido? ¿con menos incidencias? ¿con más satisfacción del cliente? ¿con más satisfacción del equipo? ¿con más margen económico?

Pero cuidadín... no soy ningún gurú del agilismo. En el fondo me va más la idea de un ciclo de mejora continua --yo lo ví por 1ª vez en la iso-9000-- :-).

--

Abel Muiño - http://ramblingabout.wordpress.com/

[German DZ]

Abel dice:

"Pero cuidadín... no soy ningún gurú del agilismo. En el fondo me va más la idea de un ciclo de mejora continua --yo lo ví por 1ª vez en la iso-9000-- :-)."

Saben que es posible certificar ISO 9000 siendo ágil? Entonces.... una cosa no es contraria a la otra.

(Esto no es respuesta, solo una publicidad de mis intereses: Agilismo Corporativo)


:)

GermanDZ

2010/2/11 Abel Muiño Vizcaino <amu...@gmail.com>

[José Manuel Beas]

2010/2/11 Abel Muiño Vizcaino <amu...@gmail.com>

El 11/02/2010, a las 10:38, José Manuel Beas escribió:

¿El manifieso ágil no te vale?

El manifiesto es tan escueto y genérico que "todo cabe" (o nada, según el nivel de extremismo de cada uno). Deja tanto a la imaginación que puede ser hasta peligroso (y eso que hace tiempo que no oigo/leo la palabra "talibán" en las conversaciones sobre agilismo... ¡es un gran progreso! :-) )

El manifiesto ágil también son los 12 principios. La primera parte, la que todo el mundo se sabe, no pasan (para mi) de meros eslóganes muy útiles para conseguir adeptos. La segunda parte, los principios, son estupendos para perder adeptos. :-)
 

Parece que estamos llegando a una situación como la del resto de metodologías... que se dice que se usa X, pero si preguntas al equipo, no están de acuerdo (y, muy probablemente, no se use nada). Por ello X acumula mala fama, hasta que alguien reinventa la rueda y volvemos a empezar.

Personalmente, considero el agilismo una llamada de atención hacia mejores formas de hacer las cosas. Scrum, Kanban, Lean... son sólo "recetas" (o "kits"... como un mueble de Ikea...). Para cada caso concreto puede que funcionen, puede que no.

100%
 

Yo mediría los beneficios antes y después de intentar ser ágil. Si los beneficios son menores después, entonces lo has intentado pero no estás siendo ágil. Y uso beneficios de forma genérica, porque cada uno tiene su criterio... ¿desarrollar más rápido? ¿con menos incidencias? ¿con más satisfacción del cliente? ¿con más satisfacción del equipo? ¿con más margen económico?

Por eso decía lo de objetivos SMART.
 

Pero cuidadín... no soy ningún gurú del agilismo. En el fondo me va más la idea de un ciclo de mejora continua --yo lo ví por 1ª vez en la iso-9000-- :-).

Lo cuál da más valor a tu opinión. Si no hubiera escépticos entre nosotros caeríamos en la autoindulgencia. Ya se te echaba de menos. :-)
 

--

Abel Muiño - http://ramblingabout.wordpress.com/

[Abel Muiño]

2010/2/11 German DZ <ge...@ndz.com.ar>

Saben que es posible certificar ISO 9000 siendo ágil? Entonces.... una cosa no es contraria a la otra.

(Esto no es respuesta, solo una publicidad de mis intereses: Agilismo Corporativo)

Creo que hay dos cosas que "salvarán al agilismo" (ya me he puesto grandilocuente... ¿veis lo que conseguís?).

1) El agilismo corporativo (gran nombre, Germán :-) )
2) Vender agilismo a los clientes

El punto 1 es básico para ser "mainstream".
El punto 2 es básico para que el cliente acepte las reglas del juego ágil (nada de fijar todas las variables).

Hasta ahora, hemos estado vendiendo agilismo a los técnicos, a los de abjo de todo... para que hagan eso de agilismo de guerrila y tal. Muy divertido. Pero creo que hay poco más que ganar ahí.

[José Manuel Beas]

Hasta ahora, hemos estado vendiendo agilismo a los técnicos, a los de abjo de todo... para que hagan eso de agilismo de guerrila y tal. Muy divertido. Pero creo que hay poco más que ganar ahí.

Veo que no estuviste en el Coding Dojo. Tendré que invitarte a un Code Retreat. :-D

Sin buenas prácticas, sin equipos con actitudes profesionales y capacitados para hacer bien el trabajo, usa la metodología que quieras porque obtendrás lo mismo: fracasos.

La "realidad" (sí, esa de la que todos nos quejamos) está llena de claroscuros y no coincide con ningún argumento extremo. Yo no he tenido nunca un equipo 100% profesional ni 100% no-profesional, pero sí he tenido algunos tíos super-comprometidos y otros super-vagos. ¿Qué tiene que ver eso con el agilismo corporativo o con el agilismo desde las trincheras? Nada (en sentido estricto), salvo que al intentar aplicar los principios ágiles en tu organización te obligas a adoptar una serie de buenas prácticas que (desde hace mucho tiempo) se ha comprobado que son beneficiosas (no he dicho novedosas, sino beneficiosas).
* Si no eres capaz de adoptar las buenas prácticas por falta de actitud, necesitas imponer una metodología desde los managers y unas prácticas desde los seniors.
* Si no eres capaz de adoptar las buenas prácticas por falta de aptitud, necesitas capacitar a tu equipo desde cursos de formación (<<publicidad subliminal>>) y con cambios organizativos que promuevan el intercambio de conocimientos y experiencias (p.ej.) [O despidiendo a unos cuantos, que tampoco viene mal, je, je]

¿Sigues creyendo que hay poco más que ganar ahí? :)

Una vez más: no se trata de ser un talibán sino de creer que hay maneras mejores (y diferentes a las que usamos habitualmente) de hacer las cosas. Y ya sé que el entorno no es el más adecuado. Justamente estoy escuchando en la radio que España es, tradicionalmente, un país con una productividad laboral bajísima. Así que no se trata sólo de aprenderse el libro del Kanban, certificarse en Scrum y liarse a poner postits en las paredes, sino en ir dando pasitos (sí, no zancadas, sino pasitos) que nos permitan estar cada día más cerca de un entorno mejor.

Cada uno tenemos "nuestra realidad" (igual que la tuvieron/tienen en su momento Fowler, Jeffries y cía), y antes de escribir el Manifiesto no sabían hacia dónde tenían que tirar cada vez que abordaban un proyecto. Nosotros tampoco conocemos ese camino (porque hay infinitos, más o menos), pero lo que nos distingue de ellos es que nosotros ya conocemos cuál es el destino. :-)

Y todo lo demás son "yaperos". :-)
http://www.presionblogosferica.com/2010/02/04/montanas-en-la-tierra-media/

Un saludo,
JMB

[Abel Muiño Vizcaino]

Este es un post totalmente opinable y de opinion. No tengo hechos para demostrar nada de lo que, los que tengan paciencia, leerán a continuación.

El 11/02/2010, a las 19:20, José Manuel Beas escribió:

¿Sigues creyendo que hay poco más que ganar ahí? :)

Sinceramente, para el agilismo... sí. Poco, muy poco.

Lo que se gana entre los técnicos es... tener mejores técnicos.

Vale, tienes a un equipo compenetrado, que ha descubierto que git es mejor que svn, se ha instalado un entorno de CI que cada 30 minutos despliega una nueva versión, Los tests unitarios están super-optimizados y se ejecutan en pocos segundos. No han tenido una build rota en los últimos 3 meses. La cobertura roza al 90%. Trabajan 8 horas, 4 días a la semana. El viernes, por supuesto, se dedican a laboratorios para mantener la formación y dar salida a la creatividad de cada uno. De hecho, uno de los componentes del proyecto actual salió de esas horas, ahorrando unas 2 jornadas de trabajo.

Es Jauja.

Entonces, tras el último sprint (y 11 demos anteriores) el cliente dice: "Es que esto no es lo que queríamos".

Si sólo "vendemos" agilismo a los técnicos, no conseguimos cambiar nada.

Si lo hacemos al revés... si el cliente EXIGE demos semanales. Si EXIGE estar en las reuniones de inicio de Sprint... entonces a los proveedores no les quedará más remedio que ser ágiles. Así que no les quedará más remedio que enseñar Scrum a sus jefes de equipo y XP a sus desarrolladores.

Al final, es una cuestión de cambiar la actitud de "quien tiene la sartén por el mango". En lo demás, hay valor (a nivel equipo e incluso personal) pero no "a nivel grandilocuente", para el Agilismo.

La queja más frecuente que oigo en las reuniones de Madrid es del estilo "encontrar un (¿buen?) Product Owner es mision imposible".

¿Todavía crees que es predicando a los técnicos como vas a cambiar "el mundo real"?

[German DZ]

Muy de acuerdo contigo Abel!!! tendrías que haber estado en la charla de Agile Madrid de ayer... 

Objetivo de ser ágil: hacer mejores negocios

¿Cómo?: haciendo mejor muchas cosas, entre otras las técnicas

Imprescindible: Servir al cliente...

"Devoción por el cliente": Es un valor ágil? creo que no.. debería serlo! esa es la guía para hacer el resto.

2010/2/11 Abel Muiño Vizcaino <amu...@gmail.com>

Este es un post totalmente opinable y de opinion. No tengo hechos para demostrar nada de lo que, los que tengan paciencia, leerán a continuación.

[jorge]

he llamado al párroco y me ha dicho que:

Customer collaboration over contract negotiation

2010/2/11 German DZ <ge...@ndz.com.ar>

[José Manuel Beas]

2010/2/11 Abel Muiño Vizcaino <amu...@gmail.com>

Este es un post totalmente opinable y de opinion. No tengo hechos para demostrar nada de lo que, los que tengan paciencia, leerán a continuación.

El 11/02/2010, a las 19:20, José Manuel Beas escribió:

¿Sigues creyendo que hay poco más que ganar ahí? :)

Sinceramente, para el agilismo... sí. Poco, muy poco.

Lo que se gana entre los técnicos es... tener mejores técnicos.

Vale, tienes a un equipo compenetrado, que ha descubierto que git es mejor que svn, se ha instalado un entorno de CI que cada 30 minutos despliega una nueva versión, Los tests unitarios están super-optimizados y se ejecutan en pocos segundos. No han tenido una build rota en los últimos 3 meses. La cobertura roza al 90%. Trabajan 8 horas, 4 días a la semana. El viernes, por supuesto, se dedican a laboratorios para mantener la formación y dar salida a la creatividad de cada uno. De hecho, uno de los componentes del proyecto actual salió de esas horas, ahorrando unas 2 jornadas de trabajo.

Es Jauja.

Entonces, tras el último sprint (y 11 demos anteriores) el cliente dice: "Es que esto no es lo que queríamos".

¿Dónde estaba tu cliente durante las 11 demos anteriores?
 

Si sólo "vendemos" agilismo a los técnicos, no conseguimos cambiar nada.

No estaban haciendo agilismo (no estaban dando valor al cliente) Insisto: lee los principios del manifiesto (la parte de atrás de la tarjeta).
http://www.agile-spain.com/principios_agiles
 

Si lo hacemos al revés... si el cliente EXIGE demos semanales. Si EXIGE estar en las reuniones de inicio de Sprint... entonces a los proveedores no les quedará más remedio que ser ágiles. Así que no les quedará más remedio que enseñar Scrum a sus jefes de equipo y XP a sus desarrolladores.

Al final, es una cuestión de cambiar la actitud de "quien tiene la sartén por el mango". En lo demás, hay valor (a nivel equipo e incluso personal) pero no "a nivel grandilocuente", para el Agilismo.

La queja más frecuente que oigo en las reuniones de Madrid es del estilo "encontrar un (¿buen?) Product Owner es mision imposible".

¿Todavía crees que es predicando a los técnicos como vas a cambiar "el mundo real"?

Sí. Porque el product owner no es el que hace el producto: es el equipo. :-)

Así que TAMBIEN hay que capacitar al equipo.

JMB

[German DZ]

Si si... yo iba un poco más allá... porque en algún punto creo que muchos creen que este principio es algo a aplicar cuando "algunas cosas ya no están tan bien".

Que la idea sea: ya me contrató, ahora voy a hacer todo lo que necesite mi cliente por el esfuerzo al que me comprometí/precio que pagó (según el tipo de contrato); y seguramente todo va a ir muy bien.

2010/2/11 jorge <jorge...@gmail.com>

[jorge]

Yo no creo que la colaboración con el cliente se aplique *cuando algo no está bien*. En nuestro caso, se trata de integrar al cliente para entender qué quiere y por qué y que él entienda cómo trabajamos, por qué y que beneficios e inconvenientes tiene. Finalmente, la colaboración se produce en la ejecución del proceso sw.

[humor del malo] ojo: uno que fue más allá fue un tal carlos jesús[/humor del malo]

2010/2/11 German DZ <ge...@ndz.com.ar>

[Abel Muiño Vizcaino]

El 11/02/2010, a las 20:19, José Manuel Beas escribió:

¿Dónde estaba tu cliente durante las 11 demos anteriores?

Es un caso ficticio, pero no me cuesta nada imaginarlo allí, en las demos, diciendo que si a todo.

O no apareciendo.

O que quien aparece es la persona encargada de gestionar el proyecto, pero quien lo acepta es otra persona cuyo rol NO implica hacer el seguimiento del proyecto.

Piensa en grandes empresas con mucha estructura, en administraciones públicas, en "mi jefe me ha encasquetao este marrón"...

Hay mil motivos... estás en un foro de gente ágil y/o interesada por el agilismo.

 Si sólo "vendemos" agilismo a los técnicos, no conseguimos cambiar nada.

No estaban haciendo agilismo (no estaban dando valor al cliente) Insisto: lee los principios del manifiesto (la parte de atrás de la tarjeta).
http://www.agile-spain.com/principios_agiles

¿Pero era culpa de ellos? ¿O del cliente que estaba jugando a otra cosa?

Pocos o ningún cliente va a decir que no a las entregas incrementales

 

Si lo hacemos al revés... si el cliente EXIGE demos semanales. Si EXIGE estar en las reuniones de inicio de Sprint... entonces a los proveedores no les quedará más remedio que ser ágiles. Así que no les quedará más remedio que enseñar Scrum a sus jefes de equipo y XP a sus desarrolladores.

Al final, es una cuestión de cambiar la actitud de "quien tiene la sartén por el mango". En lo demás, hay valor (a nivel equipo e incluso personal) pero no "a nivel grandilocuente", para el Agilismo.

La queja más frecuente que oigo en las reuniones de Madrid es del estilo "encontrar un (¿buen?) Product Owner es mision imposible".

¿Todavía crees que es predicando a los técnicos como vas a cambiar "el mundo real"?

Sí. Porque el product owner no es el que hace el producto: es el equipo. :-)

Si el cliente no lo acepta, me da igual lo que haya hecho el equipo. Y el cliente puede no aceptarlo sin motivo alguno si no está jugando con las mismas reglas.

No ocurre al revés... si el equipo no juega con las reglas del cliente entonces podemos entrar en temas de sanciones, cancelaciones de contratos y mil cosas más.

Así que TAMBIEN hay que capacitar al equipo.

Claro, nunca he dicho "no capacitéis a vuestros equipos". Lo que he dicho es que hay poco que ganar para el Agilismo ahí. ¿El equipo? Si, el equipo gana... incluso a nivel personal. El Agilismo... poco.

Insisto, mi opinión es sobre "the big picture" para el agilismo. No el que una empresa o un equipo haga mejor las cosas (que, por otra parte, no es en absoluto la exclusiva ni la marca diferencial del agilismo... IMHO los equipo que hacen Waterfall también pueden/deben estar bien preparados y tener buenas herramientas y... y...).

¿Quieres que el Agilismo sea algo "gordo"? Deja de vender a gente que se esconde en lugares oscuros con luz artificial (¿porqué siempre nos meterán en los sótanos?) y vende al que tiene la pasta. Ese es el que hará la palanca para cambiar el mundo.

Pero, ah... claro... hablan otro lenguaje y jugar a la contabilidad, powerpoint, politiqueo y otros deportes de despacho no es igual de divertido. Y, sobre todo, no da tanto resultado.... no te aplaudirán cuando pidas hacer boicot a un cliente, por ejemplo.

"Yapero" abrir un nuevo mercado es duro. Para ti, y para la empresa que según algunos debe renunciar a sus clientes.

[Juan Carlos Quijano Abad]

Gusto leerte Abe,

Dices justo lo que pienso. La "Evangelización" y las "trincheras" molan. Pero lo que cambia al mundo son los que mandan, decide y pagan... y a esos no le hacemos mucho caso en nuestros foros.

--
Saludines
Juan Quijano

[Vicenç Garcia]

+1 a Abel

2010/2/11 Juan Carlos Quijano Abad <juancarl...@gmail.com>

--
Vicenç García
http://devnettips.blogspot.com

[José Manuel Beas]

[EXPERIENCIA PROPIA]
* Start-up con departamento de desarrollo y presupuesto indecente (de grande) para hacer un desarrollo ambicioso e indefinido.
* El dueño sabe de Toyota (tiene un MBA) y el director de desarrollo sabe de multinacionales de IT americanas (trabajó para una empresa que inventó un lenguaje de programación muy conocido y cuyo nombre no puedo decir porque está siendo absorbida por otra que empezó con una base de datos también muy conocida).
* Todos los empleados trabajan por objetivos y no hay horario de entrada ni de salida.
* La dirección llega al convencimiento de que hay que hacer una metodología de desarrollo de software iterativa e incremental.
* Los técnicos (los que tenían que hacer que los programas funcionaran) no estaban (estabamos) capacitados (y en algunos casos tampoco había una actitud profesional).
* Resultado: FAIL
[/EXPERIENCIA PROPIA]

Definitivamente, parece que queréis que os digan desde arriba que hagáis Agile para así, si la cosa va mal, poderles echar la culpa a ellos (como cuando dijeron de hacer CMMI, o RUP, o METRICA o lo que sea). ¡Cobardicas! ¡Salid de vuestros cubículos, subíos a las mesas y decid conmigo: ¡Oh, Capitán, mi Capitán! :D
http://www.youtube.com/watch?v=HVS4PiVicqw

Un saludo,
Jose Manuel Beas

http://agilismo.es
http://jmbeas.iExpertos.com <-- ¡Me he mudado!
http://twitter.com/jmbeas

2010/2/11 Vicenç Garcia <vincen...@gmail.com>

[jorge]

Espero que seamos capaces de cambiar el capítulo de resultado en nuestro caso. Gracias por compartir tu experiencia, tendremos puesto el ojo en estos temas.

2010/2/11 José Manuel Beas <jose....@gmail.com>

[Juan Carlos Quijano Abad]

Buenas,

Creo tener claro que en la experiencia que estas compartiendo con nosotros el problema fue un problema de seguimiento. No de que los técnicos no estuvieran a la altura.

Con una buena gerencia o jefatura de proyecto se hubiera visto en las primeras tres iteraciones que el problema estaba en los técnicos y se hubiera tomados las decisiones para corregirlo. Al igual que se hubiera echo con cualquier otro impedimento.

Pero también es cierto que si no fuera porque los que mandan o pagan decidieron utilizar una metodología iterativa, el equipo por sus propias limitaciones, no lo hubiera podido hacer. Lo cual nos vuelve a señalar que el problema vino de la gestión del proyecto y no de su equipo de desarrollo, que era el que era.

El 11 de febrero de 2010 22:03, José Manuel Beas <jose....@gmail.com> escribió:

[EXPERIENCIA PROPIA]
* Start-up con departamento de desarrollo y presupuesto indecente (de grande) para hacer un desarrollo ambicioso e indefinido.
* El dueño sabe de Toyota (tiene un MBA) y el director de desarrollo sabe de multinacionales de IT americanas (trabajó para una empresa que inventó un lenguaje de programación muy conocido y cuyo nombre no puedo decir porque está siendo absorbida por otra que empezó con una base de datos también muy conocida).
* Todos los empleados trabajan por objetivos y no hay horario de entrada ni de salida.
* La dirección llega al convencimiento de que hay que hacer una metodología de desarrollo de software iterativa e incremental.
* Los técnicos (los que tenían que hacer que los programas funcionaran) no estaban (estabamos) capacitados (y en algunos casos tampoco había una actitud profesional).
* Resultado: FAIL
[/EXPERIENCIA PROPIA]

Definitivamente me estoy cansando de las salidas de tono. Relajate y sé consciente que estas hablando con profesionales "con los huevos pelaos" de desarrollar y gestionar proyectos y que el tono de tus ultimos post roza el menosprecio. "Oh Cesar, Recuerda que eres mortal".
 

Definitivamente, parece que queréis que os digan desde arriba que hagáis Agile para así, si la cosa va mal, poderles echar la culpa a ellos (como cuando dijeron de hacer CMMI, o RUP, o METRICA o lo que sea). ¡Cobardicas! ¡Salid de vuestros cubículos, subíos a las mesas y decid conmigo: ¡Oh, Capitán, mi Capitán! :D
http://www.youtube.com/watch?v=HVS4PiVicqw

--
Un saludo
Juan Quijano
 

[Alfredo Casado]

Mi impresión es que a algunos se os esta escapando que es esto del agilismo y que no es, hasta donde llega y cuales son sus objetivos, os recuerdo:

"estamos descubriendo mejores formas de desarrollar software..." y luego lo empieza el resto..., lo que no dicen es "estamos descubriendo mejores formas para ganar más dinero con el software". Ganar más dinero debería ser CONSECUENCIA de hacer mejor software, pero nunca el objetivo de toda es historia es más modesto que dominar el mundo con la bandera ágil, es mucho más simple, lo dicen bien claro, se trata de HACER MEJOR SOFTWARE, nada más, y por supuesto nada menos.

Si el objetivo es ganar dinero con el software hay caminos más directos, preguntar como lo han echo en alguna de las grandes consultoras, que sus directivos se han inflado y se inflan a ganar pasta.

--

[Jorge Uriarte Aretxaga]

> .... Lo cual nos vuelve a señalar que

> el problema vino de la gestión del proyecto y no de su equipo de desarrollo,
> que era el que era.
>

Hombre, aunque no me atrevo a juzgar cual fue la (o las!) causas del
fracaso sin conocerlo y sólo por la referencia dada, te diría que, en
mi opinión, no hay problema que venga de un sólo frente, ni casos de
responsabilidad exclusiva de la gestión del proyecto, o del equipo de
desarrollo. Somos equipos, a menudo a nuestro pesar, y en muchos casos
disfuncionales.

Y en cuanto al "parece que queréis que os digan", me lo tomo como lo
que es, y personalmente no veo salida de todo sino recurso literario,
en una llamada a asumir nuestras responsabilidades, sea cual sea
nuestra posición, a pelear por lo que queremos/creemeos, si es que lo
hay. ¿Quién disfrutó de la charla de Agilismo de Guerrilla de Xavi
Gost en el Agile Open? Deberíamos haberla grabado en video...

_
Jorge

[José Manuel Beas]

2010/2/11 Jorge Uriarte Aretxaga <jorge....@gailen.es>

> .... Lo cual nos vuelve a señalar que

> el problema vino de la gestión del proyecto y no de su equipo de desarrollo,
> que era el que era.
>

Hombre, aunque no me atrevo a juzgar cual fue la (o las!) causas del
fracaso sin conocerlo y sólo por la referencia dada, te diría que, en
mi opinión, no hay problema que venga de un sólo frente, ni casos de
responsabilidad exclusiva de la gestión del proyecto, o del equipo de
desarrollo. Somos equipos, a menudo a nuestro pesar, y en muchos casos
disfuncionales.

+1
 

Y en cuanto al "parece que queréis que os digan", me lo tomo como lo
que es, y personalmente no veo salida de todo sino recurso literario,
en una llamada a asumir nuestras responsabilidades, sea cual sea
nuestra posición, a pelear por lo que queremos/creemeos, si es que lo
hay.

Por supuesto. No podía ser otra cosa que una llamada a las armas. A dar un paso adelante. Aunque como toda generalización dicha en público desmerezca el esfuerzo de los que ya habéis dado muchos pasos adelante, y hace mucho tiempo ya. Pero, claro está, el mensaje no iba destinado a vosotros sino a nosotros, los cobardes, los que nos quedamos en retaguardia, temblando muertos de miedo porque no sabemos ni cargar la escopeta. :-)

 

¿Quién disfrutó de la charla de Agilismo de Guerrilla de Xavi
Gost en el Agile Open? Deberíamos haberla grabado en video...

Siempre estamos a tiempo de pedirle que la dé de nuevo. (Y hasta ahí puedo leer) :-)

un saludo,
JMB

[Jose R.]

Pues no sé, yo creo que el agilismo de guerrila mola, pero que es agilismo a medias.Lo que de verdad se debe tratar es de implicar a todas las partes. Si haces agilismo bajo el radar, perjudicas la principal solidez de los principios: la confianza.
Debemos promover más integración entre las partes, no que unos digan a otros cómo actuar...

2010/2/11 José Manuel Beas <jose....@gmail.com>

[José Manuel Beas]

Me explico fatal.

Si en tu empresa, entorno, organización... no puedes trabajar bien, tienes tres opciones:
a) te adaptas al entorno y haces lo que los demás (no trabajar bien y protestar en los bares sobre lo mal que está todo)
b) cambias de empresa con la esperanza de que en el cambio te vaya mejor (aka lotería o ruleta rusa)
c) tomas la pastilla roja, te subes a la mesa y recitas lo de ¡Capitán, Oh, Mi capitán!

Yo, después de pasar por todas (varias veces), estoy en c). ¿Me hace eso mejor? ¿Me hace peor? No, simplemente es mi opción.

¿Que sería ideal que todos fueramos cogidos de la mano cantando "Al mundo entero quiero dar un mensaje de paz" e implantaramos Scrum, formaramos a los profesionales en sus diferentes roles, capacitaramos técnicamente a todos los técnicos y todos nos quitaramos los miedos y confiaramos en los demás y todo eso? Claro. Sería muy bonito. Y no dejaré de intentar explicar que eso es lo ideal. Y no dejaré de trabajar para que sea posible. Pero si no es posible en mi entorno, no me quedaré llorando en un rincón diciendo "yapero". Me pondré en marcha y pasito a paso iré haciendo que mi pequeño mundo de piruleta alrededor mía cada día vaya siendo un poquito más parecido al ideal. Iterativo e incremental. Como citaba Raquel Laina ayer en la reunión del grupo de Madrid: "un camino de mil millas comienza con un paso".

Un saludo,
Jose Manuel Beas

http://agilismo.es
http://jmbeas.iExpertos.com <-- ¡Me he mudado!
http://twitter.com/jmbeas

2010/2/11 Jose R. <jrr...@gmail.com>

[German DZ]

Opción d) Ahora que Agile es Mainstream, convencer a las generencias (aunque solo lo hagan por moda) que este es el camino, pero hacerlo bien!

Es decir que SUMADO a la guerrilla acompañarlo con lo que vale, es decir Cursos/Coaching/Consultoría/Mentoring etc... de gente que "sepa" lo que hacer y ayude a los demás a hacerlo.

Luego será una cuestión de ver si con Agile si pueden lograr resultados que no lograron siguiendo o NO siguiendo otro tipo de procesos o NO procesos.. eso dependerá de la aptitud de cada organización.

Y en definitiva, si sos malo haciendo software, no hay proceso que te salve...

Durante años me machacaron contándome que Motorola tenía software factories CMM Nivel 5, ahora bien... el software de motorola para móviles fue cada vez peor. (info poco sustanciada, pero buehhh, casi que da igual vale la metáfora). Perdón Motorola por la mala prensa (aun extraño mi Vader!).

GermanDZ (Nada de guerrillas, vamos por el Agile Corporativo)

[Abel Muiño Vizcaino]

Dos cosas que sigo son transmitir claramente:

1) No hablo de "tu empresa" hablo de Agilismo con mayúsculas, De compromiso del cliente. Y de cosas concretas... 

Quizá estoy muy equivocado, pero creo que la situación actual es que es muy difícil encontrar a ese cliente que entiende y acepta los compromisos del desarrollo Ágil.

Muerto de curiosidad, he creado una pequeña encuesta: http://doodle.com/n8vd77kpp9wmhpfr

2) Si el nivel técnico es tan horrendo que es imposible sacar proyectos adelante sin una reeducación (como creo leer entre líneas), entonces apaga y vámonos. Externalicemos a India, que son más baratos e igual de buenos/malos.

Que el cliente exija sólo tiene una consecuencia: limpiar el mercado de "basura" (término genérico y que cada uno piense quién es basura y quien no... mi ejemplo de siempre, por experiencia propia, es la mano de obra de Coritel).

Selección natural. Si no eres capaz de desarrollar software, no deberías estar en el mercado.

Bonus 1) sobre el ejemplo concreto: realmente le falta mucha información para poder decir que el desarrollo iterativo fue la causa del fracaso. Y habiendo trabajado en startups antes, tengo todavía más dudas..

Bonus 2) ¿te das cuenta que el "yapero" lo estás poniendo tu? "Yapero" si el cliente se vuelve ágil y me lo exige a mi.... me hunde la empresa.

--