Is the Product Owner a Villain?

Short answer, yes. Long answer, still yes.

The PO hasn't has to be a villain, only look sometimes like one in front of her team.

Why such a nice gal like the PO has to look though? Simple, if she doesn't, team members will end up imposing whatever they believe that the user should need from a system rather than to hearing to user's requirements.

By the same token, as a user's representative, the PO is in charge of sometimes say "your work is not what what I need, I can't sell that to clients, you need to redo it". The team will be close to kill the PO but in the long run her firm hand rejecting not good user stories or asking for work to be redone will be key for taking the ship to good harbor.

Dirty work PO's it is, but somebody has to do it. May the force guide your steps POs.

Scrum Bolivia User Group in the Agile Alliance

Our Scrum Bolivia User Group is now officially registered in the Agile Alliance group listing, see http://www.agilealliance.org/show/1641

When Pigs Become Chickens

I received and interesting question, somebody asked me about some reasons why a pig might become a chicken I can think in a few:

1. The pig is a low performer and she is as productive as a chicken
2. The pig's motivation is so low that she acts like a chicken
3. The staff was reduced and we have less pigs or some were reassigned to other projects but still play chicken's role in our
4. Part time engineers that switch among projects and don't really contribute to any
5. Upper managers who like to play pig's role but run away when they have to get their hands dirty with complicated tasks

Mechanics and the Myth of the Satisfied Client

It’s always a true in software development that we try to satisfy clients believing that they’re always right and they always know what they want. Further, we tend to think on them like almighty goddess with unlimited decision powers. But let’s think it twice, why should we be more committed to customer satisfaction than other service industries?

Let’s take this example from real life, my real life at least. I took my car to the car shop because the front wheels were making some funny noise whenever I slammed on the brakes. The mechanic when below the car, took a look and found nothing. I insisted in that the car was making noises when I drove it, the mechanic said let’s take it for a test ride. I drove the car, slammed on the breaks and again nothing: no noises, no breaks failure no nothing. The mechanics just smiled to me and charge me a no cheap fee for his time.

As a customer, what was my problem? Did my car really have a problem? It was a random not easily reproducible bug? Honestly, I don’t know, but I’m sure that I’m not crazy and the noise was there. So the point is, does the client have enough knowledge to diagnose problems? More to the point, what approach the mechanic used to try to pin down the problem with my car? No big up front requirements, the mechanic uses and iterative approach for diagnosing, fixing is incremental and many times mechanics have to inspect and adapt their work as they move.

Lastly, mechanics usually don’t tell us how much they’ll charge us for their services; they complete the work and then ask for payment. Most of the time your car is fixed and you paid without questions. What a wonderful life mechanics have, don’t you think? Something that we can copy?

My article has been Published by the Agile Alliance

An article that I wrote last month, Key Metrics for Measuring Sprint Status, has been published by the Agile Alliance, see this link http://www.agilealliance.org/articles_by_category?id=10

The full article can be also found in this blog: http://juanbandaonscrum.blogspot.com/2009/08/key-metrics-for-measuring-sprint-status.html

Scrum Bolivia User Group on Twitter

The Scrum Alliance officially announced the creation of the Scrum Bolivia User Group on Twitter.

The Scum Bolivia Yahoo! User Group has been Created

Finally the Scrum Bolivia has an official User Group where Scrum Practitioners can meet to share experiences and learn from each other, this is an open group so no moderator approval is required. The link to this group is http://tech.groups.yahoo.com/group/scrumbolivia/



The Scrum Alliance also made public the creation of this group, and include it in its listing of official groups, see this link http://www.scrumalliance.org/user_groups/74