Chess - antoniomartel.com

Archivos de Autor: antoniomartel

The engineer and the bridge

In the 5th century BC, a certain Roman engineer was appointed to direct the construction of a bridge over the river Leza. The bridge was important for the area. People and goods would be able to use it to cross the river, saving time and avoiding travelling long distances looking for a safe place to ford the river.
The engineer received this appointment with great enthusiasm, and went on to plan an estimate for everything that would be needed for the construction. He calculated how many builders, cranes, pulleys, scaffolds and centrings would be necessary. He could clearly see that with 50 builders the bridge could be finished in 4.7 years.
With the 600,000 sestertii that he had received to execute this assignment, he quickly bought all the necessary materials according to his calculations, and had them delivered to the construction site. He recruited the 50 builders he had estimated he would need and sent them to the river bank to start work at soon as possible. There was no time to lose. The sooner it was begun, the sooner it would be finished.
Soon, however, the workers told him that they didn’t need so many pulleys and cranes, but that there weren’t enough pickaxes and saws for the job. “I can’t do anything about that,” said the engineer, “most of the money has already been spent and there isn’t much left to buy new materials. You’ll have to adapt to what we’ve got.”
The construction went on, and soon afterwards it became clear that things weren’t going as planned. The foreman told the engineer that the stone quarry where the stone was being cut was too far away, and that the road was full of bumps and potholes from last year’s flooding. It just took too long to bring the stone in carts to the bridge. “You’ll have to make an extra effort,” said the engineer, “there’s no time now to fix the road.”
The foreman also informed the engineer that it would be necessary to build arches in the bridge, to reduce the amount of materials used, and, most of all, to improve its resistance. “There’s no time for frills,” said the engineer. “We’re late. We’ll add a little extra mortar in the pillars, and that’ll be it.”
The news about the construction of the bridge came to the Prefect’s ears. He despaired when he heard about how slowly the work was progressing, so he sent for the engineer. The Prefect needed to justify his actions in Rome, and demanded that the bridge be ready for Saturnalia. The engineer explained that, in order to achieve that, he would need at least another 50 workers. As he was also pressured from above, the Prefect agreed and committed to send the new workers a month later.
Back at the bridge, the engineer gathered all the builders and asked them for an additional effort to comply with that new deadline. The workers could not understand how were they to work twice as fast if they didn’t have enough stone, and in any case they always had to wait for the mortar to set.
Not even with the new workers could the bridge be built on time. There weren’t enough tools for everyone, the stone was still slow reaching the worksite, and collapses were common because of the hurried construction process.

In ancient Rome, a bridge’s builders had to stand underneath it while an entire legion crossed it. It’s a good incentive to build firm, solid bridges, don’t you think?

You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).

Book on Scrum: Agile 101, Practical Project Management
Agile 101 – Practical Project Management
Translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt.

Lessons learnt from others

An old Spanish saying says “no one learns a shred from another person’s head.” But let’s try it anyway by reading some experiences other people encountered while managing projects.
In the previous section I’ve told you about my own mistakes in managing projects. In this section I will tell you about the main lessons Jeff Sutherland learned while helping companies like Nokia, Patient Keeper or even Google to adopt Scrum:
In Google, some of the teams adopted Scrum little by little. They did this because they feared resistance from their engineers. They thought that introducing a formal process in teams that were already highly productive would not speed them up but slow them down. They started implementing Scrum using only the most basic techniques. If Google can do it, why can’t we?
In Google, they also had a certain resistance to meeting daily. They thought it would be time spent in vain. They started with meetings that lasted a good deal longer than the initial 15 minutes. At first each engineer took quite a long time to explain what he or she was doing and the problems being faced. After a while, when all the members had explained their job and were aware of the job of the rest of the teammates, the meetings were much more fluid and helpful. To my relief, in their simplified, initial Scrum, they didn’t use a burndown chart for every iteration. They used only one per delivery. That made me feel better. I hadn’t been able to keep the Kanban board updated daily for each sprint (yes, I know, Scrumbutophobia).
The burndown chart helped them realise how long they would spend in developing a feature. For a feature that they initially estimated at 40 points and 3 weeks, they saw that in the first week they had covered only 8 points. In the second week they managed to finish only 7.5 points. But one of the managers thought that they had the feature ready in the third week. Then the graph made it clear that it wouldn’t be ready in that amount of time.

Jeff Sutherland recalls a project for the health sector which would be accessed online simultaneously by hundreds of doctors and other users. In that project, the definition of Done became more and more stringent. At first, they just had to pass the unit tests and acceptance tests. But later on, for something to be really marked as Done or Finished, it had to meet this condition: “deploy to production, and if the phone doesn’t ring for 1 hour, the new delivery is complete.”

You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).

Book on Scrum: Agile 101, Practical Project Management
Agile 101 – Practical Project Management
Translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt.

Curso de Scrum Agile 101

Tengo pensado lanzar pronto un curso de Scrum/Agile pero no tengo decididos aún formato en el que lanzarlo o los contenidos exactos que tendrá. Quiero que sea un curso sobre todo práctico y que incluya cuestionarios después de cada tema, hojas de trabajo en las que se planteen problemas o ejercicios para asegurarme de que se entiende cada una de las ideas que se explican y plantillas para las reuniones diarias, las gráficas burndown o la comunicación con el cliente.
Cuando uno intenta plantear un curso de este tipo el primer problema con que te enfrentas es si debes orientarlo a personas que ya tienen un cierto conocimiento de Scrum o Agile porque Scrum lleva ya un tiempo en el mercado o bien crear un curso más sencillo en el que los profesionales que aún no se han decidido a implantarlo en sus proyectos tengan una guía con la que iniciarse en esto de Scrum.
Al terminar el curso quisiera que los participantes hubiesen aprendido:
  • Los roles y artefactos mínimos para una implantación gradual de Scrum.
  • Roadmap para avanzar en la implantación de Scrum.
  • Las ventajas y razones principales para usar Scrum.
  • Las dificultades más importantes a la hora de implantar Scrum y cómo resolverlas
  • Cómo sacar el máximo partido a Scrum.
También hay otras muchas cuestiones como si se prefiere que los contenidos sean de sólo texto o contenga también vídeos, si se quiere incluir asesoramiento personalizado via email o videoconferencia o descuentos por grupos para empresas. Para intentar resolver todo esto he creado un pequeño formulario/encuesta en la que puedes ayudarme a saber qué puede hacer más interesante para ti un curso como éste. En la siguiente dirección tienes un enlace a la encuesta: Encuesta Curso de Scrum Agile 101. Tienes tres minutos y me ayudas a saber qué puede ser más interesante para ti? Gracias!

The 80/20 Rule

How can we avoid featuritis and concentrate just on the tasks that will make us more efficient? Many years ago, approximately a century ago, someone called Pareto realised that 20% of the pea pods in his garden amounted for 80% of his crop. The remaining 80% of his pea pods amounted to the other 20% of his pea crop. Intrigued by this ratio, he also checked that he could use this rule to other fields. He went on to discover that, back then, 20% of the population had 80% of the income. The remaining 20% of the wealth was in the hands of the poorest 80% of the population. This principle, based in empirical knowledge, has been in use since then. It helps improve efficiency and productivity in economics, commercial distribution, marketing, engineering, and, naturally, in software development.
For example, we start to develop our product with a huge list of requirements and features as a base. Yet we know that only 20% of those features will be used 80% of the time. A large chunk of the remaining features will only be used 20% of the time. We can apply this principle to development time. Using it, we can deduce that if it takes us about 10 months to build a product, in 2 of those months we will be able to develop 80% of the features. Thus it would take us about 8 months to solve the remaining 20% of the most complex and difficult features. This leads us to ponder: will people use these features? Are they really indispensable?

Say we manage to identify the most important features, and we keep them as simple as we can. Wouldn’t we be able to dispense with 8 months of work and deliver a highly effective product in 2 months only? We already know that 20% of our effort will produce 80% of our results. Wouldn’t it be worthwhile to sit for a moment and think for a bit about what we should devote our time to? I’m sure it would.

You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).

Book on Scrum: Agile 101, Practical Project Management
Agile 101 – Practical Project Management

Translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt.

Keep it Simple from Agile 101 book

Some time ago, I had a conversation with an IT colleague, about the sector nowadays. Something reminded me of an Andrés Diplotti cartoon I’d seen on Google+. In it you could see a client reviewing the application that the programmer had delivered. The client says : “It’s all fine, but I don’t see a Cancel button”. The programmer replies: “I don’t program for cowards who cancel at the last minute.”
I’ve been a programmer for a long time. I’m still a programmer, in part. So I can recognize this kind of arrogance (maybe not to that extent). I suppose that it’s a sin of my youth, a brashness that’s been mellowing with age and that some of us already felt in college.
Back then I had just discovered software-design patterns in the book The Gang of Four. Our applications started to be filled with design patterns, the more the better. It looked like we were in some sort of contest. We had to see who used the most obscure, complex pattern —the one that would be the hardest to understand. With this in mind, I can understand the posts and articles I read now. They discuss refactoring old code to get rid of design patterns, and about how expensive it is for some projects.
As the years have gone by, I have suffered the KISS principle (Keep it Simple, Stupid) in my own flesh.  Not just with patterns, but also with the customization of on-screen graphic components. Or with “phantom requirements.” This is a term I once heard from a fellow worker. It refers to those features that no one has requested, but that you consider important for your clients. Things that “most probably” they’ll end up needing. It’s the malady known as featuritis. It makes us think that the more features or characteristics our app has, the more valuable the client will find it.
A long time ago, a client’s project manager commented that someone on another work team had told him that a feature he wanted was impossible. I told him that practically everything can be done, provided enough time is spent on it. I wasn’t clear enough. I should have added: but is it reasonable to use all that time for that feature? You can use practically any programming language to send a rocket to the Moon. But, do you really want to go to the Moon, or do you want a finished app by the deadline?
So, you are saying that my design is too complex?


You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).

Book on Scrum: Agile 101, Practical Project Management
Agile 101 – Practical Project Management

Translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt.