Cost Based vs. Value Based Development

I’ve had little involvement with development teams recently (which I’d like to suggest is the reason for the lack of posts but then, I have to be honest…), the involvement I have had though has been with two projects, one of which was already in flight and for one reason or another, was faltering somewhat and therefore going through a re-estimating process, the other in the early stages of initiation, which as per our process requires some documents to be created and an associated sets of estimates to be produced for the business to sign off on the spend.

In each of the cases above I sat in on a number of meetings to try and aid the team come to an understanding of the work that was remaining / involved. I understand that any project will have budgetary constraints and inevitably a time constraint too, be it an arbitrary delivery date or not, I still find it frustrating though that we’re not asking up front the question of ourselves, “what’s the smallest amount we can do to add value?”. I’ve not come to a conclusion on this as yet as to why, perhaps it’s because of our process, perhaps it’s because we’re an internally chargeable resource and that as such we’re incentivised to drum up as much business for ourselves as possible, perhaps its just a cultural thing?

Either way, I think we’re doing a disservice to our customers (which are in actual fact just members of our own company and therefore ultimately this affects profit margins, a point well made by this blog post.) by not pushing back. If you look at principles like YAGNI used by developers, perhaps we should consider how we could apply this with the requirements that we see from our customers. Equally though by attempting to deliver everything in an allotted time we’re not giving ourselves an opportunity to deliver quality which leads to higher cost of support and change in the long run.

I’ve been advocating a switch to new methods of software delivery for some time now and I still stand by that, maybe though the real change to be made is company wide starting with a process of education (informed by us), perhaps the change isn’t about Waterfall vs. Agile, perhaps it’s more about us engaging with our customers more to discuss how we can work better for them by them working better for us and for this to happen continually to ensure that we aren’t just a cost on their balance sheet that has to be justified, that in fact we’re adding value that is apparent for all to see.

Beware The Iterative Approach

During one of our regular divisional management meetings recently, I was pleased to hear the announcement that all development projects will now be approached iteratively.

Strangely, even though this is the first real sign of an acceptance that we should be considering other methods for software delivery and given that I have been trying to promote alternative ways of delivering software for some time now, you’d think I’d be pleased. However, I feel nervous and am inclined to urge caution.

Why? Well, I’m just not sure that the people that are making this declaration actually understand what it means to be iterative, sure it means that we’ll approach stuff in iterations, mini phases if you like, but haven’t we seen that somewhere before? Let’s say you have 6 features to implement and your initial estimates suggest that each of those will take a month to complete, I think that what’s being suggested is that we’ll approach each of those in an iteration. What happens if the sixth feature that you do actually ends up taking 2 months? More importantly, what happens if the sixth feature is the one that is of most value to your customer?

In my opinion, approaching software development in an iterative manner means that, given the example above, you would consider a portion of each of the six features and look to complete each of those portions in the first iteration, and then revisit them (starting again if necessary)  in the second and so on and so until all of the features have been delivered. The two main benefits of this are that the customer gets to start using their software as early as possible and secondly, information starts to flow from the development team about their confidence of being able to deliver to the afore mentioned estimates.