Ajedrez - antoniomartel.com

Archivos por Año: 2016

Blueprint… o como quiera que se llame esto en 2017

He estado estos últimos meses ocupado intentando dar forma a un montón de ideas sobre qué hacer con el blog, posibles cursos de formación de las que ya te hablaba hace algún tiempo en la entrada Curso de Scrum Agile 101 y otras ideas sobre aplicaciones en la nube o coaching/mentoring online a través de Skype o algún otro sistema de vídeo conferencia.

Estas ideas se resumen en estos puntos que podrían convertirse en gérmenes de nuevos proyectos si veo el interés suficiente:

  • Web de formación online para la venta de cursos online sobre Agile, gestión de proyectos, gestión de recursos humanos, Lean Management o gestión a secas. Crearía una nueva web que podría llamarse Blueprint en la que mediante pago por Paypal recibirías enlaces a los contenidos que cree sobre estos temas. Veo aún pocas respuestas al cuestionario online para conocer más sobre el posible interés de los asistentes a los cursos ¿Se animan ahora a contestarlo haciendo clic en el cuestionario sobre formación online?
  • Web de asesoramiento online a través de sistema de vídeoconferencia como Skype o algún otro. Podría ser un complemento a la solución anterior en la que alguien o alguna empresa decide pagar por formación o asesoramiento más especializado al que se incluye en un curso genérico. En este formato se podrían resolver dudas o tratar problemas específicos que alguien podría tener cuando está implantando Scrum o tratando de llevar una gestión ágil de sus proyectos o empresas.
  • Nuevos libros que tengan el denominador común ‘Buenas prácticas en…’, por ejemplo, Buenas prácticas en el desarrollo de software o Buenas práctica en la gestión. Este último libro podría ser una segunda parte del libro Gestión práctica de proyectos con Scrum pero tener una visión más global a toda la gestión (recursos humanos, lean management, etc.) y no sólo a la gestión de proyectos software.
  • Aplicación en la nube para vender en formato de pago por uso a distribuidores o vendedores de productos en tiendas comerciales. Muchos de ellos aún usan un bloc de notas para tomar el pedido que le hacen sus clientes y que luego van de vuelta a su almacén a dejar la nota para preparar el pedido y llevar después la factura junto al pedido que se entrega al cliente. Ya existen sistemas similares pero con éste trataría de apostar por sencillez y economía en el presupuesto. Consistiría en una aplicación web que, desde el móvil, permita al vendedor tomar nota del pedido y que cuando llegue al almacén esté ya preparado y anotado en el sistema backend (también web). Habría que tener muchas cosas en cuenta como por ejemplo la integración con el sistema de contabilidad o de ventas que ya tengan o el sistema de impresión de albaranes o facturas (podrían ser simples pdfs).
Como ven muchas ideas para llevar a cabo y poco tiempo. 2017 se me va a quedar corto para todo esto. Ya estoy dando forma a algún curso de Scrum y haciendo sondeos con algunas empresas con comerciales o vendedores en la calle que puedan estar interesados. Si me dejan su opinión en los comentarios a esta entrada me ayudarán a saber cuáles son los sistemas en los que la gente podría tener más interés.
La idea de llamar a todos estos proyectos/empresa/startup como Blueprint viene de que en inglés los bocetos o esbozos de un nuevo edificios o el diseño ingeniería de un nuevo producto se hacía con tinta azul por lo que a esos dibujos se les llamaba blueprints.

Small start-ups

Ana had been laid off from a software-development company. After some time thinking about it, she managed to convince David and Alberto to join her in a project they had been discussing since college: founding their own company to develop software.
They were lucky that their first client soon appeared. It was a dairy-distribution company that had decided to give them a chance. The Head of IT in their area knew them from their previous jobs, had good references about them, and thought that it would be a wise idea to increase their vendor database by including a young local company. He would give them a small, non-vital project. If it worked well, many more would follow.
Ana, David, and Alberto did not consider it a small project at all. They had no experience managing projects of that size on their own, and were afraid they would “choke” on it. They had offered a very low price to build a stock-control tool, so they had to be very competitive if they were to make money with the budget they had.
There was also another added risk. The international consulting company that normally developed software for the client would be a hard opponent to beat. If the project went wrong or was late, the stock-control tool would end up being integrated as one more module in the ERP that the consulting company had already deployed for their client.
Ana and her partners decided to follow an Agile methodology like Scrum to try and reach the level of efficiency that would help them succeed in their first project. They knew that if they spent too long analysing possible features and then spent months and months implementing them, the project could be cancelled as the client would not be able to see short-term results. Their main target was to get something into production as soon as possible: something useful for the client, even if it didn’t have all the requested features.
With this idea in mind, they started to develop their software. Every 2 weeks they showed the head of IT and the warehouse managers what has been accomplished during the previous fortnight. It looked good, but the company hadn’t started to use it yet, so they didn’t know if it would work or not.
Soon Ana suggested deploying a pilot version to production, one with a pilot version that would allow them only to add new stock, to record stock entries and withdrawals, and to draft a simple stock report. There wouldn’t be any complex functionality that would foresee demand or any SMS alerts when the stock for a given product was low.
When warehouse workers started using the new application, doubts arose, but also it became clearer what was useful and what wasn’t. After so many meetings, no one had thought that it would be useful to add a history of the product’s delivery so they would know how far in advance a product should be ordered before they ran out of stock. Or that the order screen should include current orders of the same product, to avoid duplications in ordering.
The next items on which to work were quite clear now. Also, they constantly received new application-improvement requests. They had seen that if they integrated the warehouse-management tool with the invoicing software of the delivery vehicles, they would avoid typing every product twice, once for each system, which would save them lots of time and errors. This was not foreseen from the beginning, but they reached an agreement. They wouldn’t develop the demand-prediction tool, which would be postponed until a later version was developed, but instead they would add this integration with the delivery agents’ mobile devices.
Cooperating with the client, accepting changes in requirements, and frequent deliveries of working software made the project a success for the dairy distributor. Now, at this local branch, they had a piece of software that did its job and also lightened the load on the warehouse workers and the delivery salespeople. They heard about the project in the Madrid headquarters, and were considering implementing it in other locations. Who knows, maybe this would mean a new project for Ana, Alberto, and David’s start-up.

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.

Too small to fail

Kaizen, or continuous improvement, is a well-known term in business or industrial organization. It’s now spreading widely in every sector of the economy, but it also applies in social life or medicine. This philosophy arose in Japan. Their industry had  productivity and quality problems after the end of World War II. They looked for solutions, and brought experts such as  Deming. Yes, the same Deming of ITIL and the “plan-do-check-act” Deming cycle. His mission: training hundreds of professionals and engineers in quality and improvement systems. These methods had already been applied in the USA. But Japan developed them and improved them. They refined them to such an extent that years later they could return them to the Americans themselves as new work philosophies.
The principle behind Kaizen is to carry out small continuous improvements. The results of those changes are analysed and the fine-tuning resumes. In that way  the productivity or quality of the task being performed can be improved. Making small changes little by little is far more effective than trying to tackle everything in one go. This way you avoid the fear of big change—and the procrastination that normally goes with it —when faced with the idea of starting a transformation. These small adjustments, done continuously, end up becoming a habit and generating permanent results.
The idea is to make changes so easy that it would be hard to fail in their implementation. First we created the habit of changing. Then we add new changes or nudge the milestone of a change a bit further, so we can improve incrementally. It’s important to apply adjustments one by one. The idea is to avoid the complexity of choosing what to apply and when. That way we will be able to analyse the result of each of these minor improvements. If we apply several at the same time, we won’t know which one has worked and which hasn’t. Or whether the effect of one has cancelled out another.
In your project you can decide to deploy every SCRUM, TDD, unit testing, continuous integration, and so on and so forth all at once. But probably the only thing you’ll manage to do will be to drive your team crazy. Yes, all those practices are good for your project, but, are the most basic ones working? Do you have good version control? Are you delivering software every two weeks? It’s better to start by the simplest ones or the ones that you consider most effective to improve your situation. Then you will be able to add the others.
Even far away from the field of software, there are companies that use Kaizen and Lean techniques in production. Take, for example, SPB, manufacturers of household brands like Bosque Verde in Spain. Their industrial manager declares:
“SPB has improved its productivity by 15% without investing in new machinery or carrying out staff cuts. The systems we have applied have enabled our company to reduce our expense accounts from 15 to 25%. We have improved our raw-materials management by 45%. And we have reduced the stock period of our product to eleven days.”
SPB had foreseen that to improve, they would need great investments and opening new factories in northern Spain. But instead they have focused on improving their productivity plan.
We can apply such changes to improve our health or personal life too. If we have always wanted to write a book or a blog, we can set out to write 1,000 words a day. But most of us will probably abandon that idea in only a few days. However, if we set out to write just 50, the change will be so easy that it will be hard to fail. First, establish the habit of sitting and writing for 15 minutes a day. Then we can take the challenge further and make it bigger, little by little.
In my case, I have also applied similar techniques, but I’ve hardly noticed. When I published my book it hardly sold at all. For weeks and weeks it had just the few sales I considered F&F (Family & Friends). But I didn’t just park it there and forget about it. I changed it to a different Amazon category. Then I changed the cover. After that, I included some new chapters. Later, I improved the description until I found one that seemed optimal. Some of these changes made my sales increase up to 50% in a week. If I had just left it there, the book would never have reached decent positions in its categories. I would have concluded that the content wasn’t interesting. Or that it just could not sell well without a professional publishing house to support it.
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.

Five lessons learnt in project management

Every time I finish a project, I try to make a balance report for myself. I look at the things that went wrong and the things that went right. The things that I tried and worked, and those that I shouldn’t repeat. Even those times when that final balance came up negative, maybe the project was worth it if in the next one I don’t make the same missteps again.
I have combed those balances and extracted five of the most important lessons I have learned. Some are beginner’s pitfalls. Others I should have solved by simple logic but matters weren’t so obvious when I was in the middle of things. Here they are:
Agile works
It’s difficult to quantify, but ever since I started using Scrum in my projects, the number of hours spent per feature has gone down —and in my opinion quite considerably so. We were able to gain 80% of Scrum’s advantages with three things. First, the daily 15-minute follow-up meeting. Second, keeping the graph of the state of the project that tells us whether we’re doing well or not. And third, delivering software every the two weeks. Also, every fortnight, clients seemed to feel more comfortable when they received the items that we had agreed on two weeks before. In July and August it was not possible to meet. So every week we delivered a simple two-page document with the percentage of completion of each feature. This document included two paragraphs explaining why those percentages were that way. This helped us to regain credibility in a project that was quite difficult —especially in September when they could check that those percentages were real.
Not everything is positive in Scrum
Being a Scrum Master takes far more work than simply being a project manager. In those daily 15-minute follow-ups you will be told about lots of difficulties that the team needs to overcome before they can continue. Trying to find solutions will take the rest of your morning.
And having a deadline every 2 weeks can be exhausting. You cannot sprint for months. Six months later you start trotting (and that, with luck). You need to take this into account from the first planning meeting on.
Last, but not least, Scrum is not magic. Whatever method you use, you are going to need a team trained for the job at hand, ready to roll up their sleeves and work, and willing to contribute. Teams like this don’t grow on trees. If you have one, your job as a project manager is to get out of the way as much as possible.
Adding more workers to a project that’s behind schedule will only delay it further
This was sufficiently covered a long time ago in the book The Mythical Man-Month. Even so, it’s still necessary to highlight it, as there are hardly any exceptions to this rule. No matter how tight the deadlines are nine women cannot create a baby in one month.
Who owns all this?
No matter what we call it —designating the Product Owner, identifying the stakeholders, engaging them—the end we’re going to need to know who is going to validate the project in real life. And I do not mean who is going to green-light the invoice. You’ll also need to know who is going to use the product. The project will be a success only if, after delivering it, it works and it’s useful.
At some point during the project the area manager gave us all the documentation, validated the partial deliveries, tested the whole application, and congratulated us on our work. Regrettably, when his secretary came into the training session a week before deployment, she said: “that’s of no use to me: that’s no longer the right template, as I need to gather different information now.” This meant a week of extra hours and additional effort, on top of the risk of deploying a product that could be unstable.
Minimum Viable Product
If you already have something that could be helpful to the user, deliver it, deploy it, put it up for sale. Don’t wait until you have each and every one of the features finished. If you remember the Pareto principle, with just 20% of your planned features you’ll be able to cover 80% of the uses that your product will have.


When it’s in production, you’ll be able to get feedback from the users. They know with more precision what they need, and you’ll know where you’ve failed and how you can fix it. If you bet on just one final delivery, you only have one bullet to hit the bull’s eye. If we had done this, it would have saved us a lot of problems with the product of the previous example.


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

Mistakes are made all the time when we manage projects—at least I have made a few. In this section I will list only some of them. They are the most relevant or the most confessable ones, depending on your point of view. I’ve messed up in many other ways, but this chapter had to have a limit. So, here they are:
First the problem, then the solution
This is the order: first you identify a problem, and then you come up with a solution. Never the other way round. It is quite common to hear about a modern solution that we apply to the project with enthusiasm. No matter whether there was a problem to solve or not. What is the use of deploying the new and sophisticated software for Test Driven Development in our daily work, if your problem with that project is way more basic? Or if you don’t have a tight grip on the version control system?
Counting the steps instead of looking at the road
We all know that in some projects the number of hours spent tends to go through the roof. Only rarely do the predicted number of hours and the actual ones coincide. Our first reaction is normally to double-check every hour registered. Then we draft complex graphs that show us how well we’re doing versus the estimate…. But does this actually help us finish the project on time?
Imagine that someone hired us to carry a heavy load from point A to point B. We estimated that it would take 10,000 steps. What is the use of knowing that we’ve walked 5,000 steps already? Do we know where we are, or if we’ve been going in circles? Wouldn’t it be better to raise our head to see whether we are on the right path? Maybe double check that the road leads from A to B, or see whether there is an easier way to get there?
Phantom requirements
Sometimes we ask our team members to change what they’ve already done because “the client won’t accept it like that.” Or because we think the product should work in some other way. Our colleague had already finished a proposal that took time and effort. It’s better to see whether the client likes it. The client will decide whether it’s right or wrong. Investing time in unsolicited corrections will only delay delivery. Careful, though —this doesn’t mean that we shouldn’t review or check our work for quality before showing it to the client. All I’m saying is: “if it ain’t broken, don’t fix it.”
Spreading the need to rush
Project Managers normally work on several projects at the same time. This implies that they juggle several clients, with their needs and deadlines, and thus accumulate tension and stress. Personally I try not to spread the stress to other members of the work team and to supply all the serenity I can. Of course, every team member must be aware of our delivery deadlines and needs to know which job we should finish for each client. Adding the need to rush to the daily routine only brings quality problems in the final product. Or creates things that are only half solved and that you will have to solve for good later on. This will also make us spend double the amount of time that those tasks would have required in the first place.
Could you make it easier?


One of the first mistakes in a project is to start every task as soon as possible without stopping and planning which steps should be part of it, and without determining whether they are truly necessary or whether we could simplify them somehow. I mean not only implementing it in the easiest possible way, but also simplifying the task in itself. Some examples: For this complex system that interconnects several computers…. Isn’t there already some sort of pre-defined standard? Should this parser be able to solve third-order equations? The best way to spend your time is reducing the complexity of the work to be done.


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.