List<Stuff>

Charles Darwin and Continuous Delivery

Charles Darwin published On the Origin of Species in 1859. It is somewhat remarkable that some of the theories enunciated in this work can be verified over 150 years later, in human knowledge fields such different from biology as software development.

In order to set the context of the subjects discussed below, and before addressing how are we are affected by Darwin's statements, let's take a little trip, visiting some of the most successful Internet companies, whose websites have astronomical numbers of users, millions of pages served per day, and countless amounts of completed transactions.

The voyage aboard the Beagle

Darwin embarked on a journey of nearly five years aboard the HMS Beagle, which allowed him to study many animal species and to obtain valuable information to support the theories that later showed in his work. It's much easier for us to study the species that we are interested in, since we only need a few glimpses to some content that can be found online, publicly available.

We are going to start at Seattle, where a small online bookstore founded in a garage back in the 90's, has ended up becoming a global bazaar where you can buy anything from the mythical t-shirt of three wolves howling at the full moon (if you did not know about the product, I recommend you to read the customers' evaluations), to genuine uranium.

Amazon serves 137 million customers per week and has an annual revenue of 34 billion dollars. If all of its active users came together in a country, it would have twice as many people as Canada. You can imagine that, with such amazing figures, introducing new features in the website should be something that they consider thoroughly, and that it would be something that they can't afford to do so often because of the risk of bugs and unexpected errors showing up, which could lead to huge losses.

Right?

No. Nothing further from the truth. By 2011, Amazon was releasing changes in production every 11.6 seconds on average, involving up to 30,000 servers simultaneously. I'm lacking more recent numbers, but from the evolution of the business, anyone could work out that these figures must only have become even more striking.

800 miles south, at Menlo Park (California), what began as a social experiment for a group of undergraduates, is serving more than one billion active users, who upload 250 million images a day and view one thousand billion pages per month. The figures are dizzying. The effect is so strong that even some parents have named their children Facebook, literally.

The source code for Facebook is compiled into a binary weighing 1.5 GB and is maintained by more than 500 developers. Stakes are high for each change and deployment. Anyone would expect that any change is made after thorough verification of a strict QA team, and never without the explicit approval from an horde of managers, armed to the teeth with the most inflexible bureaucracy.

Or maybe not?

In fact, whoever imagines it that way, is completely mistaken. Minor changes are released into production at least once a day, and a major version is deployed once a week. Almost all the code is modified directly on the main line; they don't use branches to protect its integrity. Everyone does testing and can file bugs. Everything is automated to the maximum.

Not far from there, also in California, NetFlix does business from a town called Los Gatos. It is the largest online service for movies and television shows, which are offered by streaming to its subscribers, who sum more than 25 million.

NetFlix services receive frequent attacks that put them at risk, and even lead to failures in specific nodes, making it necessary to perform interventions in order to prevent further problems. So far, it's not that different from any other big company providing Internet services. What makes it extraordinary in the case of NetFlix, is that most of these attacks are caused... by themselves!

How can it be possible? Have they gone nuts? Are there disgruntled employees trying to sabotage the company from within?

Not really. These attacks are perfectly orchestrated by the Simian Army, the horde of little nuisances developed by Netflix to push the boundaries of their own infrastructure and applications. The Chaos Monkey randomly disables instances to ensure that they can survive this type of failure. The Latency Monkey simulates delays and loss of connectivity. The Conformity Monkey shuts down instances not adhering to a defined set of best practices, immediately and without remorse. And so on... there's even a Chaos Gorilla, the Chaos Monkey's bodyguard, who causes an outage across the entire cloud availability zone where it monkeys around. The consequence is that, when these problems occur unexpectedly, all their systems are already prepared to deal with them, since the team has been able to test the procedures, and the code has already been modified to mitigate the consequences. If it sounds interesting for you, you can even take a look at how it is implemented.

Now we return to our first stop, Seattle. Nearby, at Redmond, Team Foundation Service Team serves many other development teams worldwide, providing a tool to support the complete application lifecycle: planning, collaboration, version control, testing, automated builds, etc. With a worldwide-distributed user base, working in all time zones, availability is critical; anyone working in software development knows about the hassle of losing access to version control or not being able to use the build server. The usual approach in these cases, is to focus on a stable set of features, that allows to provide an adequate service to the users, and with minimum changes over time; that way they can guarantee that the availability of the service is not affected by defects introduced by the release of new features.

Do you agree with this approach?

They don't! The trend since the product launch has been to introduce new features continuously, with a cadence of about three weeks. And we're not talking about minor or cosmetic changes; those updates have included such important features as automated deployment to Azure, Git integration, or customizable Kanban boards. The few service outages so far have been mostly predictable, and for many of them the user has been alerted so she could be prepared.

Just the same way as Darwin did aboard the Beagle, we could indefinitely continue with our journey in search of peculiar species, in search of many other organizations working in a way that seems to defy common sense and established rules:

• Flickr deploys ​​several times a day, and until recently, they reported on their website on the time of the last deployment, and how many changes were included in it.
• At Spotify, where they maintain over 100 different systems between clients, backend services, components, etc., any of the 250 developers is authorized to modify any of these systems directly if it is needed in order to implement a feature.
• Etsy experiments with new features directly into production, a technique known as A / B testing, to identify those changes that attract more interest from customers.

What conclusions can be drawn at the light of all this information?

Are they all gone completely mad?

Or are we discovering a new way to do work, that breaks with many of the preconceived ideas considered valid so far in software development?

For example, it may seem counter-intuitive to think that the more deployments you do, the less problems you'll have while deploying. We've all had that fateful release on a Friday (you know, if it's not on Friday, you can't call it a real deployment...), which forced us to spend all weekend struggling to put the fuc#$@& application up. And the natural reaction is to avoid doing more deployments with all our strength, and postpone it as much as possible, because we know that it will hurt again. After all, if there are many more attempts, it is also much more likely to fail, isn't it?

Well, usually not. In fact, the effect is that repetition leads to more predictable and controllable deployments, with less uncertainty and much smaller and manageable issues. The underlying philosophy is that if something hurts, rather than avoid it, you should do it more often, and that way you'll make the pain more bearable. Or putting it another way, it is more acceptable a succession of small pains, than a large, concentrated traumatic pain.

Is it feasible that any single developer has the power to release any changes she deems ready to deliver? Yes, if that change is subjected to a verification process that ensures that it will not break anything once it has been released.

Is it reckless to remove from this verification process a whole chain of bureaucracy, requests, approvals, meetings between departments and a comprehensive control of the process by adequately trained roles?

It is not reckless, as long as all or most of these verifications have been coded and are run in the form of acceptance, regression and smoke automated tests, and unattended deployments, and with the ability of checking the status of all the process in an easy way. Not only it is not reckless, but it will far exceed the reliability of a group of humans doing the same process manually (or even worse, a random variation of it), often in a state of boredom and under a poor concentration. I am not talking about completely eliminating manual steps, which is usually impossible: at least there will be a manual first run of acceptance tests for the user to verify that the development team has understood whatever was intended to be addressed with the particular requirement. Or there might be some special device in our environment for which we can not set up a fully automated deployment. But we always can deal with the rest of our process, and aim to reduce these manual steps as much as possible.

Continuous Delivery is a discipline, a way to work, or a set of patterns and practices, that bears in mind all these factors and takes advantage of them to the maximum. We're going to rely on techniques such as test automation and deployment, continuous integration, transparency and visibility throughout the entire process, the detailed scrutiny of all dependencies and configuration parameters that affect the delivery of our software, the detection and early addressing of problematic changes, and many others, to enable the possibility that any slight change in our code, committed to version control, is a candidate to be released as soon as possible, and indeed it will, if nothing makes us (automatically) discard it along the way.

It is not only about continuous deployment, as many mistakenly assume, as you can be deploying crap and still do it automatically and continuously. Nor is it just continuous automated testing. It is comprised of these practices but also of many others; all of those which are needed to be confident when assuring that a change is ready for use and the user can benefit from it.

Of course, for this to be successful, close collaboration between whoever is involved is needed, in an environment where barriers and departmental silos have been removed. It is something that movements like DevOps are also addressing.

What is the benefit?

If we stick to the results, the figures from these companies, we could say that the benefit is huge. But in order to avoid falling into the ’Correlation implies Causation’ fallacy, we should be more specific and focus on the context of the software development process.What we find then is:

• A transparent and predictable delivery process. For each change, we always go through the same sequence of steps, and these are automated as far as possible. No surprises.
  
• Fewer defects in production. The defects appear and are addressed in earlier stages, even automatically. The standardized delivery process prevents any of these defects from ending up in production because of a misunderstanding, or because of the work being done in a different way. It also provides traceability of the origin of these problems.
• Flexibility to undertake changes. Changes are addressed in smaller, more manageable pieces. They are implemented and delivered promptly.
• Immediate and useful feedback about changes, even from the production environment: whether they are running smoothly, how are users accepting them, or the impact on the business.
• Less time required to deploy and release into production, since everything has been automated as much as possible.
• Empowered teams, motivated by the confidence that has been put in them, and the continued feeling of delivering increments of tangible value.

All of this sounds great, but it's not for me

The adoption of Continuous Delivery practices can be worth it, even if you do not need or do not want to release your software so frequently. Overall, the aforementioned benefits should be the same, so any team willing to improve could consider adopting this approach.

There are very special cases where Continuous Delivery might not be the best option, or even be counterproductive. I, for one, have found very few of them. Most times, these are scenarios where the effort to adopt the practices will not justify the results: legacy systems, outdated technologies, lack of adequate tools to set up the environment, designs not prepared for automation or testing, etc.

But the real problem, which unfortunately appears quite often, comes when the team or the organization itself does not adopt an open attitude to change and improvements. We could say that deep inside, even unconsciously, they do not want a transparent delivery process, they don't need fewer defects in production, or they don't want flexibility to cope with changes. Externally this manifests itself as the decision of not to invest in the necessary improvements. The most common example is the typical argument of the kind ‘our case is very unusual,’ ‘our system is very complex,’ ‘we deal with a very delicate business,’ ‘our users are very special,’ ‘my boss would never let me,’ ‘my mom won't let me’ or ‘insert your favorite excuse here.’ Among these, it is quite frequent to hear ‘we can’t afford to invest in it,’ when in fact, as we will see in a moment, is thatvwhat for sure you can't afford is not to invest in it.

Is your system bigger than Team Foundation Service?

Do you deal with a more complex business than Amazon?

Are your users more demanding than those from Facebook? Do they have more special requirements?

Do you have to serve a bigger volume of data than NetFlix?

If you're among the vast majority, those who would respond negatively to these questions, chances are that you are just feeling lazy about addressing the transition to a Continuous Delivery model. In that case, my advice is to be careful, because your organization can suffer the same fate as the dodo or the thylacine.

Natural selection

We had left Darwin aboard the Beagle, sailing the seven seas in search of unique species. At the end of his voyage, he felt perplexed about the variety of wildlife and fossils he had found, so he began an investigation that led him to enunciate the theory of natural selection in his book "On the Origin of Species".

Natural selection states that those members of a population which have the characteristics that are better adapted to their environment, are more likely to survive. What about the others? Well, sooner or later they'll end up disappearing.

It is a law that applies to living organisms, but if you think about it for a moment, what is an organization but a big living organism? Of course natural selection applies to companies and organizations, as any list of extinct companies demonstrates.

In the constantly changing environment in which most businesses operate, it is no longer enough to offer nice and cheap products. You have to deliver them sooner, and evolve them quickly in response to the demands of the users. Keeping track of metrics such as team velocity or defect rate is insufficient. The metrics that are making a difference between those who succeed and those who get stuck on the way are others:

• Cycle time: the time elapsed on average since we start working on a feature, until we have it released in production.
• Mean time to failure (MTTF): how long it takes, on average, for my system to suffer from a big issue or an outage.
• Mean time to recover (MTTR): how long it takes, on average, for my system to be fully functional again after a big problem or an outage.

Natural selection will favor those who are able to hold these values as small as possible, and this is exactly one of the areas where Continuous Delivery can help better.

OK, I don't want to become extinct. Where should I start?

Throughout this article we have focused on showing the benefits of Continuous Delivery and what could happen if we ignore it. But we have not covered in any depth how to implement it, and given the large number of patterns and practices to consider, it can end up being a process that is far from trivial.

Undoubtedly, there is a cultural side, which will demand from us to work within our organization to remove barriers and silos, and improve collaboration as much as possible.

There are lots of available resources that can help us to get started, but without any doubt the most valuable one is the excellent book by Jez Humble and David Farley, Continuous Delivery.

If your environment is based on Microsoft technologies, fortunately we have great tools available that can support most of the aforementioned practices. Visual Studio and Team Foundation Server, and related tools, will help us to implement the whole Continuous Delivery ‘pipeline’, from automating all kinds of testing and deployment, to more specific topics such as static code analysis or continuous integration. It is true that these tools require customization work and some tweaking in order to be suited for the model we are proposing, but here at Plain Concepts we can help you to prepare the environment that best suits your project; it's something that we've done before for many organizations, and seems that still none of them have become extinct.

Also, if you want to get an overall idea about how Team Foundation Server can be customized in order to support Continuous Delivery, you can have a look at my presentation on this topic at ALM Summit 3.

And if you can afford to wait a bit longer, right now I'm working with the Microsoft Patterns & Practices team in a new book about the subject that will be available in a few months, where we will cover in depth whatever is needed to put these ideas into practice in an effective way. More news about it very soon!

Charles Darwin y la Entrega Continua

Charles Darwin publicó El Origen de las Especies en 1859. No deja de ser admirable que algunas de las teorías que enunció en esta obra se pueden verificar más de 150 años después, en campos del conocimiento humano tan dispares a la biología como puede ser el desarrollo de software.

Para establecer el contexto de los temas que veremos a continuación, antes de abordar cómo nos afectan los enunciados de Darwin, vamos a hacer un pequeño viaje, en el que visitaremos algunas de las empresas más exitosas de Internet, cuyas webs cuentan con cifras astronómicas de usuarios, millones de páginas servidas al día, e incontables cantidades de transacciones completadas.

El viaje del Beagle

Darwin se embarcó en un viaje de casi cinco años a bordo del buque HMS Beagle, que le permitió estudiar multitud de especies animales y obtener información valiosa para soportar las teorías que posteriormente reflejó en su obra. Para estudiar las especies que nos interesan a nosotros, lo tenemos mucho más fácil, pues nos basta con un par de vistazos a algunos contenidos que podemos encontrar en la red, disponibles públicamente.

Empezamos en Seattle, donde una pequeña librería online fundada en un garaje en los años 90, ha acabado convirtiéndose un bazar global donde se puede comprar desde la mítica camiseta de los tres lobos aullando a la luna llena (si no conocías el producto, te recomiendo que leas las evaluaciones de los clientes), a verdadero uranio.

Amazon sirve a 137 millones de clientes por semana y tiene unos beneficios de 34.000 millones de dólares anuales. Si todos sus usuarios activos se juntasen en un país, éste tendría el doble de habitantes que Canadá. Os podéis imaginar que con semejantes cifras, introducir nuevas funcionalidades en el sitio web debe ser algo que se piensen muy mucho, y no se puedan permitir hacer con demasiada frecuencia por el riesgo de aparición de bugs y errores inesperados, que podrían conllevar pérdidas millonarias.

¿Correcto?

No. Nada más lejos de la realidad. En 2011 Amazon estaba liberando cambios en producción cada 11,6 segundos de media, que podían estar afectando hasta a 30.000 servidores a la vez. No dispongo de datos más actualizados, pero por la evolución del negocio, todo hace pensar que estas cifras no habrán hecho más que volverse aún más sorprendentes.

1.300 kilómetros al sur, en Menlo Park (California), lo que empezó como el experimento social de un grupo de universitarios, está dando servicio a más de mil millones de usuarios activos, que suben 250 millones de imágenes al día y consultan un billón de páginas al mes. Las cifras que se manejan son simplemente mareantes. La repercusión es tal que incluso hay padres que ponen a sus hijos el nombre de Facebook, literalmente.

El código fuente de Facebook es compilado en un binario que pesa 1,5 GB y es mantenido por más de 500 desarrolladores. En cada modificación y despliegue, hay mucho en juego. Es de esperar que cualquier cambio se haga tras la verificación exhaustiva de un estricto equipo de QA, y nunca sin la aprobación expresa de un ejército de gerentes armados hasta los dientes con la más inflexible burocracia.

¿O quizás no?

La verdad es que, el que se lo imagine así, está muy equivocado. Se sale a producción un mínimo de una vez al día con cambios menores, y una vez a la semana se despliega una versión mayor. Casi todo el código se modifica directamente sobre la línea principal; no usan ramas para proteger la estabilidad de la misma. Todo el mundo hace pruebas y puede reportar defectos. Todo está automatizado al máximo.

No muy lejos de allí, desde un pueblo de California llamado Los Gatos, opera NetFlix. Se trata del mayor servicio de películas y series de televisión online ofrecidas por streaming a sus suscriptores, que suman más de 25 millones.

Los servicios de NetFlix reciben de forma frecuente ataques que hacen peligrar el correcto funcionamiento de los mismos, e incluso provocan caídas en nodos concretos que hacen necesarias intervenciones para evitar problemas mayores. Hasta aquí no es diferente de cualquier otra gran empresa que proporcione servicios en Internet. Lo particular del caso de NetFlix es que gran parte de estos ataques están provocados… ¡por ellos mismos!

¿Cómo es posible? ¿Han perdido la cabeza? ¿Hay empleados descontentos intentando sabotear la compañía desde dentro?

En realidad no. Los ataques están perfectamente orquestados por la Simian Army, el ejército de pequeños incordios desarrollado por NetFlix para llevar al límite su propia infraestructura y aplicaciones. El Chaos Monkey se ocupa de deshabilitar instancias aleatoriamente para asegurarse de que se puede sobrevivir a este tipo de fallo. El Latency Monkey simula retardos y pérdida de conectividad. El Conformity Monkey cierra instancias que no cumplen un conjunto definido de buenas prácticas, directamente y sin mayores contemplaciones. Y así sucesivamente… incluso hay un Chaos Gorilla, el primo de zumosol del Chaos Monkey, que corta de un plumazo el servicio en toda la zona de disponibilidad de la nube en la que desempeña sus monerías. El resultado es que cuando este tipo de problemas aparecen de forma inesperada, todos sus sistemas y equipos ya están preparado para tratar con ellos, puesto que han podido ensayar los procedimientos y el código se ha protegido para mitigarlos. Si la idea te parece interesante, incluso puedes echar un vistazo a cómo está implementado.

Volvemos a nuestra primera parada, Seattle. Justo al lado, en Redmond, el equipo de Team Foundation Service da servicio a muchos otros equipos de desarrollo a nivel mundial, proporcionando una herramienta completa para dar soporte al ciclo de vida de las aplicaciones: planificación, colaboración, control de versiones, ejecución de pruebas, construcciones automatizadas, etc. Con una base de usuarios a nivel mundial, trabajando en todas las zonas horarias, los requisitos de disponibilidad son críticos; todos los que trabajamos en desarrollo de software sabemos el fastidio que supone quedarse sin acceso al control de versiones o que el servidor de construcciones automatizadas no esté disponible. El enfoque usual en estos casos es centrarse en una base estable de características que permitan dar un servicio adecuado a los usuarios y que cambien poco en el tiempo, de esa forma garantizamos que la disponibilidad del servicio no se ve afectada por defectos derivados de la introducción de características nuevas.

¿Estás de acuerdo con este enfoque?

¡Pues ellos no! La tendencia desde el lanzamiento del producto ha sido la de introducir nuevas funcionalidades de forma continua, con cadencias de aproximadamente tres semanas. Y no estamos hablando de cambios menores o estéticos; en esas actualizaciones han entrado características de tanta entidad como el despliegue automatizado a Azure, la integración con Git, o la personalización de tableros Kanban. Las mínimas caídas de servicio acontecidas hasta la fecha han sido en su mayoría previsibles, y en muchas de ellas el usuario es alertado para que pueda estar listo.

De la misma forma que hizo Darwin a bordo del Beagle, podríamos seguir indefinidamente con nuestro periplo en busca de especies peculiares, de otras muchas organizaciones que usan un modo de trabajo que parece desafiar el sentido común o las reglas establecidas:

• Flickr realiza varios despliegues al día, y hasta hace poco informaba en su web de la hora del último despliegue, y de cuántos cambios había incluido.
• En Spotify, donde se mantienen más de 100 sistemas distintos entre clientes, servicios de backend, componentes, etc., cualquiera de los 250 desarrolladores está autorizado a modificar cualquiera de estos sistemas directamente si lo necesita para implementar una característica.
• Etsy experimenta con características nuevas directamente en producción, una técnica conocida como A/B testing, para identificar aquellos cambios que atraen un mayor interés de los clientes.

¿Qué conclusiones podemos sacar a la vista de toda esta información?

¿Se han vuelto todos completamente locos?

¿O estamos ante un nuevo modelo de trabajo, que rompe con muchas de las ideas que considerábamos válidas hasta ahora en desarrollo de software?

Por ejemplo, puede parecer anti-intuitivo pensar que hacer más despliegues te lleve a tener menos problemas al desplegar. Todos hemos tenido esa salida a producción fatídica un viernes (ya se sabe que si no es en viernes, no es un verdadero despliegue…), que nos ha obligado a estar todo el fin de semana luchando para poner la jod$#@ aplicación en marcha. Y la reacción natural es resistirse a volver a desplegar con todas nuestras fuerzas, demorarlo al máximo, ya que sabemos que nos va a doler otra vez. Al fin y al cabo, al haber muchos más intentos, hay también muchas más posibilidades de fallar ¿no es así?

Pues por lo general no. En realidad, el efecto es que la repetición nos lleva a que los despliegues son más predecibles, más controlados, con menos incertidumbre y con problemas mucho más pequeños y controlables. La filosofía subyacente es que si algo duele, en lugar de evitarlo deberías hacerlo más frecuentemente, y así harás el dolor más llevadero. O dicho de otra forma, es más asumible una sucesión de dolores pequeños que un gran dolor traumático concentrado.

¿Es viable que cualquier simple desarrollador tenga el poder de poner en producción cualquier cambio que él considere listo para entregar? Sí, si dicho cambio es sometido a todo un proceso de verificación que asegura que no se va a romper nada si lo liberamos.

¿Es imprudente eliminar de ese proceso de verificación toda una cadena de burocracia, solicitudes, aprobaciones, reuniones entre departamentos y control exhaustivo del proceso por parte de los roles adecuadamente capacitados?

No es para nada imprudente, si todas o la mayoría de esas verificaciones han sido codificadas y se ejecutan en la forma de pruebas de aceptación, de regresión y de humo automatizadas, de despliegues desatendidos, y con la posibilidad de visualizar fácilmente el estado de todo el proceso. No sólo no es imprudente, sino que va a superar con creces la fiabilidad de un grupo de humanos que hagan el mismo proceso (o lo que es peor, una variación aleatoria del mismo) de forma manual, muchas veces en un estado de aburrimiento absoluto y con la concentración bajo mínimos. No me estoy refiriendo a eliminar por completo los pasos manuales, lo cual es por lo general imposible: al menos habrá una primera ejecución manual de las pruebas de aceptación para que el usuario pueda verificar si el equipo de desarrollo ha entendido bien lo que se pretendía conseguir con el requisito concreto. O quizá pueda haber algún dispositivo especial en nuestro entorno para el que no podamos configurar un despliegue totalmente automatizado. Pero sí podemos abordar el resto de nuestro proceso, y tender a minimizar estos pasos manuales en la medida de lo posible.

La Entrega Continua (Continuous Delivery) es una disciplina, un modo de trabajo, o un conjunto de patrones y prácticas, que tiene en cuenta todos estos factores posibles de optimización y los explota al máximo. Nos vamos a basar en técnicas como la automatización de las pruebas y despliegues, la integración continua, la transparencia y visibilidad a lo largo de todo el proceso, el control exhaustivo de todas las dependencias y parámetros de configuración que afectan a la entrega de nuestro software, la detección y tratamiento temprano de cambios problemáticos, y otras muchas, para habilitar la posibilidad de que cualquier mínimo cambio en nuestro código, que se suba al control de versiones, sea candidato a acabar en producción en el mínimo tiempo posible, y de hecho acabe allí si nada nos hace desecharlo (a ser posible automáticamente) en el transcurso todo este proceso.

No se trata tan sólo de despliegue continuo, como muchos erróneamente asumen, ya que puedes estar desplegando basura y aun así hacerlo de forma automatizada continuamente. Tampoco se trata sólo de pruebas automatizadas continuas. Se trata de esas prácticas pero también de otras muchas más; todas aquellas que necesitemos para poder afirmar con garantías que un cambio está listo para que el usuario lo utilice y pueda sacar provecho de su uso.

Por supuesto, para que esto tenga éxito es necesaria una colaboración estrecha entre todos los involucrados, y un entorno en el que se han eliminado barreras y silos departamentales. Algo muy relacionado con lo que movimientos como DevOps se están ocupando de promulgar.

¿Qué ganamos con todo esto?

Si nos guiamos por las cifras que manejan las empresas que trabajan así, podríamos decir directamente que mucho. Pero para evitar caer en la falacia de “correlación implica causalidad”, habría que concretar más, y enfocarnos en el contexto del proceso de desarrollo de software. Lo que nos encontramos entonces es:

• Un proceso de entrega transparente y predecible. Para todo cambio siempre pasamos por la misma secuencia de pasos, y éstos están automatizados en la medida de lo posible. No hay sorpresas.

• Menos defectos en producción. Los defectos aparecen y son abordados en fases más tempranas, incluso de forma automática. El proceso de entrega estandarizado evita que ninguno de estos defectos pueda acabar en producción por un malentendido o por formas distintas de hacer las cosas. Además nos aporta trazabilidad sobre el origen de estos problemas.
• Flexibilidad para asumir cambios. Los cambios se abordan en trozos más pequeños y manejables, se implementan y se entregan lo antes posible.
• Información más inmediata y útil acerca de los cambios, incluso en el propio entorno de producción: si están funcionando sin problemas, cómo son acogidos por los usuarios o cómo afectan al negocio.
• Menos tiempo empleado para desplegar y liberar en producción, ya que tenemos todo automatizado al máximo.
• Equipos motivados por la confianza depositada en ellos y la sensación continuada de estar contribuyendo con incrementos de valor tangibles.

Todo esto suena muy bien, pero no es para mí

La adopción del tipo de prácticas que propone la Entrega Continua puede ser interesante incluso si no necesitamos o si no queremos salir a producción de forma tan frecuente. Los beneficios enumerados en general serán los mismos, por lo que cualquier equipo con afán de mejorar podría plantearse seguir este modo de trabajo.

Hay casos muy especiales en los que la Entrega Continua podría no ser la mejor opción, o incluso sea contraproducente. Yo la verdad es que me he encontrado bien pocos. La mayoría de las ocasiones suelen ser escenarios en los que el esfuerzo de adoptar todas estas prácticas no va a justificar los resultados obtenidos: sistemas legados, tecnologías obsoletas, falta de herramientas adecuadas para montar el entorno necesario, diseños que no favorecen la automatización o las pruebas, etc.

Pero el verdadero problema, que además desafortunadamente suele aparecer con frecuencia, viene cuando el propio equipo o la organización no adoptan una actitud abierta al cambio y a posibles mejoras. Podríamos decir que en el fondo, de modo inconsciente, no quieren un proceso de entrega transparente, no necesitan menos defectos en producción o no buscan flexibilidad ante cambios. De cara al exterior esto se manifiesta como la decisión de que no quieren invertir en las mejoras necesarias. El ejemplo más común es el típico argumento del tipo “nuestro caso es muy singular”, “nuestro sistema es muy complejo”, “el negocio en el que nos movemos es muy delicado”, “nuestros usuarios son muy especiales”, “mi jefe nunca me dejaría”, “mi mamá no me deja” o “inserta tu excusa preferida aquí”. Es especialmente frecuente el de “no podemos permitirnos invertir en eso”, cuando en realidad, como veremos en un momento, lo que seguramente no te puedes permitir es dejar de invertir.

¿Es tu sistema más complejo que Team Foundation Service?

¿Te mueves en un negocio más complejo que Amazon?

¿Son tus usuarios más exigentes y con demandas más variadas que los de Facebook?

¿Tienes que servir más volumen de información que NetFlix?

Si estás entre la gran mayoría de los que responderían negativamente a todas esas preguntas, es muy probable que simplemente te sientas perezoso ante la perspectiva de la transición al modelo de Entrega Continua. En ese caso, mi recomendación es que tengas cuidado, porque a tu organización puede esperarle el mismo destino que al dodo o al tilacino.

Selección natural

A todo esto, nos habíamos dejado a Darwin a bordo del Beagle, navegando por los siete mares en busca de especies singulares. Al final de su viaje estaba perplejo con la variedad de fauna y fósiles que había encontrado, y comenzó una investigación que le llevó a enunciar la teoría de la selección natural en su obra “El origen de las especies”.

La selección natural nos dice que los miembros de una población con características mejor adaptadas a su entorno, son los que sobreviven con mayor probabilidad. ¿Qué ocurre con los demás? Pues que tarde o temprano acaban desapareciendo.

Es una ley que se aplica a organismos vivos, y si nos paramos a pensar un poco, ¿qué es una organización sino un gran organismo vivo? Por supuesto que la selección natural se aplica a empresas y organizaciones, como cualquier lista de compañías extintas se encarga de demostrarnos.

En el entorno en constante cambio en el que se mueven la mayoría de los negocios, ya no sirve con tener productos buenos, bonitos y baratos. Hay que tenerlos antes, y hacer que evolucionen rápidamente según las demandas de los usuarios. Ya no basta con mantener métricas como la velocidad del equipo o la tasa de defectos. Las métricas que están marcando la diferencia entre los que triunfan y los que se quedan en el camino son otras:

• Tiempo de ciclo (cycle time): el tiempo que transcurre desde que empiezo a trabajar en una funcionalidad, hasta que la tengo en producción.
• Tiempo medio entre fallos (MTTF, mean time to failure): lo que tarda mi sistema de media en tener una caída o un corte de servicio.
• Tiempo medio de recuperación (MTTR, mean time to recover): lo que tardo de media en poner en marcha mi sistema después de una caída.

La selección natural favorecerá a aquellos que sean capaces de mantener estos tiempos en valores lo más pequeños posibles, y es precisamente una de los aspectos en los que la Entrega Continua puede ayudarnos mejor.

Vale, ¡no quiero extinguirme! ¿Por dónde empiezo?

A lo largo de este artículo nos hemos centrado en ver los beneficios de la Entrega Continua y qué puede ocurrir si la ignoramos. Pero no hemos entrado mucho en ver cómo llevarla a la práctica, y dado el gran número de patrones y prácticas a tener en cuenta puede ser un proceso que diste de ser trivial.

Sin lugar a dudas hay una parte del proceso que es cultural, y en la que tendremos que trabajar dentro de nuestra organización para eliminar barreras y silos y mejorar la colaboración en la medida de lo posible.

Para ir guiándonos en los pasos necesarios hay muchos recursos disponibles en los que encontrar ayuda, pero sin lugar a dudas el mejor y más completo es el excelente libro de Jez Humble y David Farley, Continuous Delivery.

Si tu entorno está basado en tecnologías Microsoft, afortunadamente tenemos disponibles herramientas magníficas que pueden dar soporte a la mayoría de las prácticas que hemos mencionado. Visual Studio y Team Foundation Server, y otras herramientas relacionadas, van a servirnos para implementar toda la “pipeline” de Entrega Continua, desde la automatización de todo tipo de pruebas y despliegues, hasta temas más concretos como el análisis estático de código o la integración continua. Es verdad que dichas herramientas necesitan personalización y ajustes para adaptarlas a la forma de trabajar que estamos proponiendo, pero desde Plain Concepts podemos ayudaros a preparar el entorno que mejor se ajuste a vuestro proyecto; es algo que ya hemos hecho para montones de organizaciones, y parece que aún no se ha extinguido ninguna de ellas.

Para hacerte una idea de cómo puede personalizarse Team Foundation Server para dar soporte a la Entrega Continua, también puedes echar un vistazo a mi presentación sobre este tema en el ALM Summit 3.

Y si te puedes permitir esperar, en pocos meses estará disponible un libro en el que estoy colaborando con el equipo de Microsoft Patterns & Practices, y en el que contaremos con todo lujo de detalles qué se necesita para poner en práctica todas estas ideas de forma efectiva. ¡Más noticias acerca de esto en breve!

Continuous Delivery deployment pipeline with TFS

During last ALM Summit I delivered a session about setting up a Continuous Delivery deployment pipeline using TFS. These are the slides I used, I hope that they’ll be useful!

Enabling TFS 2012 new features for upgraded 2010 projects

If you follow the steps outlined in one of the upgrade procedures for TFS 2012, you’ll end up with a collection containing working projects, including all the historical data. But these projects will keep the old TFS process template, and so they will lack some of the exciting new features which are present in new projects that have been created with one of the new templates. If you went through the upgrade having in mind to use any of these features, at this point you may look like this:

For example, in this upgraded Visual Studio Scrum 1.0 PBI work item, you can see that one of the new features (storyboarding) is missing:

Fortunately, it’s possible to upgrade the process template in these projects so it becomes the matching new one. This is how the former PBI looks once its template has been converted to the new Visual Studio Scrum 2.0 (notice the ‘Storyboards’ tab):

The procedure is supported for all the Microsoft TFS process templates (Sorry, no support for third party templates such as Scrum for Team System):

• Visual Studio Scrum 1.0 projects get upgraded to Visual Studio Scrum 2.0
• MSF Agile 5.0 projects get upgraded to MSF Agile 6.0
• MSF CMMI 5.0 projects get upgraded to MSF CMMI 6.0

And after applying it you’ll get:

• Teams
• Code reviews
• Feedback tool
• My Work
• Agile planning tools
• Storyboards
• Hidden work item types (such as code review and feedback WIs, or shared steps)

Once any TFS 2010 project has been upgraded and is already available in TFS 2012, just open the Web Access site, go to the configuration section:

And click on the available link at the left.

You’ll get a wizard that analyzes the current process template, finds the matching new one and upgrades it, so all these new features are available. Couldn’t be easier.

Enjoy!!!

Habilitando las características nuevas de TFS 2012 para proyectos actualizados desde 2010

Si sigues los pasos detallados en alguno de los procedimientos de actualización a TFS 2012, obtendrás una colección con proyectos funcionales que incluyen además todos los datos históricos. Pero esos proyectos conservarán la antigua plantilla de proceso de TFS, por lo que no dispondrán de algunas de las interesantes características nuevas que están presentes en los proyectos creados con las nuevas plantillas. Si habías hecho la actualización a TFS 2012 con la idea de usar alguna de estas características, en este punto estarás en una situación similar a ésta:

Por ejemplo, en este elemento de trabajo de tipo PBI actualizado desde la plantilla Visual Studio Scrum 1.0, se puede ver que una de las características nuevas (storyboarding) no está disponible:

Afortunadamente, es posible actualizar también la plantilla de proceso en esos proyectos para que se convierta en la plantilla nueva correspondiente. Así es como aparece el anterior PBI una vez que su plantilla ha sido convertida a la nueva Visual Studio Scrum 2.0 (ahora se puede ver la sección ‘Storyboards’):

El procedimiento está soportado para todas las plantillas de TFS de Microsoft (Por el momento no hay soporte para plantillas de terceros como Scrum for Team System):

• Los proyectos con Visual Studio Scrum 1.0 son actualizados a Visual Studio Scrum 2.0
• Los proyectos con MSF Agile 5.0 son actualizados a MSF Agile 6.0
• Los proyectos con MSF CMMI 5.0 son actualizados a MSF CMMI 6.0

Y después de ejecutar el procedimiento, obtendrás:

• Equipos
• Revisiones de código
• Herramienta de Feedback
• Trabajo en curso (My Work)
• Herramientas de planificación Ágil
• Storyboards
• Elementos de trabajo ocultos (como los work items de code review y feedback, o los shared steps)

Una vez que cualquier proyecto de TFS 2010 ha sido actualizado y ya esté disponible en TFS 2012, simplemente hay que abrir el acceso web para el proyecto e ir a la sección de configuración:

Y hacer click en el enlace disponible a la izquierda:

Se abrirá un asistente que analiza la plantilla de proceso actual, encuentra la correspondiente plantilla nueva y la actualiza, de modo que todas esas nuevas características van a estar disponibles. No podría ser más fácil…

A disfrutar!!!

Last version of the Scrum Guide available in Spanish

A quick one… the last version of the Scrum Guide lacked a proper translation to Spanish, and I had to solve that!

I hope it to be useful: http://www.scrum.org/Scrum-Guides

Última versión de la Guía de Scrum disponible en Español

Una rápida… la última versión de la Guía de Scrum no tenía una traducción al Español adecuada, ¡y no me quedaba más remedio que solucionarlo!

Espero que sea útil: http://www.scrum.org/Scrum-Guides

Nuevas actividades de workflow en Team Foundation Build 11 Beta

Actividades para las construcciones automatizadas… ¡nunca son suficientes! Team Foundation Build 11 Beta viene con 69 actividades de workflow, lo que representa no menos de 28 nuevas con respecto a la versión 2010. De ellas, 14 están pensadas para usarlas en la personalización de nuestras construcciones automatizadas, prácticamente documentadas por completo, y listas para ser utilizadas.

Todas estas actividades están muy bien explicadas en la  documentación disponible en MSDN, pero voy a hacer un pequeño resumen, más que nada para ayudarme a recordarlas .

GetCommonLocalPath y GetCommonServerPath

Dada una colección de rutas locales o de servidor, estas actividades devuelven la ruta común de mayor longitud para todas ellas.

IsNotNull<T> y IsNull<T>

Comprueban si una expresión Visual Basic es no nula o nula, respectivamente.

QueryShelvesets

Hace una consulta sobre el servidor de control de versiones, y devuelve una lista de conjuntos de cambios aplazados (shelvesets) que cumplen el criterio dado. El criterio puede definirse mediante el nombre del conjunto de cambios aplazado y el propietario.

RunTests

Esta es quizá una de las actividades más interesantes de las nuevas. Nos permite ejecutar pruebas usando el nuevo Visual Studio Test Runner, que a su vez nos da soporte para el uso de frameworks de pruebas unitarias distintos a (pero incluyendo) MSTest, como NUnit o xUnit. Esta actividad es utilizada en la misma plantilla DefaultTemplate.11.1.xaml para ejecutar las pruebasm si especificamos Visual Studio Test Runner, en el cuadro de diálogo Test Source,  en la pestaña Process de la ventana de definición de la construcción automatizada.

Aquí podemos ver el lugar donde se puede seleccionar el Test runner, que por defecto es Visual Studio Test Runner:

Y aquí es donde la actividad RunTests es utilizada en la plantilla de construcción automatizada DefaultTemplate.11.1.xaml:

TfGet, TfResolve, TfShelve, TfUnshelve, TfUndo, y TfWorkfold

Estas actividades son “wrappers” a los correspondientes comandos de tf.exe, que nos proporcionan más formas útiles de interactuar con el servidor de control de versiones desde una construcción automatizada. 

WriteBuildTestError

Escribe un mensaje de error de test en el log de la construcción automatizada, el cual también aparece en la vista de resultados de la construcción automatizada:

WriteCustomSummaryInformation

Escribe un mensaje en la vista “Build summary” (el resumen de la ejecución de la construcción automatizada). Este mensaje puede incluir hipervínculos, y es posible especificar la sección dentro del “build summary” donde aparecerá el mensaje. El resultado tiene este aspecto:

New workflow activities in Team Foundation Build 11 Beta

Build activities… you just can’t get enough! Team Foundation Build 11 Beta comes with 69 workflow activities, which represents no less than 28 new ones compared to the 2010 version. From these, 14 of them are intended for use in build customizations, almost fully documented, and ready to be used.

All these activities are nicely explained in the available documentation at MSDN, but I’m going to make a brief summary, mostly for helping myself to remember them .

GetCommonLocalPath and GetCommonServerPath

Given a collection or either local or server paths, these activities will return the lowest-level common parent folder of all of them.

IsNotNull<T> and IsNull<T>

Test if a Visual Basic expression is either not null or null.

QueryShelvesets

Queries the version control server and returns a list of shelvesets which met the given criteria. The criteria can be defined using the shelveset name and the owner.

RunTests

This is maybe one of the most interesting activities among the new ones. It allows us to run tests using the new Visual Studio Test Runner, which in turn lets us to use unit testing frameworks other than (but including) MSTest, such as NUnit or xUnit. This activity is used by the DefaultTemplate.11.1.xaml itself to run the tests if we specify the Visual Studio Test Runner, under the Test Source dialog, in the Process tab of the build definition window.

Here we can see the place where we can choose the Test runner, which is Visual Studio Test Runner by default:

And here is the place where the RunTests activity is used inside the DefaultTemplate.11.1.xaml build process template:

TfGet, TfResolve, TfShelve, TfUnshelve, TfUndo, and TfWorkfold

These activities are wrappers to the corresponding tf.exe commands, giving us more useful ways to interact with the version control server from the build process. 

WriteBuildTestError

Writes a test error message in the build log, which appears also in the build results window:

WriteCustomSummaryInformation

Writes a message into the build summary. This message can include hyperlinks, and you can specify the section inside the build summary where the message will appear. The result looks like this:

Agile database development – presentation at SDC2012

Here are the slides for my presentation about Agile database development (with Visual Studio) at SDC2012. Thank you to all the attendants!

Material de la charla ALM para Azure en Destino la Nube 2012

El pasado 7 de marzo estuve hablando sobre ALM para proyectos Azure en el evento “Destino la Nube" 2012” de Microsoft.

Aquí tenéis la presentación que utilicé, y el vídeo con la grabación de la sesión.

Sesiones de ALM: Continuous Delivery, Automatización, NuGet+TFS, VS11, TFS Service, Scrum…

Si no tengo el récord, debo andar cerca… en menos de un mes he participado en tres eventos, en los cuales he sido ponente en un total de seis sesiones. Creo que debería plantearme cobrar por volumen (o por lo menos cobrar ).

Aquí os dejo el material de todas las sesiones; incluso están grabadas en video por si os interesa echarles un vistazo.

Grabación: http://channel9.msdn.com/Blogs/channel9spain/MICROSOFT-ALM-SESSIONS-2012-NOVEDADES-VSTUDIO-11-ENTREGA-CONTINUA

Grabaciones:

https://msevents.microsoft.com/CUI/EventDetail.aspx?culture=es-ES&EventID=1032504086&CountryCode=ES

http://www.zoguo.com/blog/videos/second-nug-como-hacer-el-paso-a-produccion-automatizacion-de-despliegues/

Grabación: http://www.globbtv.com/12/microsite/2012/12-horas-visual-studio-gestion-de-codigo-y-librerias-compartidas

Grabación: http://channel9.msdn.com/Blogs/channel9spain/MICROSOFT-ALM-SESSIONS-2012-NOVEDADES-VSTUDIO-11-ENTREGA-CONTINUA

Grabación: http://www.globbtv.com/2026/videos/12-horas-visual-studio-tfs-mas-ligero-en-la-nube

Grabación: http://channel9.msdn.com/Blogs/channel9spain/MICROSOFT-ALM-SESSIONS-2012-IMPLEMENTANDO-SCRUM-CON-TFS

CAS 2011 retrospective

This is my own retrospective about Agile Spain 2011 conference, which I attended last week.

Start doing

I couldn’t agree more with @eamodeorubio when he says that we should give the event a broader scope. I’m trying to help by writing this post only in English . For example, we got near zero value from @jbrains during the round table because of the language. Start doing sessions in English and inviting international speakers! I gave a session at Agile Portugal conference a few months ago, and I was amazed to see how almost all the communication was carried out in English. Don’t get me wrong – I’m not against Spanish in any way, but we’re losing lots of opportunities for learning, networking and knowing new people by restricting almost all the conference to one language.

More of

More of these awesome sessions! Unfortunately I missed a lot of the program, but I enjoyed specially the keynotes, the Kanban sessions by Mr. Maeda, and to see how @jgomezz is helping to grow up a great team at his organization.

Keep doing

Please keep with that awesome work from the organization people! I've been doing that sort of organization work lately for www.scrumweek.com, and now I can understand how difficult is to take into account all these little details that arise when you have to deal with lots of attendants, speakers, sponsors, etc. My warmest congratulations for them. Thank you to the sponsors as well, for making it possible the event to take place.

Less of

As @pepellou already said, I’d get rid of some philosophical concerns and futile discussions during sessions, retrospectives and the event in general. We’re doing software, let’s focus in that!

Stop doing

I know it’s hard to maintain attention on a Friday afternoon, but for all of these not attending the retrospective, I’d ask them to think twice when they call themselves agilists. It was sad to realize that less that a quarter of the conference attendants stayed there until the retrospective. The only positive outcome of so much people missing, was that there were more mojitos for the ones who stayed, thanks to Autentia. Maybe scheduling the round table later would have help to avoid these fugitives.

And speaking in a broader sense, I’d try to stop some arguments that are commonly carried out between code-centric and process-centric people. Both of them are needed in almost any development project, so I’d stop arguing and start collaborating!

About my session

I spoke about new approaches to several Scrum practices, using the Scrum Guide as direction. Here are the slides:

And here is the video which appears on slide 17, which is being fairly popular:

And the winner is…

I promised to give away a seat for free, for my upcoming Professional Scrum Foundations course at Scrumweek Barcelona 2011, to one of the attendants to my session.

I’ve been impressed about how Yolanda Dura and her team are struggling to succeed with Scrum and Agile, so the prize goes for her. I hope they’ll take a lot of advantage from it.

Talleres sobre ALM en CEIN (Pamplona)

En un par de días voy a estar impartiendo dos talleres en CEIN (Pamplona):

• Gestión de la configuración y compilación automática (18 de octubre): http://www.cein.es/web/es/agendanoticias/agenda/2011/10/18/10598.php
• Herramientas para la calidad (19 de octubre): http://www.cein.es/web/es/agendanoticias/agenda/2011/10/19/10596.php

Si estás por la zona esos días y te interesan los temas, es posible que aún queden plazas libres.

Primer curso Professional Scrum Foundations en España, y mucho más, en la ScrumWeek Barcelona 2011

Del 7 al 11 de noviembre va a tener lugar en Barcelona la segunda edición de la Scrumweek, un evento en el que, con la colaboración de Proyectalis, Plain Concepts y la comunidad, os ofrecemos un montón de cursos, sesiones y actividades que pueden ser de gran valor para profundizar en aspectos concretos del mundo ágil.

Para los que estéis buscando empezar con Scrum con el mejor pie, o reforzar conocimientos, estamos organizando el primer curso oficial Professional Scrum Foundations de scrum.org en España, que además de tener un enfoque y un contenido magníficos, permite obtener la certificación oficial de scrum.org. Antes de que me asalten los trolls de las certificaciones, deciros que el curso en sí mismo merece mucho la pena, como lo pueden atestiguar los cientos de personas que ya lo han recibido a nivel mundial. Si aprovechas el curso, que seguro que lo haces, habrás amortizado de sobra la inversión, aunque luego decidas no presentarte al examen para obtener la certificación (aunque ya que está incluido por probar que no quede ¿no?).

También tendremos una nueva edición del curso Professional Scrum Developer .NET en el cual exprimiremos Scrum en la práctica desde el punto de vista del rol de miembro del equipo, y poniendo énfasis en todas las buenas prácticas que pueden ayudar a trabajar mejor en un equipo ágil: integración continua, TDD, arquitectura, testing, etc. Todo facilitado por una buena ración de nuestras herramientas favoritas, Visual Studio ALM y Team Foundation Server. Y además, también con la opción de obtener una certificación, en este caso reconocida tanto por scrum.org como por Microsoft.

Los dos cursos serán impartidos por Rodrigo Corral (con lo que tenéis la calidad asegurada ), y por mí mismo.

Tendremos además la gran oportunidad de asistir al curso Management 3.0 de Jurgen Appelo, y al de Coaching de Equipos Ágiles de Ángel Medinilla. Sin duda otras dos grandísimas razones para no perderse el evento.

Y por si fuera poco, habrá además una serie de sesiones y actividades gratuitas hechas por y para la comunidad, incluyendo un Coding Dojo, algo tan novedoso en España como un Testing Dojo, y un Open Space para que todo el mundo pueda proponer y hablar de lo que más le interese.

Tenéis toda la información en la página de ScrumWeek Barcelona 2011.

¡Esperamos veros por allí!

Scrum has been updated: a summary of the changes

Adapt or die, is an omnipresent reality in the software development world, and of course Scrum is not an exception. After more than 20 years of history, the most popular agile framework gets an update which doesn’t alter any fundamental principle, but which is good to make some clarifications needed since long time ago. And also, as my fellow/trainer at Scrum.org Giovanni Bassi states, to stress the character of Scrum as a framework more than as a methodology.

The update is reflected in the new version of the Scrum Guide, published by Scrum.org last July 15th 2011. The revision has been done by the creators of Scrum, Ken Schwaber and Jeff Sutherland, with the participation of David Starr, Jim Coplien and other contributors. The Scrum Guide itself has been deeply renovated, with the goal of making it clearer and concise, and to have it gather the Scrum rules in an univocal way. For this reason, they have been excluded from the guide all the tips, strategies, practices and techniques which, even though being useful, aren’t prescribed by Scrum, and thus are optional.

The most important modifications to Scrum, which the authors themselves have gathered in a document, are the following ones:

• The team of people who are in charge of doing the work of creating each increment, is now called Development Team. All the members are Developers, no matter the concrete work they’re doing (coding, testing, design, architecture…). This modification, although seems a simple naming change, has several advantages. First, it reduces the confusion that could exist until now, since the Development Team was called simply Team. I Scrum we deal with another team which is called the Scrum Team (composed of the Development Team, the Scrum Master and the Product Owner), so the distinction between them is clearer. Furthermore, it stresses the cross-functional character of the team as a group of developers, beyond the simple sum of people with concrete roles.
  
• Until now, we said that the Development Team, during the Sprint Planning Meeting, makes a commitment about the work to be completed. The term commitment has been substituted by forecast, so during the Sprint Planning Meeting, the Development Team makes a forecast about the work to be completed during the Sprint. Once again, it may seem a simple naming change, but in my opinion, it has a good purpose: when doing a commitment, we’re ignoring the uncertainty which is present in any Sprint, pretending that we’ll complete the committed work even though changes or difficulties get in the way. Forecast is a more adequate word in order to state that we’ll try to complete the work, but that the result at the end of the Sprint can be different. Does this mean that Developers are now less responsible for their work, or that they can relax during it? That’s not the case: Development Team keeps on committing, of course. But commitment to a concrete list of items is something that usually doesn’t get well with uncertainty and with what happens in reality, while there’s more value in committing to things like working with professionalism, making things the better you can or even fulfilling the Sprint Goal – which gives us guidance about the scope of each Sprint.
  
• Burndown charts (Relase Burndown, Product Burndown, Sprint Burndown), are no longer mandatory in Scrum. We’re supposed to keep on measuring remaining work each day of the Sprint, and the trend towards the end. But the specific tool to use, is up to ourselves. Of course, burndown charts are still an excellent option, though we can use any other progress tracking tool: other kinds of graphs, simple numeric values, percentages, subjective measurements or whatever better fits our needs.
  
• Scrum no longer addresses the concept of Release Planning. It’s something that undoubtedly can be valuable in many organizations and development efforts, and in these cases we’ll obtain benefit from keeping on doing it. But if the circumstances of our organization or development don’t require it, or if we don’t need to keep a medium/long term vision about what we want to achieve, we can simply get to work without worrying about the planning further than the next Sprint horizon. This nuance promotes the framework character of Scrum, and makes it easier to apply it to many development efforts where the short term vision is much more important than having a very clear understanding about where are we going to.
  
• It is no longer mandatory to maintain a bunch of Sprint Backlog Items for each Sprint. Until now, the Sprint Backlog was the list of tasks and concrete pieces of work, resulting of decomposing and analyzing the (commited) forecasted Product Backlog Items for each Sprint. From now on, the Sprint Backlog is simply the forecasted Product Backlog Items, plus a plan to complete them. The concrete definition of what a plan consists on, is left up to the Development Team; of course, we can keep on using a tasks list to reflect the plan, but we have the possibility to choose another options. Many times it’s difficult to decompose into tasks a particular PBI, or it’s not worth the effort, or other mechanisms are preferred in order to express how are we going to do the work. The new version of Scrum gives us the chance of using tasks, or substitute them by any other mechanism, be it a high-level description, a further elaborated technical design (have in mind the exhaustive documentation issue…), or any other option that better fits our needs. Once again, this update stresses the framework nature of Scrum over being a methodology.
  
• The Product Backlog has to be ordered, instead of having to be prioritized. It is, once again, a naming change which maybe will be not so important for many people, and in the other hand will bring difficulties to others, but as the former ones, it has a purpose. In fact, prioritization is nothing but a particular kind of ordering based in relative importance or ROI, but usually these parameters are not the only ones to have in mind when finding out the optimum order in which things should be delivered. I’ll try to clarify furthermore this point in some future post or reference, as well.

Besides from the enumerated changes above, which are the ones stressed by the authors themselves, the new version of Scrum brings some additional changes which I think worth mentioning:

• The minimum recommended number of people for a Development Team is now 3, instead of 5 as it used to be. Nevertheless, the Guide puts clear that the limits are only a guideline, and that the optimum size of the Development Team is the minimum needed to complete the work, and the maximum required to keep agile.
  
• There are other minor naming changes; for example, it’s again being used Scrum Master instead of ScrumMaster, or the term Timebox is replaced by Event when referring to the several meetings in a generic way.
  
• The role and responsibilities of the Product Owner are much more clear and defined than in former versions of the Guide.

I believe that the Scrum update is a very nice piece of news, because it demonstrates the concern of the authors about keeping it up to date and make it more flexible, in order to deal with the changing needs of developments.

Below you can see myself and other fellow trainers from Scrum.org with Ken Schwaber and David Starr, during the last meeting at Boston where we discussed about these and many other interesting subjects .

Scrum se actualiza: resumen de las novedades

Renovarse o morir es una realidad omnipresente en el mundo de desarrollo de software, y por supuesto es aplicable a Scrum. Tras más de 20 años de historia, el marco de trabajo ágil más popular recibe una actualización que no altera ningún principio fundamental, pero que sirve para hacer algunas aclaraciones que venían siendo necesarias desde hace tiempo. Y también, tal y como destaca mi compañero/trainer en Scrum.org, Giovanni Bassi, para acentuar más el carácter de marco de trabajo de Scrum frente al de metodología.

La actualización está recogida en la nueva versión de la Guía de Scrum, publicada por Scrum.org el pasado 15 de julio de 2011. La revisión ha sido realizada por los creadores de Scrum, Ken Schwaber y Jeff Sutherland, con aportaciones de David Starr, Jim Coplien y otros colaboradores. La guía de Scrum en sí misma ha sido profundamente renovada, con el objetivo de hacerla más clara y concisa, y de que recoja las reglas de Scrum de forma unívoca. Por esta razón se han dejado fuera de la guía todos los consejos, estrategias, prácticas y técnicas que, aun siendo útiles, no están prescritas por Scrum y por lo tanto son opcionales.

Las modificaciones más importantes a Scrum, que los propios autores han recogido en un documento, son las siguientes:

• El equipo de personas encargados de realizar el trabajo de crear cada incremento, pasa a ser llamado Equipo de Desarrollo (Development Team). Todos sus integrantes son Desarrolladores, independientemente del trabajo concreto que desempeñen (programación, pruebas, diseño, arquitectura...). Esta modificación, aunque pueda parecer un simple cambio de nombre, tiene diversas ventajas. En primer lugar, reduce la confusión que podía existir hasta ahora, ya que al Equipo de Desarrollo se le venía llamando simplemente Equipo. En Scrum tenemos otro equipo que recibe el nombre de Equipo Scrum (formado por el Equipo de Desarrollo, el Scrum Master y el Product Owner), por lo que la distinción entre ambos queda más clara. Además, pone énfasis en el carácter multidisciplinar del equipo, como grupo de desarrolladores, más allá de la suma de gente con roles concretos.
  
• Hasta ahora, decíamos que el Equipo de Desarrollo, durante la reunión de Planificación del Sprint, hace un compromiso en cuanto al trabajo que va a ser completado. El término compromiso ha sido sustituido por previsión, por lo que durante la reunión de Planificación del Sprint, el Equipo de Desarrollo hace una previsión del trabajo que va a ser completado durante el Sprint. Una vez más puede parecer un simple cambio de nombre, pero tiene también su motivación: al hacer un compromiso, estamos ignorando la incertidumbre que está presente en todo Sprint, pretendiendo que completaremos el trabajo comprometido aunque aparezcan cambios o dificultades por el camino. Predicción es un término más adecuado para expresar que intentaremos llegar a completar dicho trabajo, pero que el resultado al final del Sprint puede ser distinto. ¿Quiere esto decir que los Desarrolladores tienen ahora menos responsabilidad, o pueden relajarse en su trabajo? Nada más lejos de la realidad: el Equipo de Desarrollo por supuesto se sigue comprometiendo. Pero el compromiso con una lista de elementos concretos es algo que suele llevarse mal con la incertidumbre y con lo que ocurre en la realidad, mientras que sí hay valor en comprometerse a conceptos como trabajar con profesionalidad, hacer las cosas lo mejor posible e incluso a cumplir el Objetivo del Sprint (Sprint Goal), que proporciona siempre una guía acerca del alcance de cada Sprint.
  
• Las gráficas de progreso (Relase Burndown, Product Burndown, Sprint Burndown), dejan de ser obligatorias en Scrum. Seguimos teniendo que medir el trabajo restante cada día del Sprint y la tendencia hacia la consecución del mismo. Pero la herramienta concreta que utilicemos es decisión nuestra. Por supuesto que las gráficas de progreso siguen siendo una alternativa excelente, aunque podemos utilizar cualquier otra herramienta de seguimiento de progreso: otros tipos de gráficas, simples valores numéricos, porcentajes, valoraciones subjetivas o cualquier otra que nos convenga.
  
• Scrum no sigue contemplando el concepto de planificación de entregas o versiones (Release Planning). Es algo que indudablemente puede aportar valor en multitud de organizaciones y desarrollos, y en ese caso nos veremos beneficiados de seguir haciéndolo. Pero si las circunstancias de nuestra organización o desarrollo no lo requieren, o simplemente no necesitamos tener una visión a medio/largo plazo de lo que queremos conseguir, podemos simplemente comenzar a trabajar sin tener que preocuparnos de la planificación más allá del horizonte del siguiente Sprint. Este matiz promueve el carácter de marco de trabajo de Scrum, y hace que sea más fácil aplicarlo a multitud de desarrollos en los que la visión a corto plazo es mucho más importante que tener muy claro hacia dónde queremos dirigirnos.
  
• Desaparece la obligación de tener una serie de elementos de la Pila de Sprint (Sprint Backlog Items) para cada Sprint. Hasta ahora el Sprint Backlog era la lista de tareas y trabajos concretos resultado de descomponer y analizar de los elementos de la Pila de Producto (comprometidos) previstos para cada Sprint. A partir de ahora, el Sprint Backlog pasa a ser simplemente el conjunto de elementos de la Pila de Producto previstos, junto a un plan para completarlos. La definición de lo que es un plan queda a criterio del Equipo de Desarrollo; por supuesto que podemos seguir utilizando una lista de tareas para reflejar dicho plan, pero se nos abre la posibilidad de usar otras opciones. En muchas ocasiones es complicado hacer un desglose en tareas de un PBI concreto, o no nos aporta mucho valor hacerlo, o son preferibles otros mecanismos para expresar cómo vamos a llevar a cabo el trabajo. En la nueva versión de Scrum tenemos la opción de utilizar tareas o sustituirlas por cualquier otro mecanismo, desde una descripción a alto nivel, un diseño técnico más elaborado (ojo eso sí con la documentación exhaustiva…), o cualquier otra opción con la que nos sintamos cómodos. Una vez más, con esta modificación se resalta el carácter de marco de trabajo frente al de metodología.
  
• La Pila de Producto (Product Backlog) debe estar ordenada, en lugar de estar priorizada. Es una vez más un cambio de nomenclatura que seguramente será poco significativo para muchos, y en cambio traerá grandes dificultades a otros, pero como los demás que hemos visto, tiene su motivación. En realidad, la priorización no es más que un tipo concreto de ordenación basada en la importancia relativa o el ROI, pero por lo general estos parámetros no son los únicos a tener en cuenta a la hora de determinar el orden óptimo en el que vamos a entregar las cosas. Intentaré asimismo clarificar más este punto en algún artículo o referencia futura.

Aparte de los cambios enumerados, que son los destacados por los propios autores, la nueva versión de Scrum nos trae algún cambio adicional que creo digno de mención:

• El mínimo recomendado de personas para formar un Equipo de Desarrollo pasa a ser de 3 personas, en lugar de 5 como ocurría hasta ahora. Aunque la guía deja claro que los límites son orientativos, y que el tamaño óptimo del Equipo de Desarrollo es el máximo aceptable para permanecer ágil, y el mínimo suficiente para poder completar el trabajo.
  
• Hay otros cambios menores de nomenclatura; por ejemplo se vuelve a usar Scrum Master en lugar de ScrumMaster, o se sustituye la expresión de Bloque de Tiempo (Timebox) por el de Evento para referirse de forma genérica a las distintas reuniones que se mantienen.
  
• La figura del Product Owner y sus responsabilidades quedan mucho más clarificadas y definidas que en anteriores versiones de la guía.

Creo que la actualización de Scrum es una noticia muy buena, ya que demuestra la preocupación de los autores por mantenerlo al día y flexibilizarlo para dar respuesta a las necesidades cambiantes de los desarrollos.

Debajo podéis verme junto a otros compañeros trainers de Scrum.org, junto a Ken Schwaber y David Starr, durante la última reunión en Boston donde tratamos éstos y otros muchos temas interesantes .

Are you using Planning Poker for estimating tasks? Maybe you should reconsider it

If you are using Planning Poker for estimating tasks in the Sprint Backlog, maybe you’d better reconsider it. It’s a tool that can be very useful when estimating user stories or Product Backlog items. But the characteristics of the tasks in the Sprint Backlog are very different from those of the Product Backlog items, and most times Planning Poker, or any other estimation tool based in orders of magnitude, is not adequate for supporting those estimations.

The main reasons of Planning Poker not being a good tool for estimating tasks are:

• Task estimates are usually given in hours, and because of the very nature of the tasks, they should be in the range of a few hours, from less than one hour to a maximum of 16 hours. That is, tasks estimates not necessarily grow by orders of magnitude, as user stories estimates tend to do, but instead of that, they stand within a small magnitude. Planning Poker only provides a few cards for the range of small estimates, and we also have cards to provide large estimations, which shouldn't even occur if the tasks had been decomposed properly.
• As a result of this, when working with Planning Poker we'll miss some values ​​that are not present (on purpose) in a Planning Poker deck, since for estimating tasks we need a ​​more accurate range of values than for estimating user stories. For example we will not be able to give an estimate of 4 or 6 hours for a task, which a priori should be perfectly possible. I've even found teams that were taking more than one card at a time to reach the desired amount for the estimate, which demonstrates the limited usefulness of the tool for this purpose.

Therefore, it would be appropriate to leave Planning Poker, and other methods based on orders of magnitude as T-Shirt Sizing, to estimate user stories. To estimate tasks, we can simply use Wideband Delphi, or even simpler tools such as analogy, decomposition or expert opinion.

Apart from this, it might even be questionable whether it is better to estimate tasks in groups or individually. Ken Schwaber himself recommends the latter (http://kenschwaber.wordpress.com/2010/10/, Example 2), although this would be a good subject for another discussion.

And finally, remember that sometimes it's even better to not estimate the tasks. Estimates are not value that we can deliver to the customer, but rather they can represent waste, and if we can properly do planning without doing the effort of estimating, we will earn this time to advance in the delivery of value. Some teams simply break down the work into tasks of a similar size, so that planning can be based on counting the tasks that we're going to be able to finish.

I’m leaving you with the slides from my session on agile estimation at the last TechEd Middle East, it's mainly about estimation for user stories, but the concepts can be useful in a wider sense.

¿Usas Planning Poker para estimar tareas? Quizá deberías pensarlo mejor

¿Estás usando Planning Poker para estimar tareas en el Sprint Backlog? Quizás deberías replanteártelo. Es una herramienta que puede ser muy útil a la hora de estimar historias de usuario o elementos del Product Backlog. Pero las características de las tareas en el Sprint Backlog son bien distintas de las de los elementos del Product Backlog, y por lo general Planning Poker, o cualquier otra herramienta de estimación que se base en órdenes de magnitud, no es adecuada para dar soporte a estas estimaciones.

Las principales razones por las que Planning Poker no es una buena herramienta para estimar tareas son:

• Las estimaciones de tareas se dan por lo general en horas, y por la propia naturaleza de las tareas, deberían estar en el rango de unas pocas horas, desde menos de una hora a un máximo de unas 16 horas. Es decir, las estimaciones de las tareas no crecen necesariamente en órdenes de magnitud, tal y como lo suelen hacer las estimaciones de las historias de usuario, sino que se mantienen en una magnitud pequeña. En Planning Poker tenemos sólo unas cuantas cartas para el rango de estimaciones pequeño, y además tenemos cartas para dar estimaciones grandes, que no deberían ni siquiera aparecer si las tareas han sido descompuestas adecuadamente.
• Como consecuencia de lo anterior, al estimar tareas con Planning Poker vamos a echar en falta algunos valores que no están presentes (a propósito) en una baraja de Planning Poker, ya que para estimar tareas necesitaremos un rango de valores más preciso que para estimar historias de usuario. Por ejemplo no vamos a poder dar una estimación de 4 o de 6 horas para una tarea, lo cual a priori debería ser perfectamente posible. Me he encontrado con equipos que estaban incluso sacando más de una carta cada vez para poder llegar a la suma deseada para la estimación, lo cual demuestra la poca utilidad de la herramienta para este fin.

Por lo tanto, lo adecuado sería dejar Planning Poker, y otros métodos basados en órdenes de magnitud como T-Shirt Sizing, para estimar historias de usuario. Para estimar tareas podemos usar simplemente Wideband Delphi, o herramientas incluso más simples como analogía, desagregación u opinión del experto.

Aparte de esto, incluso podría ser discutible si es mejor estimar tareas en grupo o hacerlo individualmente. El mismo Ken Schwaber nos recomienda lo segundo (http://kenschwaber.wordpress.com/2010/10/ , Ejemplo 2), aunque esto daría para mucho debate.

Y por último, recuerda que a veces lo mejor es ni siquiera estimar las tareas. Las estimaciones no son valor que podamos entregar al cliente, sino más bien desperdicio, y si podemos permitirnos planificar adecuadamente sin tener que hacer el esfuerzo de estimación, estaremos ganando ese tiempo para avanzar en la entrega de valor. Algunos equipos simplemente descomponen el trabajo en tareas de un tamaño similar, con lo que la planificación se puede basar en contar las tareas que vamos a ser capaces de sacar adelante.

Os dejo con las slides de mi sesión sobre estimación ágil en el último TechEd de Oriente Medio; habla más bien de estimación para historias de usuario, pero los conceptos son útiles en sentido general.

Defining “Done” at XP2011

Although it can seem obvious, sometimes it’s difficult to state when we’ve finished working on a feature or characteristic during a project. It usually happens by omission; that is, we leave apart undone things when time is short or because we don’t consider that they are important. The problem is that these things usually return soon after, as bugs, technical debt or simply pending work, and most times it represents a bigger inconvenience and effort than if we had solved them in the right moment.

Defining explicitly what means that anything is “Done” (and trying to stick to that definition), is essential in order to avoid these situations. This is what I tried to stress during my Lightning Talk last Thursday, 12th at XP2011 conference; I believe that the slides show the idea quite well: