Archivos por Etiqueta: EN

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).

Agile 101 – Practical Project Management

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).

Agile 101 – Practical Project Management

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?