Posts Tagged ‘tips’

The Good, The Bad and The Ugly Product Owner


If you have not seem “The Good, The Bad and The Ugly” (1966), now is a good time! I think this article is valuable anyway, but will probably make more sense if you have seen it.

Angel Eyes is a ProductOwner at One Man Army Inc. He is an ambitious manager eager for a promotion and to grow in the ranks of the company.

Tuco is a ProductOwner at Texas Inc. He has some ambition, but his main concern is to save his own ass. He was brought from Mexico Acme for a good sum, and he does not want to loose his job, that’s his main goal.

Blondie also works at Texas Inc. He is ambitious but has also a good sense of commitment with the company and his colleagues.

In any project, there is an underlying conflict between the personal interests of the PO and the interests of the company in which he works. A ProductOwner will always have a personal agenda in projects.

A ScrumMaster must be watchful and try to identify what are the misalignments in the interests of the Stakeholders and the interest of the ProductOwner in order to achieve a better success rate in delivery.

As a ScrumMaster you have to be very mindful of what type of ProductOwner you get.

Angel Eyes is very ambitious and only thinks on himself. He is likely to disregards how risky some of the items in the Product Backlog are. He seeks greatness blindly. Angel Eyes will probably end up dead.

Tuco is scared for his job, and is likely to disregard how much value an item in the ProductBacklog may generate for the company if that item carries a risk. He will not take any chances and wants easy wins. Tuco will end up alive, but penniless.

Blondie is ambitious, but his commitment with the company shows up. His interests seem to be very much aligned with the company and he is more likely to be a good ProductOwner. Blondie will finish alive and with the dough.

In any case, a tool a ScrumMaster has to mitigate the potential misalignment of interests between the Stakeholders and the ProductOwners is through transparency.

If your PO does not care about risks, give focus to spread this information. If your PO is scared and misses ROI opportunities, be sure to inform all involved that there is a prize to be taken. If your PO seems aligned, insist on Transparency so he won’t loose track.

A well informed Stakeholder is likely to leverage his influence on the PO to consider risks and take advantage of opportunities.

Transparency, transparency, transparency…


I’m a team member, what must I absolutely know about Scrum ?


I’m a team member, what must I absolutely know about Scrum ?

If you are a team member and know little about Scrum don’t despair. Here is a small set of recommendations I have for you:

1. You need a ScrumMaster in the team. The ScrumMaster should know about Scrum and will help with your doubts. Don’t think that you have to know all about Scrum, that is his job. There is no need to worry if you don’t become an expert in Scrum. That is not your job.

2. Learning the basic roles, artifacts and activities of Scrum is very easy, and some minutes reading should make you understand them. You should read about it and know the very basics. That’s the easy part and everyone should have it by heart. Give yourself time to learn from experience.

3. Understand that the proper use of Scrum requires good communication. While knowing the basic rules for Scrum is easy, learning how properly use Scrum to your advantage is difficult. Trust your ScrumMaster, talk to him, talk to the other team members. Keep communication channels open. Your ScrumMaster will be able to help you.

4. You have a set of skills and a job to do. If something or someone does not allow you to do your job, something is wrong. Talk to people about it. Let the ScrumMaster know about it. Ask for help. One of the key concepts of Scrum is letting people that know how to do the job do it.

Whether you know about Scrum or not, here is a rule to everyone:

5. No project can succeed if you don’t know your craft no matter how much Scrum you know. Dig into your architecture studies, read about design patterns, read about UML, dive into learning about tests or configuration management. Learn about TDD and continuous integration. All those things are essential to making software. If you are working in a business you know nothing about, take time to understand a little about it. If you can learn about tools that leverage your knowledge, do it.

Get to know YOUR trade first.

A good programmer with a process will outperform a good programmer without it, but all that a bad programmer can do with a process is to report very well how bad things are going.