Archivos por Etiqueta: Agile

Administración Pública y las nuevas prácticas de gestión

domingo, 20 octubre 2013 19:37

antoniomartel

0 Comentarios

Somos muchos los que de una manera u otra trabajamos para la Administración Pública, algunos directamente pero otros muchos indirectamente, como proveedores de servicios o productos pero trabajando en este sector al fin y al cabo.

Muchos tratamos de realizar estos servicios o entregar esos productos aplicando técnicas de gestión ágiles como Scrum o Lean Management pero solemos encontrarnos con cierta rigidez en la formalización de los contratos o en los pliegos de contratación de los concursos públicos.

Alguien preguntaba recientemente en un debate del grupo PMP Canarias en LinkedIn si las administraciones públicas estaban preparadas para la gestión de este nuevo tipo de proyectos. En mi opinión, a la Administración Pública Española aún le queda un buen trecho pero creo que ya se comienzan a ver ciertos avances en la aplicación de nuevas formas de gestión como Lean Government, especialmente en otros países.

En el NHS, el sistema de seguridad social británico, con la aplicación de técnicas Lean para eliminar retrasos innecesarios, reducir el papeleo y aprovechar los tiempos muertos de espera para realizar ‘actividades útiles’ se consiguió reducir la mortalidad en dos tipos graves de fractura de un 22,9% a un 14,6% en solo seis meses. Eso significa que en ese periodo, de media, unos 14 pacientes más lograrían sobrevivir a la operación.

Otro ejemplo de Lean Healthcare se encuentra en un hospital de distrito del NHS. La clasificación de las pruebas de ultrasonido en ‘verdes’ para las más simples y ‘rojas’ para las más complejas permitió reducir la lista de espera para estas pruebas de 12 semanas a tan solo 2. Se asignó el tiempo justo para la complejidad de cada prueba y se redujeron los trámites y el papeleo al mínimo para las pruebas más simples con lo que además de la reducción en los tiempos de espera se logró que quedasen más huecos en el calendario para tratar adecuadamente las posibles urgencias.

Mucho más reciente es la actualización de las normas de contratación del Departamento de Defensa de Estados Unidos para declarar ‘ilegales’ los proyectos en cascada. Parece ser que uno de los proyectos que ha disparado esta decisión fue el proyecto Sentinel en el que después de un proyecto fallido inicial de 170 millones de dólares, retrasos considerables, 6 años de trabajo y 451 millones de presupuesto se consiguió finalmente poner en marcha el nuevo sistema, gracias entre otras cosas, a la aplicación de técnicas ágiles de desarrollo para reducir los tiempos de entrega y los costos de cada funcionalidad entregada.

También en España parece haber un creciente número de instituciones públicas como el Museo Thyssen, el Hospital Clínico de San Carlos en Madrid y su Smart Health Lab o la Agencia Tributaria que están comenzando a usar y aplicar técnicas ágiles como Lean Government en sus negocios. Espero que estas instituciones sean solo la punta de lanza para lograr una Administración Pública más eficiente en estos ‘lean times’

Referencias:

More about estimations

jueves, 17 octubre 2013 18:48

antoniomartel

0 Comentarios

When talking about estimations ysing Agile techniques, there are certain things that are hard to accept for those who, for a few years, have already been planning and calculating times and dates.

We can find many planning techniques Agile: Planning Poker, clothing sizes ( S , M , L , XL , etc. . ) or the Team Estimation Game but, admittedly, all of them are difficult to integrate into a traditional development environment and even less for the customers of our products (at least those I’ve been working with)

Most of us are not used to see a team ‘playing cards’ for a session of Planning poker (at least I’m not) However, I agree with the philosophy behind these techniques and I think the fact that they are becoming increasingly popular it is, in part, because they are attempting to banish certain beliefs about the estimates:

Wrong estimations

Can we get it right? Estimate is to make a prediction about what would take to do a task or the materials we need to do a job. When we estimate with a high uncertainty, as when we do it based on some procurement specifications, rather than a prediction is a gamble.

It is obvious that we need to estimate. We try to predict what will happen to make decisions, but unless you have done the same task many times before and we have done it with the same team and under the same circumstances, we must know that there are high chances of being wrong.

The more effort you devote to the estimate we approach reality

To estimate has a cost and a it is a high cost. When we do not know the detail of every feature of the work, Does it make sense to devote hours and hours to elucidate tasks that do not know well? Make an exercise for me, when you finish your next project check the time recorded in each task. You will see that where you estimated 20 took 100 to you and where you estimated 100 hopefully only took 20 to complete the task. You will also see other tasks with no imputed hours. Simply they were not needed. However, how many hours were logged on tasks, which nobody thought about them at the initial estimation.

With this or that technique will estimate better

There are many estimation techniques but few will be as useful as a simple comparison of the time that took to do similar projects, the simple breakdown into smaller tasks or the expert judgment.

To use complex estimation techniques can give us a false sense of security about our estimation but it may not provide much higher reliability .However it can lead us to incur a very high cost (see above) and to invest a precious time that we could have used better in other things (such as reducing uncertainty)

Keep it Simple, Stupid

jueves, 17 octubre 2013 17:53

antoniomartel

0 Comentarios

Recently, after a conversation with a professional colleague on the current IT world, something reminded me of a Andres Diplotti cartoon I saw first time in Google+:

As a programmer I have been for a long time, and partly still I am, acknowledge that I have had this kind of arrogance (without going to these extremes) I guess it is a sin of youth that has been mitigated with age and that some of us already had since college.

By that time I remember to have discovered the software design patterns book from The Gang of Four. Our applications began to fill with design patterns, the more you used the better, in a kind of competition won by the one who used the more complex and difficult pattern. I guess this helps me to understand the posts and articles I see now on refactoring to eliminate design patterns and the cost of all these changes in some projects.

Over the years I learned firsthand the KISS principle (Keep it Simple , Stupid) not only with patterns, but also when customizing graphical components on screen or with the ‘ghost requirement’, a name that I heard on a rise to a co-worker to refer to those features that nobody asked but one believes important to the customer and that ‘for sure’ he would end up needing.

Long ago, a project manager on a client told me that someone in another team had indicated that it was impossible to get the functionality he asked. I replied that practically everything could be achieved by investing the necessary time. I was not clear enough . I should have added, Is it reasonable to use all that time on that functionality? With almost any programming language one can send a rocket to the moon but do you really want to go to the moon or do you want a working application on time?

¿Qué significa ser ágil?

domingo, 29 septiembre 2013 17:26

antoniomartel

0 Comentarios

Debido a mi trabajo, por el blog o por lo que sea, estoy usando cada vez con más frecuencia muchas de esas palabras de moda como Ágil, Sprint, Historia de usuario, velocidad de la iteración o backlog del producto. He repasado algunas de mis entradas en este blog y lo veo lleno de expresiones un tanto huecas como ‘ser ágil’ o no serlo, aportar valor al producto o aceptar el cambio.

¿Qué significa realmente todo esto? ¿Qué es eso de ser ágil y por qué iba nadie a querer ser ágil? Esto de la agilidad es más una filosofía que un concepto claro y bien definido. Supongo que es una forma de ahorrar palabras y evitar tener que dar una definición completa de cada concepto cada vez que hablamos pero quien nos escuche debe estar pensando ¿qué diablos dice?

No sé si será suficiente pero quizás pueda aportar algo de luz utilizando la presentación de Henrik Kniberg en el Paris Scrum Gathering (échenle un vistazo, no tiene desperdicio) Pongo aquí un par de puntos que me parecen muy destacados:

Esta imagen de la torre Eiffel es bastante descriptiva por sí misma. Representa bien este balance entre el caos y la burocracia (exceso de documentación, formalismos o rigidez del contrato) Uno nunca se puede mantener un equilibrio perfecto, algunas veces te quemarás un poco y otras uno recibirá un pinchazo. Mientras se esté intentando no caer en la burocracia sin abrasarse mucho no iremos por muy mal camino.

Estas dos imágenes de arriba explican también de forma muy clara lo que significa ser ágil: ¿Alguien tiene una idea? Vamos a probarla, ¿son aburridas esas reuniones? ¿Probamos a quitarlas y vemos qué tal nos va?

Y por último, la idea que a mí más me gusta y la que, al mismo tiempo, me parece más divertida (aunque aún me falta para llegar a esto):

Ágil en todos los sentidos

lunes, 09 septiembre 2013 20:35

antoniomartel

0 Comentarios

Hace algunas semanas, una persona cercana a mí me pidió que le ayudara con la revisión de un trabajo académico que debía presentar a comienzos de septiembre.

Cuando le eché un vistazo, vi que había un gran trabajo hecho, se había leído muchísima documentación, notas y referencias a libros, artículos, ponencias y otra bibliografía estaban por todos lados y las hipótesis y las conclusiones eran claras. Sin embargo, aún era necesario dar cuerpo a todo el documento, revisar que se cumplían las normas de citación para cada elemento de la bibliografía y cumplir muchos otros aspectos.

Lo primero que hicimos fue tratar de saber qué quedaba por hacer para dar por concluido el trabajo. Elaboramos una lista de los puntos pendientes: revisión de citas, síntesis, abstract en inglés, palabras clave, relectura del documento para comprobar los errores gramaticales o de expresión, cumplir con los estilos de la institución académica, incluir mapas de localización, etc. Mucho por hacer y sólo quedaban unas semanas para entregar.

Después de preparada la lista, la priorizamos, colocando siempre en los primeros puestos aquellas tareas que eran imprescindibles para poder entregar el trabajo, seguidas luego de aquellas otras que sólo darían puntos extra o no eran imprescindibles para el aprobado.

Cuando la lista estaba avanzada nos dábamos cuenta de que necesitábamos añadir nuevos elementos a la lista. Preparábamos una nueva lista y volvíamos a priorizar siempre con la idea en mente de ‘Si tuviéramos que entregar mañana ¿qué tendríamos que tener hecho?’ A medida que íbamos eliminando elementos de la lista comprobábamos que las tareas eran cada vez de menor importancia y dificultad y la desesperanza del principio daba paso a las ganas de dar los últimos remates al trabajo.

Finalmente se completó el trabajo dos días antes de la fecha tope de entrega. El día anterior se dedicó a una última lectura y revisión entregándolo solo unas horas después.

Podemos llamarlo Ágil, GTD o simple sentido común pero ¡yo prefiero trabajar así!

Página 8 de 9