Calendarios de los grupos locales y los hangouts

[Jaume Jornet]

Hola,

ayer a raiz de una pregunta de Celia comentabamos que estaria bien poder consultar los calendarios de los grupos locales y los hangouts (como la conversación se produjo dentro del hilo del hangout de Agile-Games he preferido sacarla y abrir otro hilo). Esa información esta disponible en http://agile-spain.org/calendario/ pero si no quereis pasar por la pagina, en realidad esta lo que hace es tirar de calendarios de google públicos que cada grupo local (gracias!!) ha creado y mantiene. Las urls son las siguientes:

1	AgileBcn	https://www.google.com/calendar/feeds/agilebcn%40gmail.com/public/basic
2	AgileZonaNorte	http://www.google.com/calendar/feeds/agilezonanorte%40gmail.com/public/basic
3	Agile Canarias	https://www.google.com/calendar/feeds/agilecanarias%40gmail.com/public/basic
4	Agile Levante	http://www.google.com/calendar/feeds/qnmok0q0q0b5mirrad3kkntalo%40group.calendar.google.com/public/basic
5	AgileCyL	https://www.google.com/calendar/feeds/on31o8pfd1hhtt2vk98qvvhfp0%40group.calendar.google.com/public/basic
6	Agile Aragon	http://www.google.com/calendar/feeds/agileenaragon%40gmail.com/public/basic
7	Agile Alicante	http://www.google.com/calendar/feeds/agilealicante%40gmail.com/public/basic
8	Hangouts	https://www.google.com/calendar/feeds/agilespainhangouts%40gmail.com/public/basic

Si os es mas comodo, podeis agregar los calendarios de los que esteis interesados a vuestro calendar de google (o cualquier otro que empleeis si permite consumir el feed). Para hacerlo desde google, solo teneis que ir a vuestro calendar y en la barra lateral encontrareis una opción "Add a friend calendar" en la que solo teneis que introducir el nombre de la cuenta del calendar que vereis en la url. Por ejemplo, en la primera, podeis ver que es agil...@gmail.com (no hace falta decirlo en esta lista pero por si acaso el %40 es la @)

Una vez lo hayais añadido, ya podreis ver sobre vuestro calendario los eventos que publiquen dibujados en el color que escogais para distinguirlos :D

Espero que os sirva! Gracias!!

Jaume

[José Manuel Beas]

Hola Jaume,

Muchas gracias. 

¿Sabes si se puede consumir el feed de un meetup? El de Madriagil debería ser alguno de los que aparecen en http://www.meetup.com/madriagil/#calendar 

No sé si también se podría meter a otros meetups de temas agilistas en Madrid como:

- Agile Entrepreneurship http://www.meetup.com/Agile-Entrepreneurship-Spain/

- Software Craftsmanship http://www.meetup.com/madswcraft/

- Agile Marketing http://www.meetup.com/Agile-Marketing-Spain/

Un cordial saludo,

Jose Manuel Beas

http://about.me/jmbeas

2013/3/3 Jaume Jornet <jaume....@gmail.com>

Jaume

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a agile-spain...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

[Jaume Jornet]

Pues todo parece indicar que no :( te comento:

- por lo que he podido ver, el plugin funciona con cualquier feed Atom, lo que en principio me ha dado esperanzas con la única pega del AES: no es público, el contenido es solo visible para los miembros registrados, asi que nuestra web no puede explotar los datos.

- he añadido un feed nuevo referenciando al grupo de Software Craftsmanship Madird, el unico que tiene upcoming events y que por lo tanto me permite probarlo. La url del feed es http://www.meetup.com/madswcraft/rsvps/atom/Software+Craftsmanship+Madrid/ 

- Desgraciadamente, el contenido publicado por meetup y calendar es diferente (muy logico). El plugin permite configurar como quieres displayar el mensaje mediante el uso de tags, por lo que creia que estos eran utilizados por el "parser" (pongo algunos para que veais de que hablo)

pero desgraciadamente no es asi. Mirando el código del plugin, este siempre "parsea" todos los campos que vienen en el feed de google calendar, con lo que a la que no los encuentra directamente da un error de parseo. 

Podria mirar de retocar el código del plugin para que la información de como quieres visualizar el contenido se use no únicamente para mostrarlo visualmente si no por el parser, de forma que solo intentase parsear aquellos campos que le hemos pedido que use en la configuración del feed, pero me llevaria algo de tiempo, especialmente porque meetup tampoco lo pone facil poniendo estructuras como estas

<entry>
<id>tag:meetup.com,2002-06-04:www.meetup.com/madswcraft/rsvps/atom/Software+Craftsmanship+Madrid/710680552/</id>
<title><![CDATA[Rafa de Castro: "Yes" for Práctica BDD]]></title>
<updated>2013-03-02T04:54:42-05:00</updated>
<link href="http://www.meetup.com/madswcraft/events/104049322/#rsvp_15873651" />
<content>Please click through for more information.</content>
</entry>

que no incluyen las fechas si no que debes hacer una segunda llamada usando el id para poder obtenerlas :( Estos dias voy hasta arriba de curro, pero en cuanto tenga algo de tiempo intento darle una vuelta investigando un poco mas sobre la información que publica meetup sobre sus grupos.

Sorry por no poder dedicarme ahora!!

Un abrazo,

Jaume

2013/3/3 José Manuel Beas <jose....@gmail.com>

[CNL]

Que apañaos!

Muchas gracias :) Ahora si me pierdo algo será (sólo) mi culpa jejeje :D

[david]

Hola a todos:
Este pasado Junio tuve la suerte de ser invitado por IBM-Rational
al evento IBMInnovate. El evento estuvo muy bien, especialmente porque
contaba con un path sobre Agile con ponencias de personalidades como
Scott W. Ambler y Mary&Tom Poppendieck. El tema es que en la mayor�a de
las charlas y paneles a los que asisit� (incluso en la que me toc�
hablar a m� sobre mi caso de intento de transici�n agile) siempre sal�a
la misma pregunta: �Y c�mo es posible combinar una PMO con Scrum y/u
otras t�cnicas �giles de desarrollo?

Tras las charlas �ramos varios los que coment�bamos nuestra
situaci�n en la que nos permiten aplicar ciertas t�cnicas �giles, pero
que nos las vemos y nos las deseamos para hacer encajar el PM cl�sico de
la PMO impuesta. Algunos argumentaban que medio lo llevaban dejando a la
PMO llevar la cuesti�n presupuestaria, mientras los equipos scrum se
encargaban de la ejecuci�n... a mi no me termina de convencer.

�Qu� opin�is? �radicalmente no encaja? �hay alg�n modo de hacer
convivir los dos paradigmas?

Saludos
David

[Harringer]

Antes de contestar podrias por favor concretar que es una PMO para ti.

Un saludo,

Harald

Am 03/03/2013 um 22:55 schrieb david <davidpar...@gmail.com>:

>
> Hola a todos:

> Este pasado Junio tuve la suerte de ser invitado por IBM-Rational al evento IBMInnovate. El evento estuvo muy bien, especialmente porque contaba con un path sobre Agile con ponencias de personalidades como Scott W. Ambler y Mary&Tom Poppendieck. El tema es que en la mayoría de las charlas y paneles a los que asisití (incluso en la que me tocó hablar a mí sobre mi caso de intento de transición agile) siempre salía la misma pregunta: ¿Y cómo es posible combinar una PMO con Scrum y/u otras técnicas ágiles de desarrollo?
>
> Tras las charlas éramos varios los que comentábamos nuestra situación en la que nos permiten aplicar ciertas técnicas ágiles, pero que nos las vemos y nos las deseamos para hacer encajar el PM clásico de la PMO impuesta. Algunos argumentaban que medio lo llevaban dejando a la PMO llevar la cuestión presupuestaria, mientras los equipos scrum se encargaban de la ejecución... a mi no me termina de convencer.
>
> ¿Qué opináis? ¿radicalmente no encaja? ¿hay algún modo de hacer convivir los dos paradigmas?
>
> Saludos
> David
>

[david]

Ah! perdonad, me refiero a la típica Project Management Office. Por lo
general viene inspirada en la implantación de las prácticas PMP
(Project Management Professional) del PMI (Project Management Institute)

Yo creía que la compañía en la que trabajo era la única queriendo
mezclar esos conceptos con técnicas ágiles de desarrollo, pero por lo
que comprobé el pasado Junio, parece que no es tan extraño. Al menos en
compañías con cierta tradición.

Saludos
David

[Harringer]

Si, sabemos un poco de PM-BoK. De hecho hay una linea en PMI relativo a Agile.

Igualmente el PM-BoK no se aplica como tal en una PMO. Al tratarse de un compendio no creo que haya proyecto para aplicar todo.

Por eso seria interesante saber que haces en tus PMOs, que hace equipo tecnico y que aspectos estan tratados por ambos.

Un saludo,

Harald

[david]

Hola,

En mi caso, al Oficina de Proyectos tuvo la intención inicial de
implantarse aplicando control de project management clásico hasta las
tareas de los miembros de los equipos. Algunos nos negamos en redondo a
esta situación, alegando que este modo de proceder daba al traste con
los esfuerzos de transformación ágil que se venían realizando hasta el
momento (esponsorizados por parte de la alta Dirección). Al final ha
quedado algo bastante complicado, con ciertos PMs recelosos de que lso
miembros de los equipos tengan acceso directo a los usuarios y en
general una situación que no facilita que el equipo participe en la
generación de nuevas ideas que aporten valor al negocio, donde hablar
de inceptions es bastante descabellado y donde inicialmente los equipo
realizaban las estimaciones sólo en casos excepcionales (esto último
afortunadamente ha cambiado, tras varios golpes con la cruda realidad).

Desconozco otras aplcaciones de Oficinas de Proyectos combinadas con
equipos autoorganizados. Las desconozco yo y aparentemente las
desconocían las personas con las que coincidí este verano en Orlando.
Me vi identificado cuando otros preguntaban por la solución a una
situación que a mí tampoco me estaba encajando en la organización en la
que estoy. Es por eso que lanzaba aquí la pregunta. ¿Hasta qué punto
una oficina de proyectos con visión clásica de gestión de proyectos
donde el Project Manager es el único visible y responsable del proyecto
cara a la Dirección puede combinarse con equipos autoorganizados en los
que la responsabilidad y voz es conjunta?.

Saludos.
David.

[Antonio Martinez]

Hola,

Creo que este tema esta fuera de sitio, no tiene ninguna relación con el título del hilo "Calendarios de los grupos locales y los hangouts". ¿Se puede poner en otro hilo para poder seguirlo?

Muchas gracias

[José Manuel Beas]

Hola David,

La PMO de la que hablas, entiendo que *necesita* controlar los proyectos porque está en una organización que se gestiona de manera predictiva, es decir, tiene un presupuesto y unas fechas para conseguir unos objetivos (normalmente poco concretos) antes de empezar el proyecto e incluso antes de asignarlo a un equipo en particular. De hecho, el equipo apostaría a que ni tan siquiera forma parte de vuestra organización. ¿Estoy en lo cierto?

Si es así, esta PMO tiene puede olvidarse de cómo trabajan esos equipos y limitarse a exigir que se cumplan los plazos, sancionarles si hay incumplimientos flagrantes en alguno de los términos del contrato, etc. Bueno, ya sabemos que la tasa de fracaso en estos casos es muy elevada, así que yo sugeriría optar por alguna alternativa.

Yo creo que una alternativa que funciona bien (al menos yo la he visto funcionar muy de cerca, aun no siendo una PMO formal) consiste en mantener una relación cliente-proveedor basada en la visibilidad de los avances en forma de demo periódica, posibilidad de incorporar el feedback a un backlog y predictibilidad mediante conocimiento de la velocidad del equipo sobre el consumo del backlog. La clave aquí es que el backlog debe estar priorizado y estimado y con grano suficiente para que cuando veamos peligrar el proyecto (atendiendo a la velocidad del equipo) podamos prescindir de las historias de menor valor para el cliente. 

Yo propondría que la PMO actuara como una especie de guía, asesor, coach, como-le-queramos-llamar hacia las figuras de jefe de proyecto de la organización -cuya preocupación es que la predicción se cumpla, es decir, que puede actuar perfectamente, con la adecuada formación, como dueño de producto Scrum- y el jefe de proyecto del proveedor -cuya preocupación es que la calidad de lo entregado y de la vida de su equipo sea estable, es decir, que puede actuar perfectamente, con la adecuada formación, como ScrumMaster. Sería una manera sutil de inducir a que los proveedores hagan Scrum y que el cliente se beneficiara de las ventajas sin apenas cambiar su organización.

No es tan fácil como puede parecer pero con la suficiente constancia y apoyo por parte de agentes clave en todas las organizaciones implicadas (cliente, PMO y proveedores) es más que posible. Todos deben adaptar un poco sus maneras de trabajar, pero creeme que no es tan difícil alinearlos.

¿Cómo lo ves, David? Me encantaría conocer tu opinión.

[david]

Hola Jos� Manuel,

S�, al final, la PMO es la responsable "oficial" del cumplimiento
en plazos y coste de los proyectos. Cosa que nunca ocurre excepto en los
casos en los que una estimaci�n y m�todo �gil se disfraza de estimaci�n
adivinada "PMP style". Ante este agumento, manifestado por mi (de manera
amigable) al m�ximo impulsor de esta PMO, su respuesta es que si se
falla en las estimaciones a priori es porque se especifica mal ( no cabe
tanto wishful thinking en un �nico ser humano, pero ah� le tienes).
En este caso no es cierto que la PMO est� fuera de la organizaci�n.
Es 100% interna. De hecho la tendencia es justo la contraria.Tiende a
una PMO interna con tooodo el resto subcontratado, delegando la
reponsabilidad del cumplimiento de esas estimaciones a los integradores.
Por cierto, que ante esta situaci�n uno se lo pasa "chupi lerendi" para
conseguir cerrar un contrato (ya estoy trabajando en tratar de aplicar
algo del genial cap�tulo de contratos del primer libro de Lean de los
Poppendieck).

Tus recomendaciones me parecen muy interesantes, y creo que es a lo
que vamos cayendo por puro devenir de la realidad. No creo que los
actuales PMs tengan la convicci�n necesaria para cambiar a ScrumMasters,
sino que m�s bien van actuando de Product Owners proxy. Son PO proxy
porque la mayor�a de usuarios finales "no tienen tiempo" para dedicarlo
al equipo. En los casos en los que los usuarios finales act�an de POs
reales, los PMs quedan como meros administrativos.

Procurar� poner el foco en asegurar backlogs priorizados y
estimados con grano adecuado. No es f�cil, pero coincido contigo que es
clave.

Os agradezco a ti y a Harald vuestras recomendaciones y os mantengo
informados sobre si hay avances y qu� buenas pr�cticas de combinaci�n de
ambos modelos nos van funcionando. Para m� son m�s los puntos de
conflicto que las sinergias, pero es el terreno de juego en el que toca
jugar, qu� le vamos a hacer....

Saludos
David

On 06/03/13 19:45, Jos� Manuel Beas wrote:
> Hola David,
>
> La PMO de la que hablas, entiendo que *necesita* controlar los

> proyectos porque est� en una organizaci�n que se gestiona de manera

> predictiva, es decir, tiene un presupuesto y unas fechas para
> conseguir unos objetivos (normalmente poco concretos) antes de empezar
> el proyecto e incluso antes de asignarlo a un equipo en particular. De

> hecho, el equipo apostar�a a que ni tan siquiera forma parte de
> vuestra organizaci�n. �Estoy en lo cierto?
>
> Si es as�, esta PMO tiene puede olvidarse de c�mo trabajan esos

> equipos y limitarse a exigir que se cumplan los plazos, sancionarles

> si hay incumplimientos flagrantes en alguno de los t�rminos del

> contrato, etc. Bueno, ya sabemos que la tasa de fracaso en estos casos

> es muy elevada, as� que yo sugerir�a optar por alguna alternativa.

>
> Yo creo que una alternativa que funciona bien (al menos yo la he visto
> funcionar muy de cerca, aun no siendo una PMO formal) consiste en

> mantener una relaci�n cliente-proveedor basada en la visibilidad de
> los avances en forma de demo peri�dica, posibilidad de incorporar el

> feedback a un backlog y predictibilidad mediante conocimiento de la

> velocidad del equipo sobre el consumo del backlog. La clave aqu� es

> que el backlog debe estar priorizado y estimado y con grano suficiente
> para que cuando veamos peligrar el proyecto (atendiendo a la velocidad
> del equipo) podamos prescindir de las historias de menor valor para el
> cliente.
>

> Yo propondr�a que la PMO actuara como una especie de gu�a, asesor,

> coach, como-le-queramos-llamar hacia las figuras de jefe de proyecto

> de la organizaci�n -cuya preocupaci�n es que la predicci�n se cumpla,
> es decir, que puede actuar perfectamente, con la adecuada formaci�n,
> como due�o de producto Scrum- y el jefe de proyecto del proveedor
> -cuya preocupaci�n es que la calidad de lo entregado y de la vida de

> su equipo sea estable, es decir, que puede actuar perfectamente, con

> la adecuada formaci�n, como ScrumMaster. Ser�a una manera sutil de

> inducir a que los proveedores hagan Scrum y que el cliente se

> beneficiara de las ventajas sin apenas cambiar su organizaci�n.
>
> No es tan f�cil como puede parecer pero con la suficiente constancia y

> apoyo por parte de agentes clave en todas las organizaciones

> implicadas (cliente, PMO y proveedores) es m�s que posible. Todos

> deben adaptar un poco sus maneras de trabajar, pero creeme que no es

> tan dif�cil alinearlos.
>
> �C�mo lo ves, David? Me encantar�a conocer tu opini�n.

>
> Un cordial saludo,
> Jose Manuel Beas
>
> http://about.me/jmbeas
>

> --
> Has recibido este mensaje porque est�s suscrito al grupo "agile-spain"
> de Grupos de Google.
> Para anular la suscripci�n a este grupo y dejar de recibir sus correos
> electr�nicos, env�a un correo electr�nico a
> agile-spain...@googlegroups.com.
> Para publicar una entrada en este grupo, env�a un correo electr�nico a
> agile...@googlegroups.com.
> Para obtener m�s opciones, visita
> https://groups.google.com/groups/opt_out.
>
>

[Gustavo Cebrian Garcia]

Hola Chicos,

Interesante hilo. Unas cosillas, a ver si pensamos lo mismo de la forma de actuar de esta PMO:

Para cada año, o seis meses o periodo, se debería actuar así? :

-Para cada unidad de negocio con su equipo Scrum ( Scrum Master y Product Owner ) preguntando al equipo, y granulando a alto grado, deberíamos sacar por nuestra experiencia ( siempre teniendo en cuenta que pueden salir muuuchos más requisitos ágiles (esto lo debe saber gerencia como indicáis) ) lo que van a costar los proyectos y las intenciones para esos 6 meses ( o año ).    Hablo de este periodo porque en mi opinión, tratando con una consultora, es mejor pedirle ( si se tiene un buen presupuesto y proyectos de entidad ) precio por 6 meses o 1 año...   Para estas estimaciones, se puede aplicar también PERT    ( estimación optimista, normal y pesimista - puede ayudar a tomar decisiones estratégicas ). Siempre aplicando la priorización etc, pero a veces hay que hacer esto muy flexible al resto de la empresa... ( y en esto he visto muchos fallos )

Ejemplo:  Equipo A      Proyecto A.1 ( 9 meses )  Proyecto A.2 (5 meses)

                  Equipo B       Proyecto B.1 ( 6 meses ) Proyecto B.2 ( 3 meses )

-Después de escuchar a todos los equipos se saca el presupuesto. ( para sacar el presupuesto, normalmente tiene que aprobarlo gente interna, normalmente se tiene gente interna en el equipo, gente "estable" y gente de consultoría )

-Así saco simplemenete a alto grado el presupuesto.

-Dependiendo del riesgo de los proyectos, unos equipos pueden ayudar a otros ( quitándose una persona y metiéndose en otro equipo. Cómo veis esta práctica?

( Yo la he visto a veces necesaria )

-En definitiva, es mezclar un poco la gestión predictiva ( lo que se pueda ) con una flexibilidad...

Cuál ha sido vuestra experiencia según lo que intento explicar?

Y ahora os cuento un caso super super super difícil con el que me he encontrado varias veces. Intentar estimar un Gran ERP?

Tuvimos un hilo por ahí que fue buenísimo....

--

Muchas gracias.

2013/3/6 david <davidpar...@gmail.com>

    Hola José Manuel,

    Sí, al final, la PMO es la responsable "oficial" del cumplimiento en plazos y coste de los proyectos. Cosa que nunca ocurre excepto en los casos en los que una estimación y método ágil se disfraza de estimación adivinada "PMP style". Ante este agumento, manifestado por mi (de manera amigable) al máximo impulsor de esta PMO, su respuesta es que si se falla en las estimaciones a priori es porque se especifica mal ( no cabe tanto wishful thinking en un único ser humano, pero ahí le tienes).
    En este caso no es cierto que la PMO esté fuera de la organización. Es 100% interna. De hecho la tendencia es justo la contraria.Tiende a una PMO interna con tooodo el resto subcontratado, delegando la reponsabilidad del cumplimiento de esas estimaciones a los integradores. Por cierto, que ante esta situación uno se lo pasa "chupi lerendi" para conseguir cerrar un contrato (ya estoy trabajando en tratar de aplicar algo del genial capítulo de contratos del primer libro de Lean de los Poppendieck).

    Tus recomendaciones me parecen muy interesantes, y creo que es a lo que vamos cayendo por puro devenir de la realidad. No creo que los actuales PMs tengan la convicción necesaria para cambiar a ScrumMasters, sino que más bien van actuando de Product Owners proxy. Son PO proxy porque la mayoría de usuarios finales "no tienen tiempo" para dedicarlo al equipo. En los casos en los que los usuarios finales actúan de POs reales, los PMs quedan como meros administrativos.

    Procuraré poner el foco en asegurar backlogs priorizados y estimados con grano adecuado. No es fácil, pero coincido contigo que es clave.

    Os agradezco a ti y a Harald vuestras recomendaciones y os mantengo informados sobre si hay avances y qué buenas prácticas de combinación de ambos modelos nos van funcionando. Para mí son más los puntos de conflicto que las sinergias, pero es el terreno de juego en el que toca jugar, qué le vamos a hacer....

    Saludos
    David

On 06/03/13 19:45, José Manuel Beas wrote:

Hola David,

La PMO de la que hablas, entiendo que *necesita* controlar los proyectos porque está en una organización que se gestiona de manera predictiva, es decir, tiene un presupuesto y unas fechas para conseguir unos objetivos (normalmente poco concretos) antes de empezar el proyecto e incluso antes de asignarlo a un equipo en particular. De hecho, el equipo apostaría a que ni tan siquiera forma parte de vuestra organización. ¿Estoy en lo cierto?

Si es así, esta PMO tiene puede olvidarse de cómo trabajan esos equipos y limitarse a exigir que se cumplan los plazos, sancionarles si hay incumplimientos flagrantes en alguno de los términos del contrato, etc. Bueno, ya sabemos que la tasa de fracaso en estos casos es muy elevada, así que yo sugeriría optar por alguna alternativa.

Yo creo que una alternativa que funciona bien (al menos yo la he visto funcionar muy de cerca, aun no siendo una PMO formal) consiste en mantener una relación cliente-proveedor basada en la visibilidad de los avances en forma de demo periódica, posibilidad de incorporar el feedback a un backlog y predictibilidad mediante conocimiento de la velocidad del equipo sobre el consumo del backlog. La clave aquí es que el backlog debe estar priorizado y estimado y con grano suficiente para que cuando veamos peligrar el proyecto (atendiendo a la velocidad del equipo) podamos prescindir de las historias de menor valor para el cliente.

Yo propondría que la PMO actuara como una especie de guía, asesor, coach, como-le-queramos-llamar hacia las figuras de jefe de proyecto de la organización -cuya preocupación es que la predicción se cumpla, es decir, que puede actuar perfectamente, con la adecuada formación, como dueño de producto Scrum- y el jefe de proyecto del proveedor -cuya preocupación es que la calidad de lo entregado y de la vida de su equipo sea estable, es decir, que puede actuar perfectamente, con la adecuada formación, como ScrumMaster. Sería una manera sutil de inducir a que los proveedores hagan Scrum y que el cliente se beneficiara de las ventajas sin apenas cambiar su organización.

No es tan fácil como puede parecer pero con la suficiente constancia y apoyo por parte de agentes clave en todas las organizaciones implicadas (cliente, PMO y proveedores) es más que posible. Todos deben adaptar un poco sus maneras de trabajar, pero creeme que no es tan difícil alinearlos.

¿Cómo lo ves, David? Me encantaría conocer tu opinión.

Un cordial saludo,
Jose Manuel Beas

http://about.me/jmbeas

--

Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a agile-spain+unsubscribe@googlegroups.com.

Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a agile-spain+unsubscribe@googlegroups.com.

Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.

--

Gustavo Cebrián

--

You create your own luck - Go and explore 

http://about.me/g.cebrian.garcia

[david]

Hola Gustavo, (y resto de lista de correo):
Perdona el tiempo que he tardado en contestar, pero ha sido una
semana de las interesantes...
Gracias por los comentarios, en mi opini�n contienen ideas bastante
interesantes. Es cierto que cada a�o hay que estimar unos presupuestos..
Es necesario. Recuerdo la comparaci�n que hace M. Cohn acerca de que no
dar estimaciones al cliente/usuario es como ir de compras sin poder
mirar los precios. Nos guste o no, estimar a largo es necesario. El
problema es el c�mo y la casi autom�tica conversi�n de estimaci�n en
compromiso.

Al respecto de las ideas que propones, la verdad es que ser�an muy
positivas, pero mi problema es parecido al de la pescadilla que se
muerde la cola o el del huevo o la gallina. Es decir, estimas
presupuestos, luego aprueban presupuestos, luego comienzas a
subcontratar para tener equipos que llegan para encontrarse con una
estimaci�n que no han hecho ellos ("pero �c�mo hemos podido llegar a
esto!"). Y este es el "meollo" de mi pregunta. Si la organizaci�n cree
que el objetivo es comprar proyectos a precio cerrado porque de ese modo
se elimina (se cree que se elimina) riesgo en el posible fracaso del
proyecto y adem�s aplica de ese modo la presi�n adecuada a la contrata
�C�mo narices encaja ah� la agilidad?. Quiero decir que mis preguntas y
respuestas en el hilo, no se tratan s�lo del desahogo a trav�s de una
lista de correo, sino de �hasta qu� punto debemos buscar puntos de
encuentro entre paradigmas?�hasta qu� punto estos acercamientos provocan
desaz�n en los equipos de trabajo porque lo que no puede ser no puede
ser?. Es algo como lo que hablamos en el Scrum Dojo de Febrero, �Scrum y
XP s�lo funcionan en Spotify (o similares)?

Saludos
David

PD: Como me salga alguien ahora con que en Spotify tienen una PMO,
no duermo en dos semanas.

On 07/03/13 20:17, Gustavo Cebrian Garcia wrote:
> Hola Chicos,
>
> Interesante hilo. Unas cosillas, a ver si pensamos lo mismo de la
> forma de actuar de esta PMO:
>

> Para cada a�o, o seis meses o periodo, se deber�a actuar as�? :

>
> -Para cada unidad de negocio con su equipo Scrum ( Scrum Master y
> Product Owner ) preguntando al equipo, y granulando a alto grado,

> deber�amos sacar por nuestra experiencia ( siempre teniendo en cuenta
> que pueden salir muuuchos m�s requisitos �giles (esto lo debe saber
> gerencia como indic�is) ) lo que van a costar los proyectos y las
> intenciones para esos 6 meses ( o a�o ). Hablo de este periodo
> porque en mi opini�n, tratando con una consultora, es mejor pedirle (

> si se tiene un buen presupuesto y proyectos de entidad ) precio por 6

> meses o 1 a�o... Para estas estimaciones, se puede aplicar tambi�n
> PERT ( estimaci�n optimista, normal y pesimista - puede ayudar a
> tomar decisiones estrat�gicas ). Siempre aplicando la priorizaci�n

> etc, pero a veces hay que hacer esto muy flexible al resto de la
> empresa... ( y en esto he visto muchos fallos )
>
> Ejemplo: Equipo A Proyecto A.1 ( 9 meses ) Proyecto A.2 (5 meses)
> Equipo B Proyecto B.1 ( 6 meses ) Proyecto B.2
> ( 3 meses )
>

> -Despu�s de escuchar a todos los equipos se saca el presupuesto. (

> para sacar el presupuesto, normalmente tiene que aprobarlo gente
> interna, normalmente se tiene gente interna en el equipo, gente

> "estable" y gente de consultor�a )
>
> -As� saco simplemenete a alto grado el presupuesto.

>
> -Dependiendo del riesgo de los proyectos, unos equipos pueden ayudar a

> otros ( quit�ndose una persona y meti�ndose en otro equipo. C�mo veis
> esta pr�ctica?

> ( Yo la he visto a veces necesaria )
>

> -En definitiva, es mezclar un poco la gesti�n predictiva ( lo que se

> pueda ) con una flexibilidad...
>

> Cu�l ha sido vuestra experiencia seg�n lo que intento explicar?
>
> Y ahora os cuento un caso super super super dif�cil con el que me he

> encontrado varias veces. Intentar estimar un Gran ERP?

> Tuvimos un hilo por ah� que fue buen�simo....
>
>
> --
>
> Muchas gracias.
>

[Gustavo Cebrian Garcia]

David.

La respuesta es q hay q buscar el equilibrio entre adaptabilidad y predictibiludad. Curso de de scrum master de mike cohn mìo en londres. Y siempre q estime el equipo y se tome en cuenta la velicidad. Y decir con todo el orgullo "si no creen en nosotros y en nuestra velocidad pues échennos " ( suena vacile pero es así ) y decir. "Han salido estos cambios de alcance y estos problemas... Q hacemos ahora le damos prioridad a esto.o a esto... ) pon ejemplos de tus proyectos y les abrirás los ojos.

David creo q t hemos respondido. No? Entiendo q sea muy dificil llevarlo a cabo pero es posible creo si se establece esa confianza.

Creo q con una buena presentación de los posibles casos de descontento o alegría podría ayudar. Si quieres mañana t pongo ejemplos o si quieres especificas tu alguno tuyo...

Gustavo.

El 11/03/2013 00:08, "david" <davidpar...@gmail.com> escribió:

    Hola Gustavo, (y resto de lista de correo):
    Perdona el tiempo que he tardado en contestar, pero ha sido una semana de las interesantes...

    Gracias por los comentarios, en mi opinión contienen ideas bastante interesantes. Es cierto que cada año hay que estimar unos presupuestos.. Es necesario. Recuerdo la comparación que hace M. Cohn acerca de que no dar estimaciones al cliente/usuario es como ir de compras sin poder mirar los precios. Nos guste o no, estimar a largo es necesario. El problema es el cómo y la casi automática conversión de estimación en compromiso.

    Al respecto de las ideas que propones, la verdad es que serían muy positivas, pero mi problema es parecido al de la pescadilla que se muerde la cola o el del huevo o la gallina. Es decir, estimas presupuestos, luego aprueban presupuestos, luego comienzas a subcontratar para tener equipos que llegan para encontrarse con una estimación que no han hecho ellos ("pero ¡cómo hemos podido llegar a esto!"). Y este es el "meollo" de mi pregunta. Si la organización cree que el objetivo es comprar proyectos a precio cerrado porque de ese modo se elimina (se cree que se elimina) riesgo en el posible fracaso del proyecto y además aplica de ese modo la presión adecuada a la contrata ¿Cómo narices encaja ahí la agilidad?. Quiero decir que mis preguntas y respuestas en el hilo, no se tratan sólo del desahogo a través de una lista de correo, sino de ¿hasta qué punto debemos buscar puntos de encuentro entre paradigmas?¿hasta qué punto estos acercamientos provocan desazón en los equipos de trabajo porque lo que no puede ser no puede ser?. Es algo como lo que hablamos en el Scrum Dojo de Febrero, ¿Scrum y XP sólo funcionan en Spotify (o similares)?

    Saludos
    David

    PD: Como me salga alguien ahora con que en Spotify tienen una PMO, no duermo en dos semanas.



On 07/03/13 20:17, Gustavo Cebrian Garcia wrote:

Hola Chicos,

Interesante hilo. Unas cosillas, a ver si pensamos lo mismo de la forma de actuar de esta PMO:

Para cada año, o seis meses o periodo, se debería actuar así? :

-Para cada unidad de negocio con su equipo Scrum ( Scrum Master y Product Owner ) preguntando al equipo, y granulando a alto grado, deberíamos sacar por nuestra experiencia ( siempre teniendo en cuenta que pueden salir muuuchos más requisitos ágiles (esto lo debe saber gerencia como indicáis) ) lo que van a costar los proyectos y las intenciones para esos 6 meses ( o año ).    Hablo de este periodo porque en mi opinión, tratando con una consultora, es mejor pedirle ( si se tiene un buen presupuesto y proyectos de entidad ) precio por 6 meses o 1 año...   Para estas estimaciones, se puede aplicar también PERT    ( estimación optimista, normal y pesimista - puede ayudar a tomar decisiones estratégicas ). Siempre aplicando la priorización etc, pero a veces hay que hacer esto muy flexible al resto de la empresa... ( y en esto he visto muchos fallos )

Ejemplo:  Equipo A      Proyecto A.1 ( 9 meses )  Proyecto A.2 (5 meses)
                  Equipo B       Proyecto B.1 ( 6 meses ) Proyecto B.2 ( 3 meses )

-Después de escuchar a todos los equipos se saca el presupuesto. ( para sacar el presupuesto, normalmente tiene que aprobarlo gente interna, normalmente se tiene gente interna en el equipo, gente "estable" y gente de consultoría )

-Así saco simplemenete a alto grado el presupuesto.

-Dependiendo del riesgo de los proyectos, unos equipos pueden ayudar a otros ( quitándose una persona y metiéndose en otro equipo. Cómo veis esta práctica?

( Yo la he visto a veces necesaria )

[Gustavo Cebrian Garcia]

Por cierto... Entre un montón de proyectos q teníamos yo he hecho un planteamiento ágil para todo un presupuesto de un año. T lo explico por teléfono si quieres...

[Daniel Ceillan]

El 3 de marzo de 2013 22:55, david <davidpar...@gmail.com> escribió:

    Hola a todos:

Hola!

 

    Este pasado Junio tuve la suerte de ser invitado por IBM-Rational al evento IBMInnovate. El evento estuvo muy bien, especialmente porque contaba con un path sobre Agile con ponencias de personalidades como Scott W. Ambler y Mary&Tom Poppendieck. El tema es que en la mayoría de las charlas y paneles a los que asisití (incluso en la que me tocó hablar a mí sobre mi caso de intento de transición agile) siempre salía la misma pregunta: ¿Y cómo es posible combinar una PMO con Scrum y/u otras técnicas ágiles de desarrollo?

Qué groso! felicitaciones!

Sobre esas cuestinoes siempre surgen, son parte del proceso de entendimiento de agile. 

Se suele afirmar que agile no es bueno para:

• fixed budget
• proyectos críticamente riesgosos
• tener buena documentación

He visto un proceso de negación mental similar en cuestiones de cambios organizacionales. Por ejemplo creer que cambiar el sistema de comunicación de la empresa implica cambiar su estructura. Falso. 

Agile no tiene la culpa de tus necesidades, es más bien tu responsabilidad diagramar el esquema que sirva para cumplir con las mismas. 

Agile/Scrum es un modelo no una solución. 

Actualmente trabajo en una PMO, capacitando a otros pms y gestionando proyectos. Y actualmente estamos haciendo fixed budget, scope and time con Scrum. Y aplicamos Scrum de Scrums para la PMO. 

 

    Tras las charlas éramos varios los que comentábamos nuestra situación en la que nos permiten aplicar ciertas técnicas ágiles, pero que nos las vemos y nos las deseamos para hacer encajar el PM clásico de la PMO impuesta. Algunos argumentaban que medio lo llevaban dejando a la PMO llevar la cuestión presupuestaria, mientras los equipos scrum se encargaban de la ejecución... a mi no me termina de convencer.

El PM clásico no es un PO ni un SM. Era una figura de poder y concentración de responsabilidades, con el anti-patrón de no concentrar libertades. Una mezcla explosiva (responsabilidad sin libertad). 

Presupuestos. Depende para qué. Si es para armar un contrato de fixed budget, time and scope, quizás si puede hacerlo una PMO, pero nunca sera útil sin la colaboración e interacción de los equipos. 

Quizás lo que tu estas buscando es el Enterprise Scrum. Lo han aplicado a equipos de marketing, comerciales, creativos... 

http://www.enterprisescrum.com/

Repito, es un modelo. 

 

    ¿Qué opináis? ¿radicalmente no encaja? ¿hay algún modo de hacer convivir los dos paradigmas?

Hacer convivir dos paradigmas, lo veo jodido. Puede ser en una etapa de transición y cambio. Pero llega un momento en que tenemos que velar y enterrar al viejo paradigma. Hoy no se puede ser taylorista. Eso está claro. 

Yo lo que veo aqui es que tu mezclas paradigma, con ideología, con estructura, con modelo y con método. 

Son todas cosas separadas. Incluso algunas independientes. 

Que tu empresa tenga una PMO es una cuestión de estructura. 

¿Se puede aplicar Scrum si necesito armar presupuestos cerrados? Si claro, totalmente. Eso es una cuestion estratégica. Si lo conviertes en un debate ideológico, lo más probable es que tengas lo que las ideologías nos han provisto toda la historia: una guerra. 

Scrum puede ser tu modelo de trabajo estratégico, y realmente no he visto 1 que funcione mejor. 

Y otra cosa diferente y separada es tu estrategia comercial.  Muchos clientes buscan, tristemente, el fixed budget, time and scope. Sin saber que eso no es bueno para ellos mismos. Pero quizás tu trabajo no sea "enseñarles" porque casi seguramente no estarán ahi para "aprender", sino para pedirte una solución. Después de todo, cual es el problema? mas pasta para ti. Por un lado debes darles un plan viable y convincente, pero deberás estar preparado para cuando descubran que necesitan cambiar el 65% de sus requerimientos. 

Finalmente para cerrar la idea. Lo que será tu mayor obstáculo, impedimento u oportunidad, será la dirección de la empresa. Que son los que custodian y alimentan el paradigma que guia la organización. Pero como está demostrado que del 100% de las empresas que están en problemas, en el 100% de los casos los dueños son parte del problema, deberás tener en cuenta que tu desafío no es compatibilizar Scrum con una PMO. 

Un saludo!

--
Daniel Ceillan

Blog: www.agile-patterns.com

[Gustavo Cebrian Garcia]

Hola

Yo sigo preocupado por el entendimiento de agile. Agile no es solo para mi cambiar de planes cada 2 semanas como.en.spotify. Agile también es un fixed price para empezar. Por ejemplo 3 meses para empezar... Y ser flexible en el camino. Muchísima gente todavía no entiende esto. Es decir... Es hacer Lo mejor para el proyecto revaluando la situaciòn cada sprint. No creéis?

Gustavo

--

Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.

Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a agile-spain...@googlegroups.com.

[José Manuel Beas]

Buff, demasiadas afirmaciones que me gustaría matizar. Igual cada una daría para un hilo. Mis disculpas si resulto algo confuso.

2013/3/11 Daniel Ceillan <codigo...@gmail.com>

Se suele afirmar que agile no es bueno para:

• fixed budget
• proyectos críticamente riesgosos
• tener buena documentación

He visto un proceso de negación mental similar en cuestiones de cambios organizacionales. Por ejemplo creer que cambiar el sistema de comunicación de la empresa implica cambiar su estructura. Falso. 

Lo siento, Daniel, pero esto tendrías que demostrarlo. Cambiamos los canales de comunicación (formales o informales) para habilitar la toma de decisiones, por tanto estamos cambiando las estructuras de poder (formales o informales) de la empresa. Lo cuál no tiene que ser necesariamente malo. El trabajo realmente difícil en este caso es hacer entender a todos los implicados por qué hacemos los cambios y que estos son en beneficio de todos.

 

Agile no tiene la culpa de tus necesidades, es más bien tu responsabilidad diagramar el esquema que sirva para cumplir con las mismas.  

Agile/Scrum es un modelo no una solución. 

Otro matiz pedante: Scrum es una solución. Es una receta muy concreta, basada en los principios ágiles y lean si quieres, pero una receta al fin y al cabo. Lo que ocurre es que confundimos aplicar la receta como el fin en sí mismo y no como un medio para alcanzar objetivos que ni tan siquiera verbalizamos. Mi trabajo normalmente consiste en ayudar a todos a expresar esos objetivos y a entender qué cambios introducir en su manera de trabajar para alcanzar esos objetivos (y luego otros, y luego otros...).

 

Actualmente trabajo en una PMO, capacitando a otros pms y gestionando proyectos. Y actualmente estamos haciendo fixed budget, scope and time con Scrum. Y aplicamos Scrum de Scrums para la PMO. 

Eso me gustaría verlo. En serio, no es cinismo. No es que lo vea imposible, para nada, pero sería estupendo que compartieras los obstáculos que se presentan a la hora de hacer casar el hecho de que el presupuesto (dinero, fechas y ámbitos) lo define quien luego no tiene responsabilidad sobre la ejecución. Las desviaciones, si el backlog se construye y prioriza, no debe ser un problema puesto que las funcionalidades de menor valor serán las que se queden por hacer y, por tanto, las que menos conflicto deberían presentar.

 

 

    Tras las charlas éramos varios los que comentábamos nuestra situación en la que nos permiten aplicar ciertas técnicas ágiles, pero que nos las vemos y nos las deseamos para hacer encajar el PM clásico de la PMO impuesta. Algunos argumentaban que medio lo llevaban dejando a la PMO llevar la cuestión presupuestaria, mientras los equipos scrum se encargaban de la ejecución... a mi no me termina de convencer.

El PM clásico no es un PO ni un SM. Era una figura de poder y concentración de responsabilidades, con el anti-patrón de no concentrar libertades. Una mezcla explosiva (responsabilidad sin libertad). 

Agree.

 

Presupuestos. Depende para qué. Si es para armar un contrato de fixed budget, time and scope, quizás si puede hacerlo una PMO, pero nunca sera útil sin la colaboración e interacción de los equipos. 

Quizás lo que tu estas buscando es el Enterprise Scrum. Lo han aplicado a equipos de marketing, comerciales, creativos... 

http://www.enterprisescrum.com/

Repito, es un modelo. 

 

IMHO parece aún un "work in progress más orientado a sacar otro sello de certificaciones, pero bueno, ya veremos. Desde luego que aplicar Scrum en grandes organizaciones es todo un reto. De hecho, aprovecho para recordar que en LinkedIn creé el grupo "Corporate Agile" a partir del evento que hicimos en Diciembre y al que ojalá podamos darle continuidad.

 

    ¿Qué opináis? ¿radicalmente no encaja? ¿hay algún modo de hacer convivir los dos paradigmas?

Hacer convivir dos paradigmas, lo veo jodido. Puede ser en una etapa de transición y cambio. Pero llega un momento en que tenemos que velar y enterrar al viejo paradigma. Hoy no se puede ser taylorista. Eso está claro. 

Depende el contexto y el objetivo. Si no te importa prescindir de la creatividad y participación en la mejor continua por parte de los "operarios", entonces un modelo taylorista es perfecto. Procedimientos claros que todos deben respetar y métricas que permitan mejorar los procedimientos con objetividad. Todo es mucho más predecible.

Si buscas algo diferente... ;-)

 

Yo lo que veo aqui es que tu mezclas paradigma, con ideología, con estructura, con modelo y con método. 

Son todas cosas separadas. Incluso algunas independientes. 

Que tu empresa tenga una PMO es una cuestión de estructura. 

Disagree. IMHO la estructura de una organización es reflejo de su ideología. (Al menos de la ideología del que crea la estructura formal)

 

¿Se puede aplicar Scrum si necesito armar presupuestos cerrados? Si claro, totalmente. Eso es una cuestion estratégica. Si lo conviertes en un debate ideológico, lo más probable es que tengas lo que las ideologías nos han provisto toda la historia: una guerra. 

Lo siento, Daniel. ¿Qué entiendes por estrategia? Para mí, las decisiones estratégicas de una empresa son el QUÉ quiere conseguir mientras que las decisiones operativas de una empresa son el CÓMO quiere conseguirlo. "Queremos hacer Scrum" sería una decisión operativa mientras que "Queremos que nuestros proyectos sean predecibles porque los equipos persiguen un ritmo sostenible en el trabajo" sería una decisión estratégica.

Scrum puede ser tu modelo de trabajo estratégico, y realmente no he visto 1 que funcione mejor. 

Perdón por el matiz pedante otra vez: "Depende del contexto y el objetivo". ;-)

 

Y otra cosa diferente y separada es tu estrategia comercial.  Muchos clientes buscan, tristemente, el fixed budget, time and scope. Sin saber que eso no es bueno para ellos mismos. Pero quizás tu trabajo no sea "enseñarles" porque casi seguramente no estarán ahi para "aprender", sino para pedirte una solución. Después de todo, cual es el problema? mas pasta para ti. Por un lado debes darles un plan viable y convincente, pero deberás estar preparado para cuando descubran que necesitan cambiar el 65% de sus requerimientos. 

Soflama ideológica a continuación. :-)

"En mi opinión, vivimos en un país donde tenemos la NECESIDAD de educar a los clientes y hacerles entender que pedir soluciones ya no es una opción. Ahora deben involucrarse en las soluciones. Un proveedor sólo podrá darles la solución que mejor se adapta a sus necesidades y presupuesto si el cliente se involucra en el aprendizaje mientras se construye. Todo lo demás es desperdicio. Y ya no podemos permitirnos el lujo de desperdiciar ni un céntimo."

Digo esto porque debemos hacer entender a los clientes que el único plan viable y convincente es aquel en el que participan los usuarios y los desarrolladores (incluidos la gente de siestemas, seguridad, legal, UX, financiero...). Seguir pretendiendo que esa forma de trabajar taylorista (unas pocas cabezas pensantes alejadas de la realidad del problema) no es tremendamente ineficiente en comparación con las formas de trabjar agilistas es un error estratégico morrocotudo y es nuestra responsabilidad (y una oportunidad de negocio) hacer ver que se pueden ahorrar mucho dinero cambiando su enfoque.

¿Es esto ideológico? Creo que no. Son datos objetivos.

Finalmente para cerrar la idea. Lo que será tu mayor obstáculo, impedimento u oportunidad, será la dirección de la empresa. Que son los que custodian y alimentan el paradigma que guia la organización. Pero como está demostrado que del 100% de las empresas que están en problemas, en el 100% de los casos los dueños son parte del problema, deberás tener en cuenta que tu desafío no es compatibilizar Scrum con una PMO. 

Y aquí quería llegar. Gracias Daniel. Estoy totalmente de acuerdo contigo. El mayor obstáculo (no diría el 100%) está en las Direcciones. Pero hagamos autocrítica. También está en nuestro lenguaje secreto, ajeno a sus realidades y miedos. Les llegamos con palabras extrañas y la necesidad de cambiar. Un Director de TI cualquiera, con cincuenta y tantos años, una o dos hipotecas, hijos en la universidad, un plan de pensiones que a estas alturas aún no cubriría sus necesidades vitales mínimas, EREs por doquier y la certeza absoluta de que si se queda en el paro no encontrará trabajo en lo que le queda hasta la jubilación (a eso de los 70 años) y le decimos que tiene que arriesgar su puesto de Director porque Scrum es lo más... y encima que si no sale bien es por culpa suya. O_O

¡Venga, va! Seguro que podemos hacerlo mejor. :-)

Un cordial saludo,

Jose Manuel Beas

http://jmbeas.es

[Daniel Ceillan]

El 11 de marzo de 2013 18:08, José Manuel Beas <jose....@gmail.com> escribió:

Buff, demasiadas afirmaciones que me gustaría matizar. Igual cada una daría para un hilo. Mis disculpas si resulto algo confuso.

Coincido, no es bueno afirmar, porque la gente lo lee como Verdades. No como Opiniones. 

 

2013/3/11 Daniel Ceillan <codigo...@gmail.com>

Se suele afirmar que agile no es bueno para:

• fixed budget
• proyectos críticamente riesgosos
• tener buena documentación

He visto un proceso de negación mental similar en cuestiones de cambios organizacionales. Por ejemplo creer que cambiar el sistema de comunicación de la empresa implica cambiar su estructura. Falso. 

Lo siento, Daniel, pero esto tendrías que demostrarlo.

No hace falta, porque no estoy defendiendo nada. 

 

Cambiamos los canales de comunicación (formales o informales) para habilitar la toma de decisiones, por tanto estamos cambiando las estructuras de poder

Yo dije estructuras, no estructuras de poder. A partir del momento que estamos hablando de cosas diferentes, la comparación de ideas ya no sirve. Pero igual te respondo. 

 

(formales o informales) de la empresa. Lo cuál no tiene que ser necesariamente malo. El trabajo realmente difícil en este caso es hacer entender a todos los implicados por qué hacemos los cambios y que estos son en beneficio de todos.

 

Agile no tiene la culpa de tus necesidades, es más bien tu responsabilidad diagramar el esquema que sirva para cumplir con las mismas.  

Agile/Scrum es un modelo no una solución. 

Otro matiz pedante:

Soy Argentino, tendrás que perdonarme pero estoy haciendo lo mejor que puedo por superarlo. 

 

Scrum es una solución.

De acuerdo, podemos considerarlo una solución. Pero mi análisis iba orientado a "scrum" en cuanto "modelo"

 

Es una receta muy concreta,

Podemos considerarlo una solución, pero ya considerarlo una receta, es un error muy común. Pegar postits, hacer standups, tener un backlog, no es ser ágil. 

 

basada en los principios ágiles y lean si quieres, pero una receta al fin y al cabo. Lo que ocurre es que confundimos aplicar la receta como el fin en sí mismo y no como un medio para alcanzar objetivos que ni tan siquiera verbalizamos. Mi trabajo normalmente consiste en ayudar a todos a expresar esos objetivos y a entender qué cambios introducir en su manera de trabajar para alcanzar esos objetivos (y luego otros, y luego otros...).

 

Actualmente trabajo en una PMO, capacitando a otros pms y gestionando proyectos. Y actualmente estamos haciendo fixed budget, scope and time con Scrum. Y aplicamos Scrum de Scrums para la PMO. 

Eso me gustaría verlo. En serio, no es cinismo. No es que lo vea imposible, para nada, pero sería estupendo que compartieras los obstáculos que se presentan a la hora de hacer casar el hecho de que el presupuesto (dinero, fechas y ámbitos) lo define quien luego no tiene responsabilidad sobre la ejecución.

Es que no es así, la última palabra la tiene el Equipo como unidad indivisible. Es simple, ellos estiman "desarrollo" y yo como pm evalúo y gestiono "riesgos". No es física nuclear. 

 

Las desviaciones, si el backlog se construye y prioriza, no debe ser un problema puesto que las funcionalidades de menor valor serán las que se queden por hacer y, por tanto, las que menos conflicto deberían presentar.

Se puede armar un plan de 3 meses, pero el plan original casi nunca se ejecuta, es sólo para satisfacer la necesidad de que "exista un plan". 

Lo que queda bien cerradito son los sprints, de hecho es parte de las reglas de scrum. 

 

 

 

    Tras las charlas éramos varios los que comentábamos nuestra situación en la que nos permiten aplicar ciertas técnicas ágiles, pero que nos las vemos y nos las deseamos para hacer encajar el PM clásico de la PMO impuesta. Algunos argumentaban que medio lo llevaban dejando a la PMO llevar la cuestión presupuestaria, mientras los equipos scrum se encargaban de la ejecución... a mi no me termina de convencer.

El PM clásico no es un PO ni un SM. Era una figura de poder y concentración de responsabilidades, con el anti-patrón de no concentrar libertades. Una mezcla explosiva (responsabilidad sin libertad). 

Agree.

 

Presupuestos. Depende para qué. Si es para armar un contrato de fixed budget, time and scope, quizás si puede hacerlo una PMO, pero nunca sera útil sin la colaboración e interacción de los equipos. 

Quizás lo que tu estas buscando es el Enterprise Scrum. Lo han aplicado a equipos de marketing, comerciales, creativos... 

http://www.enterprisescrum.com/

Repito, es un modelo. 

 

IMHO parece aún un "work in progress más orientado a sacar otro sello de certificaciones, pero bueno, ya veremos. Desde luego que aplicar Scrum en grandes organizaciones es todo un reto. De hecho, aprovecho para recordar que en LinkedIn creé el grupo "Corporate Agile" a partir del evento que hicimos en Diciembre y al que ojalá podamos darle continuidad.

Parece que sentiste un poco de competencia. No es mío, lo creo Mike Beedle, podes enviarle un email a el con tus apreciaciones. 

 

 

    ¿Qué opináis? ¿radicalmente no encaja? ¿hay algún modo de hacer convivir los dos paradigmas?

Hacer convivir dos paradigmas, lo veo jodido. Puede ser en una etapa de transición y cambio. Pero llega un momento en que tenemos que velar y enterrar al viejo paradigma. Hoy no se puede ser taylorista. Eso está claro. 

Depende el contexto y el objetivo.

El contexto estaba tácitamente definido: desarrollo de software. Claramente no hablamos de la industria textil. Aunque yo también probaría agile en esos contextos :)

 

Si no te importa prescindir de la creatividad y participación en la mejor continua por parte de los "operarios", entonces un modelo taylorista es perfecto. Procedimientos claros que todos deben respetar y métricas que permitan mejorar los procedimientos con objetividad. Todo es mucho más predecible.

Si buscas algo diferente... ;-)

 

Yo lo que veo aqui es que tu mezclas paradigma, con ideología, con estructura, con modelo y con método. 

Son todas cosas separadas. Incluso algunas independientes. 

Que tu empresa tenga una PMO es una cuestión de estructura. 

Disagree. IMHO la estructura de una organización es reflejo de su ideología. (Al menos de la ideología del que crea la estructura formal)

Las dos cosas son ciertas, lo que yo dije, y lo que tu dijiste. "tener o no tener una PMO" es una decisión de estructura. Pero esa decisión aislada no tiene porque ser un reflejo del la ideología. 

Las ventajas de tener una PMO son muchas. Entre ellas el knowledge sharing entre proyectos. El flujo de información. La toma de decisiones por consenso. Entre otras. 

O sea, una cosa es la decision de "hacer sprints"

Ahora de ahi a "ser ágil" hay un kilómetro. O sea de la decisión del "que hacemos" a la decisión u opción del "como lo hacemos"

 

 

¿Se puede aplicar Scrum si necesito armar presupuestos cerrados? Si claro, totalmente. Eso es una cuestion estratégica. Si lo conviertes en un debate ideológico, lo más probable es que tengas lo que las ideologías nos han provisto toda la historia: una guerra. 

Lo siento, Daniel.

¿Porque lo sientes? ¿No esta permitido disentir? ¿todos debemos pensar igual y creer lo mismo? ¿esa es la solución? ¿eso es lo ideal?

 

¿Qué entiendes por estrategia? Para mí, las decisiones estratégicas de una empresa son el QUÉ quiere conseguir

Eso son los objetivos. La estrategia es como vamos a lograrlos a largo plazo. Que esa es la diferencia entre estrategia y táctica. (por definición)

 

mientras que las decisiones operativas de una empresa son el CÓMO quiere conseguirlo.

Eso es una opción. 

 

"Queremos hacer Scrum" sería una decisión operativa mientras que "Queremos que nuestros proyectos sean predecibles porque los equipos persiguen un ritmo sostenible en el trabajo" sería una decisión estratégica.

A mi me parece que las cuestiones estratégicas (en cuanto sustantivo) son de más largo plazo. Yo utilicé la palabra "estratégico" como adjetivo. 

 

Scrum puede ser tu modelo de trabajo estratégico, y realmente no he visto 1 que funcione mejor. 

Perdón por el matiz pedante otra vez: "Depende del contexto y el objetivo". ;-)

Tomando el contexto definido arriba, sostengo lo que vi. Además mi afirmación es que "no he visto", no dije que "no exista". 

 

 

Y otra cosa diferente y separada es tu estrategia comercial.  Muchos clientes buscan, tristemente, el fixed budget, time and scope. Sin saber que eso no es bueno para ellos mismos. Pero quizás tu trabajo no sea "enseñarles" porque casi seguramente no estarán ahi para "aprender", sino para pedirte una solución. Después de todo, cual es el problema? mas pasta para ti. Por un lado debes darles un plan viable y convincente, pero deberás estar preparado para cuando descubran que necesitan cambiar el 65% de sus requerimientos. 

Soflama ideológica a continuación. :-)

"En mi opinión, vivimos en un país donde tenemos la NECESIDAD de educar a los clientes y hacerles entender que pedir soluciones ya no es una opción. Ahora deben involucrarse en las soluciones. Un proveedor sólo podrá darles la solución que mejor se adapta a sus necesidades y presupuesto si el cliente se involucra en el aprendizaje mientras se construye. Todo lo demás es desperdicio. Y ya no podemos permitirnos el lujo de desperdiciar ni un céntimo."

Vuelvo al punto retórico. que mi opinión sea una, y me parezca una postura comercial viable ¿indica que la tuya es mala? No. 

Pedir soluciones es un concepto básico del Mercado. Un cliente paga por soluciones, no por problemas. Mas allá de un paradigma productivo, esto es más una cuestión de aceptar la naturaleza del mercado. Para los que intentamos aceptarla, hay otros que con todo derecho pueden elegir cambiarla. 

Respeto y tolerancia. 

 

Digo esto porque debemos hacer entender

¿con un embudo? ¿acaso tu no estas forzando ahi la cosa? ¿que paradigma es ese?

 

a los clientes que el único plan viable y convincente es aquel en el que participan los usuarios y los desarrolladores (incluidos la gente de siestemas, seguridad, legal, UX, financiero...).

Totalmente de acuerdo. Con lo que esta entre las preguntas y este punto -> .

Lo anterior no. 

 

Ahora voy a seguir separando, sigues mezclando:

Seguir pretendiendo que esa forma de trabajar taylorista (unas pocas cabezas pensantes alejadas de la realidad del problema)

No es ni cerca de lo que yo planteé. 

 

no es tremendamente ineficiente en comparación con las formas de trabjar agilistas

Si lo es, totalmente ineficiente, pero no es lo que yo habia planteado. 

 

es un error estratégico morrocotudo y

Lo fuera si lo hubiera planteado. 

 

es nuestra responsabilidad

En realidad no. No soy el gestor del dinero ajeno, ni un apoderado. 

 

(y una oportunidad de negocio)

 

Mas lo vería como una oportunidad de aprendizaje, y desarrollo de la confianza en la relación con el cliente. Oportunidad de negocio suena a que yo gano. 

hacer ver

Eso es asumir que uno es el iluminado. 

 

que se pueden ahorrar mucho dinero cambiando su enfoque.

Agree. 

 

¿Es esto ideológico? Creo que no. Son datos objetivos.

El planteo puede ser objetivo, lo ideológico es la no-tolerancia. O intolerancia irracional. 

 

Finalmente para cerrar la idea. Lo que será tu mayor obstáculo, impedimento u oportunidad, será la dirección de la empresa. Que son los que custodian y alimentan el paradigma que guia la organización. Pero como está demostrado que del 100% de las empresas que están en problemas, en el 100% de los casos los dueños son parte del problema, deberás tener en cuenta que tu desafío no es compatibilizar Scrum con una PMO. 

Y aquí quería llegar.

Llegamos! :D

 

Gracias Daniel.

No se porque... pero de nada. 

 

Estoy totalmente de acuerdo contigo.

Ahi me perdi... no era que estabas totalmente en contra mio? estoy mareado. Pero bueno, enhorabuena! 

 

El mayor obstáculo (no diría el 100%) está en las Direcciones.

Adhiero si tomamos a obstáculo como sinónimo (en este contexto) de oportunidad. 

 

Pero hagamos autocrítica. También está en nuestro lenguaje secreto, ajeno a sus realidades y miedos.

Puede ser. De mi parte tengo la profunda experiencia de que la comprensión de las cosas no se puede inyectar. Solo es "descubrible". 

 

Les llegamos con palabras extrañas y la necesidad de cambiar. Un Director de TI cualquiera, con cincuenta y tantos años, una o dos hipotecas, hijos en la universidad, un plan de pensiones que a estas alturas aún no cubriría sus necesidades vitales mínimas,

Cuanto lío dios mio!

 

EREs por doquier y la certeza absoluta de que si se queda en el paro no encontrará trabajo en lo que le queda hasta la jubilación (a eso de los 70 años)

Que pesimista, una persona con talento nunca estará desocupada. 

 

y le decimos que tiene que arriesgar su puesto de Director porque Scrum es lo más...

¿yo planteé eso? Dios mío! No! 

De nuevo, la comprensión no se puede inyectar. Es el resultado de un proceso de descubrimiento empirico. Empirismo. Empirismo. 

Esta bien querer cambiar a la gente, pero hay que ser responsable con las afirmaciones. Y confiar en que lo van a hacer bien, sin tomar nuestras creencias como una religión. 

Guiarlos en la búsqueda de la Verdad, siendo la Verdad lo que resuelve los problemas. 

  

y encima que si no sale bien es por culpa suya. O_O

Cuando un proyecto fracasa es culpa de todos. Eso incluye a todos los involucrados. (creeme, este planteo es útil para evitar que se busquen culpables, y luego nadie asuma sus responsabilidades)

 

¡Venga, va! Seguro que podemos hacerlo mejor. :-)

Y aqui estaría bueno saber a que te refieres particularmente. 

Tiro aqui una frase que escuche de un ponente sobre gestión del cambio en un seminario que asistí hace unos días. 

Aviso que va a doler y molestar. Pero va para el backlog de la auto-critica. 

"La gente de Agile no sabe nada de Gestión del Cambio"

Y la verdad que tiene razón, se mucho de scrum, pero hay mucho que tengo que aprender. 

Sé como aplicarlo a un equipo, pero para aplicarlo a una organización... es otra historia.   

Un saludo. (muy cordial y afectuoso)

[Harringer]

Gustavo, arreglalo ya. Me estoy perdiendo :-)

Un saludo,

Harald

--

[jorge]

A mi me parece que esto que contáis - PMO -  está hecho para diluir responsabilidad y poner un parche a la falta de comunicación entre los equipos de la empresa, aka knowledge sharing.

También me parece que eso de que satisfacer necesidades (tener un plan), gestionan riesgos y nosequé más es, claramente, responsabilidad del equipo.

Te lo cambio por un coach team... by far.

2013/3/11 Harringer <harr...@gmail.com>

[Juan Quijano]

Solo varios matices:

* Scrum no está basado en los principios Agiles porque se creo casi unos años antes que el manifiesto. Es justo al reves, el buen funcionamiento de Scrum llevo a sus autores a colaborar y firmar el manifiesto Agile.

* Por mucho que insistamos los técnicos,  Agile NO es pensado ni diseñado ni con el objetivo de ir más allá de la producción de aplicaciones informáticas. Todo el mogollón actual de la "filosofía Agile/bala de plata/valeparatodo" es empujado por aquellos que de algo tienen que vivir; y no hay mejor forma de hacerlo que "educar" a todo el mundo. Al cliente, al desarrollador, a la empresa y al mundo en general (pero esto da para una acalorado debate sobre gurus y vende humos Agiles).

* Agile no indica que no se puede hacer predicciones, en ningún sitio. Lo que dice es que es seas consciente que lo único que marca el estado del proyecto es el software que funciona y que debemos estar abiertos al cambio en cualquier momento. Al igual que tampoco dice que la documentación sea EVIL, como tantos y tantos se confunden, si no que es preferible la comunicación cara a cara. Es más Scrum ES predictivo. Lo primero que se hace es un Product Backlog estimado y priorizado: eso es predecir el futuro. Lo que lo hace Agile es la gestión permanente del cambio.

Por ello es complicado hacer un PMO con delivery Agile, pero no es imposible. Solo hay que usar el sentido común e intentar que valga para lo que necesita la empresa y los clientes, en todos sus ramificaciones y puestos, y no pensar que lo mio es lo bueno, aunque se llame Agile, y que debo "enseñar" a la gente a ser "buena" XD XD (me da la risa).

En el caso específico que ha iniciado este debate, yo creo (y es solo una opinión) que, tal y como dices, la dura realidad les llevará a entender que lo ideal es que los PM aborden el papel de PO Proxy y que permitan a los que hacen las cosas el estimarlas y decidir como se hacen. Si acaso, si estás implicado en ser el agente del cambio, debes obtener todas las metricas posibles sobre lo bueno de uno sobre el otro tanto para tener datos empíricos de que tienes razón y como para que tus argumentos no se basen en sensaciones y creencias solamente, que para eso tenemos de sobra en la comunidad :P.

[david]

    Vaya, me da miedo responder... X-)
   
    Antes de nada muchas gracias a todos por la inmensa cantidad de argumentos sensatos que me habéis regalado. Me sirven para reflexionar y no desfallecer en el intento.

    En general, y tras leeros, mi conclusión es que me habéis ayudado a reafirmarme en que no encaja, pero por "inercia cultural" no me queda otra.
   
    En cuanto a mi caso concreto. Os pongo en contexto. No trabajo en un cliente, sino en el el propio depto de desarrollo de una empresa grande. No tengo cliente, tengo usuarios. Durante muchos años se hizo PM clásico waterfall digno de museo. Hace unos tres años hubo cambios en la organización, algunos vimos la oportunidad de decir a gente con capacidad de decisión en la organización que o cambiabamos la manera de trabajar o nos continuábamos muriendo. Y nos dejaron intentar cambiar, pero hay "inercia cultural"... Al cabo de un tiempo, los resultados tras el intento fueron algo mejores, pero no deslumbrantes (como era de esperar) y apareció la PMO del modo que os describí en mi anterior correo. Os puedo contar más detalles, pero hacen falta cervezas :-)

    Tal y como lo estoy viviendo yo (como lo estamos viviendo):
    * Los PMs de la antigua estructura han pasado en su mayoría a ser PO Proxy, excepto dos casos que pasaron a ser SM (curiosamente los más jóvenes y más cercanos al desarrollo)
    * Como conté en el dojo, los que queremos aplicar Scrum nos chocamos de bruces con los contratos. Los proveedores no quieren Scrum en un contrato en el que deben especificar con detalle qué funcionalidades se comprompeten a entregar, en qué tiempo exacto y a qué precio. Acabamos haciendo T&M encubierto, que como todo lo que tiene la palabra encubierto, al final no sale bien.
    * Las estimaciones son 100% compromisos ajustados al céntimo y al segundo
    * Si algún proveedor nos entra por precio cerrado (a pesar de mis advertencias :-) ), el esfuezo que gastamos en discutir cada Change Request es brutal, por no hablar del impacto que supone en el ritmo de trabajo del equipo
    * En un caso especial de un proyecto especialemte grande, se ha intentado un contrato por etapas, pero no os podéis imaginar las interminables sesiones de negociaciones para cerrar los contratos de cada etapa, las revisiones y re-revisiones de contratos.
   
    Yendo más al asunto de las PMOs, sigo pensando que el modo predictivo de trabajo, reflejado en frases del tipo: "Dime una fecha en la que tendrás esto terminado para que la ponga en mi planificación" provoca un ambiente de control local de riesgos que tiene como consecuencia un terreno estéril para el trabajo en equipo. Los Poppendieck lo dejan claro cuando escriben sobre el fracaso de los MRPs en las fábricas en contraposición a los sistemas pull (he de confesar que todos los días mientras me pongo el abrigo para irme a casa, miro su libro en mi mesa de la oficina y me digo (algo triste) "¡qué razón tenéis jodíos!").

    Claro que en Agile se hacen predicciones, pero no pueden ser compromisos sino probabilidades de cumplimiento, y (cono de incertidumbre) cuanto más lejos menos probabilidad. Debemos hacer release planning de varias iteraciones, pero no puedo convertirlo en un compromiso por la incertidumbre que existe. Y dice José Manuel: "¡Eduquemos a los clientes!", ya pero es que el balón es suyo y juegan a lo que quieren :-( Luego, al final, el scrum faster, better, cooler va a ser que sólo funciona en spotify (bueno, y en alguna que otra startup de por aquí...)

    No se si el hilo ha creado más polémica de la necesaria, pero si os sirve de algo, y contestando a la pregunta de Gustavo sobre si me habéis contestado, os diré que lo habéis hecho con creces. Muchas gracias a todos y os seguiré trayendo anécdotas de mi caso si no os parece mal (y siempre que las pueda contar, claro)
   
      Saludos
      David

[Harald Messemer]

Hola David,

De tu respuesta deduzco dos cosas que probablemente no se han discutido lo necesariamente:

1) Scrum versus contratos a precio cerrado

En mi opinión (y soy proveedor), se pueden hacer contratos a precio cerrado. Yo como proveedor me comprometo a un alcance a un precio cerrado. Si este alcance cambia hay dos opciones: a) se hace amplicación del contrato si los cambios requiren más tiempo b) se eliminan del alcance aspectos del mismo valor que los cambios. Como se observa, esto no tiene nada que ver con Scrum, sino con la gestión de un contrato.

2) Scrum con proveedores externos

De nuevo, en mi opinión, no aporta valor al cliente de imponer al proveedor de un proyecto "a precio cerrado" un modelo de trabajo determinado. El proveedor decide como quiere trabajar, siempre y cuando entrega en las fecha estipuladas y con la calidad acordada. Si se producen cambios en el alcance aplica el punto anterior.

3) Cliente hace Scrum

Si yo como cliente hago Scrum y, por el motivo que sea, necesito ampliar el equipo por recursos externos, recomiendo contratar horas o bolsas de horas a un proveedor externo. En este caso yo decido como quiero que trabajen estas personas.

En resumen, lo que en mi opinión no funciona bien es mezclar que un cliente quiere aplicar Scrum en sus proyectos y reforzar su equipo interno con capacidad externa en modalidad alcance / precio cerrado. En este caso la mejor PMO del mundo poco podrá hacer por una falta de "Segregacion de Responsabilidades".

Saludos,
Harald

2013/3/13 david <davidpar...@gmail.com>

--

Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a agile-spain...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.

[Alfredo Casado]

Menos mal que trabajo en una empresa de producto chiquitita, no somos spotify claro, hacemos scrum/xp y nos va aceptablemente.

Perdonarme, pero dolor de cabeza me da leer todo esto, que complicaciones!, el KISS no es sólo para la parte técnica. Tanto PMO, PMP, changes request, proveedores a precio cerrado que se pondrán sus buenos colchones (normal por otra parte, es lo que tiene la desconfianza). Visto desde fuera me parece increíble la cantidad de gasto, de tiempo y dinero tirado a la basura con este tipo de estructuras.

Coge un proveedor de confianza (no es tan difícil encontrar a los buenos, sobre todo para quien se mueva por esta lista y este mundillo), que hagan iteraciones de pocas semanas, un contrato en el que cualquiera pueda rescindir al final de la iteración si la cosa no va bien y que trabajén como quieran (scrum o lo que ellos, que son los expertos que tienen tu confianza, consideren mejor para el proyecto). Si el apoyo de la dirección es real y no sólo de boquilla porque mola ser "agil" y esta de moda, no debería haber problema para intentar un enfoque como este, radicalmente distinto, en un proyecto pequeñito para que nadie se asuste (aunque asustados deberían estar del gasto que tienen ahora).

No se, reconozco que soy un ignorante en estos mundos "empresariales" complejos, se hacer software eso si, y de verdad, es difícil, pero no tanto.

[david]

    Gracias por la respuesta Harald.
    Sobre la primera cuestión, como he comentado, se gasta mucho tiempo en la negociación de qué es y qué no es un Change Request.
    Sobre la segunda, mi intención inicial cuando me cayó la responsabilidad que tengo ahora, era disponer de la mayoría del desarrollo (sino todo) en equipos internos haciendo scrum. Rapidamente me quitaron la idea de la cabeza "porque es mejor negocio subcontratar a precio cerrado". En estos primeros casos no exigimos que aplicasen ningún método de trabajo específico. Dió la casualidad que el proveedor en cuestión nos dijo que hacía Scrum (al final era scrum-but... como nos pasa a muchos). El asunto es que estas experiencias fueron desastrosas rozando lo catastŕofico, por lo que indiqué que admitía el modelo de subcontratación, pero con entregas parciales frecuentes de working software y una persona de mi equipo interno trabajando con el proveedor en cuestión.
    Además, para poder entregar software funcionando, los proveedores dependen de muchos factores que se lo ponen bastante complicado (como he dicho, estoy en una empresa de cierto tamaño) y que ellos no tienen capacidad de controlar. Luego un precio cerrado les hace sangrar como no te imaginas si la cosa se termina torciendo.
    Sobre la tercera, para los pocos equipos internos que me quedan, trabajamos así como indicas (muy parecido), pero creo que este modelo se me extingue en breve.

    Saludos.
    David.

[Gustavo Cebrian Garcia]

Alfredo

Tengo q decir q si son complejos estos mundos empresariales... De verdad...

Gustavo.

[david]

    Pues sí lo son, sí lo son... (y entendedme que no cuente los detalles porque no es el objetivo de mi pregunta inicial como comentaba antes, y además me compromete, porque sí que son complicados, sí lo son).
   
    Pero siéndolo... me parece genial leer correos como el de Alfredo, porque así debería ser, y no tan complicado...
    Es posible que si no fuese tan complicado, ninguno de los que estamos en este tipo de organizaciones y fuimos al innovate el pasado verano tuviesemos PMOs... puede ser...

    Saludos
    David

[Harald Messemer]

Hola Alfredo,

Supongo que vosotros también hacéis algún tipo de contrato y me puedo imaginar que alguna vez os habréis comprometido a un alcance acotado o cerrado a un precio cerrado. Habrían sido lo más KISS posible, pero contratos.

Por otro lado, en tu mundo ideal, realmente no hubo nunca ningún problema o algo se ha torcido y habéis dedicado tiempo en como mejorar de contrato a contrato como hacerlo mejor para evitar estos malentendidos.

De esto se trata entender que ha pasado y mejorar la próxima vez. Lo que pasa es que hay organizaciones o empresas con unas estructuras que les han ido bien durante muchos años (o por lo menos eso es lo que crean). En estas organizaciones hay gente como los que escriban aqui que no les gustan estas estructuras y están pensando como romperlas.

Una de estas estructuras son los contratos de 1.000 páginas que no sirven para nada por que los buenos proyectos no se hacen en el juzgado, sino en el teclado o el whiteboard o hablando con los usuarios y el cliente. Una manera de romper estos contratos de ayer consiste en introducir de buen criterio cambios que permiten trabajar de forma clara sin que nadie se siente timado por la otra parte.

Saludos,
Harald

PD: Por cierto, mi mundo tampoco es tan complicado, ni me preocupa demasiado la complejidad de estimar el esfuerzo para implementar SAP.

2013/3/13 Alfredo Casado <casado....@gmail.com>

[Alfredo Casado]

Harald, 

hacemos producto, no somos proveedores ni somos clientes. MI único contrato ahora mismo es el que tengo con mi empresa, que mira se podría considerar un T&M, me pagan una vez al mes y si alguna de las partes no están contenta se rompe el contrato (esto con las ultimas reformas laborales es mucho más facil jeje).

[Gustavo Cebrian Garcia]

Hola,

En empresas grandes siempre t van a pedir el contrato cerrado.
( o muchas veces ) Creo q las claves son las siguientes para tener un proyecto semi agil con exito o con el menor desastre.

-Si no somos buenos estimando no nos contrates para la proxima pero el proveedor y el discutir q se tarde muy poco ( por el cambio de alcance ). Da igual muchas veces lo q se discuta... Igualmente no se va a llegar a tiempo.

- Se utiliza scrum para medir la evolución del proyecto. Si creemos q llegamos o no se menciona en cada planificación.
-detectar la desviación del.proyecto cuanto antes para decidir.
--También se utiliza PERT en las estimaciones.
-meter una persona interna está bien.  en caso de super desastre q aprenda todo el código ( debería según extreme programming )
- La estimación de cada proyecto q no vaya a más de 3 o 4 meses... Porque si no desaaaaastre seguro.
Esto lo dice mucho Cohn.

-comprometer al cliente con BDD es muy importante ( o el mítico UAT ) esto se debe hacer por sprint. Si no lo hacen bien es la responsabilidad del cliente...

Y a partir de aquí... Estimar bien bien... Comunicación planning poker... Puntos...y como digo la pmo tiene q preguntar " q habéis hecho este sprint planning para saber q vais a llegar a tiempo.

Por cierto... Para mi la pmo o super scrum master o como lo queráis llamar si que puede hacer entrevistas y mejorar el equipo aunque sea con mucha abstracciòn es decir... Sin saber de requisitos... ( esto es complicado... Tengo q reconocer )

Gustavo.

[Harald Messemer]

Entonces nada, pero si tuvieras contrato :-)

[chochis]

Osea que justificamos ser todo lo agile, lean y tal que sea posible en el proceso productivo, pero "en la parte empresarial" seguiremos siendo complejos y gastando inmensos recursos "¿Por qué es así?"

Pues yo discrepo, que queréis que os diga...

Da igual lo ágil que sea un equipo si le sometes a 'es que no lo tiendes, es muy comlpicado' injustificables, acabará desmoralizado y dará igual que sea permeable o impermeable al cambio. Y ese es el principal problema que le veo al PMO, que se cree que se trata con equipos de robots que hacen coches automáticamente, pero no, son personas y las personas necesitamos motivos y justificaciones válidas y poca incertidumbre.

En fin...

M2C

Saludos
José Luis

2013/3/13 Harald Messemer <harr...@gmail.com>

[jorge]

Siguiendo con el argumento, he visto PMOs en empresas de 150-200 empleados con equipos técnicos de unos+-30 (varios equipos) y que, claramente, tienen varios clientes internos.

No hace falta inventar nada nuevo ni descubrirlo para decir que se puede trabajar mejor y que eso implica *tener en cuenta el contexto*, que no es un bing-bang sino un viaje y que se puede hacer usando diversos enfoques.

En el contexto que proponía en la primera frase, estoy seguro de que alguien pensó que poner un PMO era una buena forma de trabajar mejor, de continuar el viaje según su (o sus) punto de vista :) aunque ya digo que, en mi opinión, es el típico mecanismo parche de falta de skills, falta de responsabilidad y confianza en los equipos y gestión del producto y de las expectativas regulero.

Yo creo que, en general, no hace falta llevar la bandera de nada (agile/lean) para dar más pasos en el viaje de trabajar mejor más que eso, solucionar los problemas de raíz y no los síntomas (que no hay comunicación, pues ponemos a alguien más que se encargue de que dos hablen en lugar de solucionar el conflicto o lo que sea)

2013/3/13 chochis <cho...@gmail.com>

[Harald Messemer]

Diria que las PMO no son el mal per se, ni un programador Java es mejor que uno Cobol. No hay definicion oficial de PMO y las PMO las llevan personas. 

En mi caso utilizamos las PMO p.e. para ayudar a que los equipos de trabajo asumen compromisos claros en plan DoD, que hagan entregas tempranas, que el software que entreguen funcione y cosas de este estilo. El equipo puede trabajar como quiera, mientras que atiende la interfaz con el cliente / usuario,

No creo que eso sea malo. No olvidad que muchos equipos, incluyendo gestores y desarrolladores, aun cometen muchos fallos basicos que algunos de la lista ya han superado hace anos.

Saludos,

Harald

[GermanDZ]

Creo que estáis confundiendo cosas… Como dice David, en lugares como El Corte Inglés sin dudas es complicada la organización que tienen montada, pero sin dudas su negocio es otro poco que ver con el software por eso es que probablemente sea más importante mantener una PMO que tenga controladas las partidas presupuestarias. También es normal que cuando la construcción de un software que fue pensado al detalle durante meses se desvía mucho luego se diga: "quiero todo el UML perfecto… compremos la suite de Rational y así los programadores ya no se podrán desviar". 

Nuevamente el problema de David en El Corte Inglés tiene poco que ver con construir software agile o si con Team Concert todo irá mejor. Es más de la organización ha decidido gastar 25 millones en IT este año, tenemos que mejorar cosas con un ROI mayor al 12% sino no compensa… y entonces las métricas pasan a ser otras.

Con esto no critico la forma en que trabajan que es muy válida según muchas escuelas de la dirección estratégica, pero de verdad que equipo/software/agile son otros temas e importan poco en ese tipo de organización. No hay que pretender cambiar la esencia de algunos negocios… sino dejarán de ser lo que son.

[Gustavo Cebrian Garcia]

German.

Dices q no hay q intentar cambiar las actuales PMOs. No entiendo exactamente los puntos q no quieres o quieres cambiar.

Gustavo.

Para ver este debate en la Web, visita https://groups.google.com/d/msg/agile-spain/-/SU3z_htn-bEJ.

[Daniel Ceillan]

Bueno como el que habla mucho dice poco. Vamos a ir resumiendo ideas. 

• Las Herramientas no tienen moral. Una batuta la puedes usar para dirigir una orquesta o para golpear en la espalda a los esclavos. Y la culpa no es de la herramienta. 

• En mi caso comparto la experiencia de haber trabajo en una PMO, y funcionó muy bien. De hecho la principal ventaja fue el knowledge sharing que se produjo. Y de ninguna manera estamos hablando de separar el actuar del pensar. La PMO es la batuta, como la usas es tu culpa. 

• Cada contexto tiene diferentes necesidades. Dependiendo del tamaño de la organización, y dependiendo de la naturaleza y necesidades del cliente. Toda Generalización es Mala, incluso ésta. 

• Tenemos que ser objetivos, sobre todo para no hacer quedar mal al movimiento agile. No tenemos que hacerlo parecer una secta. Una cosa es explicar que 
• "dados dos conjuntos de dos nueces cada uno, al unirlo podemos demostrar que al hacer el recuento, corroboramos que 2 + 2 es 4"
• y otra es salir con cara de guerra gritando "2+2 ES 4!!!! O MUERTE!! SI NO ENTIENDEN ESO, ESTAN EN MI CONTRA"

• Los mundos empresariales son complejos. Porque el mercado es un sistema complejo. El Humano es un sistema complejo. Y ninguna metodología de gestión formal es capaz de enfrentar un problema complejo. 

Creo que eso es todo por ahora. Muy bueno tu aporte Juan Quijano, creo que es una de las pocas veces que coincido plenamente contigo. 

Saludetes.