You should insist your client to take up the Product Owner role

I just read an article posted in Scrum Alliance, by Patrick who thinks otherwise. However, I strongly disagree with his point. Perhaps due to both of us working in a similar environment (development efforts provider) provide me an opportunity to better understand where he is coming from.

I have coached a few Scrum team, all of them are very new to Scrum Framework, some may have individual member who have previous Scrum experience but not the entire team. In each team, I have always insisted the Product Owner role to be played by the client side. Preferably from the same person, who sponsored the project, however this is always difficult because the project sponsor are always too busy to commit themselves into this role.

I always use the metaphor that if you want to buy something that is highly customized, and you are paying it, would you want someone to decide every single detail on your behalf? Or you would like to be able to make every single design decision by yourself? Who can know what you want better than you? If you are too busy to make all those decisions by yourself, won't you entrust someone who you know better on that role than let the supplier decide?

In my cases, I experience the following benefits when Product Owner role is played by my client representative. I focus on coaching the person to be a good Product Owner (CRACK)

C: Committed (to the team, the project and the business)
R: Reliable (has time and is available when needed)
A: Authorized (can have the final decision and can have it fast)
C: Communicative (knows how to bring the message across)
K: Knowledgeable (needs to know what it is all about)

Benefits:
1. Client feels that they own the project
This is one of the key reasons why Scrum advocates the user to play the role of PO. They should not throw the responsibility of the project over the wall. With the PO create and maintain the product backlog, direct the team on what to build on each Sprint, decide on the product backlog priority, it give them the feeling of ownership of the project. It also make the communication of the project status and certain decision making reason easier in the client organization.

2. Client enjoy the transparency and hence difficult project decision are made easier
Having the PO from the client side also encourage transparency, hence there should not have many surprises when a challenges (technical / non-technical) pops up. Should a particular user story needs more efforts that could impact the project budget and schedule, that decision was made easier with the PO having full information and visibility to it.

3. Better team spirit
You really want to eliminate the feeling of vendor vs supplier within a project team. The project team (PO, Scrum Master and Dev Team) has only one goal, i.e. to make progress to the project. Having PO from the client side will eliminate a lot of unnecessary political red tape along the way. Make all them temporary forget which company they draw their salary from will encourage them to make decision that benefit the project.

Programmer - Asset of a software company

Unfortunately, many business owners actually think the same as the CFO. There are still many company treat source code as their sole intellectual property, this is a misunderstood concept by the non-technical business owner.

A software company can still function without all other roles (Sales, Admin, Finance and etc.), but they cannot call themselves a software company if they do not have any software programmer. Hence, I think it is fair to think that software programmer is the asset of any software company. The source code is a side effect or by product.

If you ask any business owner, would you like your business assets to increase in value, or decrease? I am sure they will look at you as if you must be really silly to even ask such question. However, if you ask them again, do they have any process in place to make sure their software programmer attending training, or even allow to attend any skill enhancement program; they probably will say no. Is this not weird? I have seen most company have the process that their software programmer needs an "approval" to attend training, let alone having hours set aside every week to perform self-study. Why would you create a process to prevent your assets increase in value? Do you think like the CFO in the quote above?

Budget Calculation for Agile Project

This has been one of the most widely ask question I have encountered. How to perform budget calculation for Agile Projects where scope is variable?

I can understand why businesses would like to know how much it would cost them for a particular project. They will feel more comfortable to know their "risk" or investment boundary. While I always reminded them that they should focus on both Profit & Lost of the project rather than just the cost alone, I do share with them some approach of Project Investment model that they could consider.

1. Using the traditional way of project budgeting, while in traditional project budgeting where they need to dive deep to get accurate estimation, they should just stop at high level estimation and apply some extra percentages for buffer. For example, they should be able to derive some guesstimate at the feature level. First by determine number of feature they wanted to build, estimate efforts for each feature, apply 30% onto the estimation as buffer. They do need to remember that they need to allow the scope to change and hence not all features may be built when they the budget is finished. They need to make decision to trade off feature for every change.

2. Extension to the method above, the business should make decision after every release. They could just approve the budget for first release, at the end of first release; they then decide again the budget for the next release. In this case, they do not have to approve a big amount up front for the entire project. This would help better cash flow control of the company. With Agile project management, it allows the business to have early release compare to traditional approach. The business could then use the feedback gather from the release to decide the budget for the next release.

Young Software Product Company's Challenges on Scrum

The company is small and young, they are trying to build a product, after the first release, and they receive many "project" requests from almost every new opportunity coming in to them. The team end up throwing the Scrum out of the windows to fulfill every single request for each project. They are adding on technical debts and have no time to clear the debt.

Does this sound familiar to you if you are in a small software start-up? Balancing between product development and business development is a tough game. On one hand you are consciously aware that you should not turn your company into a System Integrator where every deal is a project and required significant modification to your product. You know that you are not charging the customer using the System Integrator rate, and you are fully aware that you will be forced to maintain separate code base for each "project". Hence the maintenance cost is much higher compare to normal product sales. However, you are desperate to have some reference account to kick start your business. What could you do?

Could we treat the project Change Request (CR) the same way as we treated the support request? In normal Scrum project, I will reduce the capacity of the team to take on new items from product backlog after the release. For example, I will only cater say, 70% of the team capacity (base on average velocity from previous sprints in Release 1) for task allocation in 1st sprint of Release 2. I will communicate with the Product Owner that the remaining 30% will be reserved for support activities. However, rest assure that the team will not stay idle should there have no support requirement. As a standard Scrum practices, team will continue to work on user stories on the next sprint if they had completed earlier for the current sprint.

In this scenario, I will make every CR for projects into a support ticket. In this case, they will go through the investigation phase, appear in the product backlog and etc. The Product Owner should then take those support case into their product design consideration just like any other support request.