Would you build a bridge with Agile? Yes. Why not?

You can use several frameworks, methodologies, techniques and tools.

I’ve used Agile on my current and two of my previous employers.

I’m a Project Management Professional, as well.

There are some kind of projects you wouldn’t want to do it with Agile.

A common example is building a bridge.


You need detailed planning for building a bridge, right? Right?


No. Not right. I would build a bridge using Agile techniques. Sometimes.

When? You ask.

If you want a rapid response. You just need to check if you can find something interesting in the other shore.

You can have just a first iteration.


Maybe this first design can only be used by early-adopters. Specialists. Or you just simply want to make a marketing impression.


Then, if it’s interesting, you can improve your first design.


And maybe use this first prototype to guide you in the construction of a better complex one.

Maybe you need a fast answer. A quick and dirty solution.


Then, when your infantry has assured a head on the other shore… you again will improve your solution, or being a new one for scratch, with more functionality. In this case tanks.


So, would I use always agile to plan and monitor the construction of a bridge. No.

Could you use it sometimes. Absolutely yes.



A matter of time. Estimation and uncertainty.

Let me ask you four questions. Ready? … Let’s go.

  • How long did it take you to go back home after work YESTERDAY?

I’m sure you can answer this one quite easily and accurately. Maybe “40 minutes”.

  • How long is it going to take you to go back home after work TODAY?

This question is a bit harder. You can say something like “Roughly 40 minutes, like yesterday”. In your head you’re making some thinking, like “I don’t need to go anywhere else, so I’m taking the same route. Besides I’m leaving at the same time than yesterday so traffic conditions should be similar.”IMG_20180812_093701_677

  • How much is it going to take you to go back home after work this day NEXT WEEK?

You could take a fast bet and say “The same… I guess”. The problem here is that, thinking on next week, you are no longer sure about the little details… Will you need to go shopping after work? Will you need to go to the doctor? Maybe next Monday the main street on your usual route will be under repairments so you will need to take a detour. Or you would leave the office two hours later and must drive at rush hour.

  • How much will it take you go back home after work this day NEXT YEAR?

Here comes the fun.

Talking about next year you’ve lost sight not only of the details, but of the big picture as well. Maybe next year your  company would have moved to another part of the city. Or your schedule could have changed. Maybe you won’t even be working for the same company. Would you still be living in the same house? In the same city? Even if the starting and finishing points are still the same, you could be taking another route since the main street is now (then) a continuos traffic jam because of that repairments they made last (this) year? You don’t really know. It could REALLY take you ANY AMOUNT OF TIME. From literally zero minutes, if you start working remote from home, to several hours if you’ve moved to a big, crowded city or to a nice house at the outskirts.

The farther the future you try to predict, the less you could know, the more you need to assume, the more you need to guess.


The mysterious cone of uncertainty (CodingHorror, Jeff Attwood): “If you don’t actively work to reduce the variability of your project*, the cone of uncertainty quickly becomes a cloud of uncertainty. When will the software be done? Who knows. That’s one reason for the long, dismal history of software project failure.”

Making Things Happen (Scott Berkun): “Schedules are simply a kind of prediction. No matter how precisely they are drafted or how convincing they appear, they are just a summation of lots of little estimations, each one unavoidably prone to different kinds of unforeseeable oversights and problems.”

Revise your assumptions: “Not every car has four wheels. Generalisations and assumptions. Everybody assumes they’re true, and they are, generally.”


Quote: The magical power behind deadlines


[To write a novel] You need a super-powered, diabolical device that will transform you into a bastion of literary accomplishment. And I’m happy to report that this implement is in the house, and it’s just waiting for you to pick it up.

Without hyperbole, I can say that this tool is the most awesome catalyst that has ever been unleashed on the worlds of art and commerce. Nearly every beautiful and useful thing you’ve ever touched or witnessed was born in its mighty forge. It’s portable, affordable, and nonpolluting. 

[…] What you need to write a novel, of course, is a deadline.

Deadlines are the dynamos of the modern age. They’ve built every city, won every contest, and helped all of us pay our taxes reasonably close to on time for years and years.

Chris Baty. Why deadlines are every writer’s secret weapon

I first published in my school’s newspaper when I was eleven. Since then I started to write a novel at least three times, never achieving more than a dozen pages.

Then NaNoWrimo came to scene, with its gigantic deadline. 50.000 words. 30 days. A novel from start to end, while doing your best to keep up with your life.

NaNoWriMo. A challenging but clear goal in an agreed, achievable time box. I couldn’t do anything but commit.

A deadline is, simply put, optimism in its most ass-kicking form. It’s a potent force that, when wielded with respect, will level any obstacle in its path.

Chris Baty. Why deadlines are every writer’s secret weapon

Optimistic ass-kicked as I was, I won. Four times. Thanks to the magical power of deadlines.

Related: How to make deadlines actually work, Jason Fried at Inc.com
Related: Why deadlines are every writer secret weapon, Chris Baty at NaNoWriMo.org
Related: About NaNoWriMo at nanowrimo.org
Related: Quotes on planning, Quotes on time pressure

Chess and life and decision making

When you play chess you have to analyze what the situation is, you have to know what your abilities are, estimate your competition’s power, and make good use of the time you have left.

Just the same as in business…
…except for one difference. You can replay chess. You can study your past moves and see what would have happened if you had played an alternative move. You can check the different expected results and see if you made it right or wrong. You can watch each game from different points of view.

But you can’t replay life.

So don’t hesitate so much, trying to make the optimal decision. Just think and decide, move on and think and decide again on your next move. You will never be sure if you are choosing the best options but, while you’re improving continuosly, being optimal really doesn’t matter so much…

Or doesn’t matter at all.

Revise your assumptions

Sky is blue, isn’t it?

No, it isn’t.

Not every tree has a brown trunk and green leaves. Not every car has four wheels.

Generalisations and assumptions. Everybody assumes they’re true, and they are, generally. But you’d better double check them before starting your project. Maybe you are assuming more than what is needed.

Focus and The Fellowship of the Ring

“I wish it need not have happened in my time,” said Frodo.
“So do I,” said Gandalf, “and so do all who live to see such times. But that is not for them to decide. All we have to decide is what to do with the time that is given us.”
(The Fellowship of the Ring, Tolkien)

So remember:

  • Bad happens
  • Bad happens even to you
  • You must embrace what has already happened, learn from it, master it and then focus on doing your best to improve it

Quote on planning

“Planning usually is initiated for the enterprise by your boss, and you’re brought in to fill out the details. […] Planning is like this: Take two steps forward and one step back. It’s like a recursive procedure: You have to continually drill down on a big plan to flush out the details that will eventually be your job to manage.” (Herding Cats, Rainwater)

So when your boss asks you to plan a project, she has already begun the planning. At least the part that connects the project with the company’s overall strategy.

Your job is to take this first plan and develop it, pouring the deeper knowledge that you have, both on technical resources and in people, into it.

Then she (and the other stakeholders) will see your plan, will criticize it and add the business part (time to market, competition, long term goals…) you couldn’t see in the first place.

Finally you will re-plan and iterate through this process as long as needed.

So if someone puts your plan down, don’t take it as personal. Remember that every plan is written to be changed.