Logo-Scrum.org_[5]

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 Winking smile.

scrumdotorgmeeting

Logo-Scrum.org_

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 Winking smile.

scrumdotorgmeeting

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.

image_thumb[1]

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.

¿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.

image

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.

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:

con no comments
Archivado en: ,,

Aunque pueda parecer evidente, en ocasiones es difícil determinar cuándo hemos terminado de trabajar en una funcionalidad o característica durante un proyecto. Suele ocurrir especialmente por omisión; es decir, nos dejamos cosas sin hacer cuando se echa el tiempo encima, o porque no las consideramos importantes. El problema es que todo esto suele retornar al cabo del tiempo en forma de defectos, deuda técnica o simplemente trabajo pendiente, y en muchas ocasiones supone un inconveniente y un esfuerzo mucho mayor que si lo hubiésemos solucionado en su momento.

Definir explícitamente qué significa que algo esté “Hecho” (e intentar cumplir esa definición), es fundamental para evitar estas situaciones. Es lo que intenté resaltar en mi Lightning Talk del pasado jueves 12 en la conferencia XP2011; creo que la presentación refleja bastante bien el concepto:

con no comments
Archivado en: ,,

The Scrum Guide, written by the Scrum creators Ken Schwaber and Jeff Sutherland, represents the official Scrum Body of Knowledge, and is an essential resource if you want to begin learning about the framework, or to clarify any occasional doubt.

It has been translated to no less than 20 languages, and, although it was already available in Spanish, it has just been released a new version which represents a significant improvement on the translation, and which has been brought up to date according to the last English original.

It has been a pleasure for me to take part in the translation effort, and I hope that the outcome will be valuable for many people… so I encourage you to visit scrum.org and have a look to the Scrum Guide in Spanish.

 

Scrum.org-small2[5]

La Guía de Scrum, escrita por los creadores de Scrum, Ken Schwaber y Jeff Sutherland, constituye la Base de Conocimiento oficial de Scrum, y es un recurso imprescindible para comenzar a aprender sobre el marco de trabajo, o como herramienta de consulta puntual que ayude a despejar dudas.

Ha sido traducida a más de 20 idiomas, y aunque ya estaba disponible en Español, acaba de ser liberada una versión que supone una mejora sustancial en la traducción, y que ha sido puesta al día a partir del último original en Inglés.

Ha sido un placer para mí poder colaborar en dicha traducción, y espero que sea de utilidad para mucha gente… así que te animo a que entres en scrum.org y eches un vistazo a la Guía de Scrum en Español.

 

Scrum.org-small2

Las características de integración entre Project Server y TFS, liberadas con el SP1 de TFS, permiten compartir información de forma sencilla y transparente entre los equipos de desarrollo y los gestores de proyecto, de modo que cada uno de ellos además va a poder seguir trabajando en la herramienta que le resulte más natural y productiva.

Es bastante típico, sobre todo al ver que algunos elementos de trabajo en TFS permiten introducir información de horas, preguntarse si TFS puede utilizarse para que los desarrolladores reporten el avance en el proyecto desde el propio TFS. Utilizando sólo TFS esto no es fácil de conseguir, ya que, aunque en la mayoría de las plantillas de proceso tenemos la posibilidad de actualizar las horas trabajadas en una tarea, no es posible indicar información adicional necesaria, tal como las fechas concretas en las que se han realizado dichas horas.

Por si te lo estás preguntando al leer todo esto, y crees que he tenido una crisis y me he pasado del agilismo al command & control, quiero recalcar que es perfectamente posible ser ágil, y a la vez beneficiarse de usar Project Server. De hecho el equipo estará incluso menos interrumpido y podrá dedicarse mejor a lo suyo, que es la entrega de valor. Es una percepción errónea muy común, pensar que las personas y herramientas dedicadas a la gestión de proyectos a alto nivel en una organización, deben desaparecer si se introducen prácticas ágiles en ella.

Por muy ágiles que seamos en cualquier proyecto en concreto, siempre habrá trabajo de coordinación entre proyectos, de lanzamiento de los mismos, de gestión a nivel organizativo, de mantenimiento del portfolio de proyectos…, y en definitiva de optimizar y sincronizar los esfuerzos que los distintos equipos vayan llevando a cabo. Esto no impide que cada equipo pueda trabajar con Scrum o beneficiarse de las prácticas ágiles; los problemas vienen cuando los gestores de proyecto intentan controlar demasiados detalles, e imponen decisiones relacionadas con el trabajo de desarrollo, que deberían ser tomadas por el equipo.

Por otra parte, un desarrollador ágil estaría cometiendo asimismo un error si no favoreciese la visibilidad de la información necesaria para el seguimiento de proyecto a nivel organización. El control empírico de procesos, que es el corazón de Scrum y de otros modelos ágiles, tiene en la visibilidad su primer requisito. Y si la visibilidad es vital para la buena marcha de un proyecto, más aún lo es un nivel por encima, a la hora de trabajar en los distintos proyectos en conjunto.

Todo esto queda ilustrado de forma muy sencilla en el escenario descrito en los siguientes enlaces, que constituye uno de los modos de funcionamiento de la integración de TFS con Project Server:

Para aprender más acerca de la integración de Project Server y TFS 2010, son útiles los siguientes enlaces:

Además de todo esto, incluyo los enlaces y las diapositivas relacionadas con la sesión que tuvo lugar en marzo en Madrid, y en la cual hablé acerca de la gestión de proyectos en general, Project Server y TFS, y cómo integrar ambas herramientas. Ojo porque se trata de la versión extendida, de 4 horas, de la sesión que posteriormente dio Ibon en evento “Destino la Nube” Smile.

Grabación íntegra y resumen del evento: http://www.globbtv.com/microsite.aspx?id=12&cmd=0&cat=111

Diapositivas:

Project Server and TFS integration feature pack, released with TFS SP1, enables information sharing in a simple and transparent way between development teams and project managers, while everyone being able to continue working with the tool that suits better his needs.

It is very common, specially after realizing that some work items in TFS can receive information about worked hours, to ask oneself if TFS can be used by developers to inform about the progress made on the project. This is not easy to achieve by only using TFS; although most process templates allow us to update worked hours on a task, it is not possible to provide some necessary information, like the actual dates when these hours were worked.

In case you were wondering, while reading, if I’ve suffered a crisis and I’ve stepped from agile to command & control, I’d like to emphasize that it’s perfectly OK to be agile, and at the same time benefit from using Project Server. In fact, the team is going to be less interrupted and thus they’re going to be able to work more on delivering value, which is what they are supposed to do. It is a common misconception to think that people working on high level project management within an organization should move away if agile practices are adopted into it.

No matter how agile we are in any particular project, there always will be some work of coordination between projects, kick-off, enterprise-level management, portfolio maintenance…, and at the end, of optimizing and synchronizing the efforts which each team is performing. This doesn’t impede each team from working with Scrum or from benefiting of agile practices; in fact, trouble usually comes when project managers try to take control of too much details, and impose decisions related to development work, which should be left up to the team.

On the other hand, any agile developer would be mistaken if he didn’t facilitate visibility of the information, necessary for project tracking at the organization level. Visibility is the first requirement for empirical process control, which is the heart of Scrum and other agile models. And, if visibility is a key for assuring any project’s good health, it is even more important one level higher, when working on different projects as a whole.

These concepts are well described in the scenario presented in the following links, which is one of the ways the TFS and Project Server integration works:

If you want to learn more about Project Server and TFS 2010 integration, these links will be useful:

Besides that, I'm including the links and slides from the session that took place last March in Madrid, where I spoke about project management in general, Project Server and TFS, and integrating them. Warning: it's the extended version, 4-hour long, of the session given later by Ibon at the event “Destino la Nube” Smile (everything in Spanish).

Entire recording and summary of the session: http://www.globbtv.com/microsite.aspx?id=12&cmd=0&cat=111

Slides:

con no comments
Archivado en: ,,

 

ProfessionalScrumDeveloper_500px

 

Coincidiendo con la ScrumWeek Madrid 2011, se va a realizar el primer curso Professional Scrum Developer .NET en España, organizado por Plain Concepts (impartido por Rodrigo y un servidor), y con el apoyo de Microsoft.

Me gustaría resumiros por qué os puede interesar un curso PSD, y qué os puede aportar de valor a los que estáis trabajando como desarrolladores en proyectos Scrum o tenéis pensado empezar a hacerlo.

En cuanto a los cursos en general:

1. PSD es un curso orientado específicamente a desarrolladores. La mayoría de los cursos Scrum que se ofrecen, suelen ser generalistas y presentan todos los roles sin profundizar en ninguno en concreto, o se centran más en el ScrumMaster. PSD está diseñado para desarrolladores en un equipo Scrum, que al fin y al cabo constituyen la gran mayoría de los comprometidos en un proyecto.

2. Un equipo Scrum es multi-funcional; debe ser capaz de afrontar cualquier tarea que sea necesaria para convertir el compromiso adquirido en un incremento de valor en cada Sprint. En un curso PSD se tratan prácticas y herramientas que facilitan esta multi-funcionalidad, no sólo relacionadas con la programación, sino también desde el punto de vista de la arquitectura, las pruebas, la gestión de defectos y otros muchos aspectos a los que un equipo, y por lo tanto sus miembros, se enfrentan durante un proyecto.

3. Un curso PSD es fundamentalmente práctico. Por lo general, la mejor forma de asentar los conceptos que se aprenden es aplicarlos en la práctica, y en un curso PSD vas a hacer precisamente esto, trabajando en equipo, utilizando desde el principio las prácticas y herramientas presentadas, y empleándolas en construir incrementos de valor tal y como se haría en un proyecto real.

4. Durante un curso PSD se realiza una inmersión total en Scrum. No sólo se presentan los elementos que constituyen Scrum, además se trabaja durante varios días en el marco de un proyecto, realizando Sprints y el resto de prácticas de Scrum como reuniones de planificación de Sprint, retrospectivas y demos. Se obtiene una experiencia Scrum completa.

5. Un curso PSD se basa en la definición correcta de Scrum, tal y como fue concebido por Ken Schwaber y Jeff Sutherland, y está recogido en la Scrum Guide. Se podría discutir bastante acerca de si es posible o beneficioso modificar Scrum, pero al menos al terminar un curso PSD, tendrás la base correcta sobre la que comenzar a trabajar y a perseguir mejoras.

6. Durante el curso se tratan específicamente disfuncionalidades, y dificultades típicas que suelen suponer un problema a la hora de aplicar Scrum en proyectos reales. Por lo tanto cuando aparezcan los problemas, tendrás un criterio que te guíe en la búsqueda de soluciones.

7. Uno de los mayores atractivos del curso es la interacción con los demás asistentes. No sólo te vas a divertir, sino que vas a aprender un montón de la experiencia de compartir varios días trabajando en equipo con personas que tienen diferentes puntos de vista y modos de enfrentarse a los problemas.

En cuanto a los cursos PSD.NET en particular:

8. PSD.NET tiene el respaldo oficial de Microsoft. Ha sido desarrollado por Scrum.org y Microsoft en conjunto, y es EL CURSO con mayúsculas para Visual Studio 2010. No hay más cursos sobre Visual Studio 2010 y ALM en los que Microsoft haya participado en el desarrollo; éste es el del grupo de producto de Visual Studio.

9. Es el único curso respaldado por Microsoft en el que se trata Team Foundation Server a fondo, desde la perspectiva del desarrollador. Sólo existe un curso oficial en MSLearning para TFS, pero está centrado en administración.

Y por último, pero no menos importante:

10. Asistir al curso te la la posibilidad de obtener la certificación PSD.NET, una certificación reconocida internacionalmente por la industria que demuestra el conocimiento adquirido acerca de cómo desarrollar software con Scrum en la plataforma .NET. Pasar la evaluación es duro, pero con la ayuda del curso irás bastante bien preparado.

 

Después de escribir el título del post, se me han ocurrido un par de razones más que aplican al curso concreto de la ScrumWeek Winking smile:

11. Al ser el primer curso en España, queremos que se pueda beneficiar del mismo el máximo numero de personas posible. Por esta razón tiene un precio muy ajustado que supone un 50% de descuento sobre el precio oficial recomendado.

12. Por si el Inglés es un impedimento para ti, el curso va a ser en Español. Eso sí, los materiales, y el examen de certificación (si te animas a hacerlo), por ahora sólo están disponibles en Inglés.

 

Ánimo que todavía queda alguna plaza disponible. ¡Nos vemos en la ScrumWeek!

 

ProfessionalScrumDeveloper_500px_thu

 

During ScrumWeek Madrid 2011, it’s going to take place the first Professional Scrum Developer .NET course in Spain, arranged by Plain Concepts (given by Rodrigo and myself), and with the support from Microsoft.

I’d like to summarize why a PSD course can be interesting for you, and why it can be valuable for any of you working as developers in Scrum projects or planning to do so.

About courses in general:

1. PSD is specific for developers. Most Scrum courses available tend to be generic, and present all the Scrum roles without going in depth into any of them, or taking care only of the ScrumMaster. PSD is designed with developers in mind, within a Scrum Team, who at the end make up the majority of the ones committing to a project.

2. A Scrum Team is cross-functional; it must be able of facing any task needed to turn the agreed commitment into a valuable increment each Sprint. During a PSD course you’ll deal with practices and tools that enable this cross-functionality, not only related to coding, but also from architecture, testing, bug management and many other aspects which a team, and thus, its members, face during a project.

3. A PSD course is mainly practical. Usually, the best way to lay down learned concepts is to apply them in practice, and during a PSD course you’re going to do exactly that, working as a team, using the presented tools and practices from the beginning, and employing them in building value increments the same way you’d do during a real project.

4. During a PSD course you’ll experiment a total immersion in Scrum. Not only the elements which make up Scrum are presented, but also work is done along several days within a project, doing Sprints and the rest of the Scrum practices like Sprint Planning meetings, Sprint Reviews and Retrospectives. You’ll obtain a complete Scrum experience.

5. A PSD course is based on the right Scrum definition, as it was conceived by Ken Schwaber and Jeff Sutherland, and is gathered into the Scrum Guide. You can discuss a lot about if it’s possible or beneficial to modify Scrum, but at least, once you’ve finished a PSD course, you’ll have the right base on which you’ll be able to begin working and pursuing improvements.

6. During the course we’ll specifically deal with typical dysfunctions and difficulties which usually represent a problem while applying Scrum for real projects. Therefore, when problems arise, you’ll have support that will guide you in the search for solutions.

7. One of the greatest advantages of the course is the interaction with the attendants. Not only you’re going to have fun, but also you’ll learn a lot from the experience of sharing several days, working as a team with people who have different points of view and ways of facing the problems.

About PSD.NET courses in particular:

8. PSD.NET is endorsed by Microsoft. It has been jointly developed by Scrum.org and Microsoft, and is THE COURSE for Visual Studio 2010. There’re not any other courses about Visual Studio 2010 and ALM where Microsoft has participated in developing; this is the one from the Visual Studio product group.

9. This is the only Microsoft supported course where Team Foundation Server is presented in depth, from a developer’s perspective. There’s only one official course from MSLearning for TFS, but it is centered around administration.

And at last, but not least:

10. Attending the course will give you the chance of obtaining the PSD.NET certification, a worldwide industry-recognized certification, that assures the knowledge about developing software with Scrum in .NET platform. It’s not easy to pass the assessment, but the course will prepare you pretty well to take it.

 

After writing the title for the post, I thought about two more reasons regarding specifically to the course being held during ScrumWeek Winking smile:

11. Since it’s the first course in Spain, we’d like to give to the maximum number of people the opportunity to take it. Because of this, it has a very tight price which means a 50% discount over the official recommended price.

12. If English is an issue for you, the course is going to be given in Spanish. But have in mind that materials and assessment (if you finally go for it) are in English at the moment.

 

There are still some remaining seats! See you at the ScrumWeek.

Last weekend (November 12th and 13th) I attended Agile Open Spain 2010, which took place at La Salle (Barcelona) and counted with Plain Concepts as the main sponsor.

It’s very difficult to get bored at an event like an Open Space, so my expectations got easily fulfilled. This is a short summary of my experience around there:

  • Working Software, session proposed by Xavi Gost. It was about the importance of working software as the only valid measure of the progress and the commitment acquired to our customers. Big (and often uncomfortable) truths got surfaced
  • Software Craftsmanship with Enrique Comba. It was a quite interesting session, where it was described nicely the approach to software development as an activity closer to craftsmanship than to industrial production (even taking into account that the craftsmen manifested a preference for growing apart from what they called “Rugby people”)
  • Frameworks, yes or not?, with Xavi Gost and Roberto Canales. A discussion took place about the convenience of using frameworks for development. For my taste, the conversation derived too much into “philosophical” terms (I was hoping something more concrete or maybe more close to development with frameworks, rather than the “social” implications that can be derived). But nevertheless very interesting
  • Scrumban, proposed by Ángel Medinilla, Frogtek and Biko. A very convenient way of dealing with all that non-planned demand that tends to be the source of many problems during Scrum projects
  • Training and certification. This session was proposed by me, and during it we were talking about the available options for getting training and certification in the Agile world. We put special attention to the Professional Scrum Developer program from scrum.org, that I’ll explain around here soon
  • Slack (sorry, but I can’t remember the name of the person that proposed the session). We were talking about different ways of assuring a minimum time for relax during the day, which allows the team get to the necessary degree of concentration and make their work better
  • Retrospective. It consisted in several group activities intended to review what happened along the day, and potential improvements. To be honest, the first part, where the most relevant ideas were surfaced by means of a game involving post-its, was not very valuable for me. Mainly because each individual will have something more valuable for her, and does not have to match another’s vision, neither I find a lot of benefit in comparing it with the global vision. On the other hand, subsequent “tribes” game, intended for identifying improvements for future events, revealed itself as very interesting and fruitful for me

As the closing act for the event, we attended an additional session held at a quite different place, sharing dinner, drinks and conversation with a handful of the attendants to the event. Of course, it was at least as enriching as the rest of the sessions that took place during the day Smile

Congratulations to the organization crew, and hope to see you at the next Agile Open…

El pasado fin de semana (12 y 13 de noviembre) asistí al Agile Open Spain 2010, celebrado en La Salle (Barcelona) y que contó con Plain Concepts como principal patrocinador.

Es muy difícil aburrirse en un evento tipo Open Space; de hecho, como era de esperar, en general se cumplieron las expectativas con creces. Éste es un pequeño resumen de mi experiencia:

  • Software que funciona, sesión propuesta por Xavi Gost. Se intentó poner de manifiesto la importancia de el software que funciona como única medida válida del avance del compromiso adquirido con nuestros clientes. Salieron a la luz grandes (y también incómodas) verdades
  • Software Craftmanship con Enrique Comba. Me pareció una sesión interesante en la que se describió muy bien la aproximación al desarrollo de software como una actividad más cercana a la artesanía que a la producción industrial (pese al distanciamiento que manifestaron los artesanos de lo que llamaban “la gente del Rugby”)
  • Frameworks sí o no, con Xavi Gost y Roberto Canales. Se estuvo discutiendo acerca de la conveniencia del uso de los frameworks en los proyectos de desarrollo. Para mi gusto la conversación derivó demasiado a temas “filosóficos” (yo esperaba algo más concreto o quizá más centrado en el propio desarrollo con frameworks que en las implicaciones “sociales” que pueda tener). Pero muy interesante en cualquier caso
  • Scrumban, propuesta por Ángel Medinilla, Frogtek y Biko. Una forma muy buena de tratar con toda la demanda no planificada que suele provocar bastantes problemas durante los proyectos Scrum
  • Formación y certificación. Esta sesión fue propuesta por mí, y en ella estuvimos hablando acerca de las opciones de formación y certificación disponibles en el mundo ágil. Nos detuvimos en especial en el programa Professional Scrum Developer de scrum.org, del cual os daré más detalles por aquí en breve
  • Slack (lo siento, no recuerdo el nombre de la persona que la propuso). Estuvimos hablando de maneras de asegurar un mínimo de tiempo de descanso a lo largo del día, que permita al equipo llegar a la concentración necesaria y hacer mejor su trabajo
  • Retrospectiva. Consistió en unas actividades de grupo en las que se recapituló lo acontecido y se buscaron posibles mejoras. La verdad es que a la primera parte, en la que se buscaron las ideas más relevantes mediante un juego con post-its, no le encontré mucho valor. Sobre todo porque cada uno tendrá algo que haya valorado más y no tiene por qué coincidir con la visión de otro, ni le veo mucho beneficio en compararlo con la visión global. En cambio, el juego de las “tribus” posterior para identificar puntos de mejora para próximos eventos, me pareció muy interesante y fructífero

Como cierre al evento tuvimos una sesión adicional en un escenario un poco distinto, compartiendo cena, copas y conversación con buena parte de los asistentes al evento. Por supuesto que fue como mínimo igual de enriquecedor que el resto de sesiones del día Smile

Felicidades a la organización, y nos vemos en el próximo Agile Open…

Plain Concepts has just received the ALM Inner Circle Western Europe 2010 Award from Microsoft, which acknowledges the effort carried on for the ALM area in Europe, helping our customers to work better with Microsoft tools in the field of Application Lifecycle Management. In the photo below, you can see Rodrigo taking the Award at the partners event, which took place this week in Antwerp, from Julio Fernández Gayoso.

entrega_ALM_IC_WE_2010_thumb

Our fellows at Test House received the award too, congratulations for them!

This is the second consecutive year that we’ve been awarded, which in addition to the fact that we’re the first (and at the moment, the only) Spanish partner that has achieved the ALM  Competency at Microsoft, proves the outstanding performance of the Plain Concepts team.

My warmest congratulations to everyone devoted to ALM in Plain Concepts, and of course, we’ll keep on working in order to keep the same level of quality and commitment.

 

ALM_IC_WE_2010_thumb1

Plain Concepts ha recibido el premio ALM Inner Circle Western Europe 2010 de Microsoft, que reconoce el esfuerzo llevado a cabo en el área de ALM a nivel europeo, ayudando a nuestros clientes a trabajar mejor con las herramientas de Microsoft en el ámbito de la gestión del ciclo de vida de las aplicaciones. En la imagen podéis ver a Rodrigo recogiendo el premio en el evento de partners celebrado esta semana en Amberes, de manos de Julio Fernández Gayoso.

entrega_ALM_IC_WE_2010

Nuestros compañeros de Test House también fueron premiados, mi enhorabuena para ellos.

Es el segundo año consecutivo que recibimos el premio, lo cual unido a que somos el primer (y hasta el momento único) partner en España en conseguir la competencia ALM en Microsoft, demuestra el excelente desempeño del equipo de Plain Concepts.

Enhorabuena a todos los que nos dedicamos a esto en Plain Concepts, y por supuesto seguiremos trabajando para mantener el mismo nivel de calidad y compromiso.

 

El próximo jueves 21 de octubre estaré en el CIIN de Cantabria para dar un repaso a todo lo relacionado con gestión de la configuración y compilación automatizada. La idea es exprimir un poco el control de código fuente de TFS, y hacer unas cuantas builds ;-)

Tenéis todos los detalles aquí.

Espero veros en el taller, un saludo!!!

con 1 comment(s)
Archivado en: ,,,,

As you maybe already know, a new Visual Studio 2010 RTM virtual machine is available, so you can play around with VS, TFS, and the provided hands-on-labs.

There are versions available for Hyper-V, Windows Virtual PC and Virtual PC 2007. But if for any reason you do want to use VirtualBox (I’ll not deal with the reasons for choosing a virtualization platform here ;-) ), you can run into problems when trying to start the virtual machine.

I downloaded the Virtual PC 2007 version with the idea of creating a new VirtualBox machine and attaching the .vhd to it. But after setting up the machine with the standard configuration, during booting process, it a blue screen appears with a “STOP 0x0000007B” error message.

It seems that the issue is related to the fact that the installed operating system is configured for an IDE controller (the one used in Virtual PC 2007), while the VirtualBox configuration wizard leaves the .vhd attached to a SATA controller.

The fix consists simply on taking away the SATA controller and attaching the .vhd to the IDE controller. After doing it, the virtual machine should manage to boot, and from that point you’d be ready to install the VirtualBox guest additions and start having fun!

This is how the working configuration looks for me (Spanish interface here, but it’d be straightforward to figure it out for other languages):

 

image

con no comments
Archivado en: ,,,

A little more than two weeks have gone since 70-512 exam is available, which qualifies for MCTS certification in TFS 2010 administration. It’s the successor of 70-510, which covered TFS 2005. In fact, five years and two versions later seem a bit of too much time from my point of view, but at least the exam has been made available short after the new TFS 2010 bits were released. This is an important point, since 2010 means a dramatic evolution from former versions, thus there are many new features in 70-512 that were not covered in 70-510.

Whishing to renew my certification, last June 24th I passed the exam, just after my fellow Ibon who took me over only by a day; as you can see, here at Plain Concepts we’re a bit of impatient, and when we want something we want it delivered right now!!! ;-)

The exam was a bit more difficult for me than 70-510, because there’re many more things to take into account, and the time to gain the required experience has been much shorter. But I think it’d be not so difficult if you have been working deploying and administering TFS 2010, and even less if you’ve worked with former versions.

In many aspects, TFS administration has been simplified with the release of tools like the administration console or TFSConfig.exe.

But without any doubt, there are other areas where complexity has grown much more: high availability for application tier, build agents and controllers, process templates changes, and an endless bunch of new details. And even more if you take into account that monster, from the point of view of administration, which is Lab Manager. Of course, all of these things and many more are evaluated during the exam.

Another problem that arises is that, as you can see at the exam’s site, preparation materials are not quite abundant; for example, there’s not any book available, so TFS installation and administration guides are the best tools that you can rely on.

Nevertheless, as I said before, I think that if you’ve been into working with TFS, and giving a thorough read to the administration guide, there’d be not any problem to pass it. So go for it!!!

When I found, while reading Agile Spain mailing list, that someone had the idea of using LEGO as an aid for Scrum Coaching, I thought that it could be a very enjoyable way of reinforcing some concepts that are addressed during the training.

But after using it during several sessions, I only can confirm what I suspected. Not only we enjoyed it like little Childs, but even more, I think that it was much easier for everyone to begin to get in touch with all the learned issues.

 IMAG0076 Digimax A50 / KENOX Q2

Simply put, the idea consists on going through a handful of Sprints, where the Team tries to build a LEGO town, committing to a backlog that has been proposed by me (as the product owner), and that has been estimated and prioritized by all the attendants working together (as members of the different Teams). As you can imagine, people gets fascinated when you show them the pile of LEGO bricks and you ask them for getting to work ;-). The process I followed, with some minor modifications, is the one described in the link which I included at the beginning of the post.

 IMAG0073 Digimax A50 / KENOX Q2

Following you can find my retrospective, based on the experience gained during several sessions carried out with different teams.

Things that went well

  • You can play the game no matter which is the technology or the kind of projects in which the Team is involved
  • Concepts are quickly settled down because of the practical approach
  • People get involved immediately
  • Lots of fun!!!

Things that didn’t go so well

  • Usually time gets too short to finish it properly
  • It’s a bit confusing to find out the tasks for the Sprint Backlog
  • There are several key concepts in Scrum that you can’t cover quite well, because the lack of time or the difficulty to carry them out; for example, Daily Scrum. But it’s always possible to complement this game with other related ones
  • If you are not careful, sometimes people pays more attention to playing with the bricks than to learning the process

Improvement actions

  • Better adjustment of Sprint length and cadence
  • Include essential Scrum practices not covered yet
  • Buy more LEGO bricks (ok, I don’t really need them, but this is the perfect excuse… you never can get enough LEGO bricks)

 Digimax A50 / KENOX Q2 Digimax A50 / KENOX Q2

con 1 comment(s)
Archivado en: ,,,
Más artículos < Página anterior - Página siguiente >