[#ALM] 3 Sprints, that’s what you need to get a team started seriously (and of course … let’s go Argentina!)

image

Hello!

This year, I’ve combined events oriented to developers, with a more business-oriented events. The difference is large, but it is amazing when you start talking to “the boss” of a hospital and explains a framework like SCRUM. He understands the basis and, in 15 minutes later, we can begin to talk about how transparency can help him in his daily basis.

Note: “the boss” is his personal presentation, this person is the director of a hospital and as has a title like CTO, CIO, CEO, CXXXXO the truth that tide.

In the middle of the nice talk, he asked me a classic of team management,

How long it takes a team to “start working well” under this framework?

The question has history. In general, to run a framework like SCRUM , the team that adopts this framework must implement it correctly. However, it is almost more important than the organization / company or context within which the team works also creates and adopts the values of SCRUM. I ever wrote about in an organization is harder to SCRUM for that SCRUM out in.

image

Having said that, and having a team that understand and adopt the values and practices of SCRUM, most experts agree that 3 sprints is the ideal amount of time in which a team can measure their work and begin to be productive. This is separate from the duration of the sprint, it can be from 1 week to 4 weeks. The important thing is that the practices associated with it are met and that the retrospectives are carried out well, POs to understand its value at the moment of arming and prioritized Product Backlog, etc. If you’ve been able to work in a team during more than 3 Sprints, you’ll see how metrics like “velocity” really starts to make sense and as the pace of work of the team begins to be more dynamic.

Returning to business events, this week I was in Nice at an event aimed at telecommunications companies. And once again, I was surprised to see as in the TELCO world, measurement of 3 weeks also applies to these types of projects. I was commenting on a similar theme with some people who are dedicated to create a layer of… software? on a “very special routers”, and at the time raised the possibility of posting their APIs on AZURE API Management, agree on how a complete cycle of several Sprints would need to start to have a serious idea of a co-ordinated team.

image

Now is time for me, so I can “cry a little” in my particular case. I work on very fast / short projects, and where the same objective carried out by more than 3 Sprints is an utopia. Another utopia is to think in the same team working more than 3 consecutive sprints (I call them elastic teams).

My experience in this particular case is based on the following:

  • Even if people can change in a team, it is important to have one or more people who bring forward best practices learned during the history of the team. Never, I repeat never, you should completely change the members of your team.
  • People can change, but the lessons remain. Implement a Wiki or a similar repo is important. In our case, what works is a OneNote shared in OneDrive, for us this brings very good results.
  • Unless you know the consequences, do not force or twist best practices. For example, if you decide not to implement a CI cycle, you must be aware of the consequences that this brings. In my case I have learned these lessons badly and pulling long hours during nights out personal errors later. Now that I know the context and I know what I stand, a Scrum Master helps me to carry them out.
  • It is essential that the Definition of Done, DOD is very clear for all: team, Product Owner, cleaning lady and even your mother. The equipment change, the user stories evolve, but the quality of what is expected to deliver cannot be changed .
  • It is not a bad practice to change the DOD. You can only do this between Sprints, never should change a DOD in the midst of a Sprint.
  • Technical debt (Technical Debt) is something that I still don’t have a good advise to share. I know that there are parts of a solution where I’m sacrificing today to pay it tomorrow, and also at certain times forced us as a team to not sacrifice nothing. I have not clear. (I think I expressed it in the best way for 3 years in painting walls, changing diapers, and the technical debt)
  • Finally and fundamental, it drives the fluid inside your team communication. Using tools such as Skype or Lync, tries to be mostly face to face, etc. Unless you’re programming SKYNET, surely you’ll be creating an app for people, and work with people… all said no?

Happy Sprinting!

Incidentally, in a few days the WorldCup will start so VAMOS VAMOS ARGENTINA!

image

 

Saludos @ Home

El Bruno

image image image Google

[#ALM] 3 Sprints, eso es lo que necesitas para poder comenzar a ser “serios” (y claro … vamos vamos Argentina !!!)

image

Hola!

Este año, he combinado eventos orientados a developers, con eventos de un calibre más orientado a negocios. La diferencia es grande, sin embargo es increíble como puedes hablar con “el jefe” de un hospital y que vea un framework como SCRUM, que entienda las bases y que en 15 minutos podamos comenzar a hablar sobre como la transparencia puede ayudarle en su día a día.

Nota: lo de “el jefe” es por su presentación personal, resulta que esta persona es el director de uno de los hospitales de más renombre en Europa y tanto CTO, CIO, CEO, CXXXXO la verdad que marea.

Pues eso, que hablando con esta persona me preguntó un clásico de la gestión de equipos,

¿Cuanto tarda un equipo en comenzar a “trabajar bien” bajo este marco?

La pregunta tiene historia. Por lo general, para que un marco como SCRUM funcione, el equipo que adopta este marco debe implementarlo correctamente. Sin embargo, es casi más importante que la organización / empresa o contexto dentro del que trabaja este equipo también crea y adoptelos valores de SCRUM. Alguna vez escribí sobre cómo en una organización es más difícil SCRUM para adentro que SCRUM para afuera.

image

Dicho esto, y teniendo un equipo que comprenda y adopte los valores y prácticas de SCRUM, la mayoría de los expertos coinciden que 3 sprints es la medida ideal a partir de la cual, un equipo y su contexto comienzan a ser productivos. Esto es idependiente de la duración del sprint, puede ser 1 semana o 4 semanas; lo importante es que las prácticas asociadas al mismo se cumplan y que se realicen bien las retrospetivas, que los POs comprendan su valor al momento de armar y priorizar el Product Backlog, etc. Si has podido trabajar en un equipo durante más de 3 Sprints, verás como la métrica de la velocidad realmente comienza a tener sentido y como el ritmo de trabajo del equipo comienza a ser más dinámico.

Volviendo a eventos de negocio, esta semana estuve en Niza en un evento orientado a empresas de Telecomunicaciones. Y una vez más, me sorprendí al ver como en el mundo de las TELCO, la medida de 3 semanas también se aplica para esos tipos de proyectos. Estuve comentando un tema similar con unas personas que se dedican a crear una capa de … ¿software? sobre unos “routers muy especiales”, y al momento de plantear la posibilidad de publicar sus APIs sobre AZURE API Management, coincidimos en cómo sería necesario un ciclo completo de varios Sprints para poder comenzar a tener una idea seria de un equipo coordinado de trabajo.

image

En este momento me tocaría “llorar un poco” por mi caso particular. Donde trabajo en proyectos muy rápidos, y donde un mismo objetivo llevado adelante por más de 3 Sprints es una utopía, y ni hablar de un mismo equipo trabajando más de 3 sprints seguidos (equipos elásticos les llamo yo).

Mi experiencia para este caso particular me baso en lo siguiente:

  • Si bien las personas cambian, es importante tener una o más personas que sean las que lleven adelante las buenas prácticas aprendidas del equipo. Nunca, repito NUNCA, deberías cambiar por completo los integrantes de tu equipo.
  • Las personas cambian, pero las lecciones quedan. Implementar una Wiki o un repo similar es importante. En nuestro caso, lo que tnemos es un OneNote compartido en OneDrive y la verdad es que da resultados muy buenos.
  • A menos que conozcas las consecuencias, no fuerces las buenas práctias. Por ejemplo, si decides no implementar un ciclo de CI, debes ser consciente de las consecuencias que ello trae. En mi caso he aprendido estas lecciones de mala manera y tirando muchas horas durante noches para sacar adelante errores personales. Hoy que conozco el contexto y sé a lo que me atengo, un Scrum Master me ayuda a llevarlos adelante.
  • Es fundamental que la defnición de hecho (Definition of Done, DOD) esté clara para todos, equipo, Product Owner, la señora de la limpieza e inclusive para tu madre. Los equipos cambian, las user stories evolucionan, pero la calidad de lo que se espera entregar NO PUEDE CAMBIAR.
  • Tampoco es una mala práctica cambiar el DOD. Eso sí, solo entre Sprints, nunca debes cambiar un DOD en medio de un Sprint.
  • La deuda técnica (Technical Debt) es algo con lo que todavía no me centro. Sé que hay partes de una solución donde estoy sacrificando hoy para pagarlo mañana, y también en determinados momentos nos obligo como equipo a no sacrificar nada. No lo tengo claro. (creo que lo expresé de la mejor forma hace 3 años en Pintando muros, cambiando Pañales, y la Deuda Técnica)
  • Por último y fundamental, impulsa la comunicación fluida dentro de tu equipo. Utiliza herramientas como Skype o Lync, intenta que sea en su mayoría face to face, etc. Salvo que estes programando SKYNET, seguramente estarás creando una app para personas, y trabajas con personas … todo dicho no?

Happy Sprinting !!!

Por cierto, empieza el mundial en unos días asi que VAMOS VAMOS ARGENTINA !!!

image

Saludos @ Home

El Bruno

image image image Google