• Saltar a la navegación principal
  • Saltar al contenido principal
Icono Jeronimo Palacios

Jeronimo Palacios & Associates

Transformación digital

  • Agile Academy
    • Scrum Mastery
  • Próximos cursos
  • Scrum.org
    • Applying Professional Scrum
    • Applying Professional Scrum for Software Development
    • Professional Scrum Master
    • Professional Scrum Master II
    • Professional Scrum Product Owner
    • Professional Scrum Product Owner Advanced
    • Scaled Professional Scrum
    • Professional Agile Leadership
    • Professional Scrum with Kanban
  • Kanban University
    • Team Kanban Practitioner
    • Kanban System Design
    • Kanban Systems Improvement
  • Servicios
    • Formación
      • Management 3.0
      • SAFe 5.0
      • Lean Change Management
      • DevOps Institute
    • Agile Coaching
      • Discover and deliver Agility
      • Solicitud de propuesta de servicios profesionales
    • Software
      • Diagnóstico de Arquitectura de Software
    • Recursos
  • Blog
  • Guías
    • Método Kanban
    • Nexus
    • Definitiva Scrum
    • Oficial Scrum
  • Acerca de
    • Videos sobre Scrum y Kanban
  • Contacto
  • Show Search
Hide Search

Resultados de buscar : kanban

5 libros para leer antes de final de año

Conforme se va acercando el último trimestre de 2016, es hora de revisar las listas de propósitos. Y entre ellas está la de lectura. Este año ha sido muy interesante porque, más allá de los refritos de cosas que se han dicho antes, han salido algunas joyas que merece la pena incorporar a la biblioteca. Esta es mi lista de lectura para antes de comenzar 2017

Large Scale Scrum: More with LeSS

Large Scale Scrum: More with LeSS

Este es el libro oficial de LeSS. Uno en el que Craig Larman y su equipo han trabajado durante años y que se ha retrasado múltiples veces. El libro no es sino una extensión de lo que LeSS viene predicando desde hace tiempo. En lugar de preguntar ¿Cómo escalar? hay que preguntarse: ¿Como replicar las estructuras de Scrum en una organización.

El libro ya se encuentra a la venta aunque los plazos de entrega pueden demorarse bastante. Sin duda, se convertirá en una referencia para todos los que llevamos agilidad a las grandes organizaciones.

Comprar Large-Scale Scrum:More with LeSS (Addison-Wesley Signature) en Amazon.

The Lean Practitioner’s field book

Lean Practitioner's field book

No te dejes engañar por el título del este libro. Porque esto no es libro. Es una biblia. Una de esas que se convierten en manual de referencia de cualquier campo. No esperes amenas explicaciones noveladas de por qué y cómo aplicar Lean porque no las encontraras.

Sin embargo, tienes una fantástica colección de material y técnicas sobre Lean que no encontrarán recopiladas en ningún otro sitio. No es un libro para leer de principio a fin, sino para tenerlo como material de cabecera.

Comprar The Lean Practitioner’s Field Book: Proven, Practical, Profitable and Powerful Techniques for Making Lean Really Work en Amazon

Managing for Happiness

51hzlqcvu0l-_sy392_bo1204203200_

Este libro es una reedición del best seller Management 3.0 de Jurgen Appelo. Es una edición renovada en la que Jurgen ha estado trabajando para relanzar principalmente en el mercado americano.

El formato es igual al de su su predecesor Workout. Libro grande, muchas imagenes y completamente visual. Management 3.0 ha sido una revolución en la manera que las organizaciones piensan sobre gestionar personas y recursos.

La felicidad vende, y Jurgen ha sabido aprovechar el tirón para publicar esta edición renovada del que probablemente ha sido uno de los libros más leídos por manager en todos sitios durante los últimos años.

Comprar Managing for Happiness: Games, Tools, and Practices to Motivate Any Team en Amazon

Reinventing Organizations

51rwsjzgsrl-_sx335_bo1204203200_

Este libro no es de 2016, pero si no lo has leído todavía, debería de saltar automáticamente a tu lista de prioridades. En línea con un nuevo modelo de pensamiento que va más allá de las organizaciones y traspasa las barreras de lo personal y lo social, Reinventing Organisations no es un libro que describa cómo reinventar sino más bien qué es lo que podemos esperar en las organizaciones en el próximo cambio de paradigma.

Muy en línea con el trabajo de John Kotter y su modelo de cambio en ocho pasos o Theory U, del cual hay una nueva edición que ha empezado en Septiembre en edX y a la cual todavía te puedes apuntar.

Fréderic es un iluminado, alguien que está por encima de su tiempo y que será estudiado en unos años en los libros de texto. Cuando estuvo en Berlín, tuve la oportunidad de compartir algo de tiempo con él y sólo puedo decir que me quedé impresionado.

Comprar Reinventing Organizations: A Guide to Creating Organizations Inspired by the Next Stage in Human Consciousness en Amazon

Kanban essential condensed

essential-kanban-cover1

La última recomendación es la guía oficial de Kanban. La literatura sobre Kanban ha sido en general escasa, a excepción del Kanban “blue” book de Anderson y el Kanban from the Inside de Mike Burrows, que en mi opinión son difíciles de digerir si estás introduciendo en el método.

En la guía condensada se explican los principios de gestión del cambio, principios de gestión, las partes básicas de Kanban o STATIK. Lo mejor de todo es que es totalmente gratuita. Hay un libro en preparación que vendrá a complementar esta guía que al final puede saber a poco, pero no se le espera hasta 2017.

Descargar Kanban Condensed guide gratis

Comparativa entre frameworks ágiles de escalado: SAFe, LeSS and Nexus

Cuando usamos Scrum a nivel individual, muchas veces surgen dudas sobre los roles o sobre determinadas maneras de enfocar situaciones. Cuando lo hacemos escala, dependiendo del framework que sigamos, esas diferencias se acentúan mucho.

Las diferencias entre los tres grandes frameworks de escalado son sutiles e importantes. No es la misma labor la que hace un Scrum Master en un entorno que use SAFe que en uno que use LeSS. En el primero, su trabajo es más de gestión, mientras que en el segundo, se espera que sea más un coach.

Es por ello que es interesante que aquellas organizaciones que están practicando agilidad a escala definan, entiendan y comuniquen cuales son sus expectativas con respecto a los roles y a sus funciones dentro de la práctica ágil.

Esta recopilación no sería posible sin el fantástico trabajo de Charles Bradley de ScrumCrazy.

TemaLeSSSPSSAFe
Framework: ¿Tiene elementos obligatorios para poder decir: usamos el framework?Necesario vs Optional
(Es un Framework)
Necesario vs Opcional
(Es un Framework)
Todo es Opcional
(Es una librería)
Definición y estructura
TemaLeSSSPSSAFe
Estándar del Framework/Definición del FrameworkLas reglas de LeSS
28 reglas/2 páginas
Guía de Nexus
11 páginas
The Big Picture
Sitio web de SAFe
Prácticas adicionales+400 a 3 niveles+40 a 1 nivelLas mismas. Todas las prácticas son complementarias
¿Donde se definen las prácticas adicionales?3 libros y algunas en claseEn la clases SPSEn el sitio web de SAFe
Product Owners, Product Managers y Product Backlog
TemaLeSSSPSSAFe
Product Owner “Supremo”Product OwnerProduct OwnerNuevo Rol: Product Manager
Cuantos Product OwnersUno para cada grupo de equiposUno para cada grupo de equiposUno por equipo
Product ManagerNo es un rol oficial, pero ayuda a los equiposNo dice nada al respectoRol específicos de SAFe; dirige a los POs de los equipos
Cuantos Product BacklogsUno por grupo de equipos (con vista por equipo)Uno por grupo de equipos (con vista por equipo)Uno por cada equipo + Un Backlog a nivel programa
Enfoque a nivel equipo
TemaLeSSSPSSAFe
Enfoque primario de los equiposScrumScrumScrum, XP, Kanban, Combinación (Siempre con SM y PO)
Tipo de ProductosSoftware, FirmareSoftware, FirmwareSoftware, Firmware, Hardware
Estándar de Scrum a nivel equipoGuía de Scrum o Scrum PrimerGuía de ScrumGuía de Scrum con modificaciones específicas de SAFe
Colaboración, Coordinación e Integración entre equipos
TemaLeSSSPSSAFe
Coordinación entre equipos: FrameworkEventos conjuntos y refinamiento, al menos 51% Feature TeamsEventos conjuntos y refinamiento, Nexus Integration Team, Nexus Daily Scrum y Nexus Sprint PlanningEventos conjuntos y refinamiento. Eventos trimestrales, System Team, Scrum of Scrums, Team Backlog, Team PO
Coordinación entre equipos: Prácticas AdicionalesLos equipos Scrum eligen de entre 11 mecanismos, incluyendo CoP, SoS, Integración de códigoCoP; Equipos Tiger/Scrumble; Integración continua, tableros de refinamientoN/A Todas las prácticas son complementarias en SAFe
El rol del Scrum Master
TemaLeSSSPSSAFe
Número de Scrum MastersFull Time para 2-3 equiposNo especifica el número de Scrum Masters por equipoNo especifica el número de Scrum Masters por equipo
Rol en la coordinación entre equiposNo es responsabilidad del Scrum MasterLa responsabilidad es del NIT, no del Scrum MasterLa responsabilidad es del Scrum Master
Otras responsabilidades del Scrum MasterPromover agilidad y coaching a nivel organizaciónNinguna, las descritas en la guía de ScrumResponsable de reportar al management
Rol de Scrum Master “supremo”No, todos los Scrum Masters son igualesEl Scrum Master del Nexus Integration Team se encarga de hacer coaching a la organización. También puede ser un SM normalRelease Train Engineer

Los 10 libros ágiles fundamentales

El mundo agile cuenta con abundante y amplia literatura sobre muchos temas, lo cual hace que sea difícil identificar cuales de estas ideas son válidas o están mejor contrastadas. Donde empezar o como tener una mejor visión se hacen imposibles con la cantidad de libros que hay en el mercado.

Muchos alumnos y visitantes del blog me preguntan por donde deberían empezar a leer. A continuación hay una lista de los que yo considero los libros ágiles fundamentales, donde se toca Scrum, Kanban, Management, Systems Thinking, Valores… he querido evitar ofrecer un compendio de libros técnicos para centrarme más en la visión holística de aquellos que necesitan entender las distintas dimensiones de la agilidad organizacional.

Estos son los 10 libros que hay que leer.

Por un Scrum Popular

Tobias Mayer y Alan Cyment

Por un Scrum PopularCuando obtuve mi certificación CSM en 2008, lo hice en uno de los pocos cursos públicos que Tobias Mayer ha dado como Certified Scrum Trainer. Al contrario de lo que esperaba, hablamos muy poco del framework en sí -lo suficiente para tener el conocimiento mínimo- y hablamos mucho de personas, de dinámicas y de cómo el éxito de Scrum estaba ligado a entender a las personas y no al proceso.

En “Por un Scrum Popular”, Tobías comenta distintas ideas que hacen que Scrum pueda tener éxito en capítulos muy cortos. Alan ha traducido, ampliado y dado su toque personal a la edición en Español.

Comprar “Por un Scrum Popular en Amazon

Coaching Agile Teams

Lyssa Adkins

coaching agile teamsEste libro es básico para aquellos que sean Scrum Masters o Agile Coaches. Lyssa tiene una gran influencia que viene de la International Coach Federation y ha sido clave para cambiar el significado de lo que un Scrum Master significa en Scrum.

No es un libro rápido de leer. Con sus casi 400 páginas, hace un análisis detallado de distintas características de un Scrum Master así como de distintas herramientas para poder ser mejor Scrum Master.

Comprar Coaching Agile Teams en Amazon

Software en 30 días

Ken Schwaber y Jeff Sutherland

software in 30 daysDespués de 20 años de Scrum, Jeff y Ken decidieron atacar de una vez uno de los problemas que siempre ha tenido el marco de trabajo. Management no lo entiende. Scrum es visto como una cuestión de técnicos. De equipos de desarrollo. De Project Managers. Pero no de Management.

Este libro está orientado a los managers. Explica como el desarrollo ágil es necesario para mantener una empresa competitiva en una economía digital. Tiene múltiples ejemplos de grandes organizaciones que han adoptado desarrollo ágil de software exitosamente. Además, explica como medir Scrum y como relacionarlo con una cuenta de resultados.

Comprar Software en 30 días en Amazon.

The Heart of Change

John P. Kotter

the heart of changeJohn Kotter es un especialista en cambio. Además de haberlo estudiado durante muchos años, ha trabajado para intentar desgranar cuales son los elementos clave para canalizar el cambio. Para muchos es un guru, y a través del Harvard Business School ha elaborado un modelo para gestionar la innovación y el cambio dentro de las organizaciones que permite flexibilidad y constancia.

Tiene una presentación excelente que es un gran resumen de su trabajo en Youtube.

Comprar The Heart of Change en Amazon

The Phoenix Project

Gene Kim, Kevin Behr, George Stafford

the phoenix projectLa primera vez que escuché hablar de The Phoenix Project, me pareció que iba a ser una plasta infumable. ¿Una novela sobre DevOps? ¿Quien tiene el valor de tragarse eso? Así que la dejé en la pila de libros por leer durante bastante tiempo.

No fue hasta este Verano, de viaje por Japón, que decidí empezar a leerla. Es una novela. Y como tal sabe arrancarte emociones. Hacia la mitad del libro prácticamente estaba gritándole al personaje principal que se fuera de su empresa, que estaba rodeado de irresponsables con ninguna idea de lo que estaban haciendo. Después viene la catarsis. Como en toda novela, tiene sus puntos fuertes y sus puntos flacos. Yo la recomiendo porque es realmente difícil mostrar las bendiciones de DevOps de una manera tan clara y sencilla.

Comprar The Phoenix Project en Amazon

Kanban from the Inside

Mike Burrows

kanban from the insideSi todavía piensas que hacer Kanban es visualizar el trabajo en un tablero, estás muy equivocado. Kanban ha evolucionado increíblemente desde 2008, dando lugar a un marco de trabajo muy descriptivo y poco prescriptivo, que utiliza herramientas como Systems Thinking para modelar una organización con vistas a cambiarla.

Las agendas en Kanban. Los principios de la gestión de cambio. Los valores. Las métricas. Mike cubre todos y cada uno de esos aspectos en un libro muy exhaustivo donde se mezclan experiencias en la trinchera como teoría y aplicación directa. Para mí es el mejor libro sobre Kanban que hay en el mercado.

Comprar Kanban from the Inside en Amazon

Scrum, a pocket guide

Gunther Verheyen

scrum a pocket guideDe este libro he hablado en varias ocasiones en el blog. Para mi es el libro de cabecera en Scrum. Sin ser tan corto como la guía de Scrum pero basado en ella -Gunther y Ken han colaborado estrechamente durante muchos años-, esta guía es un pequeño manual que, independientemente de los años que lleves usando Scrum, puede ayudar a darte ideas o incluso provocar alguna epifanía sobre como funciona.

Gunther es un experto en Scrum. Durante muchos años se ha encargado de liderar la serie Professional Scrum de Scrum.org y para mi personalmente ha sido clave como mentor para entender Scrum.

Comprar Scrum, a pocket guide en Amazon

LiftOff

Diana Larsen y Ainsley Nies

liftoffDiana Larsen es muy conocida por otro libro suyo, que se considera básico para aquellos equipos que empiezan a hacer retrospectivas, el Agile Retrospectives. En este libro, que puede resultar pesado y desorganizado pero es un diamante en estado bruto, analiza junto a Ainsley Nies cuales con los elementos fundamentales para crear y lanzar equipos ágiles. El libro es un marco de trabajo para estandarizar el proceso de creación de equipos ágiles, dándoles las primeras herramientas para que puedan despegar por sí mismos.

Comprar LiftOff en Amazon

The 5 Dysfunctions of a team

Patrick M. Lencioni

5 dysfunctions teamEn este libro, fundamental para entender como funcionan las dinámicas de equipo, Lencioni describe como los mayores activos de un equipo pueden ser a la vez sus mayores amenazas. Tratando de resolver problemas de forma directa no sólo no ayudará, sino que hay que aprender a ver detrás de los problemas y buscar soluciones sintéticas que provoquen cambio a largo plazo.

Est libro es lectura obligada para todos aquellos que como Scrum Masters, o Product Owner, trabajen con equipo día a día, viéndose obligados a tomar parte de estas dinámicas.

Comprar The Five Dysfunctions of a Team: A Leadership Fable en Amazon

Drive

Daniel Pink

driveLlegamos al último de la lista con un libro sobre Psicología humana, a través del cual entenderemos que los verdaderos motivadores de nuestra vida a largo plazo no son el dinero o las recompensas, sino la capacidad de ser autónomos, maestros y tener un propósito para entender lo que hacemos.

Daniel Pink explica cuales son las bases Psicobiológicas y las razones desconocidas de por qué estos tres elementos y su promoción tendrán un efecto más positivo en una persona que cualquier recompensa económica.

Comprar Drive: The Surprising Truth About What Motivates Us en Amazon

Métricas ágiles fundamentales (I)

La principal medida de progreso en marcos de trabajo ágiles no son los puntos de historia, sino el software terminado. Muchos equipos siguen utilizando una medida de estimación subjetiva como una métrica absoluta para predecir. Malas noticias. Los puntos de historia (story points) no sirven para nada. Las buenas. Existen varias métricas ágiles que son fundamentales y pueden empezar a usarse inmediatamente. Veámoslas.

Métricas Macro

Las métricas macro son aquellas que permiten obtener información a alto nivel de una pila de tareas por hacer, lo cual permite tomar decisiones o plantear teorías para el conjunto de equipos que desarrollan un producto.

diagrama de flujo acumulado

El Cumulative Flow Diagram (CFD)

Este diagrama indica cuantos Product Backlog Items hay en cada uno de los estados del backlog. Para obtenerlo, se puede usar software -en el caso de la imagen, JIRA- o de forma manual de forma muy sencilla. Esto es, dibujando un diagrama, y al final de cada día, actualizando el valor acumulado de cada uno de los elementos que tenemos en el Product Backlog.

WIP Limit

WIP

La primera de nuestras métricas ágiles es el WIP. El WIP nos indica en cualquier momento el trabajo que está en curso. Si miramos el diagrama detenidamente, podemos obtener el trabajo en curso en cualquier momento midiendo la distancia entre el trabajo pendiente del backlog y el trabajo que todavía no ha sido entregado. Esta medida nos indica, de un vistazo, si los equipos están trabajando en demasiadas cosas a la vez.

Reducir el trabajo en curso contribuye a reducir la frecuencia de entrega. En entornos ágiles, las entregas frecuentes son muy importantes y permiten obtener un feedback rápido del cliente para poder adaptar la estrategia.

Algunas organizaciones tienen 6 o más meses de trabajo en curso. ¿Que significa eso en métricas de negocio? Que existe una inversión que no está produciendo ningún resultado y que conforme pasa el tiempo, reduce su posible retorno (ROI) y por tanto aumenta el riesgo. Reducir el trabajo en curso se hace más fácil relacionando las métricas de producto con las métricas de negocio de esta manera.

De esta manera, se justifica la necesidad de introducir técnicas de Continuous Delivery o DevOps en los equipos de desarrollo, o incluso de refactorizar la base de código para facilitar entregas más frecuentes.

customer lead time metric

Average Customer Lead Time

Si trazamos una línea horizontal en el diagrama de flujo acumulado, obtenemos el tiempo medio de entrega al cliente para el conjunto de nuestro Product Backlog. A pesar de ser un concepto de Scrum, también se puede utilizar en Kanban u otros métodos.

El tiempo medio de entrega al cliente nos dice cuanto pasa, de media, desde que ponemos algo en el backlog hasta que esto está entregado. Es un concepto macro. Puede que haya elementos del backlog que normalmente tarden mucho menos o mucho más.

Si un equipo no se siente identificado con un customer lead time muy alto ya que normalmente tardan poco en completar los ítems, hay que observar varios factores.

El primero es si la definition of done de ese equipo permite realmente poner el software en producción. Que una tarea esté hecha por el equipo y tenga que esperar un proceso de puesta en producción hace que su ROI descienda con el tiempo.

El segundo puede ser que el Product Backlog se haya convertido en la “carta a los reyes magos”. Eso hace que las posibles ideas junto con el análisis de su beneficio vayan perdiendo sentido con el tiempo y que el Product Owner no esté trabajando lo suficiente para mantener un backlog que aporte valor al negocio.

cycle time metric

Cycle time

Si trazamos la diagonal entre el WIP y el Customer Lead Team, obtenemos el tiempo de ciclo. Esto es, el tiempo que el equipo pasa trabajando en la tarea hasta que esta está entregada. Esto no es el tiempo real que un desarrollador tarda en realizar la tarea, sino el total desde que se empezó hasta que se dio por terminada.

Se puede ver la relación obvia entre estas tres métricas. Reducir el WIP afecta al customer lead time y al cycle time. Para reducir el Cycle Time no nos queda más remedio que reducir el Customer Lead Time.

La ley de little

En realidad, todo esto tiene un nombre: la ley de Little. Este señor demostró la relación entre el número medio de clientes en una tienda, su frecuencia de llegada y el tiempo medio que pasaban en la tienda. A pesar de sonar bastante inofensivo, es la base de Kanban.

Por otro lado, aunque usemos Scrum, podemos tratarlo como un sistema Kanban, dado que tenemos acceso a el diagrama de flujo acumulado del cual podemos extraer las métricas. En otro artículo hablaré de cómo hacerlo con números.

Así, si una organización quiere aumentar la agilidad ofreciendo software en ciclos más cortos, no tiene más remedio que invertir en mejorar las herramientas que favorecen que el software se ponga en producción, esto es, operaciones y desarrollo. Aquí entra en juego el factor humano. No se puede simplemente añadir más miembros a un equipos, sino que requiere tener en cuenta otro triángulo de hierro: El de infraestructura/arquitectura, producto y personas. En el próximo de la serie, hablaremos de métricas micro.

Empezar en Agile: guía fundamental para Managers

Tanto si usas Scrum o cualquier otra metodología ágil y eres Manager, tu trabajo va a experimentar un gran cambio. Pronto. Un cambio casi total. Mientras que antes tu trabajo consistía en gestionar o coordinar, ahora tu trabajo consiste en facilitar que los equipos ágiles puedan hacer su trabajo.

La historia del Management

El management es un invento del siglo XX, una reminiscencia de la Revolución Industrial. Aunque nos suele muy lejano, todavía vivimos en esa era. Transformación Digital. No es sino una vuelta de tuerca más al fenómeno de la automatización que comenzó con el ferrocarril.

Management es un invento que da una respuesta a algo que nunca había pasado antes. Gracias a la automatización, ahora se podía separar el hacer el trabajo y pensar sobre el trabajo. Los operarios de una fabrica se podían concentrar en una tarea relativamente complicada y ser parte de algo mayor, como hacer puertas de un vehículo a motor. Separación total. El Manager sabía del proceso completo y el operario de su trabajo. El manager estaba arriba. El operario abajo.

Hace 80 años, el manager podía medir lo que hacía el operario porque conocía el trabajo mejor que el. A día de hoy, el manager desconoce la mayor parte del trabajo que hacen sus reportes directos. Y eso está bien..El problema es que el trabajo ha cambiado. En 50 años hemos pasado de una situación en la que el manager sabía sobre todo el trabajo a una situación en la que, especialmente en el software, el desarrollador sabe más sobre lo que está haciendo y las herramientas que está usando que lo que sabe su jefe. Eso ha hecho que el concepto de management quede completamente obsoleto. El trabajo del Manager en Agile no tiene nada que ver con lo que ha hecho anteriormente.

La complejidad de desarrollar software

Desarrollar software es complejo. De hecho es más complejo que cualquier otro tipo de ingeniería. Las condiciones cambian, la tecnología nunca llega a poder ser dominada -y para cuando lo es, cambia drásticamente- y los requerimientos cambian cada vez que el usuario mira la aplicación. Si existiera una organización que representara a todos los ingenieros, su motto sería: Esto no es lo que yo quería.

Para lidiar con la complejidad es necesario maximizar la capacidad de gestionar el riesgo. Utilizar iteraciones cortas. Ciclos de feedback rápidos. Ser capaz de inspeccionar y adaptar de forma inmediata. Para poder hacer eso, es necesario trasladar gran parte de las responsabilidades del Manager hacia abajo.

En un entorno ágil, los managers no toman decisiones, sino que facilitan que otros las tomen. No gestionan, sino que ayudan a otros a gestionar. Dividimos la organización en pedacitos pequeños en los que cada persona tiene una pequeña responsabilidad. Si se hace demasiado grande, la dividimos aún más. Nadie posee suficiente para ser demasiado poderoso y al mismo tiempo nadie posee suficiente para poner en peligro a toda la organización.

La alternativa ágil al Management tradicional

Jurgen Appelo, con su Management 3.0 did un pistoletazo de salida a una nueva forma de ser Manager en un entorno ágil. En estos entornos el manager tiene una influencia indirecta, y lo que hace es gestionar un entorno, de la misma manera que gestionaría un entorno en la naturaleza.

¿Extraño? Aquellos que cultivan bonsais, crían acuarios o tienen una pequeña huerta nunca pensarían en decirle a sus peces que coman o hacer performance reviews sobre el crecimiento de su pequeño Ficus. En lugar de eso, intentan reproducir entornos reales, añadiendo sales o eliminando plagas. Lo mismo hace un Manager en un entorno ágil.

Un Manager ágil no tiene por qué asistir a un curso de Management 3.0, ni haber leído un libro sobre Agile Management; es más, es probable que muchas de las cosas que haya hecho antes ya estén orientadas a crear ese entorno donde la gente pueda crecer y desarrollarse.

Algunas responsabilidades de un Manager en un entorno ágil

Facilitar la adopción de un método que ayude a lidiar con la complejidad, como Scrum o Kanban. Los Managers en ocasiones son el mayor impedimento a la implantación ágil, cuando en realidad pueden ser su mayor aliados. Estar convencido del paso, para asegurar la supervivencia y competitividad de la organización es fundamental. En un entorno ágil, el Manager es el coach del método y no el director del trabajo.
Gestionar riesgos a través de la transparencia. Un Manager ágil ayuda a la gestión de riesgos manteniendo la transparencia. Una política de e-mail o salarios abierta. Facilidades para saber lo que pasa en la organización como las kudos-box o la promoción de herramientas de valor como el Net Promoter Score son parte del trabajo de un manager ágil.
Promocionar la auto-organización y auto-gestión como parte de la gestión de la complejidad. La auto-organización juega un papel fundamental, y aceptar la incertidumbre sobre lo que puede ocurrir forma parte de esa promoción. Muchas organizaciones invierten ingentes cantidades de recursos en intentar predecir en lugar de aceptar que este mundo y la economía son cambiantes e intentar adaptarse tan pronto como detectan una desviación.

Y después… ¿Qué?

Es probable que como Manager, pienses o conoces a alguien que piense que esto no es para ellos. Incluso que esto es una moda pasajera. O un poco más de humo. Te entiendo perfectamente. Sin embargo, si eres manager, quizás también tengas esa sensación de que tu trabajo está cambiando y todavía no sabes muy bien hacia donde se dirige.

Es el momento de, al menos, echar un vistazo al otro lado de la puerta y saber lo que te espera. Créeme. Te va a gustar.

  • « Ir a la página anterior
  • Ir a la página 1
  • Páginas intermedias omitidas …
  • Ir a la página 47
  • Ir a la página 48
  • Ir a la página 49
  • Ir a la página 50
  • Ir a la página 51
  • Ir a la página siguiente »

Mantente al día a través de nuestra Newsletter Susbribirse

Jeronimo Palacios & Associates

Copyright © 2022 · Jerónimo Palacios & Associates S.L.

  • Aviso legal
  • Condiciones de venta
  • Política de cookies
  • Política de privacidad