[#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] Agile Customers are a #MustHave (and of course this to use Microsoft Feedback Client)

Hello!

Yesterday I make a statement: if we want to have visible results, the first distinction that we have to do; is not to be oriented in the technology trend (or architecture or development roles) but instead try to create a context orientated to the business itself; in this team work you’ll fin customers and the agile team. And of course, very a important part of it are clients or customers.

Caution! we should not confuse these roles with the Product Owner we know of SCRUM. According to the Guide, PO is the main author of the User Stories, he manages the Product Backlog, he defines the priority of the stories, he defines the acceptance tests, and he approves the work carried out by the Agile Team. However, that is not a “real customer”; a true customer is involved in an early stage and he is the one who detects a problem or a need and which will use the final solution created by the team. In an Agile Team it is very important to involve a person with the knowledge of business from day one, but the question always remains: Is this person a real reflection of a client?

Note:My short experience has taught me that when more time working with these experts from business, more we begin to know the business and can improve our solution. The tradeoff is that these SMEs also begin to learn how an Agile Team and are adapting to the team practices. This is not bad, however it can be counter-productive if not is valid with the other “clients”.

My answer to this is: The solution to meet an end customer, does not go through involving all clients within the development team, but instead think to plan some type of activity to obtain feedback from them. The concept of Agile Customer implies that we work partially with an on-site Customer (that in the long run you end up making the Product Owner and if you have good luck this work is not in part but full time). As an addition to this concept I would like to add the following activities

  • In a Sprint Review, integrate not only the familiar faces of the project; It tries to involve new people. At a previous session or at the beginning of the meeting, you spend time to explain the purpose of the Sprint Review and the dynamics of work; and he tries to get his feedback during the same.
  • Remember the 2 fundamental premises related to dealing with customers
  • Do not implement anything that has not been approved by a client
  • Nobody can replace an end user of the application
  • Use tools such as “Request Feedback” from Team Foundation Server or Visual Studio Online to engage these people and have a frequent Feedback on the progress of the application.

    image

    Finally, remember that while change is a constant, a closed version depends on the capacity that we have to manage the expectations of our customers. Be honest and be solution a success.

    References: If you want to know more about Microsoft Feedback Client you can see my posts here.

  • Saludos @ La Finca

    El Bruno

    image image image Google

    [#ALM] Welcome to Agile Customers (y porque no, Microsoft Feedback Client)

    Hola!

    Ayer quedó claro que, si queremos tener resultados visibles, la primera distinción que debemos realizar no tiene que estar orientada hacia la tecnología (o arquitectura o roles de desarrollo) sino al contexto donde se creará la solucion; este contexto está formado por customers y por el equipo de trabajo. Una parte muy importante de la misma son los clientes o customers.

    Ojo, no debemos confundir a estos roles con el Product Owner que conocemos de SCRUM. Según la guía el PO es el principal autor de las User Stories, maneja el Product Backlog, define la prioridad de las historias, define los tests de aceptación y aprueba el trabajo realizado por el Agile Team. Sin embargo, ese no es el “cliente”; el verdadero cliente es el que en un estadio inicial detecta un problema o necesidad y es el que utilizará la solución final creada por el equipo. En un Agile Team es muy importante involucrar a una persona con los conocimientos de negocio desde el día cero, pero siempre queda la pregunta: ¿es esta persona un real reflejo de un cliente?

    Nota: Mi corta experiencia me ha enseñado que cuando más tiempo trabajamos con estos expertos de negocio, más comenzamos a conocer el negocio y podemos mejorar nuestra solución. La contrapartida es que estos SMEs también comienzan a conocer como funciona un Agile Team y se van adaptando a las prácticas del equipo. Esto no es malo, sin embargo puede resultar contraproducente si no se valida con los demas “clientes”.

    La solución para conocer a un cliente final, no pasa por involucrar a todos los clientes dentro del equipo de desarrollo, pero si planificar algún tipo de actividad para obtener feedback de los mismos. El concepto de Agile Customer implica que trabajemos de forma parcial con un On-Site Customer (que a la larga se termina convirtiendo en el Product Owner y si tienes mucha suerte este trabajo no es en forma parcial sino full time). Como un adicional a este concepto me gustaría agregar las siguientes actividades

    • En una Sprint Review, no solo incorpores las caras conocidas del proyecto; intenta involucrar a nuevas personas. En una reunión previa o al principio de la reunión, dedica un tiempo para explicarle el objetivo del Sprint Review y la dinámica de trabajo; e intenta obtener su feedback durante el mismo.
    • Recuerda las 2 premisas fundamentales relacionadas con el trato con los clientes
    • NO IMPLEMENTES NADA que no haya sido aprobado por un cliente
    • NADIE puede sustituir a un usuario final de la aplicación
  • Utiliza herramientas como “Request Feedback” de Team Foundation Server o Visual Studio Online para involucrar a estas personas y tener un Feedback frecuente sobre el avance de la aplicación.
  • image

    Para finalizar recuerda que si bien el cambio es una constante, una versión cerrada depende mucho de la capacidad que tengamos de manejar las expectativas de nuestros clientes. Se honesto y la solución seá un éxito.

    Referencias: Si quieres saber más sobre Microsoft Feedback Client puedes ver mis posts aquí.

    Saludos @ La FInca

    El Bruno

    image image image Google

    [#ALM] Do you really need roles in a team? (usually not)

    Hello!

    Today I’m going to avoid the intro and some context and I’ll go directly to the question:

    Are necessary roles in an Agile team ?

    The answer is simple: Yes. But they are not roles that usually people know, there are only 2 roles in a single Agile Team

    • Some people with a problem
    • An Agile Team with the ability to provide a solution to this problem

    And that’s all. The 1st role is usually known as a client or customer, and is defining the problems or needs that will work the 2nd team. The 2nd team is where lives the usual roles, best-known as front end developer, backend roles developer, analyst, etc.

    The important thing in an agile team is that members should be flexible enough to cover any position. Since the ZERO day, the team should be able to to add value. This does not remove the need for some specialist, in example: a tuning of a databases. This should be be dictated by the evolution of the solution, and if the architecture is emerging from the team, there will not be a problem. (remember discarded classical architects! ))

    And I’ll close with a tip: The next time that you start an agile team, don’t consider the specific capacities of the people in relation to what they can do, but rather keep in mind the capacity that they have to adapt to what comes up. Remember that the only constant in a team change and:

    Agile customers knows that a product can always improve, and also knows that they are responsible for the changes introduced in the product

    Analysts knows that a solution is never complete, the context and the problems tend to change and they must adapt the analysis models as these changes are discovered

    The developers know that we will never write perfect code, so that we refactor the code, we base our code on tests and change the code again and again to improve it

    Happy Teaming Open-mouthed smile !!!

    Saludos @ Home

    El Bruno

    image image image Google

    [#ALM] Son necesarios los roles en un equipo? (usualmente NO)

    Hola!

    Hoy voy a dejar de lado una intro para poner contexto en el post y voy directamente a la pregunta:

    ¿Son necesarios los roles en un equipo Agile?

    La respuesta es simple: SI. Pero no son los roles que usualmente la gente conoce, en un Agile Team solo existen 2 roles

    • Personas con un problema
    • Un equipo ágil con la capacidad de dar una solución a ese problema

    Y ya está. El 1er rol es usualmente conocido como cliente o customer, y es que define los problemas o necesidades sobre las que trabajará el 2do equipo. Dentro del 2do equipo es donde surgen los roles más conocidos como front-end developer, back-end developer, analyst, etc.

    En realidad lo importante en un equipo ágil es que los integrantes sean lo suficientemente flexibles como para poder cubrir cualquier posición. De esa manera, desde el día ZERO el equipo puede comenzar a aportar valor. Esto no quita que en determinados momento sea necesario acudir a un especialista, por ejemplo en una tarea de tunning de bases de datos. Esto suele ser dictado por la propia evolución de la solución, y si la arquitectura es flexible como para emerger a partir del equipo, no será un problema. (recuerda descarta los arquitectos clásicos!)

    Dicho esto, solo queda cerrar con un consejo. La próxima vez que armes un equipo ágil, no tengas en cuenta las capacidades específicas de las personas en relación a LO QUE PUEDEN HACER, sino más bien ten en cuenta la capacidad que poseen para ADAPTARSE A LO QUE SURJA. Recuerda que la única constante en un equipo es el cambio y:

    Los clientes ágiles saben que un producto siempre puede mejorar, y tambien saben que ellos son responsables de los cambios que introducen en el mismo

    Los analistas saben que un análisis nunca está completo, el contexto y los problemas tienden a cambiar y ellos deben adaptar los modelos de análisis a medida que se descubren estos cambios

    Los developers sabemos que nunca escribiremos el código perfecto, es por eso que refactorizamos, nos basamos en tests y cambiamos el código una y otra vez para mejorar el mismo

    Happy Teaming Open-mouthed smile !!!

     

    Saludos @ Home

    El Bruno

    image image image Google

    [#PEBBLE] #UX and Pebble (for simple people like me)

    Hi!

    Marta, a very good friend of mine, is an UX expert. A long time ago she told me a phrase kind of impossible for me. However, if you repeat this phrase to some people you’ll get their attention and some cult, and you’ll become a hipster with beard, Starbucks fun and crazy clothes.

    When you design an app you must try to make the color vibrate and controls breath

    Someone will probably get it, no me. That’s why, when I get my Pebble I know this world is for me. Let me explain

    - no colors, only black and white

    - small resolution = 144 x 168 px

    - a small set of fonts are supported

    - the official design guide suggest the creation of flat apps

    - it also suggest a minimalist approach in the Pebble app design

    So after this, I know Pebble apps are for me! let’s take a look at this one

    image

    This app is the sample app included in chapter 4 of the Pebble UX Design Guide)

    Download: https://developer.getpebble.com/2/design/

    Greetings @ Berlin

    El Bruno

    image image image Google

    [#PEBBLE] Un poco de #UX y Pebble (lo poco que entiendo yo de eso)

    Hola!

    Mi amiga Marta, que de esto de UX sabe y mucho, alguna vez me dijo una frase que no entendí muy bien. Eso sí, si repites esta frase en determinados círculos pareces un experto hipster aficionado a Starbucks, con barbaca y camisa leñadora

    En una app tienes que lograr que los controles respiren y los colores vibren

    Ahi lo dejo. Y es por eso, que en mis “yo interior” decidí mejor dedicarme a apps en Pebble. Los motivos son claros

    - el entorno es blanco y negro

    - la resolución de las apps es de 144 x 168 px

    - solo soporta un grupo reducido de fonts

    - la guía de diseño de apps te recomienda crear apps “planas” (flat apps)

    - un enfoque minimalista es lo que debería guiar el diseño de Pebble apps

    Con esto dicho, lo tuve muy claro > es para mi! Y claro, con algo tan simple como esto

    image

    No tengo margen de equivocarme (por cierto esta app es la ficha que se muestra de ejemplo en el capítulo 4 de la guía de diseño de Pebble)

    Download: https://developer.getpebble.com/2/design/

    Saludos @ Berlin

    El Bruno

    image image image Google

    [#ALM] Improving the way we work (all the time, even in Easter time)

    Hello!

    A few days ago, in Peru some crack hosted the DevDays and today while I was reviewing some materials, I found this slide of Ernesto and while I was runnig 11KMs I did a little thinking about it.

    image

    How long would it take your organization to deploy a change that involves just one single line of code?

    In my line of work, change is a constant. Once I’ve commented on the type of work with elastic equipment, where we are usually 3 people, and we can get bigger up to 20 with a specific objective and then back to 3. This makes the inspection and adjustment a little more complex than usual. However the basis is to give the best and perform a high quality job, this is something that we must never lose.

    So with this scenario in mind, I decided to go back a few steps (about 23 according to my graphics) and try to update 1 line of code in a project / demo that is in production since 2013 April and publish it again.

    The process was a little tricky  and didn’t take me more than 2 hours, and I want to share some highlights about this:

    -The code download was trivial, and the compilation had no problems.

    -I cannot say the same of the unit Tests, I started to have problems with a few tests. It seems that our kind friends of JSON decided to update since April of the year until now several versions.

    -That was solved with and update of a pair of NuGet packages, and this triggered a series of updates that forced me to wrtie some code. With packages like SignalR, and EOF.

    -A year ago, I had a discussion with a member of the team which had pigheadedness in use Azure Mobile Services. Luckily I decided to implement the services with WebApi layer and passing the benefits of Azure Mobile Services. I have open a test project that we started to work and I think that in one year can not update anything.

    -That was kudos for me, now I get some punishment about a bad decision I made. Last year I think we can use LightSwitch to a perform a few trivial maintenance in a couple of tables. Those trivial maintenance now have more functionality than a calculation of demographic application, and after migrating the same between versions of LightSwitch, we have reached a point of no return where … I leave this here. This is a bad point for me. And I know that at some point I must raise the priority of this PBI and put it in a Sprint to make the app again.

    There are a couple of more stories to tell, but the conclusion is that in my case later 2 hours in upgrading a line of stitching a project in production. And this in an app in which nobody works has between 11 and 12 months old. I don’t even think what it would cost “get back to life” code that is measured in years.

    Conclusion: Although it is not a current scenario to meet the need for modifications in code of this type, I will challenge this scenario with 3 participants of the team and see the best way to be prepared for this situation. 2 hours isn’t much when is code is familiar for me, however in a “hostile” environment these 2 hours can easily be 2 days or more… Open-mouthed smile

    Saludos @ Home

    El Bruno

    image image image Google

    [#ALM] Mejorando el proceso (todo el tiempo, tambien en Semana Santa)

    Hola!

    Hace unos días fueron los DevDays en Perú y hoy mientras repasaba algunos materiales, me encontré con esta slide de Ernesto y mientras corría 11KMs hice una pequeña reflexión sobre la misma.

    image

    En mi línea de trabajo el cambio es una constante. Alguna vez he comentado sobre el tipo de trabajo con equipos elásticos, donde usualmente somos 3 personas, y podemos subir a picos de 20 con un objetivo concreto y luego volver a ser 3. Esto hace que la inspección y adaptación sea un poco más compleja que lo habitual.  Sin embargo la base de un trabajo con calidad, es algo que no debemos perder nunca.

    Asi que con este escenario en mente, decidí volver atrás algunos pasos (unos 23 segun mis gráficos) e intentar actualizar 1 línea de código de un proyecto / demo que está en producción desde abril del año pasado y publicar el mismo nuevamente.

    El proceso fue un poco engorroso y no me tomó más de 2 horas, y en el mismo vi lo siguiente:

    - La descarga de código fue trivial, y la compilación no tuvo problemas.

    - No puedo decir lo mismo de los unit Tests, empecé a tener problemas con algunos. Parece que a los amigos de JSON se les ha dado por actualizar desde abril del año pasado hasta ahora varias versiones.

    - Eso se solucionó con la acutaliacion de un par de NuGet packages, y esto desencadenó otra serie de actualizaciones que ME OBLIGARON A TOCAR CODIGO. Especialmente con packages de SignalR, y EF.

    - Hace un año, tuve una discusión con una persona del equipo que se había emperrado en usar Azure Mobile Services. Por suerte decidí implementar la capa de sercicios con WebApi y pasando de las ventajas de Azure Mobile Services. He abierto un proyecto de prueba con el que empezamos a trabajar y creo que en un año no se puede actualizar nada.

    - Esa era la de cal, ahora la de arena. Yo me puse perro en usar LightSwitch para unos mantenimientos triviales de tablas. Esos mantenimientos triviales ahora tienen más funcionalidad que una aplicación de cálculo de crecmiento demográfico, y después de migrar la misma entre versiones de LightSwitch, hemos llegado a un punto de no retorno donde … bueno ahi lo dejo. Este error me lo como yo. En algún momento deberé subir la prioridad de este PBI y meterlo en un Sprint para hacer la app de nuevo.

    Hay un par de historias más para contar, sin embargo la conclusión es que en mi caso tarde 2 horas en actualizar una línea de cósido de un proyecto en producción. Y esto en una app en la que nadie trabaja que tiene entre 11 y 12 meses de antiguedad. No quiero ni pensar lo que costaría “revirir” código que se mida en años.

    Conclusión: Si bien no es un escenario corriente el encontrarme con la necesidad de modificaciones en código de este tipo, deberé comentar este escenario con los 3 participantes del equipo y ver la mejor forma de estar preparados para esta situación. 2 horas no es mucho cuando es código que te resulta familiar, en un entorno “hostil” estas 2 horas pueden ser fácilmente 2 días o más … Open-mouthed smile

    Saludos @ Home

    El Bruno

    image image image Google

     

    Saludos @ Home

    El Bruno

    image image image Google

    [#TFS] Is Microsoft going to leave TFSVC for GIT? NO (let me put this more clearer: NO!)

    Hello!

    Brian Harry didn’t put the source of this confusion, so I wont do the same. Brian Harry maked this clear, he explained that Microsoft and Visual Studio and the Team Foundation team will continue betting and working for the model of centralized Souce Control that Team Foundation provides.

    A few days ago a small dilemma on Twitter was armed when someone alleged that, speaking with people at Microsoft, he had confirrmation on no more support for TFSVC and all will be moved to GIT. This was very out of scope, and much. I told you how to make migration a few days ago, using GIT-TF, and Brian also makes it clear there are some features that are not available in an environment with GIT and yes for TFSVC, the main idea is to get the best experience for a developer .

    And the noise level was fairly high, as to which Brian Harry has to make clear the response in a post: plan to abandon Microsoft TFSVC for GIT? > > Not.

    Source: http://blogs.msdn.com/b/bharry/archive/2014/04/14/is-microsoft-abandoning-tfvc-in-favor-of-git.aspx

    Saludos @ Home

    El Bruno

    image image image Google