Son las estimaciones tan malas?

Una de las charlas que mas me gusto del Bolivian Scrum Day 2013 es la de Thomas Wallet "No estimarás" - Mensaje fuerte, no? Y creo que esta bueno para mover el bote (como dicen en 10 Pines), pero, como siempre, tenemos que tomar el mensaje con cuidado y no echarle la culpa a la herramienta, como escuche alguna vez decir a Henrik Kniberg. Es estimar realmente malo? Existen muchas situaciones donde claramente no lo es. Si yo tengo que tomar un vuelo en Viru Viru y quiero saber cuando es que debería estar en el aeropuerto, realizo una estimación de cuanto voy a tardar y cuando tendría que levantarme. Hablando de software, muchas veces necesito o me es útil tener una 'estimación' del costo de una feature (para saber si me va a alcanzar la plata - poder planear -  o para saber si las voy a construir o voy a construir otra - poder priorizar -). Entonces cuando la estimación es mala o se convierte en un problema?

- Si lo voy a hacer si o si: tiene sentido estimar algo que si o si tengo que completar? Piensen en sus tareas personales? Se ponen a pensar cuanto van a tardar en hacer algo si lo tienen q hacer si o si? Perder tiempo en estimar en estos casos es realmente eso, perderlo.

- El otro gran problema con las estimaciones es cuando se toman como un contrato y no se tiene en cuenta que son estimaciones!! Y que es díficil estimar. Y que mientras menos se entienda el problema, peor se va a estimar!!

Entonces, yo que soy un poco más moderado propongo que entendamos porque estamos estimando y que tengamos en cuenta el retorno de inversión de esta estimación. Que quiero decir con esto? Si de esta estimación no depende absolutamente nada importante de la empresa, no perdamos mucho tiempo!! (y tampoco perdamos el tiempo haciendo tests). Si por el contrario, para la empresa es muy importante, entonces 'invirtamos' más tiempo en la estimación. Preocupemosnos un poco más!!

Otro de los puntos que me llamó la atención de la charla es que el modo talibán de dejar las estimaciones es básicamente intentar tener items de mas o menos el mismo tamaño y abandonar las iteraciones, midiendo el throughput y el ciclo... Esto también me hace ruido. Yo no creo que este cambio en el ciclo de vida del proceso este relacionado con las estimaciones y si con la no utilidad de las iteraciones. Este punto me va a ser mucho más díficil de fundamentar (será porq no lo tengo tan claro), pero voy a intentarlo. Tener items del mismo tamaño siempre es bueno, en Scrum, Kanban, XP o donde quieras. Permita calcular cualquier métrica mas facilmente, permite encajar los items dentro del sprint backlog, etc. Otro punto (no relacionado, pero bueh.. lo tiro!): Samuel Crescencio dijo que en su opinion, las retrospectivas son el componente mas importante de Scrum (quizás lo dijo para exagerar la importancia de las retrospectivas..). Bueno, pues para mi el componente más importante de Scrum son las iteraciones (timeboxedas). Por que? Porque las iteraciones son las q mantienen el foco, crean el pulso del proyecto, permiten calcular la velocidad y son el enabler de la inspeccion y adaptación. Adonde voy con todo eso? (ni yo se). A q si queres dejar de estimar usando Scrum podes hacerlo. Simplemente pone un numero (aleatorio) de ítems en una iteración y dps. ajustalo en las iteraciones subsiguientes (si tenes ítems del mismo tamaño, esto debería ser muy fácil). Pero debe haber otras razones mas importantes para eliminar la iteración (o para no hacer iteraciones o Scrum si nunca hiciste). Mucha variabilidad en la capacidad del equipo.. Un equipo de desarrollo que comparte responsabilidades de producción.. hasta podría enumerar una diferencia grande en el tamaño de los ítems (haciendo q algunos no entren en la iteración), pero partimos de la base q el tamaño de los ítems es similar..Entonces quizás es a mi q se me mezcló un poco la ultima opción o no se que, pero me cuesta ver la opción de ítems del mismo tamaño + Kanban como una opción para dejar de estimar. Para mi, dejar las iteraciones tiene que tener que ver con otra cosa.


En conclusión creo que las estimaciones sigue siendo buenas, cuando se las usan para lo que son y cuando existe confianza entre las gente que realiza las estimaciones y la gente que las va a usar. Desde que leí a Alistair Cockburn, siempre dije que creo q tenemos que ser críticos y entender el porque de cada uno de los componentes/tecnicas que usamos en nuestra metodología para tener la metodología más liviana que resuelva nuestros problemas (componentes que no aportan valor o son mal usados son desperdicio). Las estimaciones pueden ser un componente que agrega valor o no. Evaluemosló.

Daré una charla en el Scrum Bolivia Day 2013!!

Si, estoy muy contento porque a fin de mes tendré la oportunidad de asistir al Scrum Bolivia Day en Santa Cruz de la Sierra, un lugar que hacer mucho tiempo quería ir! Gracias Juan por la invitación y nos vemos pronto!!

Descripción

La revolución ágil introdujo grandes cambios en todas las áreas del desarrollo de software y el area de management no fue una excepcion. Pero cuales fueron estos cambios? Cuales son los desafíos del manager en la era ágil? En esta charla abordaremos estos tópicos con el objetivo de entender mejor las responsabilidades de un manager ágil y brindaremos herramientas que los ayudaran en sus desafíos diarios. Entre los puntos incluidos están: teoría de sistemas adaptativos complejos, como crear equipos motivados y como delegar responsabilidades.

Agile Knowledge Repository

Summary

This area deals with knowledge acquisition and knowledge management in an organization. One of the main points of CMMI is to maintain a process repository (as expressed in the Organization Process Definition Area) that enables the organization to acquire and maintain its knowledge. Agile Organizations should maintain this repository, by creating an Agile Culture (I expressed my doubts about being able to create a documented knowledge repository in an agile software organization, as I think software development is a craft). Therefore, processes and techniques live inside the people's brains of the organization and is acquired and maintained by practicing and teaching those process and techniques. Knowledge is maintained using the model used in the past by guilds.

Goals

- There is a knowledge path that people follow inside the organization, starting from apprentice (someone that is learning, does exercises, pair programs with someone and has a lot of time to educate himself) to Journeyman (which is someone that knows the craft and is able to teach it).
- Knowledge is shared openly and collaboratively inside the organization. Culture is strong. More senior software craftsmen lead and teach the rest of the group on "how we do things inside here". Values float in the air.

Standard Practices

I have taken these practices from 8thlight, a company I visited a few months ago. In 8thlight:

- Employees start as apprentices. Their job at that moment is to learn how to develop software and how the company manages their projects. They do exercises and pair programming with more senior craftsmen.
- Software craftsmen have one or more apprentices in charge. So their responsibility is to teach apprentices the processes and techniques used inside the organization.
- Knowledge is shared and maintained by practicing together. Employees do code retreats or katas together. The philosophy is programmers need to practice their craft and this practice is performed on code that is not business oriented.

Presentation in Agiles 2012

Transforming Cultures on Prezi

Agile Collaboration Area

Summary

The Agile Manifesto says "Business people and developers must work together daily through the project". Everyone, within the organization and beyond it (i.e. clients) must work jointly towards a shared objective, help each other, have good intentions, share all the information and ultimately to do what's best for the everyone involved.

Goals

- Collaboration between the organization and its clients is enabled financially. Contracts should enforce collaboration.
- Collaboration among team members in a project and among different departments of the organization should be enforced. 
- All stakeholders should be involved throughout the duration of a project.

Standard Practices

Clients work with team members to specify the requirements and prioritize them in a backlog that will be used continually during the project. Features are presented to these clients early in the life of the project to be able to receive feedback and change according to it. This change should be enabled in the contract (if the contract penalizes delays, the team won't be willing to accept any changes during the life of the project). Everyone in the team should share the same objectives. Therefore, policies and rewards should be devised with this in mind.

Agile Communication Area

Summary

Communication is key in an Agile organization. Developing software is a communication problem. Communication needs to flow as fast and clear as possible among all members of the organization. An environment that enables and enforces communication should be built.

Goals

- There is an environment that allows interactions among all members in the organization freely.
- All members of the organization can easily  communicate with each other.
- There is complete transparency to everyone about the goals, status, direction of the project/organization.

Standard Practices

- The office is an open space, where all members share the same information. There are visual radiators in many places of the office that allow members of a project and all members in the organization to understand the status and direction of the different projects.
- Team members in a project interact as much as possible to synchronize and make sure there is a shared understanding of what needs to be built. In Scrum, there are different meetings that enable and enforce this communication: 1) Planning meeting at the beginning of each iteration 2) Daily Standup every day 3) Demo and Retrospection at the end of the iteration. Besides this, practices like pair program or code review sessions push the members to interact even more. Understanding the effectiveness of the different types of communication types helps devise a communication strategy. When is possible, face to face communication is the most effective type of communication but there are situations when the team is distributed geographically and therefore other communication methods should be used. Increasing the communication to its highest level should be the direction in these cases.

Self Organization Area

Summary

This area's goal is to create an environment where all members feel empowered to contribute all their knowledge and energy for the organization's benefit. Leaders and more experienced individuals should guide less experienced ones and set constraints and directions.

Goals

- Team members are empowered
- The team self organizes to create the best solution to the specified problems.
- Leaders create and maintain an environment where self-organization can thrive

Standard Practices

- Within a project, a cross functional team self organizes to develop the best solution to the problem.
- Managers are servant leader that teach through example and help other members to grow within the organization and to give the best of them.