public class ScrumTeam implements SoftwareFactory{


Scrum doesn’t work.

The team is not able to focus in the vague user stories coming from unclear requirements that show up always in the last minute and nobody is accountable for.

The quality is very low.

The people mood is underneath demotivation.

And all is very strange. Why it doesn’t work? We are doing Scrum! We are following the rules, what else do they wanted?

Ok, the daily meeting became sort of reporting but, in the end there is always a manager eager to know how is everything going on, isn’t? It’s normal, it’s still Scrum facing real life.

We were even more agile than the framework and we decided, well, the manager did, to gain that stupid time that we were losing doing refinement sessions for other things; nothing better than a non-discussed one-line user story for a team member creativity.

Furthermore, the team was so big and split it in individuals with barely interactions between them maybe didn’t help out but, guys, this is like having a lot of teams doing a lot of things. As much teams the better, they say.

Besides that, the rest of Scrum worked out very well. Needless to say that we decided to avoid retrospectives, because we didn’t have time to lose and, of course, also the reviews. But we kept sprints. More or less. Depending on the client releases.

Yes. Our fault. Probably with all those changes Scrum started to not be Scrum but we needed to do it because it wasn’t well implemented. Luckily we realized that on time and now we are going to improve, I promise, some changes are coming:

First of all we are going to mix people among different teams of different products so they will spread the knowledge. That will be great for the oncoming releases. More people, more work done in less time. Great.

We are going to remove also the Scrum Master role. Well, we have been working without SMs several months and nothing happened so more hands to code. Who needs Scrum Masters them when you have more Product Owners than teams?

Also, we will include the manager rotating among all the teams, which will reinforce people motivation for sure. And people is always criticizing the amount of meetings that Scrum have so we will avoid retrospectives again to gain more coding time.

Now we are on the right path, I can feel it. Now it will be fine. Now this strange way of doing things called Scrum that we love and that only applies to developers won’t throw any exception.



  • Are you doing Scrum?
  •  Yes, but we have slightly modified it according to our company needs because, in the end, Scrum had too many meetings.
  • Oh, cool, let me ask you again: are you doing Scrum?

When somebody tells me that Scrum has an excess of meetings I start wondering which one could we remove because, oh my lord, if there is something that an engineer love is removing things and, if possible, without the recycle bin preent. So, where is the starting point?

  • The daily meeting? Oh yes… we will gain the most precious fifteen minutes of the day and, in fact, people talk constantly so they will figure out at some point what the others are doing.
  • The sprint planning? Perfect, lets avoid the planning. Nevertheless it’s a pointless and long meeting where the team focuses in the sprint that is going to start and decides what to do and how to do it. The backlog is always there so the work should be always clear.
  • The backlog refinement? Absolutely agree. I don’t know why POs aren’t using telepathy nowadays.
  • The sprint review? Completely pointless. The result of the sprint done by incredible mature teams in perfect and enviable environments are always available in the end of each sprint so anyone can see it, touch it, test it and understand it.
  • The sprint retrospective? Yes, please. There is no need to play with cards, legos, draws and post-its; we are here to work. To work like we always have worked.

There is no need to play with the words as there is no need to say that we use Scrum when we don’t really use it. It’s not mandatory to do Scrum to be in the cutting edge of technology.

But, if we don’t want to feel uneasy with the environment or the agile community, we don’t want to use the term Scrumbut and we need to satisfy our inner micromanager without taking into account that all the Scrum meetings are intended to empower the team, lets call our process Watercrum. How knows, maybe it will become mainstream.

10 tips for dummies that any great product owner need to know


Product ownerSeriously?

We love lists, we love magical recipes; thus we love magical recipes that can save our live in form of a list, and if the list has ten or less points, the better.

The product owner role is, in my opinion, the most critical one within the Scrum framework and IMHO is the most forgotten one; we tend to emphasize the great and complicated work of the Scrum Masters, maybe because someone decided to add the word Master at some point, setting aside the poor product owner out of the team.

So, what can do a product owner to excel? The first step, avoiding any magical list, should be to act as a real product owner:

  • following the rules,
  • fostering the values,
  • embracing the principles and
  • sharing the goals.

This is a hard task by its own and once understood and achieved maybe we could think in overtaking some top-notch level.



Does Agile need to work?


WordsAgile has became mainstream during the last years. A lot of companies talk about Agile and try to use it, implement it, adopt it, foster it, compare it, adapt it, modify it,  or even find excuses if it finally doesn’t work. But, does Agile need to work? Or is it an abuse of language?

What really needs to work is your business. Agile is a mindset, that promotes a behavior, that is reinforced with the use of some frameworks that, in the end, fit quite well with Agile.

Words are important and we need to take care of them, not only in the Agile world but everywhere. Otherwise, maybe we will say finally that language doesn’t work.

Playing with brainstormings



Some months ago the great people from Talentians called me to help them in a brainstorming session. The idea was simple: gather insights about what they were, where they wanted to go and hopefully ending with some actions to take in a short period of time in order to achieve their goals.

We didn’t work directly finding the vision, the mission and the values, typically shown in all the corporate webpages but we put in common what the company was for each one of them. How we did it?

Lego brainstorming recipe for 5 to 6 people


  • Lego pieces, no less than 1000 of beautiful colors.
  • Post-its and markers (this is like salt and pepper in the agile world, always present).
  • A wall or a flip-chart.


Preparation: 5 minutes.

Cook: 1 hour

Ready in: 2 hours.

1.- Set-up the session with a light activity of 5 minutes or less. You can ask the people to define their feelings in one word, or their expectations of the session or any other activity that put the people in context and align. Beers are allowed.

2.- Give some post-its and markers to everyone involved.

3.- Seat the people around the table and spread all the Lego pieces in front of them.

4.- Give them 10 minutes to build something with all the pieces they want that represent, for them, the company. (It is not as easy as it seems).

5.- When the time is done each one explain to their colleagues what their construction is about.

6.- Every one pass their construction, clockwise, to a colleague. The new owner of the figure has 5 minutes to improve it, either adding more pieces or changing the existing ones or removing some of them. When the time is over the person has to explain what she has done and why.

7.- Once all the members have explained their improvements in their current constructions, the real owner of the figure, the former, the father, the original one needs to write in a post-it what that improvement means to her.

8.- Repeat steps 6 and 7 until every one have touched all the constructions. When the round ends each one has to have one post-it for each modification.

9.- At this point is time to gather all the post-its, to post them in a wall, group them, analyze them finding for similarities and work all together in the common ideas that have came out. More beers are allowed now.

10.- Once we have the top ideas is time to use any technique you know to decide some actions to take 🙂

lego pieces

Some conclusions showed up after facilitating this session:

  • Playing with something tangible, physical such as Lego pieces make the people reappraisal their thoughts. It’s not easy but it’s a way to explore other ways of communication coming out with new insights that otherwise, using only words, could not appear.
  • You create a structure quietly, thinking any detail and any piece; thinking how you can represent what you have in mind and, afterwards, another person modifies it, holy s***!. This is a good exercise of sharing, of understanding other points of view and accepting and embracing changes.
  • It’s worth it to analyze how people try to improve other’s constructions and what are the common pattern to do that.

Observer pattern


How much energy are you willing to dedicate to a specific problem, person, situation or momentum? How much effort do you think is needed from yourself? Recently I realized that my energy ran out so quickly and I think I was looking for the causes in the wrong mental drawer. Eventually, though,  I recalled a typical design pattern widely used in software architecture: the observer pattern.

Have I been really an observer of the situation? Then, why my energy dropped off so fast? The conclusion that I came out is No, I haven’t been. In fact, I have been quite involved in every situation. I have been there, inside, being part sometimes of the problem without even notice it.

If you take a look at the definition of the observer pattern in the Wikipedia and change the word observer by Agile Coach maybe you will find some curious relationships that fit with your current life. Nevertheless this pattern is not perfect and can cause, among other things, memory leaks.

“Agile” “Coach”


Some days ago I was thinking about the purpose of being an Agile Coach and sadly I realized, or at least I thought, that being an Agile Coach is impossible just because the words. Can agile and coach suit together?

This is only an opinion, a humble opinion in fact and I expect that someone refute it eventually but as far as I know a coach tries to help the others find their own solutions to their problems. When putting the word agile, that in the end implies a specific set of tools and techniques that come with the agile way of thinking, we are giving beforehand the solution to some unknown problems. But this is not the saddest part, the commercial part is that those other are hiring us because they want, sometimes even without really knowing their problems, that their solutions would be agile.

So what? Honestly, the word agile has a very marketing power and we need to exploit it. But to exploit doesn’t mean to abuse. We need to reinforce the message, we need to spread the values and we need to be honest and sincere not selling agile just because it’s cool.

By the way, my LinkedIn profile still shows “Agile Coach” and I’m not going to remove it. At least not for now.

Route Coaching Game


Some months ago I got in touch with @BrainPicnicNews, the author of Ikonikus. I bought this game with the idea of use it in retrospectives and it worked (and works) really well. Talking with Manu he gave me the contact of  @abrionesbarco, a guy who was working in another game just intended for coaching purposes. I loved the idea so I acquired my Route Coaching game.

Route Coaching Game

Needless to say that I have used this game a lot, not only for coaching purposes in one-to-one meetings but also in retrospectives with four and five people and, the most amazing part, in job interviews!

It’s interesting to see how the people try to express themselves with cards and icons. The way how I use it it’s simple and follows, more or less, the rules proposed by Ángel Briones: Depending on the meeting (a retro, a personal meeting or a job interview) I post a question that is the goal, something that have happened or that we want to achieve and, with this setup in the table, the game begins and longs for 20-30 minutes, enough time to gather and share a lot of information with all the participants.

I will keep up using it and making up more rules and I encourage you to do the same.

Por un Scrum popular


There are books that should be a must in any agile library. One of those books, without any doubt is “Por Un Scrum Popular: Notas para una Revolución Ágile“. Yes, it’s in Spanish, even it’s a translation from “The People’s Scrum: Agile Ideas for Revolutionary Transformation“.

Por un Scrum Popular cover

Por un Scrum Popular cover

I’ve read the Spanish version and this is, I think, the only technical book that I’ve bought in this language. Sincerely, I don’t regret. Under my point of view, the book is very well translated and contains, after each chapter, a brief annotation from Alan Cyment (@acyment), which gives the book one more drop in its revolutionary content.

Of course this is a text  that can be read at any time, whatever the level of Scrum that the reader could have but if you have played with the framework in the real life, in the trenches, with real issues, real people and real projects for sure you will assent at every sentence, you will seize every paragraph and you will drop some agreement tears after each chapter.

A lot of quotes could be extracted from the book but it’s not worth it, the best thing you can do, if you are in this fight, is just read it. And enjoy it 🙂


Blockers; more than I expected


If you have asked me some months ago which I thought it would be the most important agile blocker inside a company for sure my answer would be ‘project management’. In fact I think that the same answer had appeared also only some weeks ago.

Project management… but, do you really think so?
Well, yes and no; project management or top management could be an important blocker to any change that involve management but there are, in fact, more blockers than expected, starting from the people who must be part of agile teams.

How can a future team member be a blocker?
How can a QA specialized person be a blocker?
How can a project manager be a blocker?

To tell you the truth, maybe blocker shouldn’t be the correct word, but I’m still searching for a new one.

Fear of change. Typical. In all the old-fashioned hierarchical layers of a firm. Fear of not being indispensable when, as a matter of fact, we are all expendable at any time.

Being agile requires a strong change of mentality. But this can’t be automatic; a lot of information is required, as well as a lot of training, coaching, more information, demonstrations and, the most important thing among the rest: to know the context.

There are a lot of context that we need to know or, at least, that we need to realize that they exist. Starting from the company’s context, the department’s context and all the personal contexts of the involved people. Difficult, isn’t? Well, challenging, that’s all 😉