The Product Owner in Scrum

What is the role of the Product Owner in Scrum? 

The product owner’s responsibility is to ensure that the product is developed and delivered in a manner that maximises the paying owner’s return on investment.  In Scrum, what this means is that the product owner must identify for the Team those product features that deliver the highest business value for money amongs the outstanding product features not yet delirvered.

There is the assumption that there will never be enough money to build every desired feature.  Therefore, the features need to be prioritised.

The Product Owner does not dictate to the Team the specific set of features they need to build in a Sprint.  

Specifically, the Product Owner does not tell the Team how many features they ought to build during a certain Sprint – that decision belongs to the Team alone.  The Product Owner’s main role is to inform the Team of the priorities, so that they don’t proceed to deliver lower value features over high value ones.  There can be exceptions - for example a lower value feature may be included in the Sprint over a higher value one because the higher value one is too big to be added to the current Sprint, while the lower values one is small enough to be added.

It is possible that the product owner is the customer, but he or she must never be the Scrum Master.

The Systems Engineer Genie

A whimsical look at what it could be like if the genie has been trained as a Systems Engineer.

A man walks along the beach and comes across a magic lamp.  He rubs the lamp, and out comes a Genie.

“Greetings, Master, I am a Genie from INCOSE.  Your wish is my command.” says the Genie.

Excited, the man says: “I want a million dollars!” and holds out his hands, anticipating the goods.

But nothing happens.

The man demands: “Where’s my million dollars?”

Genie: “I am an SE Genie. That’s not how we work.  First, I have to understand what it is you want to achieve, and help you come up with the best solution.  Master, why do you need a million dollars?” 

Man: “What ?!? Ok I want a million dollars so I can quit my job not have to work anymore!  Give me my money!”

Genie: “Ok, so you’re not happy with your job.  We should look at the different possible solutions to that problem and not jump to conclusion about the solution.  For example, perhaps you can move to a different job?  I can grant you a new job.  Or how about I make it so that you enjoy your current job.  Say, if we make you the boss?”

Man: No, no, no!  I want a million dollars so I can enjoy myself.  So I can do what I want, like travel, eat good food and drink great wine.   I don’t want to work anymore.

Genie:  Ah I see.  Now, instead of a million dollars, what about a lifetime free air travel?  And lifetime free meal vouchers.

Man: No, I want money!

Genie: OK, I guess we have settled on the concept of operations. You get money, and spend it on whatever you like.  Now, let’s get the requirements right.  Are you talking about Australian dollars, US dollars, Brunei dollars, Hong Kong dollars?

Man: “US dollars! A million US dollars”

Genie: Great, How do you want to receive it? In cash? In coins? Deposited to your bank account? A lump sum? An annuity?

Man: “What?”

Genie: How does this requirement sound:  “The genie shall arrange to deposit a million US dollars into the following bank account XXX-XXXX no later than 5 business days from today.”

Man: Great! Let’s do it.

Genie: We’ll also need to agree on how you will VERIFY that you have received the million dollars.

Man: “What?”

Genie: Verification, how will you check that I have fulfilled your wish?

Man: Ok!  Uh… I will check my bank statement, and if I see a million dollars, then we’re fine.  I will also sign a document saying: WISH GRANTED.

Genie: Then we have to integrate the money into your life.  How will you explain this to the tax authorities?  Do you have any outstanding debt?  Should the money be placed under your name or to a legal entity?

Man: Forget about those things and just give me my damn million dollars!

Genie: We also need to think about the effectiveness of this proposed solution.  Like, will 1 million dollars be as as 2 million dollars?

Man: Just give me 100 million dollars !

Genie: Granted!

And the man got his 100 million dollars and got investigated by the tax authorities and his money got frozen by the anti-money laundering regulatory commission and the man spent the rest of his life paying legal defense bills, all because he ignored the sensible analysis required by the SE Genie.

The Likelihood of an Event

The biggest constraint in risk management, indeed the very reason for the existence of the discipline, is our inability to foresee what will happen next. 

In most cases where people have to manage the risk of an event, it is very common to rely on subjective estimates of the likelihood that the event will happen. It may be easy to deliver criticism of this approach, but alternative options are limited.  

An improvement over such a simplistic 'gut feel' approach is to incorporate the phenomenon that events of a smaller scale occur at a higher frequency than similar events of bigger scale.  Earthquakes of low magnitude occur very frequently. Killer earthquakes occur far less frequently. 

The relationship of the frequency between the two types of events is described a the Power Law Distribution.  If we keep track of smaller scale events, we will be able to predict with a certain degree of confidence the frequency of the bigger scale events.

***

Deciding That a Crisis is Upon Us

A key challenge that needs to be met in the face of a serious situation is determining whether we are in a crisis or not? Whence is the transition from non-crisis to crisis? Is it time to initiate the crisis management plan, or not yet?

The US military gives us a good model of crisis with the DEFCON
status. It allows a staged reaction to a crisis that may be impending
or may not be impending.  It allows the military to prepare and also not to over-prepare.

As facts become known, and the understanding of the situation becomes more solid, the authorities are able to step up or step down preparations
and mobilisations for handling the crisis.

Business organisations would to well to think about a staged approach to
their crisis management plans.

Checklists

Checklists and questionnaires belong in the toolbox of risk professionals. A checklist works best when used by the risk professional while interviewing an information source, whom we’ll call an interviewee. 

The checklist becomes far less effective when simply handed over to the interviewee because when you let the interview work by himself,  it raises new undesirable dynamics:

• First, the interviewee loses the chance to ask questions about the questions being asked.  He may misunderstand what is being asked, but unaware of it.  In such a case, even if you informed the interviewee that they should ‘feel free’ to ask if they have questions, will not help much, because in this case, the interviewee is not even aware that they misunderstand.
• Second, the interviewee may not have as much interest as the interviewer in the process of gathering data.  In cases like this, you can expect that only the minimum amount of information will be written down in the checklist.
• Third, the interviewee may not see the whole point of the interview, and why they must fill in the checklist. As in the second dynamic above, this results in lacking information.
• Fourth, a large number of checklists and forms are very badly designed, which can easily lead an interviewee to confusion. Many forms ask for too many things. The interviewer may have energy to fill in the first few entries, but a noticeable drop in energy due to a drop in interest can often be seen.

A well designed form helps much toward eliciting good information.  At the very least, the following should be addressed when designing questionnaires and checklists:

• Who is going to use the contents of the checklist?
• To what purpose are they going to use the contents?
• Who is going to provide information to the checklists? (That is, who are the interviewees)
• What kind of questions and prompts should the checklist contain in order to elicit the information required?
• What kind of information does the current version of the checklist contain that are not needed?
• In what ways can the questions and prompts be misunderstood?

It is vital that a checklist be tested on several interviewees first before finalising it use.

Risk Management Software Packages

In a LinkedIn discussion someone asked for recommendations on a web-based risk management software package that’s suitable for a SME (small to medium enterprise).  The key need was for managing a risk register and for tracking risks.  Some of the recommendations were:

• @Risk (http://www.palisade.com/risk/)
• Balanced RiskCard (http://www.riskcard.co.uk/)
• Active Risk Manager (www.strategicthought.com)
• Link ResQ (http://www.linkresq.ie)
• RiskAid or RiskAid Enterprise (http://www.riskreasoning.co.uk/)
• STREAM (www.acuityrm.com)
• Covalent Enterprise Risk Manager (http://www.covalentsoftware.com/product/erm/)
• EsyRiskManager (http://www.dnv.com/)
• Pims (www.omega.no)
• JCAD RISK (www.jcad.com)
• Magique (www.magiquegalileo.com)
• Aon RiskConsole (http://www.aon.com/denmark/en/esolutions/aon-risk-console.jsp)
• RiskyProject (http://www.intaver.com/riskyprojectprof.html)
• (http://www.align-alytics.com/)  (what product?)

This is quite a handful of choices. I’m hoping to be able to spend some time lokking into each one.

An approach to planning

Planning a project involves identifying the activities required to deliver the project and the inter-dependencies between those activities.  These activities and the dependencies are then modelled onto a network diagram.

Task duration estimates are often padded, as a matter of good practice, but also as a matter of covering one's behind.  Things often don't go according to plan and one has to allow for that.  If I estimate that task A will take 10 days, and I say it will take 10 days, and then something goes wrong, then not only do I look bad, I might also I end up delaying the next task which was set to begin 10 days later.  So the common practice is to be generous with our estimates and pad them for contingencies.  Such padding implicitly addresses the risks faced.  

There is another approach that integrates project schedules with risk management, and at the same time highlights the possible sources of these risks.

One way to bring this planning to a different level is to first make a realistic and optimistic estimate of how long each task will take.  Let's say if a task will take 7 days if no problems occur, then we start with 7. We do the same for each task. Then we study the task and its dependencies and try to understand what could go wrong that can cause its accomplishment to exceed 7 days.  Then we try to address those things that can go wrong.

Let's say the person doing the task will normally take 7 days to accomplish this task, but has other stuff on his plate, therefore it may take more that 7 days for him to complete the task.  Why?  Because his time and attention could be diverted to the other tasks.  If we don't highlight this reason then we can't manage it.  Suppose we identified that this person really has other stuff on his plate, then we can take steps.  We can schedule his task to be done after he has finished his other stuff, or we can arrange things so that he suspends work on other stuff, or we can just accept things as they are and simply pad the number of days.  At the very least, we have identified a possible cause of problems.  

There could be other factors to consider: this person could get sick during that time, his machine might break down, he could misunderstand the specifications,  or what's required of him and then we will need to redo things, and so on.

By thinking through the possible reasons for exceeding the optimistic estimate, we begin to identify possible causes of delays and we begin to be able to plan for those causes: try to minimize their chances of occurring, minimize the impact if they occur, etc..