[#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

[#ALMRANGERS] Version Control Guide V3 (antes conocida como Branching and Merging Guide)

Hola!

 

Después de darles bastantes vueltas al asunto, los rangers han liberado una nueva versión de la guía de Branching y Merginng, o con su nuevo nombre: “Version Control Guie V3”. Est guía en realidad es un paso adelante en el camino de una filosofía no basada en regla sino en recomendaciones y buenas prácticas, luego cada equipo es lo suficientemente maduro para elegir el mejor camino.

Por ejemplo, ¿recuerdas mi post sobre no usar ramas en tu equipo de desarrollo? Lamentablemente eso fue lo que muchos entendieron del post, cuando en realidad el objetivo del post era intentar simpliicar el trabajo de un equipo implementando solo aquello que de valor a la solución sobre la que se trabaja … que me enrollo. Pues mira como empieza esta guía.

image

Impresionante! la guía recomienda comenzar sin una estrategia de branching, a partir de allí la solución emergerá con el tiempo.

Joyas como estas tiene varias dentro, la verdad es que RECOMIENDO LEER LA GUÍA, ahora se ha convertido en un excelente ejercicio para saber si vamos por el buen camino.

Descarga: http://vsarbranchingguide.codeplex.com/

Saludos @ Camino a Niza

El Bruno

imageimageimageGoogle

[#VS2013] Productivity Power Tools 2013, Welcome to Syntactic Lines!

Hello!

If you’re like me and changes your source code editor font size to 8 points, to see “more code” at a single glance, surely this new feature of the Productivity Power Tools 2013 will be good for you.

It is called Syntactic Lines and what it does is reduce by 25% the size of lines in which there is neither letters nor numbers. In this way, “simple” lines of our code are smaller and the code is more readable. (or tighter, to choose)

This is the official example presenting

image

Look interesting, I will see after using it a bit if it is really useful:

Download: http://visualstudiogallery.msdn.microsoft.com/dbcb8670-889e-4a54-a226-a48a15e4cace?SRC=VSIDE

Saludos @ Home

El Bruno

image image image Google

[#VS2013] Productivity Power Tools 2013, Welcome to Syntactic Lines!

Hola!

Si eres como yo de poner el tamaño de la fuente en 8 puntos, para poder ver “más código” de un único vistazo, seguramente esta nueva funcionalidade de las Productivity Power Tools 2013 te gustará.

La misma se llama Syntactic Lines y lo que hace es reducir un 25% del tamaño de las líneas en las que no haya ni letras ni números. De esta manera, las líneas “simples” de nuestro código quedan más pequeñas y el código queda más legible. (o más apretado, a elegir)

Este es el ejemplo oficial que presentan

image 

Pinta interesante, veré después de usarlo un poco si es realmente útil :

Descarga: http://visualstudiogallery.msdn.microsoft.com/dbcb8670-889e-4a54-a226-a48a15e4cace?SRC=VSIDE

Saludos @ Barcelona

El Bruno

image image image Google

[#ALM] #SCRUM, the #Atleti and the Cholo

image

Hello!

If you don’t like soccer / football I recommend that you keep not reading this post. Although we must differentiate between people who don’t like football and people who are “anti-football”. The people of the 2nd group are characterized by trying to impose their vision in any place and with any group of people (against the football of course). To this group I’ll always choose the option “Live and Let Die“. If you are the first maybe the post can get to you, if you’re of the 2nd you know Winking smile

This weekend the club Atlético de Madrid was proclaimed champion of the Spain Football League. After 10 years of domain of Real Madrid and Barcelona, we get to a point where a “small club” to win the most long and complicated competition. When I say “small” I do not mean the number of followers, but rather the economic capacity that reinforces this club. The large ones can invest millions year to year, it is very likely that Atletico Madrid has to sell any of their good players to be able to start the new campaign. (Let us not forget that football tries to be a noble sport, governed by the amazing capitalism laws)

The last thing I want to say, to put a bit of context is that equipment which has today the Atleti, is almost the same as your technician found almost 2 years (January 2012). At that time the team was going through a hard time. They were about to go to a worst category, they were out of the Copa del Rey and the morale of the Team was on the floor. Until Diego Pablo Simeone, also known as “El Cholo” arrives to the club.

I’m not into the club and I do not know El Cholo, but from the outside what is appreciated is that beyond working on the structure of the club, and invest in new signings, new faces or new forms; El Cholo decided to invest in the team, invest on people. They adopted an attitude of improvement in the field defined by a very simple and yet very powerful phrase: “we play match-by-match“. Not asked their players anything weird, just play the best they know in every match. And this result you can see 16 months later. I don’t think that anyone can find a more dedicated team than the Atleti. Their players play every game like it is the last game of their live. This probable make other clubs who have invested hundreds of millions in signings rethink if the right way to have a team is based on €uromillons.

And what does this have to do with Scrum? Does El Cholo make Sprints? Does Mono Burgos perform TDD? Neither one thing nor the other (remember that Scrum does not mean TDD) although if you see clearly, that there are many things that draw attention. For example:

-The plan of El Cholo was never long-term, always has been based on “match to match“. If you like football, surely you’ve noticed how he has been getting the better of each player testing and testing in every game until you have a very balanced and very good staff.

- People are important, and the experience is what is most valued. See today how the Atleti stays by injury with some very important low, however it covers them with others coming back to give the best of themselves. With a defined focus and constant work has allowed that the team is homogeneous and that there are no dependencies of key figures (eye, having a couple of cracks that will be in the history books). This in Scrum is known as adaptation .

-My personal Feeling about El Cholo, when he speaks, is transparency. This is because it would have to be there to meet him. However compared to other clubs, it seems that the Cholo remembers ken Schawber and is based on one of the 3 pillars to carry his campaign forward.

If you see it in perspective, you’ll see that it is just football; and that behind this there is a team with one goal clear. Also if you like the metrics you’ll see that El Cholo numbers are good, but the sensations that gives this team are best. And that is essential in a team, the sense of security that gives the same when it works. Everyone has to have that level of confidence to know that you will arrive on time, with a finished product. The Atleti today makes it, and in a natural way.

It is not SCRUM as we know it, however today the Atleti has emerged champion of the League, and next weekend to play the final of the Champions League in Lisbon with Real Madrid. I believe that the results are sure that more than one will be putting together a model session of team building based on the work of El Cholo Winking smile

PD: El Cholo Simeone once said the following words which explains his results-oriented philosophy: “keep faith, must be conviction, must have courage, have to assume some challenges, because that assumes no risk, and that no risks, no wins”.

References: The SCRUM Guide, https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide-ES.pdf#zoom=100 

Saludos @ Barcelona

El Bruno

image image image Google