You are going to fail

Eventually, you are going to fail. Not once but many time.

Wimbledon finalists (and champions) are remembered of this fact each time they enter the court.

If you can meet with Triumph and Disaster
    And treat those two impostors just the same;   
Yours is the Earth and everything that’s in it,   
    And—which is more—you’ll be a Man, my son!

If (Ruyard Kipling)

And basketball champions like Michael Jordan said it long ago.

26 times I’ve been trusted to take the game-winning shot and missed.
I’ve failed over and over and over again in my life.
And that is why I succeed.

The Sign of the Swoosh (Goldman, Papson)

And both professional tennis and professional basketball are competitive games. Many works today are not competitive but cooperative ones.

When facing innovation, being able to fail and face it in the same way as success is not only a skill. It is a MUST. That’s what this “celebrating failure” culture is about.

Both your successes and your failures report useful information and open new paths to tackle new challenges. Embrace them. The only people not failing are the ones not trying.

Related: Trying is harmful.

Related: On winners and dealing with failure.


Quotes on documentation: Discovery vs The Agile Manifesto

Working software over comprehensive documentation
That is, while there is value in the items on
the right, we value the items on the left more. (Beck et al)

Living documentation offers a way to track (and correct) decisions that turn our to have been wrong, as weel as providing a mechanism for managing change requests.

The BDD Books: Discovery (Nagy & Rose

Not every documentation is a waste of time.

Documentation is a tool. Use it wisely.

Three ways to standardize

Option A.
We’ve already figure out the way.
We’ve a mean and lean team that works great.
Let’s standardize and replicate.
What works for this team will work for the others.

Option B.
We know each team is different.
We’ve unique individuals with their own skills and abilities.
Let’s facilitate each team to find their own way to make it.
Each team knows better how to make it by themselves.

Option C.
We haven’t figure out the way. We understand that each team is different.
But we know how to let each team figure out their own way.
Let’s standardize this.
And replicate.

To sum up…
The three options could work (and did it in the past!) depending on the environment, restrictions, culture and so on. The three options could also fail.

We’d better choose wisely and let ourselves learn from results. Then improve. Standardize. And replicate.

(*) Hint: nothing to do with the Monty Hall problem 😉

Team’s organization: using a physical whiteboard or being digital

You are working in an agile team, so you probably find a good idea using a kanban panel, a lean comm-cell or something like that.



what if you are in a remote team? Lots of applications solve this from a technical point of view. Whiteboard emulators, with virtual post-its and sharpies on colours you can’t even name.


And then the problems arise. You are discussing an issue and the panel is not there, directly visible. Maybe the application is not open, so you need to log in, and maybe your password expired yesterday night, so you end up discussing without looking at the board.

Maybe the team is not 100% remote, and a part of the team is co-located while others are remote. Then, the people at the office find convenient having a physical panel, so they can interact easily with it even with the computers off. Nice idea, but then the remote workers can’t watch it, can’t update it.

What could we do? As many times, the answer is… it depends.

  • team 100% remote: go digital. 100% digital. Everybody meets in front of a screen, so it’s convenient to have 2 windows, one with the IM/videoconference software, the other with the board. And while working, the board must be open. Always.
  • team 100% colocated: go with the whiteboard. 100% physical. You benefit from the size, the fact that is always present and the easiness of manipulating items.
  • part remote, part co-located: this is the hard situation. Best case scenario is going digital with a big screen (MS-Surface?) always on, so the colocated people still benefit from the 100% co-located scenario, and every meeting with the remote colleagues will benefit from having online app. If can’t afford a Surface, a 45″ screen will do the trick with an small computer (arduino?), a mouse and a keyboard permanently attached, on and open so you can easily manipulate it.

And as always, try, inspect and adapt. Plan, do, check and act. You already know…


  • Remote. Office not Required (Friend, DHH): “Feeling like a second-class worker doesn’t take much.[…] There’s also the annoyance of having every debate end with ‘John and I talked about this in the office yesterday and decided that you idea isn’t going to work’. Fuck that.”
  • Combining Lean with Agile: the developer perspective (Kris Hoogendoorn): “Above is a photograph of our Scrum board before we embarked on our Lean journey and a picture of our Lean Comm Cell today. You can immediately see how Lean has transformed our daily stand-up. Instead of just focusing on progress with the Scrum board, we now focus on three additional aspects every day”
  • Kanban Boards, Atlassian. “Regardless of whether a team’s board is physical or digital, their function is to ensure the team’s work is visualized, their workflow is standardized, and all blockers and dependencies are immediately identified and resolved.”


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.