Mucha jerga molona corporativa, pero esto huele a leguas que no es nada más que una forma para descargar la responsabilidad en los curritos y no tener que pagar mandos intermedios...
Hay muchos tipos de trabajo. Y cada uno es responsable de sus acciones en este tipo de empresas (banco) que está todo registrado y encorsetado.
El mero hecho de tener un jefe no significa que sea responsable de la acción agrupada de todos los que están por debajo de él. Ni el hecho de no tenerlo tiene porqué hacer que la responsabilidad se diluya.
Cuando quitan los mandos intermedios es porque el control ya lo da un ente que se llama: sistema de gestión. Que es el que se adapta a todos los cambios legales de la empresa y es reporgramado continuamente para que los empleados actúen según los protocolos marcados por la directiva.
Creo que ninguno de los comentarios anteriores es de alguien que trabaje en el dector tecnológico... esto no es palabrería, es una metodología, se usa mucho y funciona.
#6Cuando quitan los mandos intermedios es porque el control ya lo da un ente que se llama: sistema de gestión
Esto suena a que cuando hay algún problema la culpa es del sistema y/o del departamento de TI, nadie toma responsabilidad de los fallos humanos, que haberlos, haylos...
No hablamos de diseñar y construir un puente
No, hablamos de gestionar el dinero y activos de los ciudadanos... cosa que me parece tan seria como diseñar y construir cualquier tipo de obra de ingeniería.
#7 Bueno, si y no. Por cada sitio que la aplica correctamente hay 100 que dicen ser agile pero es mentira cochina. Yo curro en uno de esos 100. Dicen que somos ágiles porque tenemos un scrum meeting por la mñn
#7 Agile es, efectivamente, una metodología, un nombre propio, pero la gente que no tiene conocimientos en ese campo (como el periodista del artículo) es normal que lo confunda con ser ágil como adjetivo (algo así como te digan que en tal empresa van a cambiar los coches ejecutivos por ford mustang y haya quien diga que los caballos consumen mucho heno y contaminan con sus heces). Lo de "sin jefes", obviamente viene de haber echado un ojo a la wiki y oír campanas sin saber muy bien por donde suenan, en Agile también hay jefes, directivos, juniors, gente que cobra más y gente que cobra menos...
Por otro lado, Agile es una metodología que funciona muy bien para algunos entornos, como desarrollar para spotify, pero que se adapta con dificultad a otros, donde la transversalidad, por motivos de seguridad, validaciones y demás, no es factible de manera realista.
No es el mejor sistema para construir software médico, militar y vaya, hasta ahora el bancario se ponía también como ejemplo de donde no parece apropiado aplicar metodologías Agile.
Quizás ING demuestre que sí es posible, y eficiente, muchas veces el progreso se da cuando alguien demuestra que lo que los demás decían que no se podía, sí se puede... Pero tampoco hay que olvidar que muchas, muchas otras veces, la realidad es que no se podía así, y el intento se hostia.
La otra posibilidad es que sea solo una pose, igual que cuando su CEO dijo lo de "no somos una empresa de banca, somos una empresa de tecnología que casualmente tiene una licencia de banca", que lo de Agile sea solo una capita por encima, que se limite al frontend más pinturero de su web, pero que, como todo banco, siga teniendo más yayos kobold-eros que devops de golang...
ING está cayendo en imagen. Y no me extraña sólo hay que ver lo que está pasando con sus SIN comisiones. Antes operar una acción era un 0.25% sin comisiones, luego le pusieron un coste mínimo de 8 euros y ahora ya van por un mínimo de 20€ de comisión, sin poner esa palabra por ningún lado por supuesto
#2 ¿Quien protesta de que haya mandos intermedios?, si son precisamente esos los que más responsabilidad, presión y estrés tienen para que la empresa funcione.
#7 Me imagino que, como con cualquier idea o método, se podrán hacer implantaciones desastrosas pero me da la impresión de que hay un montón de buenas ideas en ese método de organización y que, a poco que se le ponga un poco de inteligencia a la implantación, puede terminar mejorando mucho el funcionamiento de muchas organizaciones, sobre todo medianas y grandes.
y con la riqueza del idioma que usamos, tenemos que usar vocablos en otro idioma para expresar lo mismo, que suene más interesante o importante o rimbombante o lo que sea... si es que somos tontos.
#11 bueno, cuando hay un jefe intermedio lo que suele ocurrir es que es un tío al que le pagan para señalar quien es el culpable de entre los "curritos" de su departamento... ahora ocurrirá lo mismo, pero sin pagar a alguien para que señale.
#14hasta ahora el bancario se ponía también como ejemplo de donde no parece apropiado aplicar metodologías Agile.
Trabajo desarrollando para banca con metodologías Agile y aquí funciona bien. Pero es verdad que una metodología agile funciona si se aplica estrictamente en todos los sentido y se entiende bien la horizontalidad.
Me explico:
Los Product Owner y Scrum Master hacen las veces de jefes, quieras o no. Pero scrum te habilita a ti como 'currito' a decirle claramente a tu 'jefe' que la descripción que ha puesto de la tarea es pésima y tú no te puedes comprometer (commitment) con esa tarea y con una estimación correcta. Y eso significa que le acabas de echar atras a tu jefe su trabajo. Pero es a lo que me refiero con estrico y horizontal. O todos no comprometemos a ser Agile o falla estrepitosamente.
La primera vez que le dices a tu jefe, 'vuelve a definir esa historia' es raro pero una vez él se da cuenta que dedicando 15 minutos más a dejar todo atado nos facilíta enormemente la vida y hace que se cumplan plazo y estimaciones.
Es un cambio de mentalidad pero bien hecho es muy eficiente. Y ya el tema de transversabilidad y multidisciplinaridad ya lo tratamos otro día que me he cansado
Pues a mi me parece un planteamiento cojonudo. En vez de montar una jerarquía llena de jefes potencialmente inútiles en la que se favorece el trepismo y todo funciona de forma lenta e ineficaz, generas un entorno de trabajo en el que cada uno se siente valioso por lo que aporta al equipo, y no existe la posibilidad de que un mal líder bloquee por completo el avance del proyecto. Estoy harto de escuchar quejas de malos jefes que no valoran a sus empleados o que no ayudan a que el trabajo avance, generando frustración entre los trabajadores, que ni logran objetivos ni se ven valorados. Es cierto que puedes tener un buen jefe, pero gracias a métodos como este, no lo necesitas.
Además, esa gente que orienta su carrera profesional a "dirigir equipos"... es que es un puto chiste. Es gente que se aleja del lado técnico porque no quieren mancharse las manos, y que lo único que hacen es decirle a todo el mundo lo que tiene que hacer sin saber realmente en qué consiste esto (considerando la velocidad a la que cambia la tecnología, no puedes mantenerte al día si no estás en contacto con el problema).
#17 Nadie a dicho que Stalin siguiese a rajatabla los postulados y teorias de Marx... porque una cosa es el Stalinismo y otra el Marxismo... es fácil mezclar todo en uno para la manipulacion en los medios y la derecha...
#16 Iluso, habla de muchas cosas, pero de subir sueldo nada, más responsabilidad, más curro pero dd pasta nada. Por otro lado, puedes poner en LinkedIn cosa muy chulas, con palabros nuevos y ya con eso estás apañado.
#4 Dice que los squads son grupos de trabajo empoderados, se les empodera hasta cierto punto. La totalidad de la empresa se refiere a la parte que trabaja, no a la que recibe rentas del capital.
#19 la mejor matización que se podía hacer, porque aún está por ver a un jefe responsable por: el accidente de angrois, el del metro de Valencia, los sobrecostes de las chorrocientas obras públicas, y un largo ETC.
En la empresa privada dependiendo del mamoneo también pasa.
#2 A qué te refieres con lo de currito? El significado que creo que le da la gente es: Neo-esclavo cuya vida ha sido en un principio dirigida hacia convertirse en un esclavo apto. Después, ya como esclavo en activo, a generar plusvalía para aumentar aún más el dominio del sistema depredador imperante.
A lo mejor otras personas lo usan distinto, pero por el momento esa es la impresión que tengo de su uso.
Esta peña iba en Patinete dentro de las oficinas en el año 2000. Y tenían Playstations en cubiculos supercuquis. Al final, toda esa mierda, no servia para nada. Los patinetes acabaron abandonados.
Va a ser la risa cuando tomen decisoones en comité, esas decisiones se alarguen meses y el mercado se los coma.
El jefe distribuye el trabajo ordenando a los empleados que lo hagan, causandose problemas si alguien no acepta la orden. La "distribución" del PO es presentarlo a los equipos y ya decidirán ellos lo que se puede hacer.
#9 Sin saber muy bien que hace esa persona exactamente, puede no ser lo mismo.
No se si estas familiarizado con la metodologia agil scrum, pero uno de los roles en esa metodologia es la figura del scrum master*, el scrum master es una persona que se encarga de llevar el sprint que es un periodo de x semanas (normalmente 2 pero pueden ser mas o menos) donde a principio del sprint se establece un objetivo o mision para el sprint. En un sprint hay al menos 3 tipos de reuniones, el sprint planning que es donde se establecen los objetivos y se introducen las tareas en el sprint, el stand up diario que es cada dia a la misma hora donde cada persona del equipo dice que hizo ayer, que va a hacer hoy y si tiene algun bloqueo y por ultimo al final del sprint hay un retrospective donde se discute que ha ido bien en el sprint, que ha ido mal y que cosas se deben cambiar para el siguente. Adicionalmente hay una sesion de demos donde se muestra lo que se ha hecho en el sprint al resto de departamentos con el animo de recibir comentarios y ajustar lo que se tenga que ajustar. El scrum master es un poco el organizador de esto, es el que esta en contacto con otros departamentos para saber cuales son las prioridades, es el que se encarga de resolver los bloqueos en el caso de que un desarrollador este bloqueado por otro departamento, es el que facilita las reuniones, el que se asegura que no se extienden en el tiempo.
Como digo al principio del sprint se establece cual es el objetivo del mismo, yo como desarrollador no suelo tener mucho que decidir al respecto, otros departamentos (generalmente el de producto) son los encargados de saber que es prioritario para el producto, pero dentro de una funcionalidad el equipo de desarrollo es el encargado de decidir como se hacer, como se divide y como se implementa dicha funcionalidad y el tiempo que esa funcionalidad se va a llevar en desarrollar, no hay ningun jefe que me diga que tengo que hacer, como o cuando, el scrum master no es mi jefe ni mucho menos, yo puedo decirle al scrum master que algo no se puede hacer, que algo no se va a hacer en el tiempo esperado o que algo no se puede hacer en este momento y es el, el encargado de comunicarselo a otros departamentos para que actuen en consecuencia. No es un jefe, simplemente tiene una responsabilidad distinta a la mia, pero no esta sobre mi. Es en definitiva un coordinador pero sin el poder de imponer nada, solo de coordinar, porque no tiene el conocimiento necesario para decirle a un desarrollador como trabajar.
* Lo siendo por la terminologia en ingles, no se si hay equivalente en Español, yo todo esto lo he aprendido y lo uso en Reino Unido que es donde vivo y trabajo, no es por ser pedante.
#42 Evidentemente tampoco me refiero a los que tienen el puesto por ser familia de... al final esos tienen a otro al lado que es el que hace que las cosas funcionen.
#45 Si, personal y de empresa. Lo de empresa es un desproposito. Plataforma caida, envios de cartas a direcciones antiguas dadas de baja, anulaciones de tarjetas sin motivo....
#9 Es que eso no es así si esta bien implementado.
Haciéndolo correctamente el PO solo prioriza, luego es el equipo el que decide cuanto trabajo puede acometer de lo que hay en la lista para las siguientes dos semanas y cada persona se autoasigna trabajo según va quedando libre.
Es decir que en este caso solo diría que hay que hacer y cual es la prioridad de cada tarea.
Mas allá de eso es el equipo el que decide quién hace qué.
24# si, pero sigue sin ser un jefe, un scrum master solo facilita el trabajo y indica al equipo las prioridades. No tiene la autoridad que se puede esperar de un jefe.
#52 Yo también soy usuario desde hace varios años y no he tenido problema, pero como todo, a lo mejor yo soy el caso aislado o a lo mejor eres tu. Tampoco se como es el trato con las empresas.
#28 Lo que describes no es un jefe intermedio, eso es un tío que no sabe ni cuál es su trabajo y a todas luces no vale para el puesto. Muy seguramente porque o bien lo han enchufado o bien lo ascendido porque era peor en lo que hacía y es un mal menor así y no podían echarle por diversas circustancias. He visto los dos casos.
#22 Twyp se hizo en Holanda y la app española se ha hecho en España con los jefes españoles que son un puto dolor y siguen con la mentalidad caciquil de siempre. No quieren hacer nativo porque no se quien les contó que era mejor no hacerlo así.
De hecho la app holandesa es muy distinta a la española y funciona muy bien. Lo se de primera mano porque he trabajado en varios bancos holandeses haciendo las apps
#14 en ING y en otros bancos holandeses se lleva haciendo así desde hace años. Lo que ING ha hecho ha sido cargarse a todos sus mandos intermedios que entorpecían esto. Y funciona muy bien al menos en la mentalidad de aquí (Holanda). En España no funcionará a no ser que cambien de mentalidad
#45 En Hipotecas son los más lentos. Me lo dijo la de la inmobiliaria y luego lo comprobé con mis propios ojos. En el Santander corrían a que firmara, en Bankinter fueron más rápidos. En ING se me pasaban los plazos, los llame para decirles que lo necesitaba antes de una fecha... y ellos a su ritmo. No les importa perder ni hipotecas ni clientes con cuentas nomina.
Me jode porque si llego a hacer que iba a firmar con Bankinter, lo hubiera negociado mejor.
#36 el PO es quien lidera. Hay un lider, el problema viene cuando se malinterpreta la """igualdad""" y el equipo se revela. Ya lo digo ojala les vaya bien.
En mi empresa también hemos aplicado metodología agile en todo la jerarquía. También salió en prensa (la compañía in jefes). Mentira cochina, sigue habiendo jefes categoría y jerarquía, eso sí con post it de colorines.
#32 DevOps es lo que aplican para sistemas en mi empresa con Kanban boards. Y literalmente la peña de operaciones dice que está hasta la polla de saltar de un sitio a otro a arreglar mierdas por falta de planificación.
#28 Un jefe intermedio se encarga de repartir el trabajo y supervisar el resultado de los empleados a su cargo. Que habrá sitios donde baste un tipo que se asoma para mirar de vez en cuando, pero también hay muchos donde su trabajo es imprescindible.
A mí, por ejemplo, me encargan pequeñas tareas que hago sin tener una visión total del problema. Mi jefe sí la tiene y es quien se encarga de que decirme exactamente lo que se me pide, sin necesidad de que yo conozca todo lo demás.
#30 ING no pretende implantar Agile en su desarrollo de SW (donde me parecería viable y hasta oportuno, al menos en zonas concretas de ese SW, como decía antes), sino en TODA su estructura, toda, toda su "banca", y vaya, ahí se me antoja notabilísimamente más complejo.
Soy razonablemente escéptico al respecto, porque algo de como se curra en banca se, pero tengo expectativas y conozco gente dentro de ING, si lo logran de verdad, será todo un hito, y se convertirían en un referente importantísimo, en ese aspecto, para muchas otras empresas grandes, de esas en las que "es impensable".
#13 Tres semanas duró el scrum en una empresa que estuve.
- ¿Fulanito, has terminado tal formulario?
- No, porque los DBAs no me crearon las tablas en oracle.
- ¿Por qué no creasteis las tablas, DBAs?
- Porque nos llegó la urgencia de ....
y así todo.
#30 Bueno, si y no. Lo de mandar a tomar por culo los requisitos que te han escrito en una servilleta de bar y les ha sobrado espacio es tan viejo como el desarrollo de... cualquier cosa. Vamos, seguro en la edad del bronce un herrero ya lo hizo con un guerrero que le pidió "una espada" sin especificar si la quería de una mano, de mano y media o de dos
Vale que agile lo formaliza un poco y queda menos violento, pero vamos, es la misma mierda de siempre. La verdadera ventaja de agile esta en fijar objetivos concretos a corto plazo de forma que tras cada sprint tengas un progreso real en el desarrollo del producto. Y en involucrar al cliente/jefe (product owner) en el desarrollo para evitar lo de "te mando los requisitos (de mierda) y no me vuelves a ver hasta 6 meses después cuando me quejo que lo que has hecho no es lo que yo quería".
Y precisamente es la mentalidad de involucrar al cliente en el día a día del desarrollo lo que cuesta infinito cambiar.
La transversalidad y currar en squads efectivamente es otro tema (relacionado, pero otro tema).
#30 Una de las mejoras del teletrabajo fue que los jefes de proyecto dejaron de contarme los cambios al verme por los pasillos, y tuvieron que mandarme las peticiones por email / tareas internas.
#14 efectivamente. Un buen ejemplo es en el sector eléctrico, donde hay sitios donde hay un único departamento de ingeniería para especificación de requisitos. Vete tú a decirles que vas a montar un sistema de control de una subestación eléctrica usando Agile...
#2 los jefes intermedios no desaparecen, solo se adaptan a la nueva forma de trabajar. Siguen existiendo y siguen teniendo las mismas responsabilidades, aunque algunas las comparte con el resto del equipo
Los que trabajamos en tecnología en empresas que no son dinosaurios chapados a la antigua ya hace tiempo que usamos éste tipo de tecnologías y nuestra vida es mucho mejor y la de la empresa también.
Sin ir más lejos el ejército estadounidense lleva décadas usando éste tipo de organizacion por squads, y son profesionales con distintas especializaciones que forman parte de un mismo equipo y que pueden realizar tareas de manera autónoma sin depender de ningun mando intermedio o comunicación externa para lograr sus objetivos.
Si divides tu gran objetivo en pequeñas tareas y asignas equipos multidisciplinares con perfiles especializados para llevar a cabo dichas tareas y les otorgas cierta autonomía, se reducen las congestiones burocráticas, las dependencias departamentales y la información fluye de manera mucho más ágil entre los implicados, sin hacer ruido en las personas que no estan implicadas en el proyecto.
#1 Es que si que hay jefes intermedios, solo les han cambiado el nombre:
Esto no significa que no haya responsables. Cada ‘squad’ cuenta con un ‘product owner’ (PO, en la jerga ‘agilista’), que es el encargado de decidir el orden de las tareas, aunque no es un jefe como tal. “Distribuye el trabajo y, sobre todo, prioriza, para saber qué carga de trabajo tiene cada uno”, asegura Sarasola.
Vamos, dice lo que tiene que hacer cada uno y es el responsable de ese equipo, lo que viene a ser un jefe.
#7 Pues a ver si tu lo explicas mejor, porque el artículo no me aclara mucho...
Si la gente se organiza en squads (cada una con un jefe) y los squads se organizan en tribus (tambien cada una con un jefe), exactamente como es eso de no tener jefes?
Entiendo que no tienes departamenteos especializados, tienes equipos multidisciplinares, lo que me parece una buena idea, pero tampoco es especialmente original, sinceramente no veo lo revolucionario
Si hay jefes intermedios protestamos. Si no hay protestamos.
Otro caso de estudio es el uso de la palabra curritos...
Si hay jefes intermedios protestamos. Si no hay protestamos.
Otro caso de estudio es el uso de la palabra curritos...
Líder, responsable, o cualquier denominación sin tener la categoría correspondiente es un timo para los empleados.
Hay muchos tipos de trabajo. Y cada uno es responsable de sus acciones en este tipo de empresas (banco) que está todo registrado y encorsetado.
El mero hecho de tener un jefe no significa que sea responsable de la acción agrupada de todos los que están por debajo de él. Ni el hecho de no tenerlo tiene porqué hacer que la responsabilidad se diluya.
Cuando quitan los mandos intermedios es porque el control ya lo da un ente que se llama: sistema de gestión. Que es el que se adapta a todos los cambios legales de la empresa y es reporgramado continuamente para que los empleados actúen según los protocolos marcados por la directiva.
No hablamos de diseñar y construir un puente.
Esto suena a que cuando hay algún problema la culpa es del sistema y/o del departamento de TI, nadie toma responsabilidad de los fallos humanos, que haberlos, haylos...
No hablamos de diseñar y construir un puente
No, hablamos de gestionar el dinero y activos de los ciudadanos... cosa que me parece tan seria como diseñar y construir cualquier tipo de obra de ingeniería.
Un abrazo!
Por otro lado, Agile es una metodología que funciona muy bien para algunos entornos, como desarrollar para spotify, pero que se adapta con dificultad a otros, donde la transversalidad, por motivos de seguridad, validaciones y demás, no es factible de manera realista.
No es el mejor sistema para construir software médico, militar y vaya, hasta ahora el bancario se ponía también como ejemplo de donde no parece apropiado aplicar metodologías Agile.
Quizás ING demuestre que sí es posible, y eficiente, muchas veces el progreso se da cuando alguien demuestra que lo que los demás decían que no se podía, sí se puede... Pero tampoco hay que olvidar que muchas, muchas otras veces, la realidad es que no se podía así, y el intento se hostia.
La otra posibilidad es que sea solo una pose, igual que cuando su CEO dijo lo de "no somos una empresa de banca, somos una empresa de tecnología que casualmente tiene una licencia de banca", que lo de Agile sea solo una capita por encima, que se limite al frontend más pinturero de su web, pero que, como todo banco, siga teniendo más yayos kobold-eros que devops de golang...
En un par de años se ve.
PD: Ahí no entran los de lo público
Como usuario de su app, no van por el buen camino. En cambio la de Twyp sí está currada.
Trabajo desarrollando para banca con metodologías Agile y aquí funciona bien. Pero es verdad que una metodología agile funciona si se aplica estrictamente en todos los sentido y se entiende bien la horizontalidad.
Me explico:
Los Product Owner y Scrum Master hacen las veces de jefes, quieras o no. Pero scrum te habilita a ti como 'currito' a decirle claramente a tu 'jefe' que la descripción que ha puesto de la tarea es pésima y tú no te puedes comprometer (commitment) con esa tarea y con una estimación correcta. Y eso significa que le acabas de echar atras a tu jefe su trabajo. Pero es a lo que me refiero con estrico y horizontal. O todos no comprometemos a ser Agile o falla estrepitosamente.
La primera vez que le dices a tu jefe, 'vuelve a definir esa historia' es raro pero una vez él se da cuenta que dedicando 15 minutos más a dejar todo atado nos facilíta enormemente la vida y hace que se cumplan plazo y estimaciones.
Es un cambio de mentalidad pero bien hecho es muy eficiente. Y ya el tema de transversabilidad y multidisciplinaridad ya lo tratamos otro día que me he cansado
Seguro que lo compensan con sueldo emocional.
Además, esa gente que orienta su carrera profesional a "dirigir equipos"... es que es un puto chiste. Es gente que se aleja del lado técnico porque no quieren mancharse las manos, y que lo único que hacen es decirle a todo el mundo lo que tiene que hacer sin saber realmente en qué consiste esto (considerando la velocidad a la que cambia la tecnología, no puedes mantenerte al día si no estás en contacto con el problema).
#17 A quien no asistía le daban un pioletazo.
En la empresa privada dependiendo del mamoneo también pasa.
A lo mejor otras personas lo usan distinto, pero por el momento esa es la impresión que tengo de su uso.
Va a ser la risa cuando tomen decisoones en comité, esas decisiones se alarguen meses y el mercado se los coma.
El jefe distribuye el trabajo ordenando a los empleados que lo hagan, causandose problemas si alguien no acepta la orden. La "distribución" del PO es presentarlo a los equipos y ya decidirán ellos lo que se puede hacer.
No se si estas familiarizado con la metodologia agil scrum, pero uno de los roles en esa metodologia es la figura del scrum master*, el scrum master es una persona que se encarga de llevar el sprint que es un periodo de x semanas (normalmente 2 pero pueden ser mas o menos) donde a principio del sprint se establece un objetivo o mision para el sprint. En un sprint hay al menos 3 tipos de reuniones, el sprint planning que es donde se establecen los objetivos y se introducen las tareas en el sprint, el stand up diario que es cada dia a la misma hora donde cada persona del equipo dice que hizo ayer, que va a hacer hoy y si tiene algun bloqueo y por ultimo al final del sprint hay un retrospective donde se discute que ha ido bien en el sprint, que ha ido mal y que cosas se deben cambiar para el siguente. Adicionalmente hay una sesion de demos donde se muestra lo que se ha hecho en el sprint al resto de departamentos con el animo de recibir comentarios y ajustar lo que se tenga que ajustar. El scrum master es un poco el organizador de esto, es el que esta en contacto con otros departamentos para saber cuales son las prioridades, es el que se encarga de resolver los bloqueos en el caso de que un desarrollador este bloqueado por otro departamento, es el que facilita las reuniones, el que se asegura que no se extienden en el tiempo.
Como digo al principio del sprint se establece cual es el objetivo del mismo, yo como desarrollador no suelo tener mucho que decidir al respecto, otros departamentos (generalmente el de producto) son los encargados de saber que es prioritario para el producto, pero dentro de una funcionalidad el equipo de desarrollo es el encargado de decidir como se hacer, como se divide y como se implementa dicha funcionalidad y el tiempo que esa funcionalidad se va a llevar en desarrollar, no hay ningun jefe que me diga que tengo que hacer, como o cuando, el scrum master no es mi jefe ni mucho menos, yo puedo decirle al scrum master que algo no se puede hacer, que algo no se va a hacer en el tiempo esperado o que algo no se puede hacer en este momento y es el, el encargado de comunicarselo a otros departamentos para que actuen en consecuencia. No es un jefe, simplemente tiene una responsabilidad distinta a la mia, pero no esta sobre mi. Es en definitiva un coordinador pero sin el poder de imponer nada, solo de coordinar, porque no tiene el conocimiento necesario para decirle a un desarrollador como trabajar.
* Lo siendo por la terminologia en ingles, no se si hay equivalente en Español, yo todo esto lo he aprendido y lo uso en Reino Unido que es donde vivo y trabajo, no es por ser pedante.
Haciéndolo correctamente el PO solo prioriza, luego es el equipo el que decide cuanto trabajo puede acometer de lo que hay en la lista para las siguientes dos semanas y cada persona se autoasigna trabajo según va quedando libre.
Es decir que en este caso solo diría que hay que hacer y cual es la prioridad de cada tarea.
Mas allá de eso es el equipo el que decide quién hace qué.
24# si, pero sigue sin ser un jefe, un scrum master solo facilita el trabajo y indica al equipo las prioridades. No tiene la autoridad que se puede esperar de un jefe.
Ahí has patinado y mucho, supongo que por desconocimiento.
De hecho la app holandesa es muy distinta a la española y funciona muy bien. Lo se de primera mano porque he trabajado en varios bancos holandeses haciendo las apps
Me jode porque si llego a hacer que iba a firmar con Bankinter, lo hubiera negociado mejor.
A mí, por ejemplo, me encargan pequeñas tareas que hago sin tener una visión total del problema. Mi jefe sí la tiene y es quien se encarga de que decirme exactamente lo que se me pide, sin necesidad de que yo conozca todo lo demás.
Agile no deja mucho margen al pasteleo, algo que choca de frente con la mentalidad latina en general (Fr, It, y mediterráneos).
En la cultura holandesa por contra es prácticamente intuitivo.
Soy razonablemente escéptico al respecto, porque algo de como se curra en banca se, pero tengo expectativas y conozco gente dentro de ING, si lo logran de verdad, será todo un hito, y se convertirían en un referente importantísimo, en ese aspecto, para muchas otras empresas grandes, de esas en las que "es impensable".
- ¿Fulanito, has terminado tal formulario?
- No, porque los DBAs no me crearon las tablas en oracle.
- ¿Por qué no creasteis las tablas, DBAs?
- Porque nos llegó la urgencia de ....
y así todo.
Vale que agile lo formaliza un poco y queda menos violento, pero vamos, es la misma mierda de siempre. La verdadera ventaja de agile esta en fijar objetivos concretos a corto plazo de forma que tras cada sprint tengas un progreso real en el desarrollo del producto. Y en involucrar al cliente/jefe (product owner) en el desarrollo para evitar lo de "te mando los requisitos (de mierda) y no me vuelves a ver hasta 6 meses después cuando me quejo que lo que has hecho no es lo que yo quería".
Y precisamente es la mentalidad de involucrar al cliente en el día a día del desarrollo lo que cuesta infinito cambiar.
La transversalidad y currar en squads efectivamente es otro tema (relacionado, pero otro tema).
Sin ir más lejos el ejército estadounidense lleva décadas usando éste tipo de organizacion por squads, y son profesionales con distintas especializaciones que forman parte de un mismo equipo y que pueden realizar tareas de manera autónoma sin depender de ningun mando intermedio o comunicación externa para lograr sus objetivos.
Si divides tu gran objetivo en pequeñas tareas y asignas equipos multidisciplinares con perfiles especializados para llevar a cabo dichas tareas y les otorgas cierta autonomía, se reducen las congestiones burocráticas, las dependencias departamentales y la información fluye de manera mucho más ágil entre los implicados, sin hacer ruido en las personas que no estan implicadas en el proyecto.
Ponme un caso real de asunción de esa "tremenda responsabilidad" que merece un generoso salario....
es.wikipedia.org/wiki/Sistema_de_producción_Toyota
Esto no significa que no haya responsables. Cada ‘squad’ cuenta con un ‘product owner’ (PO, en la jerga ‘agilista’), que es el encargado de decidir el orden de las tareas, aunque no es un jefe como tal. “Distribuye el trabajo y, sobre todo, prioriza, para saber qué carga de trabajo tiene cada uno”, asegura Sarasola.
Vamos, dice lo que tiene que hacer cada uno y es el responsable de ese equipo, lo que viene a ser un jefe.
CC #2
Si la gente se organiza en squads (cada una con un jefe) y los squads se organizan en tribus (tambien cada una con un jefe), exactamente como es eso de no tener jefes?
Entiendo que no tienes departamenteos especializados, tienes equipos multidisciplinares, lo que me parece una buena idea, pero tampoco es especialmente original, sinceramente no veo lo revolucionario