Of Gods and Procrastination: Agile Management

Of Gods and Procrastination: Agile Management

Common errors in Agile management, and how to get the best quality code from your developers without tying them to their keyboards.

Quickly embraced by some, completely ignored by others, Agile management spent the last decade and a half gaining popularity. Today it has become one of the most trendy phenomena, and most companies claim to have adapted and applied its principles. And indeed, that is true, yet almost always in a modified, and even sometimes in a corrupted, way.

Most of us in software development have been in different teams and projects, as developers in some, and as team leads & managers in others. We coped with clients in kick-off meetings, decoding acceptance criteria and wireframes, defining the MVP, accepting changes in the requirements, and modifying the scope in the middle of the sprint. We made mistakes and learned the hard way. Mistakes that we should not commit again. Yet sometimes, we see them happening again in our own team, when visiting clients, or meeting teams with whom we will collaborate, etc. Today, I want to focus on the troubles I see the most among managers with software developer teams.

Agile Management Common Errors

Meeting a Tight Deadline by Adding Additional Resources to the Team

You check the estimation for the running sprint and find out that the team is currently 16 hours behind the schedule. It seems like no problem at all; you have a developer that just finished his project, he will join the struggling team for two days, and you guys will be back on track.

By doing this, the team probably won’t meet the deadline. Why? The mistake here is to think that a developer performs easy, automatable work. Well, he doesn’t. Even if he is familiar with the technologies used in the project, he still needs an introduction to what the project is about, what has already been done, where all the documentation is, what wireframes are still being reviewed, and a very long list of other things. Besides the fact that the productivity of this developer will be low (at least in the beginning), he will also need to be assisted by the rest of the team to be taught everything described above. A task that is usually assigned to one particular person. Well, that person’s productivity will also drop as he will be distracted and will have to spend hours helping and training the new member of the team.

Parkinson’s Law

In the beginning, Parkinson’s Law had a different meaning. Today it states that work expands to fill the time available for its completion. Let’s say we are having a performance issue with a particular project. So we assign one of our best developers to investigate what the problem is and to fix the bottleneck. To do that, we decide to spare a week of time.

Parkinson’s Law is not always present in a developer; sometimes it’s stronger, sometimes it’s weaker. Yet freedom of time in a task, especially if it doesn’t have a clear where-to-end point, will lead to its expansion, occupying all the time available for it. Sometimes it can even be worse, where the resulting solution suffers from over-engineering that adds unnecessary complexity to the project. To avoid this situation, the task must have strict goals and acceptance criteria, or otherwise, a frequent polling in order to see the results achieved so far.

Multiple Projects and Distributed Teams

Although out there you can find an enormous amount of articles on how to succeed with distributed teams applying Agile, keeping in mind an even distribution of tasks, understanding time and cultural differences, etc, not all projects are good to do such a thing. Especially when each developer forms a part of several different teams at the same time. In the attempt to make each one of the developers an ‘all-terrain’ developer, they end up working on multiple projects at the same time; for instance, Monday and Tuesday on project A, and from Wednesday to Friday on project B.

You have probably heard about the developer’s focus. This is when the developer is in their most productive state of mind. Once they lose that focus, however, it takes some time to get it back. Well, the same thing happens when switching between projects and checking what was missed while being away. Although some tools help to mitigate this effect, Dailies, Jira or Trello, for example, it still drags down one’s productivity.

It’s easy to disagree about this topic, but by default, I do defend the 6th principle of the Agile Manifesto, for both ‘co-location’ and ‘co-time’:

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

Time Pressure Increases Productivity

It’s surprising how common it is to discover among your co-workers and professional colleagues that they had the same dark experience. Often in a startup or in a small company, with a very talented manager that made them ‘believe in themselves and in the product,’ which ended up in countless extra hours, tons of stress, and impossible-to-meet deadlines. As developers accept such working conditions, it allows their manager to presume that the team is quite productive, as the ratio of delivered functionalities and time is unbelievably high.

In fact, the productivity of the team might be considered high, as long as you don’t take into account the quality of the work done and the extra (and unpaid) hours. Those kinds of conditions inevitably lead to two results:

  • First, the quality of the code goes down hill. This means more bugs passing through (no need to explain that a bug in production is hundreds of times more expensive for the company than the time needed to get it done right in first place), the test coverage fails, functionality is implemented partially, etc. Under time pressure, developers won’t work more, developers will work faster. Basically quantity over quality.
  • Second, at a certain point, the developer ends up quitting. Once he realizes that things won’t change and that his workaholic attitude and commitment to the company isn’t really good for him, he will definitely find another place to try his luck. Usually, the one that leaves is the one that had the most pressure, i.e. the one that can actually leave because he knows he has another option. And guess what? That’s the developer that you can’t let go.

To finish with this paper, I would like to point out the link between the code of a developer and his motivation. Usually, Software Development is not just something that ‘pays the bills,’ it’s someone’s passion. For a developer, to have the chance to write quality code means a burst of motivation. Take that chance away, and the motivation is gone.

And when a manager’s focus for the team is to keep up the productivity, the quality rarely increases in a significant way. When the focus is on quality, however, productivity tends to soar.

Fuente: Of Gods and Procrastination: Agile Management – DZone Agile

¿Es un pájaro? ¿es un avión? ¡No! ¡Es Scrum!

En un principio se crearon los programadores y los proyectos, pero no había nada más que tinieblas y el espíritu del cliente cabreado planeaba por los departamentos.
Así que un buen día, dos tipos llamados Takeuchi y Nonaka dijeron: ¡Hágase el Scrum!
Y vieron los jefes de proyecto que era bueno, y volaron sombreros en algarabía.
Casi sin saberlo, se había inventado lo que iba a ser una de las implementaciones Agile más populares del planeta.

¿Qué aportó Scrum que lo diferenció del resto de formas de gestionar proyectos? En mi opinión dos aspectos básicos: transparencia con los clientes y ciclos de release periódicos y definidos.
En los otros sistemas de gestión que usé anteriormente (if any!) los proyectos se cargaban de una pesada losa de documentación que se llevaba casi la mitad de los costes disponibles y que el cliente debía firmar entre un mar inmenso de dudas (y de papeles).
Esta es la semilla de las frustraciones y lo que ha marginado a los proyectos de software hacia una de las experiencias más insatisfactorias que pueda sufrir el ser humano, junto a la de participar en juegos de azar y ponerse a dieta.

Tocar el producto desde el principio

Ver el producto mientras crece (Fuente: http://thegardenpalette.wordpress.com)

Ver el producto mientras crece
(Foto: http://thegardenpalette.wordpress.com)

Este aspecto es el más valorado por el cliente, quien es ni más ni menos que el que nos paga.
La sensación de estar metido desde la “mórula”, la génesis de su proyecto, les hace ser más comprensivos con los posibles imprevistos que puedan ir surgiendo, amén de proporcionarles una infinita tranquilidad sobre su inversión.
Yo lo comparo con comprar por internet: pagas por algo que no has tocado, ni olido ni visto. ¿Quién no mira el tracking code para ver dónde está el paquete? Puede que esté parado en Berlín y lleve tres días, pero sabes que está ahí.

Con Scrum el futuro propietario del producto, el padre adoptivo, también sabe dónde está, y además también sabe cómo se va construyendo. Esto que parece nimio es nuestra revolución. ¡Estamos iniciando a un muggle a los rudimentos de la magia! Esta persona aprenderá que los programas no son “dar un botón y listo”, que tienen tanto de artesano como ese Murillo que tanto admira y que sabe que es único.
Será comprensivo (salvo Saurons) cuando le digamos que ese BotónVerdeQueSaltaYVuela que le prometimos es totalmente imposible, pero que intentaremos hacerlo de una manera parecida.

Lo que hay que hacer bien clarito

La gran herramienta de Scrum es el Product Backlog, que no es ni más ni menos que la lista de funcionalidades que debe realizar el software que vamos a empezar a hacer, perfectamente ordenada y documentada incluso a nivel de procesos.
Es la Herramienta, así con mayúsculas, y todo el mundo podrá verla y tocarla desde el principio.
Lo ideal es montarla como una Wiki, y que vaya evolucionando como el germen de la documentación del proyecto, ayudándolos de los resultados de los sprints y las actas de reunión.

Mantener al equipo centrado

Es común que haya interferencias externas (teléfono, propuestas de cambio, etc) que desconecten a los programadores de su tarea. Tarea dicho sea de paso que está mal reconocida y valorada. Programar es algo muy complejo y necesita una altísima carga de concentración y de eficiencia mental. Cualquier distracción hará que el desarrollador tenga que perder dicho estado de foco en la tarea y, después de 10 minutos al teléfono, tenga dificultades para saber qué estaba haciendo justo antes.

Programadores concentrados en la tarea (Fuente: http://www.pce.uw.edu)

Concentrarse en las tareas evita errores
y facilita los objetivos (Foto: http://www.pce.uw.edu)

El Scrum Master es nuestro “papi”, que lo arregla todo todo, y que evita que tengamos que sufrir dichas distracciones y cuyo trabajo nunca es fácil, teniendo que manejar las situaciones con la maestría que les caracteriza.
Este rol es fundamental y, bajo mi punto de vista, es el más importante de todos. Era un rol que hacíamos los programadores habitualmente cuando llamaba el cliente para quejarse por algo o para preguntar qué tal iba el módulo ChachiOptimizador que le estábamos haciendo.

Objetivos cercanos y factibles

Los Sprints son eso: objetivos a realizar en un corto periodo de tiempo que incrementarán la funcionalidad del software.
Para los programadores este aspecto es magnífico porque nos permite saber qué tenemos que hacer (ojo a ese plural) para cumplir la planificación prevista.
Las tareas son concretas, divisibles por módulos y asignables libremente (en principio), y usando un Pomodoro todo parece más fácil, y lo mejor de todo es que ¡es trabajo en equipo!

Scrum Board, tomado de http://scrum4kids.blogspot.com/

Scrum Board de tareas domésticas (Foto:http://scrum4kids.blogspot.com)

Cualquier cambio o nueva característica habrá de respetar el Sprint. Nada de imprevistos durante ese tiempo cerrado e intocable, ya se planificará en la siguiente iteración.
Ah, y ojo con valorar dichas novedades en tiempo y dificultad sin contar con los que las tienen que hacer: en Scrum eso es ilegal.
Y nada de sofisticados sistemas: una pizarra, papeles y un reloj de cocina es lo único que vamos a necesitar. Con esto no habrá proyecto que se nos resista.
Esta es la revolución Scrum, y ha venido para quedarse, al menos en mi equipo.
Ha llegado la cordura a la gestión de proyectos.

Fuente: ¿Es un pájaro? ¿es un avión? ¡No! ¡Es Scrum!