Believe it or not...

Now I remember that there is things that are like the gravity force... we don't need to understand it to make it works...

One guy starts to float and to elevate to the infinite and starts to scream "SOMEONE PLEASE EXPLAIN ME THE GRAVITYYYYYY IT IS NOT WORKIIIIIIIIIIiiiiiiinnnnggggg....."


Gravity works instead you like it or not, you understand it or not, you believe it or not.

Also in the ancient ages there was people that won battles thanks to the gravity force, letting some rocks dropping from a hill, and those who won the battle didn't have any idea about what the fuck was moving the stones drop down.

Some people will think "this about gravity is a fashion, I'm now in the post-gravity stage". Others will think that "this about gravity is a process and to make it works you must do it always the same way". And others will think "gravity is an spirit that binds as to the Earth, is the Love of the Planet that keeps us attached to our fate"

The truth is that doesn't matters what you think, what you believe, what you understand, what you reject... gravity will be working for you, or against you and maybe that will be the difference between win or loose today's battles.

Agile has some relation with this, is to recognize thing's nature, human's nature and team's nature. Is to accept that nature, and to put it to work for the results. Without care how much intangible or incredible it should appears some times...

Send me your opinion!

Understanding Transparency

Hi All!

This time we will review the concept of Transparency.

Let’s read the Scrum Guide:

Definition of “Done” When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this varies significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment.

Now we are going to analyze this story:

  • Hi Tom! Welcome back! Hey we are defining the next business objective, can you view it?
  • Hi Peter! Yes of course! I can see it, very nice draw! What you need to know?
  • I need to know if you agree that it is a number…
  • Yes, for me it is a number! so we are ready to go for the next business objective. 

Some weeks later they discover, too late, that Tom understood the number was a 6, and Peter understood it as a 9. So we can have visibility, we can have an agreement… but transparency starts when we have the same understanding about the same thing.

Thanks for reading!

Send me your opinion!

An example of Product Ownership

Hi All!

Today, I want to share with you this video. It could be considered a reality film about a Real successful Product Ownership Process.

This video really made me think about Product Ownership. What caught my attention was the emphasis that the Leader makes over the people. And most important how he pushes constantly with the VISION.

I hope you enjoy it and this will be useful for you.

Thank you!

An Agile view to Optimize your Business

If you don’t know how an Agile view could optimize your startup business, here you have an example.

"37 signals" are the creators of tools like Basecamp, and they tell their story in this book.

“Getting Real”


I strongly recommend to read this book if you are at least thinking on starting a new business. This can save a lot of waste in the process, and help you to “feel” the market and find the best business opportunities.

For an entrepreneur, is very important to develop his “explorer” skills, and to keep his mind open and wide.

You can have the pdf book for free.

Send me your opinion!

Comparison of software development processes.

Hi All!!
This time I created for you a little story, you might like it.

Once upon a time there was a Customer who meet with several development teams.

The Customer wasn't able to pick one team, so he setted up a match with all of them, and the Winning Team will win the hole customer's portfolio.

Curiously, each team informed that they will use a different development methodology. Everyone started at the same time ... while some moved directly to develop after a little customer's introduction, others meet with him and make some questions.

Of those who stayed chatting with the client, some developers maked requirements quickly and the rest made ​​requirements using arduous and endless meetings to define the product specs to develop ...

After a few days we have the first teams that presents their final product. Those who used light requirements begin development and get meeting weekly with the client. Those who use hard requirements were still working on specs.

After three months most of the teams deliver the product, including those who made light requirements too. The group behind hard requirements is still working hard behind closed doors.

After a few months some groups surrender and deliver the product as it is.

In a couple of months more, the more strict teams finish and deliver ...

Go now and see the result...

Here is what the customer had in mind:

Some Teams made commercial proposals:

These are the hard functional specs:

These are the quick and light specs:

These Teams used old solutions:

Those fans of propietary software:

Those who chose a Software as a Service:

Those who chose closed solutions:

Those fans of reusing what exists:

Those who hired a freelancer:

Light spec, but without approximation:

Incremental method. They don't start a module, until finish another first:

These guys used an ego approximation:

These guys used an evolutive approximation process:

What Waterfall could deliver:

These had budget problems:

I hope you liked this.

Match's winner: "The evolutive approximation process". Will talk about that later.

Send me your opinion! 

Agile patterns and anti-patterns that I was finding.

Hi everyone!

This time I bring to you a resume of all agile patterns and anti-patterns that I was finding in the way. I collected them from own and others experience. In many cases these were my own errors, and when I discovered them, they were added to the collection. I thought that was interesting to put them nicknames, to illustrate a little more the problem's root.

This is a pre-view of the Book I'll write.

I hope that this patterns will be for you so userful, didactyc as funny.

I wait for your feedback!

  • Photogenic Agile . Is Agile for the photo. He demonstrate to be part of the Agile movement, but don't understand it at all.
  • Agile anti christ. This is convinced that the Agilism is not good, but never tried it. And those who make it work is by good luck.
  • Agile as a slogan. Names agilism to sell, but behind closed doors ... don't uses it at all.
  • Agile all in one. There is a person with the role "Scrum Developer Master Owner."
  • Feudal Agile The client make estimations.
  • Agile Soldier. The Stand Up is a military report, with penalties, reviews and push-ups.
  • Agile or death. Everything must be perfect. If a post-it is twisted, he straightens it.
  • Agile Carousel. Iterates but don't moves forward. 
  • Agile Titanic. They wanted to amaze the first class with speed and they sank the ship, but the price is paid by third class.
  • Agile Denied. He asks for other's opinions, but not listen them.
  • Agile-radio controlled. He wants to push a button, move the lever, and all must obey.
  • Agileban. He couldn't make Scrum works, and uses Kanban. And then calls it Scrum to feel better.
  • Pusillanimous Agile. He is not Agile because the Customer is not Agile.
  • Forensics Agile. He performs the Retrospective, but when it is too late.
  • Telepathic Agile. He not communicates until demo. And don't writes acceptance criteria even.
  • Nike Agile (Just-Do-It). He believes that to be Agile is simply doing what is needed to be done.
  • Agile Hero. He believes that the Force is the solution to all. If he is late, then works overtime or increase the team. If he has lack quality increases controls. If he needs a resource, increases Stock.
  • Hole-In-One Agile Unknown approximation process. If it is not done, is not useful. It's All or Nothing.
  • Agile Drugstore. Open 24 hours. Do not leave for tomorrow what you can do at night.
  • Agile Sheriff. The Manager friendly dedicates to watch the process. Intervenes only when something goes wrong, with wrong manners, and to find the guilty.
  • Cast Away Agile. He hires a remote freelancer. Then he don't communicates until the project's end.
  • Agileitis. Or rather known as "Means delay End". Perfectitis. Qualititis. Architectitis. Testitis.
  • Agile Patrol. Visibility is concerned, but as a tool for control of personnel.

Send me your opinion!

TDD and ATDD with JavaScript

Hi Agile People!

In this chance I want to share with you this tool that I recently created and implemented. It is a little JavaScript Unittesting Library, and a TDD exercise building the Conway's Game of Life.

So this has at least three uses:
  • To perform testing in JS 
  • To do TDD/ATDD on JS 
  • It is a CodeRetreat or CodingDojo facilitation tool. 

In the last case, is just enough with download the project, erase the code on Game and Cell classes, erase the tests and start coding!

¿Why JavaScript?

Well, it can run in every environment, using Firefox, Chrome or Chromium, you can enter to the console, and see the test's results.

And on the other side, it is a way to create something visually attractive to the people who atted to the meet up, and for that, more motivational.

You can see the Game running here: http://js-tdd.sourceforge.net/

And you can download the project doing:

svn checkout svn://svn.code.sf.net/p/js-tdd/code/trunk js-tdd

I hope you enjoy this!

Send me your opinion!

Agile persecution.

Hi Agile fans!

This time I bring to you an example. Is a Video that can help you to think about some agile principles and contrast with your present habits. The story consist on a "spy persecution". This scene belongs to the movie "Johnny English Reborn (2011)".

Here we can see that the MI7 agent uses the best tools money can buy, respects the lower effort principle, and the simplest way. Additionally, he maintain a high quality sustainable effort. Please note that he uses an "strategic effort", generating great results thanks to the "power of good tools" not the "power of effort".

I hope you enjoy it.

I wait for your feedback!