• 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

Scrum en la practica

#ScrumClinic: Marcos de trabajo en grandes organizaciones y proyectos en Scrum

Es habitual que lectores del blog y alumnos de los cursos de Scrum y cursos de Kanban me escriban para preguntarme dudas sobre la forma en la que implementan Scrum y Kanban en sus organizaciones. Hasta ahora, siempre he respondido en privado. Estas ideas se agrupan en dos secciones: #ScrumClinic y #KanbanClinic. Si tienes una consulta, mandala a través del formulario de contacto

En el curso aclaramos que son los equipos de desarrollo los que acuerdan las prácticas a emplear y que las “buenas maneras” están bien para comer en una mesa, pero encorsetan a los equipos y limitan su autogestión. En el caso del banco, que ya sabemos que no es un buen ejemplo, al ser líneas ocupadas de elementos distintos, pero englobados dentro de un mismo objetivo (reingeniería de procesos de pagos o cobros), ¿no podría resultar conveniente el articular un marco de trabajo común, aunque fuera laxo? eso facilitaría que los miembros de los equipos pudieran cambiar de proyecto con el fin de prestar apoyo concreto o expandir conocimiento.

Los proyectos bajo scrum, como todos, tienen un comienzo y un final. Cuando el proyecto satisface los objetivos, ¿cómo se articula el mantenimiento de la aplicación?, y hablo de mantenimiento, no de evolución. No veo que tenga mucho sentido el conformar un equipo scrum para dar respuesta reactiva a los problemas que pueda presentar un producto. Por otra parte y abundando en el párrafo anterior, si es un área definida de una organización la que se encarga de esta tarea, el contar con un esquema definido, con una arquitectura congruente entre aplicaciones podría tener la seguridad de que se enfrenta siempre a proyuectos con una estructura homogénea, lo que redundaría en un ahorro de coste al ser el tiempo necesario para familiarizarse con el produco, menor.

Jorge Alarcón, alumno del PSM

Marcos de trabajo comunes

Con respecto a la primera cuestión, hay dos preguntas que responder:

  • ¿Si Scrum permite la autoorganización y la capacidad de autogestión de los equipos de desarrollo, cómo fomentamos la participación transversal?
  • ¿Cómo evitamos que cada equipo termine usando tecnologías o prácticas distintas que no tienen conexión entre sí?

Veámoslo desde tres puntos de vista: Nivel equipo, nivel producto y nivel organización.

Nivel Equipo: La perspectiva del Product Owner

strategic alignment index

He publicado en múltiples ocasiones que la labor del Product Owner va mucho más allá de tomar requisitos y que es una pieza fundamental en la optimización de valor y retorno de la inversión que hacemos en el desarrollo de productos.

Una de las herramientas estratégicas de un buen Product Owner es el Total Cost of Ownership: Cuanto me cuesta mantener mi producto vs cuanto me reporta. Mirando la imagen que encabeza este texto, se puede apreciar que los productos que nos interesan son aquellos con un bajo TCO que estén alienados con la estrategia de IT y de Negocio.

Desde la perspectiva del Product Owner, esto supone promover que el desarrollo de producto se alinee con la estrategia global de IT de la organización. Por ejemplo, de establecer el uso de marcos y herramientas comunes a lo largo de toda la organización. Sólo así el Product Owner puede obtener un ROI mayor de la inversión que hace cada Sprint en el desarrollo de producto. Y eso se hace a través de una gestión estratégica del Product Backlog.

El TCO está extraido del libro Managing IT Innovation for Business Value de Intel Press.

Nivel Producto: Desarrollo de productos a escala

Durante el PSM, aprendemos como aplicar Scrum a un equipo de desarrollo. Al final del curso, tocamos brevemente el tema de escalado. Cuando escalamos Scrum -entendido como tener más de tres equipos desarrollando el mismo producto con el mismo Product Backlog– tenemos que extender las técnicas de Scrum más allá de un sólo equipo.

Este es el caso con la autoorganización. En un entorno a escala, la autoorganización y la capacidad de decisión de un equipo están limitados por el resto de los equipos. Por ejemplo cuando usamos Nexus. Hay dos elementos que nos ayudan.

  • El primero es una Definition of Done común: La DoD en Nexus es un mínimo común denominador para todos los equipos del Nexus. Luego cada equipo puede restringirla aún más. Eso asegura que se pueda entregar un incremento integrado cada Sprint.
  • El segundo es el NIT: El Nexus Integration Team es accountable por la integración del producto. Esto significa que es necesario que las prácticas de los equipos no vayan en contra de otros equipos.

Nivel Organización: Modelos de gobierno ágiles

Una de las razones del éxito de Scaled Agile Framework (SAFe) es que proporciona un modelo de gobierno donde todos los elementos existentes previamente en la organización se ven claramente representados.

SAFe lidia con la incertidumbre inherente a los cambios organizacionales proporcionando respuestas a nivel jerárquico y de gobierno, mientras que LeSS o Nexus no lo hacen. Disciplined Agile Delivery también lo hace. La gente de DAD y SAFe saben que las grandes organizaciones se preocupan menos por Sprints y Retrospectivas. Su foco está puesto en como gobernar el barco.

Scrum.org está apostando por el recién nacido Scrum Studio para el área de gobierno que hasta ahora ni Scrum ni Nexus habían tocado.

Dentro de Scrum Studio, uno de los elementos fundamentales es el SDK (Scrum Development Kit), una amalgama de directrices de desarrollo de Software, herramientas de desarrollo y despliegue que son las que marcan ese marco común en una gran organización.

Ese marco común permite mantener el desarrollo de productos alineado con las estrategias de IT y de Negocio, un TCO controlado y un delivery en candencia, mientras que sigue existiendo un amplio margen para la autoorganización y la autogestión.

Si quieres saber más sobre Scrum Studio, puedes echarle un vistazo a esta presentación de Dave West, CEO de Scrum.org.

Proyectos en Scrum

Ahora la segunda cuestión: Proyectos y mantenimientos en Scrum.

Durante muchos años, se ha utilizado el paradigma del proyecto para el desarrollo de Software. El problema es que el desarrollo de software no acaba nunca. Por eso el enfoque que utilizamos desde Scrum.org es el del paradigma del producto.

Las tres métricas de éxito de un proyecto son Coste, Alcance y Tiempo. ¿No es posible que un proyecto cumpla esas métricas y aún así sea un desastre, que no genere valor alguno? Sí, y hay muchos casos de los que tirar para esta situación.

En cambio, al hablar de productos, nuestro enfoque de métricas cambia hacia ¿Generamos valor o no? Dedicamos los dos días del PSPO a entender como funciona Scrum a partir de la perspectiva del valor generado y no de si se ha hecho en tiempo, alcance y coste.

Scrum sirve para la gestión de proyectos: Un proyecto en Scrum tiene una duración de un Sprint, y todas las fases del proyecto ocurren dentro de ese Sprint.

Cuatro señales de que Agile no funciona en tu organización

En ocasiones, durante los cursos de scrum o de kanban, los alumnos me preguntan cuales son las señales que indican que Agile no funciona. Uso Agile de manera extensa aquí porque independientemente de que framework usemos, estas señales son casi generales para cualquier iniciativa ágil.

Todo el mundo está siempre ocupado

Los sistemas Agile-Lean tienen una característica muy curiosa: son ineficientes. Al poner el foco en el valor, es normal que se generen ineficiciencias a nivel local. Estas ineficiencias son resueltas por los individuos y los equipos. Así se evita que se acumulen a nivel global y se creen colas y excesos de inventario a medio hacer.

Eso hace que sea muy frecuente que haya uno, dos o tres miembros del equipo de desarrollo con poco trabajo, que se encuentren dando apoyo a otros, aprendiendo o directamente descansando. Cuando en una organización todo el mundo está muy ocupado durante el día, lo siguiente que miro es el inventario de trabajo en curso (WIP) para casi invariablmente, encontrar decenas de Product Backlog Ítems y Tickets que estan atascados en alguna fase

El día se divide en tramos de una hora

En el magnífico artículo de Paul Graham: Manager’s schedule, Maker’s schedule, se explica perfectamente por qué estructurar el día en tramos de una hora afecta tanto a la productividad de las personas involucradas en el desarrollo de Software.

Para hacer una presentación en Power Point, el manager puede dedicar una hora por la mañana y una hora por la tarde. Sin embargo, para resolver problemas que se encuentran en el dominio complejo, necesitamos esa misma hora sólamente para hacer una estructura mental de lo que pretendemos hacer. Romper a mitad de proceso significa volver a empezar desde cero.

Las organizaciones ágiles entienden esto y liberan de todas las reuniones a sus desarrolladores, dejando las mínimamente imprescindibles para mantener la transparencia, inspección y adaptación.

No se cuestionan las premisas

Tanto en organizaciones que han adoptado Scrum como marco de trabajo de referencia como aquellas que lo han hecho con Kanban, es habitual que se cuestionen las premisas desde distintos puntos de vista. Desde Scrum, es habitual que el equipo de desarollo pida al Product Owner que explique el motivo de introducir una u otra historia de usuario en el Product Backlog, los datos en los que se basa y cual es el beneficio que quiere conseguir.

En Kanban, los equipos se centran en gestionar el flujo de trabajo y adaptar los límites de trabajo en curso dependiendo de como quieran jugar con el ciclo de vida de desarrollo del software (SDLC). Entienden que si aumentamos el WIP en la fase de análisis ahora, necesitaremos planear más recursos en la fase de testing de dentro de tres semanas.

Los espacios de trabajo se diseñan por marketing

Recuerdo que hace un par de años visité las oficinas de una empresa abanderada como ágil en Madrid. Después de darme un paseo a la hora de los Daily Scrums, me senté en la terraza al sol con la persona que me acompañanaba y me preguntó: ¿Que opinas? ¿Que has visto que cambiarías?

Le dije que me había fijado en cómo los equipos no tenían espacios para hacer el Daily Scrum. Pude observar como a la hora convenida, los Scrum Masters sacaban las pizarras y las llevaban en la mano para mostrar el Sprint Backlog al equipo mientras se reunian en medio de la nada.

También le dije que si yo fuera Scrum Master, lo primero que haría sería clavar esas mismas pizarras en las preciosas paredes cubiertas de vinilos con mensajes positivos. En la oficina no había ni una sola pared o ventana que tuviera nada. El mandato: Las paredes son más importantes que entregar valor había calado.

#ScrumClinic: Sprint 0 e Inception

Es habitual que lectores del blog y alumnos de los cursos de Scrum y de Kanban me escriban para preguntarme dudas sobre la forma en la que implementan Scrum en sus organizaciones. Hasta ahora, siempre he respondido en privado. Me gustaría aprovechar esas ideas para inaugurar dos secciones: #ScrumClinic y #KanbanClinic. Si tienes una consulta, mandala a través del formulario de contacto

Hola Jerónimo, se que debes tener una agenda muy ocupada, pero agradeceria mucho me puedas ayudar con esta duda que tengo.

Sigo tu blog muy asiduamente desde aqui Perú. Actualmente en nuestra organización están comenzando a implementar Agile (Scrum propiamente dicho) y los coaches nos comentan que el flujo a seguir es Inception – Sprint 0 – Ejecución Scrum.

Lo que me parece curioso es que hablan de Sprint 0, sin embargo tu lo mencionas como algo inmaduro en tu blog (https://jeronimopalacios.com/2016/09/formar-equipos-agiles-cuando-estas-empezando-en-scrum/).

Después de una ejecución en un proyecto aquí en la empresa, vi necesario un espacio de tiempo entre el inception y el Sprint 1, y mi duda es la siguiente:

Si este espacio de tiempo para preparar el terreno (infraestructura, IDEs, herramientas, refinamiento del MVP en Historias de Usuario) es parte de un posible Sprint 0 o son actividades propias de un Inception.

Te estare muy agradecido que me puedas brindar tus comentarios.

Gracias, desde Perú!

En Scrum, no hay Sprint 0

Si vamos a la guía de Scrum, no encontraremos mención a ninguna de estas dos técnicas. La gestión de proyectos en Scrum se produce en un sólo Sprint y abarca todo el ciclo de vida del software: planificación, diseño, desarrollo, testeo y entrega en un sólo Sprint.

Tener un Sprint 0 es solo una manera de intentar hacer Scrum en fases o lo que es lo mismo, waterfall en Sprints. En Scrum siempre se comienza por el primer Sprint y al final del mismo se entrega una funcionalidad de negocio terminada. Eso permite enfocarse en lo que es realmente fundamental para entregar esa pieza de Software.

Existe una manera de tener el tiempo necesario para montar todo el despliegue usando Scrum, y esto es simplemente ajustando la longitud del Sprint. Esta depende de dos factores:

  1. El tiempo mínimo que el equipo de desarrollo necesita para producir valor: Si el equipo no es capaz de producir software terminado en dos semanas, ¿Para que poner Sprints de dos semanas? Si el equipo no es capaz de entregar software en 30 días o menos, hay que ver los impedimentos y eliminarlos.
  2. Un horizonte aceptable de riesgo para el Product Owner: El Product Owner, como responsable de gestionar la inversión del desarrollo, tiene que sentirse cómodo con el horizonte de planeamiento planteado por el equipo de desarrollo.

Si el equipo no puede entregar software en dos semanas, pueden tener Sprints de 3 o de 4 semanas. Scrum no dice: “Sprints de dos semanas”, sino “Software en 30 días o menos”.

¿Que sentido tiene hacer un Sprint 0 si las necesidades del proyecto pueden cambiar en dos, tres o cuatro Sprints? Scrum es desarrollo de Software iterativo e incremental, donde cada Sprint tiene varias oportunidades de inspeccionar y adaptar. Un Sprint es un proyecto completo.

Si tomamos todas las decisiones en el Sprint 0, no estamos haciendo mucho más que una fase de “preparación al desarrollo”, donde estaremos tomando muchas decisiones que luego pueden ser erróneas conforme vayamos descubriendo nuevas necesidades que antes no estaban claras. No es muy distinto de PMP o Prince2 y nos llevará al mismo problemas.

La utilidad de un inception

Un inception es una técnica que permite descubrir que se quiere hacer para poder llenar un Product Backlog. Es una reunión ligera, que puede durar unas pocas horas, y su lugar ideal de realización es durante el Sprint Planning del primer Sprint.

Sin embargo, muchas organizaciones intentan hacer inceptions que duran varios días y luego necesitan una o varias semanas para poder analizar con detalle cada uno de los Product Backlog Items para poder ordenar el Product Backlog.

Esto tiene otro nombre: Toma de requisitos. Da igual que ahora se haga con Post-its® y en una reunión facilitada, sigue siendo lo mismo que se lleva haciendo muchos años.

Los inceptions no forman parte de Scrum, son técnicas que no deben de interferir en el framework. Por lo que nos cuentas, querido lector, los coaches de tu organización, están adaptando el marco de trabajo Scrum a las técnicas que ellos conocen.

Esto en realidad esto está inventado, y se llama Waterfall

El problema es que en organizaciones en las que se dan estas situaciones, la inversión en agilidad está directamente desperdiciada. Es solamente ponerle distintos nombres a lo que se ha hecho siempre. Un proyecto se convierte en las siguiente fases:

  1. Inception: Conocido como fase de toma de requisitos.
  2. Sprint 0: Conocido como fase de preparación al desarrollo/arquitectura/infraestructura.
  3. Desarrollo: Conocido como el mismo nombre en métodos tradicionales
  4. Testeo: ídem
  5. Hardening: Conocido como fase de estabilización
  6. Despliegue: Conocida como fase de igual nos hemos equivocado en cosas y tenemos que volver a empezar

Asumiendo que cada una de esas fases dura 1 o 2 sprints, estamos poniendo Software enfrente del cliente cada 3 o 6 meses. Eso en el mejor de los casos. En el peor de los casos desarrollaremos durante un año sin que el cliente haya visto nada ¿En qué es distinto esto de los métodos tradicionales como PMP o Prince2? En nada.

La premisa de Scrum es: “Software terminado en 30 días o menos”, de forma iterativa e incremental. Todo lo que sea salirse de eso, llámese Sprint 0 o Inception no es Scrum y es una señal de organizaciones y equipos inmaduros.

Si no son capaces de hacer esto, es mejor empezar con otra técnica, como Kanban, que permite una mejora evolutiva partiendo de un proceso ya existente. Seguir con Scrum es abocarse al fracaso en esta situación.

software in 30 days

Recomiendo la lectura del libro de Ken Schwaber y Jeff Sutherland, creadores de Scrum: Software en 30 días o menos. En el mismo se explican las mecánicas básicas de como funciona Scrum y de cual es el ciclo de vida de desarrollo de software cuando se utilizan métodos ágiles.

Comprar Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, and Leave Competitors in the Dust en Amazon

Qué hacer cuando el Product Owner está ausente

Esta es una situación común en muchas organizaciones que empiezan con Scrum en su búsqueda de la solución a todos los problemas.

El Product Owner no existe o está ausente todo el tiempo, lo que hace que recaiga todo el trabajo encima del equipo de desarrollo. Veamos que hacer.

Si no hay Product Owner o Scrum Master

Uno de los alumnos de mis clases era el CTO de una empresa mediana de desarrollo de herramientas para Recursos Humanos. Después del primer día de clase, en las preguntas finales del día, levantó la mano y dijo: Pero… si no hay Scrum Master o Product Owner, Scrum se puede adaptar, ¿No?

La respuesta es NO. Scrum requiere muy pocas cosas. Un Product Owner, un Scrum Master, un Equipo de Desarrollo.

Si no somos capaces de poner dos de esas tres, no vamos a obtener muchos beneficios.

Esta situación es típica de empresas muy rígidas que están afrontando problemas verdaderamente graves pero que buscan una solución fácil.

Todo les vale mientras no tengan que cambiar. Lo siento. Malas noticias. Scrum requiere unos cambios mínimos para avanzar.

La solución en este caso es, simplemente, no hacer Scrum. No llamar a lo que hacemos Scrum, porque el día que decidamos darle un oportunidad, los miembros de la organización ya tendrán una visión negativa del mismo.

Es mejor implementar algunas prácticas de XP, como el Daily Standup, Release and Iteration Planning o una base de código compartido que intentar hacer Scrum.

XP es una introducción perfecta a muchas prácticas que se utilizaran más adelante en Scrum.

Si el Product Owner está ausente todo el tiempo

Esta segunda situación es bastante común, y se da también en empresas consultoras que nominan como Product Owner al cliente sin pensar siquiera si entiende lo que esto supone.

El nivel de colaboración entre el Product Owner y el equipo de desarrollo es muy necesario, pero la mayoría de los Product Owners lo que entienden es que es un representante del negocio.

Nada más alejado de la realidad. El Product Owner es el negocio y no estando disponible para el equipo de desarrollo está poniendo en riesgo la inversión que supone dedicar un Sprint a hacer Software sin tener ningún feedback.

Al final, es el Product Owner el que tiene que dar la cara por todas las decisiones que se han tomado en torno a qué invertir el tiempo durante el Sprint.

Un Sprint del equipo Scrum cuesta de 25.000€ a 75.000€ por Iteración y es el Product Owner el responsable de manejar ese presupuesto. Una buena pregunta para el Product Owner ausente es: ¿En que hemos invertido los últimos 25/50/100.000€?

Es habitual que aquellos Product Owners que están demasiado ocupados para dar la cara respondan que ellos no manejan el dinero. Incluso se sientan ofendidos.

En la mayoría de las ocasiones, esta situación viene dada por no entender cuales son sus responsabilidades. Alguien les ha explicado que tienen que representar al cliente y las ha recomendado ver Scrum en 8 minutos o Scrum explicado a mi abuela, pero nunca les han explicado por qué existe el perfil.

Mi recomendación en este caso es invertir tiempo en explicar al Product Owner cual es el sentido del rol en Scrum. Empezar por preguntas como ¿Donde has invertido los último X€ de la empresa? llamará su atención lo suficiente como para propiciar una conversación

Cuando el Scrum Master o el equipo toman la responsabilidad del Product Owner

En algunos equipos ocurre algo distinto. El Product Owner delega en el Scrum Master o el equipo de desarrollo la toma de decisiones sobre lo que hacer. Esta opción es válida en Scrum, siempre y cuando tengamos claro que el último responsable de lo que haga el equipo sigue siendo el Product Owner.

Se puede delegar el hacer el trabajo pero no la responsabilidad sobre el trabajo. Un ejemplo típico sería el del Product Owner que ha estado ausente y llega al Sprint Review a quejarse del trabajo. Lo primero que hay que apuntar es que él o ella son responsables de lo que ha ocurrido y que han preferido no ejercer su rol y dejarlo a otros.

Cuando el Scrum Master toma la iniciativa de cubrir al Product Owner, no sólo le está haciendo un flaco favor al resto, sino que además está haciendo mal su trabajo como SM. El objetivo final del rol del Scrum Master es que Scrum funcione. Tomando la iniciativa de cubrir al PO, lo único que está haciendo es tapar las distinciones y problemas del marco de trabajo.

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

  • « Ir a la página anterior
  • Ir a la página 1
  • Ir a la página 2
  • Ir a la página 3
  • Ir a la página 4
  • Ir a la página 5
  • Ir a la página 6
  • Páginas intermedias omitidas …
  • Ir a la página 8
  • 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