#Humor – #SCRUM and #Project

Hola!

Es triste que esto que parece un chiste, sea de verdad // Sadly this seems to be a joke, but sometimes is true

Saludos @ Madrid

/El Bruno

[#OPINION] #Scrum nos explica por que es mejor recibir regalos en Navidad que en Reyes

M

Buenas !!!

Hoy toca escribir algo que a más de uno le sonará muy rebuscado, sin embargo me ahorrará innumerables conversaciones de 5 minutos sobre por qué es mejor recibir los regalos en Navidad y no en Reyes.

Todos los que conocemos SCRUM, sabemos lo importante que es la acción de “aportar valor”. Esta tarea, se lleva a cabo gracias a las aportaciones del Product Owner. Esta persona se encarga de asegurar que el equipo entrega elementos de valor en cada Sprint.

Sobre la premisa anterior también se espera que el equipo aporte valor de forma rápida y se adapte a los cambios. En inglés esta frase se lee mucho mejor “maximizing the team’s ability to deliver quickly and respond to emerging requirements.” (link)

Antes de llegar a la conclusión del título del post, sentemos las bases del escenario:

  • Los regalos de Noche buena / Navidad se reciben en la noche del 24 de diciembre
  • Los Reyes Magos nos dejan sus regalos la noche del 5 de enero
  • Por lo general tenemos vacaciones desde Navidad hasta Reyes. 2 semanas desde el 24 de diciembre hasta el 6 de enero.

Si recibimos los regalos en Reyes y tenemos que volver a trabajar el 7 de enero, pues solo podremos disfrutar de los mismos unas pocas horas. (Esto también aplica a los niños y el colegio que luego de reyes vuelven al cole)

Si en cambio, los regalos los recibimos en Navidad pues de alguna manera podemos afirmar que

  • Santa Claus está aportando algo, mal que mal, cualquier regalo nos pone felices 😀
  • Santa Claus está actuando de forma rápida. No tenemos que esperar 15 días para tener uno o más regalos en nuestras manos. (Importante: 15 días suele ser un sprint!)
  • Santa Claus realmente está aportando valor desde el punto de vista de negocio. Es mucho mejor tener un regalo con tiempo para disfrutarlo 2 semanas, que tenerlo y no poder usarlo

Asi que bien, sobre las bases de SCRUM declaro que, si solo recibiremos un único regalo, es mucho mejor recibir regalos en Navidad que en Reyes.

Obviamente, el mejor escenario de negocio posible es recibir regalos en Navidades y luego también en Reyes … aquí no hace falta SCRUM, un poco de sentido común y egoísmo nos aclaran la mente para esto 😀

Feliz Navidad !!!

Saludos @ El medio del monte en Ávila

/El Bruno

Referencias:

Scrum, http://en.wikipedia.org/wiki/Scrum_(software_development)

[#SCRUM] Y el delicado camino a la incompetencia

Hola!

Todos sabemos que Scrum es la solución a todos los problemas. En la página 12 de la guía de Scrum hay una frase que dice lo siguiente:

Scrum Hoch bIquv qay’ taS

Que traducido del Klingon viene a significar

Scrum es la solución para todo tipo de problemas

Y listo! Ahora bien, si analizamos los 3 pilares de Scrum: Transparencia, Inspección y Adaptación; los mismos nos indican que un equipo a medida que utiliza Scrum, aprende a ser más eficiente. La base de esta teoría es que el equipo sea independiente y tenga capacidad de autogestión.

Sin embargo, esto último también puede terminar con un efecto boomerang: Un equipo puede ir a peor ejecutando Scrum. Y es que, no todos las personas que trabajan en nuestro rubro cumplen con la premisa de “Scrum no es para aficionados”.

Es normal que un equipo, cuando comienza a gestionarse, los resultados no sean los esperados. Es ese punto donde la inspección y adaptación ayudan a que el equipo pueda comenzar a mejorar. Sin embargo, también existe la posibilidad de que un equipo nunca mejore. Que siempre el listón este muy bajo y que no exista un análisis interno de inspección y adaptacion. (Aclaración: en estos casos la transparencia suele estar cercana al 95% de opacidad)

¿Y qué hacer en estos casos? Una opción es volver a dar soporte al equipo, que popularmente lo comparo con criar niños de 3 años. Ayudar en cada paso, ser el facilitador, etc. Un poco de Scrum Master con el rol de padre. Y hasta aquí debes llegar, luego de un par de Sprints es momento de volver a evaluar si el equipo es autosuficiente. En caso contrario … pues cambia el equipo.

Es una pena, sin embargo la motivación con la que algunas personas llevan adelante su trabajo no es la misma que la que tienen otras. Y en el caso de los trabajos con tecnología esta motivación suele ser intrínseca, con lo que los “premios a corto plazo” son una tapadera muy poco productiva.

Una forma de explicar esto es la práctica de “El que rompe la build pone 1€ en un frasco”. El objetivo de práctica no es asustar para que los developers se desangren poniendo miles de €uros (yo lo he hecho), ni tampoco es recaudar para las cervezas de los jueves (también lo he hecho). Esta práctica implica un trabajo de fondo, donde cada persona es suficientemente consciente de que la calidad no es opcional y de que romper la build es detener el equipo en marcha. Y esto es suficiente, muchas personas lo entienden, otras lo ven como una gracia.

Asi que bien, Scrum puede servir para que los equipos aprendan a autogestionarse y a mejorar sprint a sprint; y también sirve para detectar equipos que no poseen ganas de mejorar y .. bueno que tal vez sea necesario cambiar.

 

Scrum Guide: https://www.scrum.org/Scrum-Guide

Scrum no es para aficionados: https://elbruno.com/2013/12/24/scrum-scrum-no-es-para-aficionados/

Saludos @ Home

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

[#ALM] #SCRUM, el #Atleti y el Cholo

image

Hola!

Si no te gusta el futbol te recomiendo que no sigas leyendo este post. Aunque hay que diferenciar a los que no les gusta el futbol y a los que son “anti-futbol”. Las personas del 2do grupo se caracterizan por intentar imponer su visión en cualquier sitio y con cualquier grupo de personas en contra del futbol. En mi caso, “Live and Let Die” como dice la canción. Si eres de los primeros tal vez el post te interese, si eres de los 2dos pues ya sabes Winking smile

Este fin de semana el Atlético de Madrid se ha proclamado campeón de la liga de futbol en España. Después de 10 años de dominio del Real Madrid y del Barcelona, ha aparecido un club “pequeño” para llevarse la competición a largo plazo más complicada. Y ojo, que cuando digo pequeño no me refiero al número de seguidores, sino más bien a la capacidad económica que refuerza este club. Así como los grandes pueden seguir invirtiendo millones campaña a campaña, es muy probable que el Atlético de Madrid, tenga que vender a alguno de sus jugadores para poder comenzar la nueva campaña. (No nos olvidemos que el futbol intenta ser un deporte noble, regido pora las fabulosas leyes del capitalismo)

Lo último que quiero comentar, para poner un poco de contexto es que el equipo que tiene hoy el Atleti, es casi el mismo que encontró su técnico hace casi 2 años (enero de 2012). En ese momento el equipo estaba pasando por un mal rato. Estaban a punto de descender, fuera de la copa del rey y con la moral sobre el piso. Hasta que llegó Diego Pablo Simeone, también conocido como “El Cholo”.

No estoy dentro del club y no conozco al Cholo, pero desde fuera lo que se aprecia es que más allá de trabajar sobre la estructura del club, e invertir en nuevos fichajes, nuevas caras o nuevas formas; el Cholo decidió invertir en el equipo. Adoptó una actitud de mejora en el campo definida por una frase muy simple y a la vez muy potente: “jugamos partido a partido”. A sus jugadores no les pidió nada extraño, solo que jueguen lo mejor que saben. Y ese resultado se puede apreciar 16 meses después. No creo que nadie pueda encontrar un equipo más dedicado que el Atleti. Lo que corren sus jugadores en cada partido, hace que otros clubes que han invertido cientos de millones en fichajes se replanteen si la forma correcta de tener un equipo es a base de €uromillones.

Ya, ¿y esto que tiene que ver con Scrum? El Cholo hace Sprints? El Mono Burgos hace TDD? Ni una cosa ni la otra (recuerda que Scrum no significa TDD) Aunque si lo ves con claridad, sí que hay muchas cosas que llaman la atención. Por ejemplo:

– El plan del Cholo nunca fue a largo plazo, siempre se ha basado en “partido a partido”. Si te gusta el futbol, seguro que te has dado cuenta de cómo ha ido sacando lo mejor de cada jugador probando y probando en cada partido hasta tener una plantilla muy equilibrada y muy buena.

Las personas son lo importante, y la experiencia es lo que más se valora. Hoy vemos cómo el Atleti se queda por lesión con unas bajas muy importantes, sin embargo cubre las mismas con otras personas que vuelven a dar lo mejor de sí. El trabajo constante y con un foco definido ha permitido que el equipo sea homogéneo y que no haya dependencias de figuras claves (ojo, que tienen un par de cracks que quedarán en los libros de historia). Esto en Scrum se conoce como Adaptación.

– La sensación que da el Cholo, cuando habla, es de Transparencia. Esto es relativo porque habría que estar allí para conocerlo. Sin embargo comparándolo con otros clubes, parece que el Cholo se acuerda de ken Schawber y se basa en uno de los 3 pilares para llevar adelante su campaña.

Si lo ves con perspectiva, verás que es simplemente futbol; y que detrás de esto hay un equipo con un objetivo en claro. Además si te gustan las métricas verás que los números del Cholo son buenos, pero las sensaciones que da este equipo son mejores. Y eso es fundamental en un equipo, la sensación de seguridad que da el mismo cuando trabaja. Todos tienen que tener ese nivel de confianza para saber que se llegará a tiempo, con un producto terminado. El Atleti hoy lo hace, y de una forma natural.

No es SCRUM como lo conocemos, sin embargo hoy el Atleti ha salido campeón de la liga, y el próximo fin de semana juega la final de la Champions League en Lisboa con el Real Madrid. Creo que los resultados saltan a la vista y seguro que más de uno estará armando un modelo de sesión de team building basado en el trabajo del Cholo Winking smile

PD: El Cholo Simeone una vez dijo las siguientes palabras que dejan clarauna filosofía de trabajo orientada a resultados: “hay que tener fe, hay que tener convicción, hay que tener coraje, hay que asumir ciertos desafíos, porque el que no asume no arriesga, y el que no arriesga, no gana”.

Referencias: La Guía de SCRUM, https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide-ES.pdf#zoom=100

Saludos @ La Finca

El Bruno

image image image Google

[#ALM] SCRUM does not mean TDD

Hello!

A few years ago the beginning of this post would be something like this:

In the world of software development doesn’t surprise me…

However, more and more I am realizing that today the beginning should be something like this:

Try to continuous improve the way of work in a team is important so …

Why? A few days ago, I was part in a twitter thread where I tell that TDD is not necessary / mandatory in the development of the software. I know, incendiary bomb. In the thread participated some very skilled people like @jc_quijano @ialcazar @juanmagomer @lfraile @r_corral; so I decided to contribute with my point of view so I low the level a little. At the end I mentioned Rodrigo’s post which opened mi mind almost 9 years ago “quality is not optional in the software development“.

At the end the question of why I said that there was no need to do TDD was not answered, so here it goes.

SCRUM is great, no? We all agree on that. When you start to believe in SCRUM you realize that is an empirical framework; everything is based on learning from experience. From this on is necessary confidence and trust in a team, that means transparency. And when you have these 2 pillars; you can begin with inspection and then adaptation based on what you learned from the experience.

I recently was talking about how to improve the work in a Marketing team; and after knowing the context and suggest SCRUM as a framework so they can organize their work; I have the great satisfaction seeing that this group of people start to develop their own scheme of work. While we respected SCRUM roles and artifacts, based on the experience and knowledge sharing across the Group, it began to self-management to achieve a common goal .

This is the experience that I thought sharing to a brutal and assertive phrase:

WHERE ARE TDD THE IN A MARKETING TEAM? EHHHH WHERE?

Thus all uppercase with an exceeding of the Doctor House arrogance. But as always the reality I put on my site shortly after.

This week I was not lucky enough to be in the BUILD, so I decided to go and learn about the world of Health. Specifically to comment on how some aspects of mobility and innovation will change the way in which we work in this world in the future.

And in that context, speaking with a person responsible for a hospital, dropped me the following sentence: “we have the best professionals in the world, and perhaps the best tools for them. It should be a 100& effective team and yet most of the errors we have are caused by people.”

How many times we heard this? many and the world of software development we do is… TDD! (well it is an option, the other is simply do the thing well from the beginning). This person was very receptive and with a very open profile, so I told him about the basis of TDD. In a short time, this person took the concepts of TDD and start think in how he can apply them in every day’s work inside the hospital.

Note: You probably know that the one of the first places where a TDD approach was implemented, was in NASA in the 1950s and 1960s, to ensure that materials they received from external manufacturers met the standards that they defined?

I was stunned! And I realized that even SCRUM is born of a concept that has nothing to do with the development of software, it comes from phase in a RUGBY match, where a part of the team put all the strength together and try to push to the same direction.

So, after giving back to the topic, I think that perhaps the title of the post should be something like

SCRUM does not imply you do TDD; It involves a team to define the best way of working.

Surely in software development, this will involve TDD; in other disciplines… because you see your knowledge.

PD: if any not had noticed, the word TEAM is one of the most important in Team Foundation Server, no?

Saludos @ Home

El Bruno

image image image Google

[#AVANADE] Avanade teams up with Scrum.org !!!

Hello!

Last Friday, in the #CommunityDay14 I was very very temped to tell everyone about this news. I spend some time with Luis Fraile, Rodrigo Corral, Vicent Alves, JC and others and it was very hard not comment anything about his.

Now, after several years of work in conjunction between Avanade and Scrum.org, we have reached an agreement in order to have an Agility Path inside Avanade. This has many flavors, however what I can personally highlight is that working with people of Scrum.org is is a pleasure but is not easy. This agreement is deeply inside Avanade, on topics such as collaboration, training, certifications, etc. Do this in a company of 20000 employees, I assure you that it is not an easy task, but again Scrum.org people are very commited to Scrum so they support is amazing.

But the result is 100% rewarding today!

More informacion: http://www.avanade.com/us/about/avanade-news/press-releases/Pages/avanade-teams-with-scrum-org-to-improve-software-development-page.aspx

Saludos @ Home

El Bruno

image image image Google

[#AVANADE] Avanade teams up with Scrum.org !!!

Hola!

Por dios … el viernes en el #CommunityDay14 me estuve comiendo las uñas al lado de grandes como Luis Fraile, Rodrigo Corral, Vicent Alves, JC y otros para no comentar la noticia.

Ahora sí, después de varios años de trabajo en conjunto con Scrum.org, hemos llegado a un acuerdo para poder tener un Agility Path dentro de Avanade. Esto tiene muchos matices, sin embargo lo que personalmente puedo resaltar es que trabajar con la gente de Scrum.org no es fácil, es un placer pero no es fácil. Este acuerdo toca a Avanade desde adentro, en temas como colaboración, training, certificaciones, etc. Hacer esto en una empresa de 20000 empleados, les aseguro que no es una tarea fácil.

Pero el resultado hoy es 100% GRATIFICANTE !!! después de muchos años de conversaciones (los que conocen las grandes corporaciones sabrán apreciar esto más que nadie)

Saludos @ Home

El Bruno

image image image Google

[#SCRUM] SCRUM is not for amateurs

Hello!

After a couple of talks in Cordoba on how to build software, I ended up recalling a phrase, shaerd to me by Edu about scrum 

SCRUM is not for amateurs

Important stuff > EDU now got the PSD, so whenever we talk about this stuff he brings me back to a lot of concepts that I‘ve to apply in daily basis. When we talk about Scrum and constant improvements, we always assume people who are part in a team have to use the best tools available and apply the best practices to build software.

The best tools are achieved with €uros or dollar$, and that part is easy. But to know and apply the best practices requires time and dedication, and that is something you don’t find in everyone. A good professional takes time to improve his role and the way he works. In a team that practices SCRUM, it is strange to have to explain the basis of good practices to your teammates. Much more common is that someone comes up with a new idea, share it with the team and then is the team that decides whether it is feasible to implement.

This is also the basis that in a team that practices SCRUM “classic architectures” is not defined, architecture emerge as improvements are added to the product being built. And of course, all of this is given by 2 fundamental premises

  • Only that which brings value to the product that builds should be built
  • We must avoid adding features that are not necessary

A bad example to mention is the classic moment where we add functionality to the product that we do not need. For example, we prepare an application to support multiple languages or multiple cultures, because we know that it is very likely that in a couple of months your application needs this functionality. We also know that if we apply these changes now, it will be much easier to implement them. The error at this point is to assume that this road is viable, when in reality only we must build ONLY what is approved and within the SPRINT BACKLOG. If we have doubts about, the PO is the figure that we must address this issue.

But well, now I’m getting more in how team SCRUM as in the phrase with which we must stay

SCRUM is not for amateurs

Merry Christmas!

Greetings @ La Rancherita

El Bruno

imageimageimageGoogle

[#SCRUM] Scrum no es para aficionados

Hola!

Después de un par de charlas en Córdoba sobre cómo se construye software terminé recordando la frase de SCRUM que me dijo el Edu el otro día

SCRUM no es para aficionados

Ahora que el EDU ha sacado el PSD, cada vez que hablamos me sirve de recordatorio de un montón de conceptos, que no aplicamos en el día a día. Cuando hablamos de SCRUM y de la mejora constante, siempre asumimos que las personas que forman un equipo utilizan las mejores herramientas y las mejores prácticas para construir software.

Las mejores herramientas se consiguen con €uros, esa parte es fácil. Pero para conocer y aplicar las mejores prácticas hace falta dedicación, hace falta que cada persona dedique tiempo a mejorar como profesional. En un equipo que practica SCRUM, es extraño tener que explicar las bases de buenas prácticas a tus compañeros. Es mucho más usual que una persona llegue con una idea nueva, la comparta con el equipo y que luego sea el equipo el que decida si es viable de implementar.

Esta también es la base de que en un equipo que practica SCRUM no se definen las clásicas “arquitecturas”, la arquitectura emerge a medida que se agregan mejoras al producto que se construye. Y claro, todo esto viene dado por 2 premisas fundamentales

  • Sólo se debe construir aquello que aporte valor al producto que se construye
  • Hay que evitar agregar features que no sean necesarias

Un mal ejemplo a mencionar es el clásico momento donde agregamos una funcionalidad al producto que no necesitamos. Por ejemplo, preparamos una aplicación para que soporte múltiples idiomas, porque sabemos que es muy probable que en un par de meses la aplicación necesite esta funcionalidad. Además sabemos que si aplicamos estos cambios ahora, será mucho más fácil implementarlos. El error en este punto es asumir que este camino es viable, cuando en realidad SOLO DEBEMOS CONSTRUIR LO QUE ESTE APROBADO POR EL PO Y DENTRO DEL SPRINT BACKLOG. Si tenemos dudas al respecto, el PO es la figura con la que debemos solucionar este tema.

Pero bueno, ya me estoy adentrando más en como funciona el equipo de SCRUM que en la frase con la que debemos quedarnos

SCRUM no es para aficionados

Feliz Navidad !!!

Saludos @ La Rancherita

El Bruno

image image image Google