El Scrum Master y el Equipo de Desarrollo

Publicada el abril 23, 2017 por antoniomartel

El trabajo del Scrum Master no es el de jefe de proyectos ni es sólo el de servir de ayuda al Product Owner (que tampoco es el jefe de proyectos). En el trabajo diario del Scrum Master también debe ofrecer servicios de ayuda al Equipo de Desarrollo además de al Product Owner.

El más importante quizás sea el de eliminar impedimentos para el progreso del Equipo, es decir, ayudar en lo que el equipo necesite para tener su trabajo preparado y no tener que estar esperando por nada. Si por ejemplo se necesita solicitar una exportación de la base de datos antes de realizar algún trabajo, será trabajo del Scrum Master realizar estas gestiones para que el Equipo de Desarrollo lo tenga preparado a tiempo y no tenga que quedarse esperando a que esto se resuelva.

Otro de los puntos importantes en los que debe trabajar el Scrum Master es en el de guiar al Equipo de Desarrollo en ser autoorganizado y multifuncional. Los equipos de desarrollo normalmente esperan que alguien les asigne las tareas y a encargarse sólo de aquellas tareas que pone el título de su contrato. El Scrum Master debe intentar cambiar este paradigma haciendo que cambie esta mentalidad para que el Equipo de Desarrollo sepa elegir sus propias tareas (de acuerdo por supuesto a la priorización hecha por el Product Owner) y a encargarse de todas las tareas sin derivarlas a otros departamentos porque ellos son los especialistas (departamentos de administradores de bases de datos o de analistas para que ellos hagan el análisis o un import o export de bases de datos).

Entre los trabajos del Scrum Master también está el de organizar los eventos o reuniones de Scrum para facilitar que éstas sucedan. Deberá organizar la reunión diaria, la reunión de demo, la reunión de retrospectiva, procurar que todos asistan y que sea del máximo provecho para todos los interesados.

También deberá servir al Equipo de Desarrollo para ayudarlo a crear productos de alto valor que no quiere decir que tengan un nivel de calidad alto, que se da por supuesto, sino a que el Equipo de Desarrollo esté centrado en producir funcionalidades y características que le aporten el máximo valor o utilidad al producto que se está construyendo.

Por último, y no menos importante, el Scrum Master deberá guiar al Equipo de Desarrollo cuando éste no ha trabajado nunca con Scrum para ayudarles en su adopción y en que sea completamente entendido por todo el equipo.

Publicado en Blog, Blog 1 | Etiquetado , , , , | Deja un comentario

El Scrum Master y el Product Owner

Publicada el abril 16, 2017 por antoniomartel

El rol de Scrum Master en un equipo Scrum no es el de jefe de proyecto como suele suponerse equivocadamente. Es más bien el de un guía que ayuda a todos a entender cómo funciona Scrum y que intentan asegurar que las prácticas de Scrum son bien entendidas y funcionan de la mejor forma posible.

El Scrum Master ayudará a los Interesados y a otras personas fuera del equipo Scrum a entender cuáles con las mejores formas de interaccionar con el Equipo Scrum, por ejemplo, si un Interesado tienen una solicitud de mejora que hacer, el Scrum Master deberá hacerle saber que es mejor si se la comunica al Product Owner para que este la meta en la pila de trabajo y la priorice si así lo cree necesario.

El Scrum Master es un líder al servicio del Equipo Scrum. En concreto, el trabajo que realizará el Scrum Master para el Product Owner será:

  • Ayudarle a gestionar la Pila del Producto de manera efectiva, por ejemplo, facilitándole herramientas para gestionar los elementos de la pila (MS Excel, Trello, JIRA, etc.) o indicándole cómo y cuando debe priorizar entre las tareas.
  • Explicarle cuando debe entrar en más detalle en ellas para que el Equipo de Desarrollo las pueda entender correctamente con especificaciones claras y concisas.
  • Ayudarle a entender las estimaciones empíricas que haga el Equipo de Desarrollo, es decir las basadas en datos reales y experiencias pasadas y no sólo en predicciones.
  • Asegurarse de que el Dueño del Producto sabe cómo priorizar las tareas y funcionalidades a realizar basándose en el Retorno de Inversión y en el coste que tienen. Es decir si una funcionalidad tiene un coste o tiempo de realización de 5 y un valor para la organización de 8 quizás convendría hacerla después de una funcionalidad de coste 2 y valor 6 porque conseguiríamos un valor similar para la organización (6) en menos de la mitad de tiempo, tan sólo 2 (y la organización la disfrutaría antes también).
  • Entender y practicar la agilidad, es decir, explicarle las principios ágiles que hay detrás de Scrum como los del manifiesto ágil. Algunos de ellos son: Nuestra mayor prioridad es la de satisfacer al cliente, Aceptamos que los requisitos cambien, Entregamos software funcional frecuentemente entre dos semanas y dos meses, Los responsables de desarrollo y el equipo de desarrollo colaboran juntos estrechamente durante todo el proyecto, etc.
  • Facilitar los eventos Scrum según se requiera: Organizarlos, reservar las salas, convocar las reuniones, llevar los artefactos que sean necesarios, comunicar el orden del día y los puntos de la reunión, etc.
Estos son los servicios que el Scrum Master presta al Product Owner, en próximos posts explicaré los servicios que el Scrum Master presta al equipo de desarrollo y a la organización en su conjunto.
Publicado en Blog, Blog 1 | Etiquetado , , , , | Deja un comentario

El tamaño del Equipo de Desarrollo

Publicada el abril 9, 2017 por antoniomartel

Lo que nos indica la guía de Scrum como mejor tamaño del Equipo de Desarrollo (no el Equipo de Trabajo, sólo el Equipo de Desarrollo, es decir, sin contar con Scrum Master y Product Owner) es de tres miembros cuando menos y nueve como tamaño máximo.

La idea es tener un equipo lo suficientemente pequeño para ser ágil pero que puedan entregar al final de cada Sprint una cantidad de trabajo que merezca la pena como para ponerlo en producción. En cambio no se quiere que tenga un tamaño tan grande, mayor de 9, que haga que se multipliquen las interacciones en el equipo y que haga difícil la coordinación entre ellos.

¿Para un Equipo de Desarrollo de sólo una o dos personas merece la pena Scrum? Estaríamos añadiendo un overhead o sobrecarga de reuniones y ceremonias que podría dificultar la normal marcha del trabajo haciendo perder tiempo al equipo. En mi caso personal, para equipos de estos tamaños aún así he intentando ser ágil siguiendo sólo cuatro principios básicos de Scrum para obtener el máximo de sus ventajas sin sobrecargar de reuniones que podrían ser inútiles al ser tan pequeños. Por ejemplo, mantener la reunión diaria, la reunión de demo, el Sprint y las Pilas de Producto y de Sprint.

En cambio, yendo hacia el lado contrario, tener 10, 11, 12 o más miembros en un Equipo de Desarrollo podría requerir demasiada coordinación y demasiadas reuniones para ponerse de acuerdo entre todos. Si se van a auto-organizar ese tamaño va a llevar demasiada complejidad como para repartirse tareas y coordinarse sin que haya un seguimiento estricto de qué hace cada uno o las dependencias entre el trabajo entre unos y otros y qué tiene que estar listo primero para que el otro pueda avanzar.

El Dueño del Producto y el Scrum Master no cuentan como miembros del equipo de desarrollo a menos que también estén trabajando en la lista de cosas pendientes a acabar dentro del Sprint. En ese caso sí son contados como miembros del Equipo de Desarrollo sumando una o dos personas más según sea el caso.

Hay estrategias para el escalado de Scrum (estrategias para cuando el proyecto es tan grande que un sólo equipo no puede con todo) como DAD (Disciplined Agile Delivery) que no son tan estrictos con los tamaños de los equipos y no prescriben unos tamaños límites mínimo o máximo tan cerrados como estos.

Publicado en Blog, Blog 1 | Etiquetado , , , , | Deja un comentario

El Equipo de Desarrollo

Publicada el abril 2, 2017 por antoniomartel

Son las personas que trabajan en el producto durante el Sprint para entregar una versión Terminada al final del mismo. Deben trabajar para que esa versión lista al final de cada Sprint pueda ser subida a producción. No quiere decir que al final de cada Sprint haya que subir obligatoriamente una nueva versión sino que está lista, probada y preparada (Terminada) para que potencialmente pueda ser desplegada en producción si alguien así lo decidiese. Son los miembros del Equipo de Desarrollo los que trabajan en la creación de esa nueva versión o Incremento del producto que se prepara cada Sprint.

Los Equipos de Desarrollo se estructura y organizan de tal forma que puedan gestionar su propio trabajo. Para conseguir esto los equipos de desarrollo deben cumplir estas características:

  • Son autoorganizados: Ellos mismos se asignan las tareas según su conocimiento y la preparación o la disponibilidad que tenga cada uno. No es el Scrum Master ni el Product Owner quién reparte las tareas, ni les indican cómo deben hacer su trabajo. Son ellos los profesionales que trabajan en esto y quienes mejor conocen cómo hacer las cosas para terminar el Sprint con una versión que podría ser subida a producción.
  • Son multifuncionales: Esto suele causar confusión con frecuencia. Equipos multifuncionales son aquellos en los que se pueden encontrar en su interior a miembros del equipo con todas las habilidades necesarias para trabajar en la nueva versión, es decir, que tendremos dentro del equipo a alguien capaz de realizar análisis funcional si es necesario analizar algún aspecto en este Sprint y a alguien con conocimientos de DBA si es necesario realizar alguna tarea de administración de base de datos. Tener un equipo completamente multifuncional es una cosa difícil pero nos dará bastante ventaja a la hora de desarrollar ya que no habrá que asignar la tarea a otro departamento, que tendrá sus propias prioridades, para luego mantener a la espera todo el trabajo del Sprint hasta que este departamento pueda llevarla a cabo y entregarla.
  • No existen títulos dentro del Equipo de Desarrollo: Todos son desarrolladores, no existe un miembro que tiene el título de Analista y por tanto sólo desarrolla esas tareas. Lo mismo para el Tester y sólo él o ella testean, podrían hacerlo todos aunque haya miembros del equipo que por sus habilidades y conocimientos estén más especializados para hacer algún tipo de tareas sobre otras pero la responsabilidad cae dentro de todo el Equipo de Desarrollo.
  • No hay sub-equipos dentro de los Equipos de Desarrollo: Esto quiere decir que no hay un sub-equipo de testers o de analistas que sólo se encargan de esto, tampoco los hay de dominios específicos dentro del producto, por ejemplo, no hay un sub-equipo que trabaje sólo con las funcionalidades que tienen que ver con la facturación y otro con las funcionalidades de control de almacén. Todos trabajan en todas las partes del producto.
Publicado en Blog, Blog 1 | Etiquetado , , , , | Deja un comentario

Los Interesados

Publicada el marzo 27, 2017 por antoniomartel

Los Stakeholders tienen un nombre bastante feo en su traducción al español para Scrum: Los Interesados. Se les llama así por que tienen algún interés en el producto que se está construyendo. Pueden que sean los dueños o accionistas de la empresa que está pagando por el desarrollo, el jefe del departamento de ventas que quiere un nuevo módulo para la facturación o simplemente los usuarios de la aplicación que se está desarrollando y que tienen particular interés (de ahí lo de Interesado) en que la aplicación o el producto (recordemos que Scrum no se usa sólo para el desarrollo de Software) funcione lo mejor posible.

Estos Interesados han nombrado a un Dueño del Producto para que los represente y a él deben dirigirse siempre que quieran alguna modificación, recordarle alguna prioridad o añadir nuevas características al producto. No deberían dirigirse directamente al equipo de desarrollo para explicarles lo importante que es que la nueva exportación a Excel esté incluida en la próxima versión que se lance. De priorizar estas cosas y darles el valor oportuno debe encargarse el Dueño del Producto. En él estarán centralizados todas las peticiones de cada Interesado.

El jefe de ventas está interesado en la integración de la facturación con los móviles, el jefe de almacén quiere un nuevo sistema de avisos cuando cae el stock, un usuario de administración quiere que los listados puedan exportarse a Excel con sólo un botón porque le ahorraría un montón de clics de ratón. Todos tienen interés en que el producto salga lo mejor posible pero alguien tiene que decidir qué se construye ahora. Los presupuestos tampoco son infinitos y hay algunas cosas a las que hay que decir ‘No, ahora no puede hacerse’ o simplemente ‘No’.

De esta gestión de los Interesados y sus intereses debe hacerse cargo el Dueño del Producto que tendrá que anotar o tener en cuenta cada solicitud y ver si es factible hacerse o no y si va a dar mayor valor al producto final construyendo eso antes que cualquier otra cosa.

Si el Equipo de Desarrollo está en una empresa externa habrá que gestionar también los cambios en la Lista de Producto y los nuevos requerimientos. Será necesario hacer caer de esa lista de cosas por hacer otras funcionalidades ya acordadas que ahora se estiman menos importantes pero que tendrían un coste de desarrollo similar, o bien aumentar el presupuesto (pero recordemos que los presupuestos no son infinitos).

Publicado en Blog, Blog 1 | Etiquetado , , , , | Deja un comentario

El Dueño del Producto

Publicada el marzo 20, 2017 por antoniomartel

El Dueño del Producto (Product Owner) es el responsable de gestionar la Lista o Pila del Producto (Product Backlog) con la lista de funcionalidades que deberá tener el producto. La gestión de esa Pila del Producto implica que es también el responsable de que el producto final tenga el mayor valor posible y para ello deberá obtener el máximo valor del trabajo del Equipo de Desarrollo.

Para gestionar esa Pila del Producto deberá:

  • Expresar claramente los elementos de la Lista para que queden claros para todos y que esa Lista muestre  en qué estará trabajando el equipo en los próximos Sprints.
  • Asegurarse de que el Equipo de desarrollo entiende los elementos de la Lista con el detalle suficiente. El Dueño del Producto conoce bien su producto y lo que se quiere conseguir con él, por tanto es el responsable de que cada funcionalidad a implementar está bien detallada y explicada para el Equipo de Desarrollo.
  • Ordenar los elementos de la Lista de Producto para obtener los objetivos que tiene el producto lo antes posible, priorizando para ello los de más valor para el producto en el mercado o en su organización.
  • Optimizar el valor del trabajo del Equipo de Desarrollo. Para ello deberá hacer que mediante la Pila del Producto debidamente ordenada y priorizada el Equipo de Desarrollo trabaje en las funcionalidades de más valor en cada momento, evitando trabajo redundante o inútil en tareas de poco valor añadido.

Es además la única persona responsable de gestionar esa Lista de Producto. Eso implica que puede estar representando a varias personas o a un comité de Interesados (Stakeholders) en el producto en la empresa cliente que nos contrata o de la propia empresa que desarrolla el producto pero es sólo el Dueño del Producto el único responsable de expresar, detallar, optimizar y priorizar la Pila del Producto. Los Interesados en el producto pueden querer cambiar la Lista, añadir nuevas funcionalidades o darles otra prioridad pero deberán hablar primero con el Dueño del Producto para expresarle sus deseos y sólo él podrá cambiarla.

El rol del Dueño del Producto es un rol fundamental en todo proyecto (se llame como se llame según la metodología) por lo que toda la organización que contrata el desarrollo del producto debe respetar sus decisiones. Él es quién decide qué va a hacerse con el producto y que funcionalidades tendrá por lo que tiene un peso muy grande en que el producto final sea un éxito o no.

No se permite acceder al Equipo de Desarrollo para pedirle que realice funcionalidades distintas a las indicadas en la Lista de Producto. El Equipo de Desarrollo deberá actuar siempre en función de lo que diga el Product Owner y no cualquier otro Interesado en el producto.

Publicado en Blog, Blog 1 | Etiquetado , , , , | Deja un comentario

El equipo de trabajo Scrum

Publicada el marzo 12, 2017 por antoniomartel

En un proyecto gestionado con Scrum el equipo de trabajo estará formado por tres perfiles: el Dueño del Producto (Product Owner), el Scrum Master y el Equipo de Desarrollo (Development Team).

Ninguno de esos perfiles es el de jefe de proyectos o rol similar ya que estos equipos Scrum son autoorganizados. Esto quiere decir que ellos mismos deciden cómo llevar a cabo el trabajo y se reparten las tareas ¿Quién mejor que el Dueño del Producto para saber lo que hay que hacer y lo que se quiere conseguir? ¿Y quién mejor que el Equipo de Desarrollo para saber cómo hay que las tareas? Ellos dividirán las funcionalidades en tareas más pequeñas, las priorizarán y se las asignarán a si mismos. Ellos mismos se organizan el trabajo cada dos o tres semanas, lo que dure el Sprint.

Los equipos de trabajo también son multifuncionales. Esto significa que dentro del mismo equipo de trabajo encontraremos todos los perfiles necesarios para hacer el trabajo. Si hay que analizar algo lo hará algún miembro del equipo de trabajo. Si hay que realizar una tarea de administración de base de datos lo hará algún otro miembro del equipo (como en DevOps).

Por ejemplo, si necesitamos que se realicen frecuentemente este tipo de tareas de base de datos en el trabajo diario tendremos que contar con alguien con formación de DBA en el equipo. De esta forma el equipo de trabajo puede también autoorganizarse al no depender de otro departamento que tendrá sus propias prioridades y por el que habría que esperar a que realice la tarea. Mientras espera el equipo de desarrollo tendría que dedicarse a otras cosas, quizás menos importantes, hasta que se lleve a cabo la tarea por otro departamento o área de negocio.

Este modelo de equipos de trabajo de Scrum mejora la flexibilidad y la productividad al no estar tan encorsetado y tener un equipo más creativo e independiente.

Al realizar entregas iterativas e incrementales, es decir, realizar una entrega del producto cada vez mayor al finalizar cada Sprint, el equipo de trabajo obtiene feedback de la opinión de los usuarios y los interesados de forma frecuente. Este feedback le permitirá priorizar las próximas tareas y corregir la línea a seguir si es necesario. Estas entregas incrementales son de producto «Terminado» y probado. De esta forma siempre hay disponible una versión plenamente funcional del producto lista para ser usada.

Publicado en Blog, Blog 1 | Etiquetado , , , | Deja un comentario

Teoría de Scrum

Publicada el marzo 5, 2017 por antoniomartel

Scrum es un marco de trabajo basado en el control de procesos empírico y por tanto no basado en predicciones o suposiciones. Esto quiere decir que el conocimiento procede de la experiencia, la observación de los hechos y de tomar decisiones basándose en lo que se
conoce. Las decisiones se toman en base a los resultados que se están viendo en el proyecto y no en base a planificaciones a largo plazo y a fechas de entrega supuestas al principio del proyecto.

Si en un proyecto tenemos que decidir si eliminamos o no una característica nueva de un producto o si es necesario dedicar más esfuerzo al desarrollo de una parte del proyecto para llegar a cumplir los límites establecidos, esta decisión la tomaremos basándonos en los datos sobre el esfuerzo que ya nos ha costado construir esta característica o similares o en los datos reales del tiempo que nos ha llevado construir las tareas ya realizadas. No nos basamos en un diagrama de Gantt con la predicción realizada al inicio del proyecto con lo que supuestamente iba a costarnos realizar estas tareas y con los límites que tenemos para cumplir la planificación, sean estos ya reales o no.

Todos los proyectos intentarán ser lo más previsibles posible y predecir cuando estarán acabadas las cosas pero, si con el objetivo de mejorar la previsibilidad usamos diagramas de Gantt, estimaciones y fechas de entrega a largo plazo con la información que teníamos al empezar el proyecto, podríamos estar teniendo el efecto contrario y volver al proyecto más imprevisible de lo que debería.

Si en lugar de trabajar y trabajar para que los planes sean exactos, asumimos que esos planes pueden estar equivocados y que son sólo eso, planes, podemos tomar las decisiones basándonos en los datos reales que vamos conociendo del proyecto para intentar ser lo más previsibles posible con los que tenemos actualmente.

Para mejorar la predictibilidad del proyecto y poder prever más fácilmente cuando vamos a acabar un conjunto de tareas o todo el proyecto, Scrum se basa en tres pilares:

Transparencia

Scrum entrega de forma iterativa pequeños incrementos del producto de forma que va añadiendo nuevas funcionalidades o características al producto final. La lista de cosas pendientes de terminar es pública, la lista de cosas terminadas y su estado es pública también. Se comparte además un lenguaje común entre todos los participantes en el proyectos de forma que sea claro y transparente para todo el mundo en qué estado está todo.

Cuando se dice que algo está ‘terminado’ debe significar lo mismo para todo el mundo y que no se barren dejabo de la alfombra con tal de hacer una marca en su casillero funcionalidades hechas pero que no han sido lo suficientemente probadas o no son prácticas. Las cosas están en estado ‘Hecho’ o ‘Terminado’ de forma transparente para todo los usuarios de Scrum sin ocultar nada a ninguno. Por eso se habla de tener una definición de ‘Hecho’ o de cuando algo puede decirse que está terminado.

Inspección

Otro pilar básico de Scrum, lo que se ha entregado y el estado en el que están las cosas se puede inspeccionar por los interesados en el proyecto o el dueño del producto (Product Owner) de forma que compruebe que está en perfecto funcionamiento y que el estado es real. Esto se hace en parte con la reunión de demo, con la transparencia de los entregables que se entregan de forma iterativa para que puedan ser probados y con las revisiones de lo que queda por hacer.  Estas revisiones no deben realizarse de forma tan frecuente que la inspección ralentice el trabajo.

Adaptación

Si en las revisiones de la inspección se comprueba que el producto, el plazo para construir o la nueva característica que se está construyendo se desvían de límites
aceptables, o que el producto resultante no será aprobado, deben hacerse cambios para intentar volver a límites dentro de lo aceptable. Estos ajustes deberán hacerse cuanto antes para evitar mayores desviaciones sobre lo que quede por realizar.

Adaptaciones o ajustes como estos son los que hacen que Scrum no sea predecible y no puedan darse largos plazos de predicción porque siempre se está adaptando el producto para mejorarlo y evitar mayores desviaciones sobre el producto ideal con el presupuesto que tenemos.

Para poder realizar estas inspecciones y sus correspondientes adaptaciones Scrum prescribe cuatro eventos o sucesos dentro de cada Sprint. Estos eventos son descritos con más detalle en otros post de este blog:

  • Reunión de Planificación del Sprint (Sprint Planning Meeting)
  • Scrum Diario (Daily Scrum)
  • Revisión del Sprint (Sprint Review)
  • Retrospectiva del Sprint (Sprint Retrospective)
Publicado en Blog, Blog 1 | Etiquetado , , | Deja un comentario

Curso práctico Scrum – Agile 101

Publicada el enero 4, 2017 por antoniomartel

Publico en esta entrada los posibles contenidos que tendría el curso sobre Scrum/Agile 101. Los que me conocen o han leído mi libro saben que no será un curso de Scrum para seguir al pie de la letra, para eso ya están las guías de Scrum que publican Scrum.org o Scrum Alliance.

Será una guía práctica que te permite saber cómo implementar el Scrum que ya conoces de oídas o del que incluse ya tienes un certificado pero no sabes muy bien cómo llevarlo al día a día de tus proyectos.

El contenido estarían divididos en unidades y capítulos como los que pongo a continuación. Sólo falta que ustedes voten por añadir o incluir nuevos capítulos (aún faltan algunos):

  • Introducción y fundamentos de Scrum
  • Descripción reuniones, artefactos, participantes y roles de Scrum (con cheat list o hoja de resumen)
    • Tres capítulos: El rol de Product Owner, El rol de Scrum Master, El rol de los interesados o stakeholders.
    • Tres capítulos: El product backlog, el sprint backlog y la gráfica burndown
  • Cómo implantar Scrum en tus proyectos (con checklist para comprobar que se está haciendo lo importante)
  • Sección cómo… o qué hacer cuando… con Errores y dudas más habituales.
    • Capítulos Buenas prácticas del software (todo no es Scrum en un proyecto).
  • Qué certificación Scrum elegir
  • Scrum ventajas e inconvenientes
  • Estimaciones ágiles en tus proyectos
  • Lecciones aprendidas
  • Kanban
  • Entender y cómo usar la gráfica burndown.
Será un curso fácil de seguir en el que cada capítulo o unidad contaría con:
  • Uno PDF con texto explicando el contenido de la unidad
  • Otro PDF con texto y contenidos adicionales que no son estrictamente temario pero que ayudarán a completar y entender la información del temario.
  • Un vídeo en el que explico de viva voz los contenidos de la unidad siguiendo gráficas o slides de presentaciones.
  • Un ejemplo práctico basado en un caso real en el que pongo en contexto el contenido de la unidad.
  • Una batería de tests de 10 preguntas sobre la unidad y un ejercicio propuesto sobre el contenido de la unidad. En el siguiente paso a estos tests se darían las soluciones o claves al ejercicio propuesto.
La idea es que el contenido del curso pueda completarse con unas 40 o 50 horas de trabajo de forma que puedas terminarlo en 4 o 5 semanas si le dedicas unas 10 horas a la semana (1 hora diaria y un par horas más el fin  de semana podría ser un ejemplo).
Al final del curso habría un test con preguntas abiertas y cerradas junto a un ejercicio práctico que corregiría personalmente. Este test sería diferente para cada alumno y si se suspende se tendría derecho a otro intento (con otro examen diferente). Se entregaría a los aprobados un PDF con mi firma y un logo del curso que podría descargarse desde mi web con un enlace como el siguiente https:antoniomartel.comcertificadosmanuel-echevarria-agile101.pdf para que puedas entregar el link a cualquier empleador o jefe tuyo y pueda comprobar por el mismo que el PDF es original.
El contenido del curso está aún abierto. Si te gusta lo que vas leyendo del curso y te animas a contestar unas preguntas para saber qué te puede interesar y qué no, pásate por el enlace a la encuesta del curso Scrum – Agile 101 y me ayudarás a saber qué puede ser más interesante para los alumnos del curso.
Publicado en Blog, Blog 1 | Etiquetado , , | Deja un comentario

Blueprint… o como quiera que se llame esto en 2017

Publicada el diciembre 31, 2016 por antoniomartel

He estado estos últimos meses ocupado intentando dar forma a un montón de ideas sobre qué hacer con el blog, posibles cursos de formación de las que ya te hablaba hace algún tiempo en la entrada Curso de Scrum Agile 101 y otras ideas sobre aplicaciones en la nube o coaching/mentoring online a través de Skype o algún otro sistema de vídeo conferencia.

Estas ideas se resumen en estos puntos que podrían convertirse en gérmenes de nuevos proyectos si veo el interés suficiente:

  • Web de formación online para la venta de cursos online sobre Agile, gestión de proyectos, gestión de recursos humanos, Lean Management o gestión a secas. Crearía una nueva web que podría llamarse Blueprint en la que mediante pago por Paypal recibirías enlaces a los contenidos que cree sobre estos temas. Veo aún pocas respuestas al cuestionario online para conocer más sobre el posible interés de los asistentes a los cursos ¿Se animan ahora a contestarlo haciendo clic en el cuestionario sobre formación online?
  • Web de asesoramiento online a través de sistema de vídeoconferencia como Skype o algún otro. Podría ser un complemento a la solución anterior en la que alguien o alguna empresa decide pagar por formación o asesoramiento más especializado al que se incluye en un curso genérico. En este formato se podrían resolver dudas o tratar problemas específicos que alguien podría tener cuando está implantando Scrum o tratando de llevar una gestión ágil de sus proyectos o empresas.
  • Nuevos libros que tengan el denominador común ‘Buenas prácticas en…’, por ejemplo, Buenas prácticas en el desarrollo de software o Buenas práctica en la gestión. Este último libro podría ser una segunda parte del libro Gestión práctica de proyectos con Scrum pero tener una visión más global a toda la gestión (recursos humanos, lean management, etc.) y no sólo a la gestión de proyectos software.
  • Aplicación en la nube para vender en formato de pago por uso a distribuidores o vendedores de productos en tiendas comerciales. Muchos de ellos aún usan un bloc de notas para tomar el pedido que le hacen sus clientes y que luego van de vuelta a su almacén a dejar la nota para preparar el pedido y llevar después la factura junto al pedido que se entrega al cliente. Ya existen sistemas similares pero con éste trataría de apostar por sencillez y economía en el presupuesto. Consistiría en una aplicación web que, desde el móvil, permita al vendedor tomar nota del pedido y que cuando llegue al almacén esté ya preparado y anotado en el sistema backend (también web). Habría que tener muchas cosas en cuenta como por ejemplo la integración con el sistema de contabilidad o de ventas que ya tengan o el sistema de impresión de albaranes o facturas (podrían ser simples pdfs).
Como ven muchas ideas para llevar a cabo y poco tiempo. 2017 se me va a quedar corto para todo esto. Ya estoy dando forma a algún curso de Scrum y haciendo sondeos con algunas empresas con comerciales o vendedores en la calle que puedan estar interesados. Si me dejan su opinión en los comentarios a esta entrada me ayudarán a saber cuáles son los sistemas en los que la gente podría tener más interés.
La idea de llamar a todos estos proyectos/empresa/startup como Blueprint viene de que en inglés los bocetos o esbozos de un nuevo edificios o el diseño ingeniería de un nuevo producto se hacía con tinta azul por lo que a esos dibujos se les llamaba blueprints.
Referencias:
Publicado en Blog, Blog 1 | Deja un comentario

Small start-ups

Publicada el octubre 23, 2016 por antoniomartel
Ana had been laid off from a software-development company. After some time thinking about it, she managed to convince David and Alberto to join her in a project they had been discussing since college: founding their own company to develop software.
They were lucky that their first client soon appeared. It was a dairy-distribution company that had decided to give them a chance. The Head of IT in their area knew them from their previous jobs, had good references about them, and thought that it would be a wise idea to increase their vendor database by including a young local company. He would give them a small, non-vital project. If it worked well, many more would follow.
Ana, David, and Alberto did not consider it a small project at all. They had no experience managing projects of that size on their own, and were afraid they would “choke” on it. They had offered a very low price to build a stock-control tool, so they had to be very competitive if they were to make money with the budget they had.
There was also another added risk. The international consulting company that normally developed software for the client would be a hard opponent to beat. If the project went wrong or was late, the stock-control tool would end up being integrated as one more module in the ERP that the consulting company had already deployed for their client.
Ana and her partners decided to follow an Agile methodology like Scrum to try and reach the level of efficiency that would help them succeed in their first project. They knew that if they spent too long analysing possible features and then spent months and months implementing them, the project could be cancelled as the client would not be able to see short-term results. Their main target was to get something into production as soon as possible: something useful for the client, even if it didn’t have all the requested features.
With this idea in mind, they started to develop their software. Every 2 weeks they showed the head of IT and the warehouse managers what has been accomplished during the previous fortnight. It looked good, but the company hadn’t started to use it yet, so they didn’t know if it would work or not.
Soon Ana suggested deploying a pilot version to production, one with a pilot version that would allow them only to add new stock, to record stock entries and withdrawals, and to draft a simple stock report. There wouldn’t be any complex functionality that would foresee demand or any SMS alerts when the stock for a given product was low.
When warehouse workers started using the new application, doubts arose, but also it became clearer what was useful and what wasn’t. After so many meetings, no one had thought that it would be useful to add a history of the product’s delivery so they would know how far in advance a product should be ordered before they ran out of stock. Or that the order screen should include current orders of the same product, to avoid duplications in ordering.
The next items on which to work were quite clear now. Also, they constantly received new application-improvement requests. They had seen that if they integrated the warehouse-management tool with the invoicing software of the delivery vehicles, they would avoid typing every product twice, once for each system, which would save them lots of time and errors. This was not foreseen from the beginning, but they reached an agreement. They wouldn’t develop the demand-prediction tool, which would be postponed until a later version was developed, but instead they would add this integration with the delivery agents’ mobile devices.
Cooperating with the client, accepting changes in requirements, and frequent deliveries of working software made the project a success for the dairy distributor. Now, at this local branch, they had a piece of software that did its job and also lightened the load on the warehouse workers and the delivery salespeople. They heard about the project in the Madrid headquarters, and were considering implementing it in other locations. Who knows, maybe this would mean a new project for Ana, Alberto, and David’s start-up.

You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).

Book on Scrum: Agile 101, Practical Project Management
Agile 101 – Practical Project Management

Translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt.

Publicado en Blog, Blog 1 | Etiquetado , | Deja un comentario

Too small to fail

Publicada el octubre 21, 2016 por antoniomartel
Kaizen, or continuous improvement, is a well-known term in business or industrial organization. It’s now spreading widely in every sector of the economy, but it also applies in social life or medicine. This philosophy arose in Japan. Their industry had  productivity and quality problems after the end of World War II. They looked for solutions, and brought experts such as  Deming. Yes, the same Deming of ITIL and the “plan-do-check-act” Deming cycle. His mission: training hundreds of professionals and engineers in quality and improvement systems. These methods had already been applied in the USA. But Japan developed them and improved them. They refined them to such an extent that years later they could return them to the Americans themselves as new work philosophies.
The principle behind Kaizen is to carry out small continuous improvements. The results of those changes are analysed and the fine-tuning resumes. In that way  the productivity or quality of the task being performed can be improved. Making small changes little by little is far more effective than trying to tackle everything in one go. This way you avoid the fear of big change—and the procrastination that normally goes with it —when faced with the idea of starting a transformation. These small adjustments, done continuously, end up becoming a habit and generating permanent results.
The idea is to make changes so easy that it would be hard to fail in their implementation. First we created the habit of changing. Then we add new changes or nudge the milestone of a change a bit further, so we can improve incrementally. It’s important to apply adjustments one by one. The idea is to avoid the complexity of choosing what to apply and when. That way we will be able to analyse the result of each of these minor improvements. If we apply several at the same time, we won’t know which one has worked and which hasn’t. Or whether the effect of one has cancelled out another.
In your project you can decide to deploy every SCRUM, TDD, unit testing, continuous integration, and so on and so forth all at once. But probably the only thing you’ll manage to do will be to drive your team crazy. Yes, all those practices are good for your project, but, are the most basic ones working? Do you have good version control? Are you delivering software every two weeks? It’s better to start by the simplest ones or the ones that you consider most effective to improve your situation. Then you will be able to add the others.
Even far away from the field of software, there are companies that use Kaizen and Lean techniques in production. Take, for example, SPB, manufacturers of household brands like Bosque Verde in Spain. Their industrial manager declares:
“SPB has improved its productivity by 15% without investing in new machinery or carrying out staff cuts. The systems we have applied have enabled our company to reduce our expense accounts from 15 to 25%. We have improved our raw-materials management by 45%. And we have reduced the stock period of our product to eleven days.”
SPB had foreseen that to improve, they would need great investments and opening new factories in northern Spain. But instead they have focused on improving their productivity plan.
We can apply such changes to improve our health or personal life too. If we have always wanted to write a book or a blog, we can set out to write 1,000 words a day. But most of us will probably abandon that idea in only a few days. However, if we set out to write just 50, the change will be so easy that it will be hard to fail. First, establish the habit of sitting and writing for 15 minutes a day. Then we can take the challenge further and make it bigger, little by little.
In my case, I have also applied similar techniques, but I’ve hardly noticed. When I published my book it hardly sold at all. For weeks and weeks it had just the few sales I considered F&F (Family & Friends). But I didn’t just park it there and forget about it. I changed it to a different Amazon category. Then I changed the cover. After that, I included some new chapters. Later, I improved the description until I found one that seemed optimal. Some of these changes made my sales increase up to 50% in a week. If I had just left it there, the book would never have reached decent positions in its categories. I would have concluded that the content wasn’t interesting. Or that it just could not sell well without a professional publishing house to support it.
You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).
Book on Scrum: Agile 101, Practical Project Management
Agile 101 – Practical Project Management

Translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt.

Publicado en Blog, Blog 1, English | Etiquetado , , | Deja un comentario

Five lessons learnt in project management

Publicada el octubre 20, 2016 por antoniomartel
Every time I finish a project, I try to make a balance report for myself. I look at the things that went wrong and the things that went right. The things that I tried and worked, and those that I shouldn’t repeat. Even those times when that final balance came up negative, maybe the project was worth it if in the next one I don’t make the same missteps again.
I have combed those balances and extracted five of the most important lessons I have learned. Some are beginner’s pitfalls. Others I should have solved by simple logic but matters weren’t so obvious when I was in the middle of things. Here they are:
Agile works
It’s difficult to quantify, but ever since I started using Scrum in my projects, the number of hours spent per feature has gone down —and in my opinion quite considerably so. We were able to gain 80% of Scrum’s advantages with three things. First, the daily 15-minute follow-up meeting. Second, keeping the graph of the state of the project that tells us whether we’re doing well or not. And third, delivering software every the two weeks. Also, every fortnight, clients seemed to feel more comfortable when they received the items that we had agreed on two weeks before. In July and August it was not possible to meet. So every week we delivered a simple two-page document with the percentage of completion of each feature. This document included two paragraphs explaining why those percentages were that way. This helped us to regain credibility in a project that was quite difficult —especially in September when they could check that those percentages were real.
Not everything is positive in Scrum
Being a Scrum Master takes far more work than simply being a project manager. In those daily 15-minute follow-ups you will be told about lots of difficulties that the team needs to overcome before they can continue. Trying to find solutions will take the rest of your morning.
And having a deadline every 2 weeks can be exhausting. You cannot sprint for months. Six months later you start trotting (and that, with luck). You need to take this into account from the first planning meeting on.
Last, but not least, Scrum is not magic. Whatever method you use, you are going to need a team trained for the job at hand, ready to roll up their sleeves and work, and willing to contribute. Teams like this don’t grow on trees. If you have one, your job as a project manager is to get out of the way as much as possible.
Adding more workers to a project that’s behind schedule will only delay it further
This was sufficiently covered a long time ago in the book The Mythical Man-Month. Even so, it’s still necessary to highlight it, as there are hardly any exceptions to this rule. No matter how tight the deadlines are nine women cannot create a baby in one month.
Who owns all this?
No matter what we call it —designating the Product Owner, identifying the stakeholders, engaging them—the end we’re going to need to know who is going to validate the project in real life. And I do not mean who is going to green-light the invoice. You’ll also need to know who is going to use the product. The project will be a success only if, after delivering it, it works and it’s useful.
At some point during the project the area manager gave us all the documentation, validated the partial deliveries, tested the whole application, and congratulated us on our work. Regrettably, when his secretary came into the training session a week before deployment, she said: “that’s of no use to me: that’s no longer the right template, as I need to gather different information now.” This meant a week of extra hours and additional effort, on top of the risk of deploying a product that could be unstable.
Minimum Viable Product
If you already have something that could be helpful to the user, deliver it, deploy it, put it up for sale. Don’t wait until you have each and every one of the features finished. If you remember the Pareto principle, with just 20% of your planned features you’ll be able to cover 80% of the uses that your product will have.

 

When it’s in production, you’ll be able to get feedback from the users. They know with more precision what they need, and you’ll know where you’ve failed and how you can fix it. If you bet on just one final delivery, you only have one bullet to hit the bull’s eye. If we had done this, it would have saved us a lot of problems with the product of the previous example.

 

You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).
Book on Scrum: Agile 101, Practical Project Management
Agile 101 – Practical Project Management

Translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt.

Publicado en Blog, Blog 1, English | Etiquetado , , | Deja un comentario

Lessons learnt

Publicada el octubre 19, 2016 por antoniomartel
Mistakes are made all the time when we manage projects—at least I have made a few. In this section I will list only some of them. They are the most relevant or the most confessable ones, depending on your point of view. I’ve messed up in many other ways, but this chapter had to have a limit. So, here they are:
First the problem, then the solution
This is the order: first you identify a problem, and then you come up with a solution. Never the other way round. It is quite common to hear about a modern solution that we apply to the project with enthusiasm. No matter whether there was a problem to solve or not. What is the use of deploying the new and sophisticated software for Test Driven Development in our daily work, if your problem with that project is way more basic? Or if you don’t have a tight grip on the version control system?
Counting the steps instead of looking at the road
We all know that in some projects the number of hours spent tends to go through the roof. Only rarely do the predicted number of hours and the actual ones coincide. Our first reaction is normally to double-check every hour registered. Then we draft complex graphs that show us how well we’re doing versus the estimate…. But does this actually help us finish the project on time?
Imagine that someone hired us to carry a heavy load from point A to point B. We estimated that it would take 10,000 steps. What is the use of knowing that we’ve walked 5,000 steps already? Do we know where we are, or if we’ve been going in circles? Wouldn’t it be better to raise our head to see whether we are on the right path? Maybe double check that the road leads from A to B, or see whether there is an easier way to get there?
Phantom requirements
Sometimes we ask our team members to change what they’ve already done because “the client won’t accept it like that.” Or because we think the product should work in some other way. Our colleague had already finished a proposal that took time and effort. It’s better to see whether the client likes it. The client will decide whether it’s right or wrong. Investing time in unsolicited corrections will only delay delivery. Careful, though —this doesn’t mean that we shouldn’t review or check our work for quality before showing it to the client. All I’m saying is: “if it ain’t broken, don’t fix it.”
Spreading the need to rush
Project Managers normally work on several projects at the same time. This implies that they juggle several clients, with their needs and deadlines, and thus accumulate tension and stress. Personally I try not to spread the stress to other members of the work team and to supply all the serenity I can. Of course, every team member must be aware of our delivery deadlines and needs to know which job we should finish for each client. Adding the need to rush to the daily routine only brings quality problems in the final product. Or creates things that are only half solved and that you will have to solve for good later on. This will also make us spend double the amount of time that those tasks would have required in the first place.
Could you make it easier?

 

One of the first mistakes in a project is to start every task as soon as possible without stopping and planning which steps should be part of it, and without determining whether they are truly necessary or whether we could simplify them somehow. I mean not only implementing it in the easiest possible way, but also simplifying the task in itself. Some examples: For this complex system that interconnects several computers…. Isn’t there already some sort of pre-defined standard? Should this parser be able to solve third-order equations? The best way to spend your time is reducing the complexity of the work to be done.

 

You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).
Book on Scrum: Agile 101, Practical Project Management
Agile 101 – Practical Project Management

Translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt.

Publicado en Blog, Blog 1, English | Etiquetado , , | Deja un comentario

Auditoría en Oracle Discoverer

Publicada el octubre 19, 2016 por antoniomartel

Otro post técnico, en esta ocasión sobre Oracle Discoverer (Oracle Business Intelligence SE One) y cómo conocer, entre otras cosas, qué usuarios trabajan sobre qué libros, con qué frecuencia usan la herramienta, cuando fue usado por última vez un libro o el uso de la aplicación que cada semana hacen los usuarios.

Oracle guarda en las tablas del esquema propietario de la EUL toda la información relativa a los documentos o informes a ejecutar, los datos a utilizar por la capa de presentación y mucha otra información. Estos datos son usados por Oracle Discoverer para hacer una predicción de los queries que el usuario va a ejecutar y poder anticipar los datos a traer de la base de datos para dejarlos en caché por si los solicitase.

En la tabla eul?_qpp_stats se guarda esta información de predicción y es la que se usa en estos ejemplos para ejecutar una auditoría.


Auditoría por usuarios

Como ejemplo, la siguiente consulta muestra el nombre de todos los usuarios que han hecho uso de la aplicación, la fecha de la última vez que la usaron, el número total de veces que la han usado y la media de días entre cada uso:

SELECT 
       stats.qs_created_by AS «Usuario»,
       TRUNC (MAX (stats.qs_created_date)) AS «Fecha último uso»,
       COUNT (stats.qs_created_date) AS «Nº de veces que se ha usado»,
       TO_CHAR ((MAX (stats.qs_created_date) – MIN (stats.qs_created_date)) / COUNT (stats.qs_created_date), ‘99990.00’ ) AS «Media de días entre cada uso»


FROM eul5_qpp_stats stats
GROUP BY (stats.qs_created_by)
ORDER BY MAX (stats.qs_created_date) DESC


Auditoría por documentos

Con esta otra consulta SQL es posible obtener un listado de los informes/reports creados por los usuarios y guardados en la base de datos, el nombre del usuario que los creó y la fecha de la última vez que fue ejecutado el documento (los informes sin estas fechas son informes que nunca fueron lanzados después de guardar):


SELECT DISTINCT
       DOCS.DOC_CREATED_BY AS «Usuario»,
       DOCS.DOC_NAME as «Informe»,
       (SELECT TRUNC(MAX(DM.QS_CREATED_DATE)) 
        FROM EUL5_QPP_STATS DM
        WHERE DM.QS_DOC_NAME = STATS.QS_DOC_NAME) as «Última ejecución»
FROM EUL5_QPP_STATS STATS, EUL5_DOCUMENTS DOCS
WHERE DOCS.DOC_NAME = STATS.QS_DOC_NAME(+)
GROUP BY DOCS.DOC_CREATED_BY, DOCS.DOC_NAME, STATS.QS_DOC_NAME
ORDER BY «Última ejecución» DESC, DOCS.DOC_CREATED_BY, DOCS.DOC_NAME;

Auditoría por semanas

En esta consulta se obtiene la lista de usuarios que usaron la aplicación cada semana y el número de veces que lo hicieron. Para cada usuario se muestra:

  • Año al que corresponde la semana.
  • Fecha del lunes de esa semana.
  • Fecha del domingo de esa semana.
  • Usuario que usó la aplicación esa semana.
  • Número de veces que ese usuario usó la aplicación en la semana.
La consulta sería la siguiente:

SELECT

       TO_CHAR (stats.qs_created_date, ‘yyyy’) «Año»,
       TRUNC (stats.qs_created_date, ‘day’) «Lunes»,
       TRUNC (stats.qs_created_date, ‘day’) + 6 «Domingo»
       u.nombre «Usuario»,
       COUNT (stats.qs_created_date) «Nº de usos» 
FROM eul5_qpp_stats stats, usuarios u
GROUP BY 
       TO_CHAR (stats.qs_created_date, ‘yyyy’),
       TRUNC (stats.qs_created_date, ‘day’),
       TRUNC (stats.qs_created_date, ‘day’) + 6,
       u.nombre
ORDER BY 
       TO_CHAR (stats.qs_created_date, ‘yyyy’) DESC,
       TRUNC (stats.qs_created_date, ‘day’) DESC,
       TRUNC (stats.qs_created_date, ‘day’) + 6 DESC,
       u.nombre ASC 
Publicado en Blog, Blog 1 | Etiquetado , , | 2 comentarios

The engineer and the bridge

Publicada el octubre 18, 2016 por antoniomartel
In the 5th century BC, a certain Roman engineer was appointed to direct the construction of a bridge over the river Leza. The bridge was important for the area. People and goods would be able to use it to cross the river, saving time and avoiding travelling long distances looking for a safe place to ford the river.
The engineer received this appointment with great enthusiasm, and went on to plan an estimate for everything that would be needed for the construction. He calculated how many builders, cranes, pulleys, scaffolds and centrings would be necessary. He could clearly see that with 50 builders the bridge could be finished in 4.7 years.
With the 600,000 sestertii that he had received to execute this assignment, he quickly bought all the necessary materials according to his calculations, and had them delivered to the construction site. He recruited the 50 builders he had estimated he would need and sent them to the river bank to start work at soon as possible. There was no time to lose. The sooner it was begun, the sooner it would be finished.
Soon, however, the workers told him that they didn’t need so many pulleys and cranes, but that there weren’t enough pickaxes and saws for the job. “I can’t do anything about that,” said the engineer, “most of the money has already been spent and there isn’t much left to buy new materials. You’ll have to adapt to what we’ve got.”
The construction went on, and soon afterwards it became clear that things weren’t going as planned. The foreman told the engineer that the stone quarry where the stone was being cut was too far away, and that the road was full of bumps and potholes from last year’s flooding. It just took too long to bring the stone in carts to the bridge. “You’ll have to make an extra effort,” said the engineer, “there’s no time now to fix the road.”
The foreman also informed the engineer that it would be necessary to build arches in the bridge, to reduce the amount of materials used, and, most of all, to improve its resistance. “There’s no time for frills,” said the engineer. “We’re late. We’ll add a little extra mortar in the pillars, and that’ll be it.”
The news about the construction of the bridge came to the Prefect’s ears. He despaired when he heard about how slowly the work was progressing, so he sent for the engineer. The Prefect needed to justify his actions in Rome, and demanded that the bridge be ready for Saturnalia. The engineer explained that, in order to achieve that, he would need at least another 50 workers. As he was also pressured from above, the Prefect agreed and committed to send the new workers a month later.
Back at the bridge, the engineer gathered all the builders and asked them for an additional effort to comply with that new deadline. The workers could not understand how were they to work twice as fast if they didn’t have enough stone, and in any case they always had to wait for the mortar to set.
Not even with the new workers could the bridge be built on time. There weren’t enough tools for everyone, the stone was still slow reaching the worksite, and collapses were common because of the hurried construction process.

In ancient Rome, a bridge’s builders had to stand underneath it while an entire legion crossed it. It’s a good incentive to build firm, solid bridges, don’t you think?

You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).

Book on Scrum: Agile 101, Practical Project Management
Agile 101 – Practical Project Management
Translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt.
Publicado en Blog, Blog 1, English | Etiquetado , , | Deja un comentario

Lessons learnt from others

Publicada el octubre 18, 2016 por antoniomartel
An old Spanish saying says “no one learns a shred from another person’s head.” But let’s try it anyway by reading some experiences other people encountered while managing projects.
In the previous section I’ve told you about my own mistakes in managing projects. In this section I will tell you about the main lessons Jeff Sutherland learned while helping companies like Nokia, Patient Keeper or even Google to adopt Scrum:
In Google, some of the teams adopted Scrum little by little. They did this because they feared resistance from their engineers. They thought that introducing a formal process in teams that were already highly productive would not speed them up but slow them down. They started implementing Scrum using only the most basic techniques. If Google can do it, why can’t we?
In Google, they also had a certain resistance to meeting daily. They thought it would be time spent in vain. They started with meetings that lasted a good deal longer than the initial 15 minutes. At first each engineer took quite a long time to explain what he or she was doing and the problems being faced. After a while, when all the members had explained their job and were aware of the job of the rest of the teammates, the meetings were much more fluid and helpful. To my relief, in their simplified, initial Scrum, they didn’t use a burndown chart for every iteration. They used only one per delivery. That made me feel better. I hadn’t been able to keep the Kanban board updated daily for each sprint (yes, I know, Scrumbutophobia).
The burndown chart helped them realise how long they would spend in developing a feature. For a feature that they initially estimated at 40 points and 3 weeks, they saw that in the first week they had covered only 8 points. In the second week they managed to finish only 7.5 points. But one of the managers thought that they had the feature ready in the third week. Then the graph made it clear that it wouldn’t be ready in that amount of time.

Jeff Sutherland recalls a project for the health sector which would be accessed online simultaneously by hundreds of doctors and other users. In that project, the definition of Done became more and more stringent. At first, they just had to pass the unit tests and acceptance tests. But later on, for something to be really marked as Done or Finished, it had to meet this condition: “deploy to production, and if the phone doesn’t ring for 1 hour, the new delivery is complete.”

You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).

Book on Scrum: Agile 101, Practical Project Management
Agile 101 – Practical Project Management
Translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt.
Publicado en Blog, Blog 1, English | Etiquetado , , | Deja un comentario

Curso de Scrum Agile 101

Publicada el octubre 17, 2016 por antoniomartel
Tengo pensado lanzar pronto un curso de Scrum/Agile pero no tengo decididos aún formato en el que lanzarlo o los contenidos exactos que tendrá. Quiero que sea un curso sobre todo práctico y que incluya cuestionarios después de cada tema, hojas de trabajo en las que se planteen problemas o ejercicios para asegurarme de que se entiende cada una de las ideas que se explican y plantillas para las reuniones diarias, las gráficas burndown o la comunicación con el cliente.
Cuando uno intenta plantear un curso de este tipo el primer problema con que te enfrentas es si debes orientarlo a personas que ya tienen un cierto conocimiento de Scrum o Agile porque Scrum lleva ya un tiempo en el mercado o bien crear un curso más sencillo en el que los profesionales que aún no se han decidido a implantarlo en sus proyectos tengan una guía con la que iniciarse en esto de Scrum.
Al terminar el curso quisiera que los participantes hubiesen aprendido:
  • Los roles y artefactos mínimos para una implantación gradual de Scrum.
  • Roadmap para avanzar en la implantación de Scrum.
  • Las ventajas y razones principales para usar Scrum.
  • Las dificultades más importantes a la hora de implantar Scrum y cómo resolverlas
  • Cómo sacar el máximo partido a Scrum.
También hay otras muchas cuestiones como si se prefiere que los contenidos sean de sólo texto o contenga también vídeos, si se quiere incluir asesoramiento personalizado via email o videoconferencia o descuentos por grupos para empresas. Para intentar resolver todo esto he creado un pequeño formulario/encuesta en la que puedes ayudarme a saber qué puede hacer más interesante para ti un curso como éste. En la siguiente dirección tienes un enlace a la encuesta: Encuesta Curso de Scrum Agile 101. Tienes tres minutos y me ayudas a saber qué puede ser más interesante para ti? Gracias!
Publicado en Blog, Blog 1 | Etiquetado , , | Deja un comentario

The 80/20 Rule

Publicada el octubre 16, 2016 por antoniomartel
How can we avoid featuritis and concentrate just on the tasks that will make us more efficient? Many years ago, approximately a century ago, someone called Pareto realised that 20% of the pea pods in his garden amounted for 80% of his crop. The remaining 80% of his pea pods amounted to the other 20% of his pea crop. Intrigued by this ratio, he also checked that he could use this rule to other fields. He went on to discover that, back then, 20% of the population had 80% of the income. The remaining 20% of the wealth was in the hands of the poorest 80% of the population. This principle, based in empirical knowledge, has been in use since then. It helps improve efficiency and productivity in economics, commercial distribution, marketing, engineering, and, naturally, in software development.
For example, we start to develop our product with a huge list of requirements and features as a base. Yet we know that only 20% of those features will be used 80% of the time. A large chunk of the remaining features will only be used 20% of the time. We can apply this principle to development time. Using it, we can deduce that if it takes us about 10 months to build a product, in 2 of those months we will be able to develop 80% of the features. Thus it would take us about 8 months to solve the remaining 20% of the most complex and difficult features. This leads us to ponder: will people use these features? Are they really indispensable?

Say we manage to identify the most important features, and we keep them as simple as we can. Wouldn’t we be able to dispense with 8 months of work and deliver a highly effective product in 2 months only? We already know that 20% of our effort will produce 80% of our results. Wouldn’t it be worthwhile to sit for a moment and think for a bit about what we should devote our time to? I’m sure it would.

You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).

Book on Scrum: Agile 101, Practical Project Management
Agile 101 – Practical Project Management

Translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt.

Publicado en Blog, Blog 1, English | Etiquetado , , | Deja un comentario

Keep it Simple from Agile 101 book

Publicada el octubre 9, 2016 por antoniomartel
Some time ago, I had a conversation with an IT colleague, about the sector nowadays. Something reminded me of an Andrés Diplotti cartoon I’d seen on Google+. In it you could see a client reviewing the application that the programmer had delivered. The client says : “It’s all fine, but I don’t see a Cancel button”. The programmer replies: “I don’t program for cowards who cancel at the last minute.”
I’ve been a programmer for a long time. I’m still a programmer, in part. So I can recognize this kind of arrogance (maybe not to that extent). I suppose that it’s a sin of my youth, a brashness that’s been mellowing with age and that some of us already felt in college.
Back then I had just discovered software-design patterns in the book The Gang of Four. Our applications started to be filled with design patterns, the more the better. It looked like we were in some sort of contest. We had to see who used the most obscure, complex pattern —the one that would be the hardest to understand. With this in mind, I can understand the posts and articles I read now. They discuss refactoring old code to get rid of design patterns, and about how expensive it is for some projects.
As the years have gone by, I have suffered the KISS principle (Keep it Simple, Stupid) in my own flesh.  Not just with patterns, but also with the customization of on-screen graphic components. Or with “phantom requirements.” This is a term I once heard from a fellow worker. It refers to those features that no one has requested, but that you consider important for your clients. Things that “most probably” they’ll end up needing. It’s the malady known as featuritis. It makes us think that the more features or characteristics our app has, the more valuable the client will find it.
A long time ago, a client’s project manager commented that someone on another work team had told him that a feature he wanted was impossible. I told him that practically everything can be done, provided enough time is spent on it. I wasn’t clear enough. I should have added: but is it reasonable to use all that time for that feature? You can use practically any programming language to send a rocket to the Moon. But, do you really want to go to the Moon, or do you want a finished app by the deadline?
So, you are saying that my design is too complex?


You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).

Book on Scrum: Agile 101, Practical Project Management
Agile 101 – Practical Project Management

Translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt.

Publicado en Blog, Blog 1, English | Etiquetado , , | Deja un comentario