Estimates, Risk & ROI

Today I got involved in a friendly debate about Cost Estimates in product development or project management.

In particular I responded to this statement from @PeterKretzman:

"Implicitly or explicitly, you can't make a purposeful decision without 'estimating' cost."

 He in turn was responding to a tweet from @duarte_vasco, who is of course an advocate of the #NoEstimates movement.

Firstly let me say that I am not a vocal advocate of the #NoEstimates movement. I've read the literature and applied it to my experience and other things I've read, but I don't feel strongly enough about it to be trying to raise awareness of it, or get more people to consider it.

In reading the quote above today though, I challenged myself to think about whether the statement was true or not, and asked the OP whether he had considered fixing the cost, and instead estimating the value that could be achieved for this cost, to achieve the same goal as [I imagine] estimating the cost. Namely; Is the ROI sufficient that I will take the risk.

Risk is what I want to talk about next, because all of this, for me, comes down to professional management of risk. ROI is a calculation of Return (reward) received based on the hope that Investment (cost) will provide. If we assume that Return and Investment are variable:

e.g. [We believe that ] our company needs a new way to bill our customers.

 ==> The hypothesis is perhaps that some customers prefer certain billing types, and that providing more options for billing will generate an increased chance of converting a sales lead into a paying customer.

 ==> We _estimate_ that in order to build the functionality, we will incur total costs of £XXXX.XX and XXX weeks

 ==> We _estimate_ that the increase in conversion will generate an addition of £XXXX.XX in sales/annum and/or profit, and as such can calculate the point at which the work will have paid for itself, and project ROI into the future.

Because we've estimated, that implies uncertainty. The cost is uncertain and so is the conversion uplift. Uncertainty is risk in this context. If the cost estimate is negatively off, but the conversion uplift is accurate then the ROI is screwed. If the cost estimate is accurate but the conversion uplift doesn't materialise, then the ROI is screwed. If both are negatively inaccurate, then we're really screwed.

Consider an alternative:

[We believe that] our company needs a new way to bill our customers.

 ==> The hypothesis is perhaps that some customers prefer certain billing types, and that providing more options for billing will generate an increased chance of converting a sales lead into a paying customer.

 ==> We _estimate_ that the increase in conversion will generate an addition of £XXXX.XX in sales/annum and/or profit.

 ==> Based on the estimate of value, we _fix_ the investment we are willing to make to find out whether we are correct. No estimate of cost [implicit or explicit] is required. Because we've estimated, that implies uncertainty. The conversion uplift is uncertain. Uncertainty is risk in this context. If the conversion uplift estimate is off, the ROI is screwed.

The cost wasn't estimated though, it was fixed. We've removed some element of uncertainty and in real terms ensured that we've limited our risk.

And this fixing of cost Doesn't need to be as constraining as it may sound. Imagine if its just a hard decision point, where we can choose whether to invest further or not? If you've heard of the sunk-cost fallacy, hopefully you'll recognise the value that creating this decision point [which gives you options] provides?

So what am I not saying?
 - I'm not saying that fixed cost is the way to go for everything
 - I'm not saying that you can focus only on the return (value) and not on the investment (risk).
 - I'm not saying that estimating is bad in any way.

What am I saying?

 - In risk lies opportunity, but risk should be actively managed, and using past performance etc to predict or estimate ROI can be a useful way to manage risk.
 - I am saying that logically, if the cost can be infinite, you can fix the return you want but typically it is more pragmatic to fix the cost and gamble instead only on the return.

Feel free to let me know what you think.

Faking it until you make it

Thanks to Gemma Cameron (@ruby_gem) for providing the impetus for me to blog again for the first time in ages.

A colleague of Gemma's - Jim Jeffries (@jjeffries1) tweeted today that breaking a waterfall project into sprints didn't make you agile.

Whilst I agreed, I felt that I'd been noticing that certain practices could yield benefits to teams even if their understanding of them, or more importantly *why* they were followed was quite shallow, and so I asked whether Jim felt that it could be a step in the right direction.

For instance, imagine a new starter into a team which observe a healthy daily stand up meeting. Does this person need to know the alternatives to this ceremony and have a deep appreciation of the principles which went into formulation of this ceremony, in order to enjoy its benefits?

Jim clarified that in his scenario, the only change from waterfall he was thinking of was to call each phase of the waterfall project a sprint, for example Sprint 1 == Analysis, Sprint 2 == Design etc.

Had this not been the case, had the scenario been breaking a long waterfall project into sprints but also enforcing that a product increment be released at the end, then I think that its possible that this might be a beneficial step towards agility - even if no depth of understanding was reached.

I think that a person's 'journey towards agility' is quite fractal, and that you can keep coming back to old practices and beliefs and re-analyzing them after you've had new experiences and learned new things.

And I think that you can, in some contexts, "fake it until you make it" by copying the practices of those who have been on the journey before you, and still gain at least some of the benefits.

DDD - a cute suggestion for naming of repositories

Tonight I've been messing around with some code in a TDD code-kata fashion, coding for practice as much as anything else. I decided to start to implement an order management system with CMS-like functionality, as a home project I could use to keep my interest over many nights of toil.

Anyway, I started to create a repository class - see Eric Evans Domain Driven Design (DDD). This class would be responsible for handing me my SalesOrder aggregate root entity from some obscure infrastructure that my domain didn't need to know about. I found that I was struggling with what to name this class. I was torn between SalesOrder (which seemed more pure domain language-ish but could cause me later confusion between that and my SalesOrder entity, and SalesOrderRepository (which gave me the separation I craved but didn't seem to fit with Uncle Bob's clean code naming guidance, nor Evan's ubiquitous domain language!).

I Googled around a bit as is my wont, and found a really interesting webpage. Let me share with you what it advised:

Instead of calling my repository either SalesOrder or SalesOrderRepository, what if I called it AllSalesOrders. This is:

1. Very domain languagey
2. Forces me to remember at all times that I am operating on/with a list
3. Gives me some really elegant looking client code like allSalesOrder.For(customer) and allSalesOrder.ForDeliveryOn(date)
4. Makes it pretty darn easy for me to spot when I've broken the single responsibility pattern allSalesOrder.AddCustomer(customer)