Doing Agile- Product Owner

Have you ever heard of the following comments?

“You are the expert, you tell me what to do”

How about these comments?

• “I will not be able to participate the meeting today and if you have any questions, pass them via mail”
• “I have given you all my requirements. Now you can run the project”
• “I will be little bit busy this week as I am working on an important proposal. Since you have good understanding about what I want, let me know if there is anything you can’t resolve“

OK, let’s discuss some details.

Although Agile was first introduced in early nineteen nineties, there are many organizations that haven’t done its first agile project yet. Refer M&T 2008 survey.

There are many issues that an Agile team faces when they tries to use Agile Methodology with a customer organization that does not have previous experiences in Agile.

Let’s take Scrum and start with Product Owner.

Who is Product Owner?

Let’s try to look in to the definition in order to start the discussion. Let’s see what Mountain Goat has to say about the definition.

According to their Redistributable Scrum presentation, PO,

• Define the features of the product
• Decide on release date and content
• Be responsible for the profitability of the product (ROI)
• Prioritize features according to market value
• Adjust features and priority every iteration, as needed
• Accept/reject work

The definition is pretty straight forward and let’s sees how a typical Scrum project would happen for a customer organization that does not have previous experiences in Scrum or Agile.

What is happening?

Now let’s run the project in fast forward mode. The main character is a person who is trying to set up the project. Be it a Project Manager, Scrum Master, Senior Team Member or Head of PMO.

Before starting

• You request that the Product Owner (PO) role should be played by a person from customer’s organization. The response?  You will get a name of a person immediately.
• Then you will explain the process, roles, responsibilities, etc. to the Product Owner and everything is perfectly understood by the PO.
• Then you will put your demands to the table. For example, the PO should be there in Sprint Planning Meeting, Daily Scrum, etc. Response? Every demand is accepted.

So with everything going pretty well, you are pretty happy and excited about the new project and its delivery.

Sprint 0?

• Now you ask the PO to create the User Stories.
• Then after couple of days, you will get a “2-3 page document” that describes the system in high level.

Opps!!!

• Then you will send your User Story template and ask him to document the requirement according to that format.

Let’s discuss some details now.

Typical issues when you have customer PO

1. User Stories –  What is that? Never understands the User Story template and usefulness it (well “never” is bit of exaggerate but it is very rare this understanding is there)
2. Product Backlog – OK, I will do. But never creates the Product Backlog (PB) correctly
3. Requirement ownership; That is me – But the requirement ownership is pushed to the project team when the project progresses
4. Agile process – What is that? Never understand the process related to Scrum/Agile
5. Sprint Planning meeting – Good to have.  This meeting is a meeting where the development team explain their version of requirements to the PO.
6. Scrum Meetings –  I will be there. If you find the guy, you are lucky.
7. Release Demo – This is what I was looking for. Yes you will find the guy attending. He will be mostly happy with what the team has produced. But he will always has the question why functionality X is not there in the release – Where the X functionality is never even planned at the release.
8. Agility- OK, I can change anything. Misunderstanding of Agility. When you initially talk about agile process, the response would be “yeah I have heard about that and it’s good that we are using it”. But what are the thoughts behind those words? Ha, we can change everything.
9. Retrospective- Everything is fine. He will provide very good feedback about working with the team – Of course the team deserves it as they have taken the burden of PO and come up with great results. But availability of PO, commitment of PO, etc. never discussed in the retro.
10. When do you finish –  My demand. Always wanting to know when we can finish the development. Exact date, not possible in Scrum (at least in the start of the development)

Implications to the Project

Let’s see how the above points would affect the project.

Requirement Ownership

If you look at the problems related to requirements in the project, (a proper PB will never come from customer and requirement ownership slowly pushes to the team as project progress) what would typically happen is that the project team gets the requirement ownership. This means we would have

• Missing requirements
• Wrong requirements
• Incomplete requirements

This kills the foundation of Scrum and there is a great risk of wrong product being developed before somebody catches it.

Also this would require deploying shadow resources such as “Proxy PO”, “BA”, “Project Manager”, etc. This makes the cost of development higher than usual.

Lack of understanding of Scrum process

When there is no understanding of the process, there will be no understanding about the activities, tools, techniques, etc. which goes with it. For example, what is sprint burn-down is and the benefits it would give.

This would lead to two major problems

1. Customer is always curious about what is going to happen and how the team would work to achieve the final milestone.  This would lead to a situation where customer is not certain about the things going on with the development team and the bonding between the customer and team is not that cohesive.
2. There will be demands to the project team from the customer for things that are not possible to satisfy from the Agile model. For example when the team will finish the project, etc. This leads to a situation where the team has to revert to non-Agile tool and techniques to satisfy those demands as there is pressure from the management to satisfy those in order to keep the customer happy. For example, how many of you have seen, teams preparing MS project plan to find out the end date in addition to the scrum tools?

This situation will lead to

• Duplicate of work
• Lack of trust towards Scrum process by both the team and customer
• Extra pressure to the project team due to the demands that cannot be satisfied

Lack of participation to the meetings and lack of enthusiasm

• Lack of guidance to the project team resulting project team moving in not so correct direction
• Taking un-necessary effort for the tasks that should not be there in an ideal Scrum. For example requirement elaboration, documentation, etc. This lead to a situation where the team is being distracted from their main tasks in order to perform above mentioned supportive tasks.
• Need to deploy shadow resources such as “Proxy PO”, “BA”, “Project Manager”, etc. This makes the cost of development higher than usual.

Miss-interpretation of Agility?

This miss-conception of anything can be changed anywhere is deadly dangerous to the project. There are many situations that during the Sprint, the requirements are changed, release dates are changed, etc.

• When requirements are changed in the middle, those are not well thought of and never properly planned. This will make wrong functionality being developed, regression issues, etc.
• Also this will lead to requirements being conflicted with each other.
• With this it is no possible to find out team’s real velocity.

Impact of biased retrospective

Answer is pretty simple.  The improvements needed from customer are never done and none of the above discussed issues are ever corrected.

Reasons for the above Situations

1. Customer is the King – Typical customer supplier relationship makes customer to pass everything (especially boring tasks) to supplier. In most cases, the supplier team is not strong enough say no to that. Even if there are courageous personalities in the team who can do that, those people are normally killed by management of supplier stating the importance of customer, etc.
2. Conceptual difference – Scrum and Agile are conceptually different from traditional approach which customers are used to.  Therefore making it little difficult to understand the concepts and specially usefulness of them.  For example, you don’t talk about team velocity, you don’t estimate work in story points. Instead in traditional world you estimate man hours and give them a fixed finish date.
3. Time to enjoy – For some customer PO, working on a supplier project is an opportunity to relax from his tough day today work. Why? In a failure, there is supplier project team to take the blame no matter whose fault is.

What should you do?

• Project is the king. No matter what happened, it should be both customer’s and supplier’s responsibility to ensure that the project is successful. Therefore customers should learn to be more flexible and suppliers should learn to be stronger.
• Education. If you find a customer who does not have previous exposure to Scrum/Agile, it should be a part of the project process to run a workshop to educate them as well as if possible to ask them to go on a professional training. May be it is a good idea to have at least one person from customer to be certified as a certified scrum master.
• There should not be any compromise to process. Unfortunately the process is as good as people it runs. But the project teams should always try to adhere to proper process and should not find alternatives. For example, project teams should not employ “Proxy BAs” and instead should push customer to do the work properly.