TL;DR: An effective software development process for the kind of software that I build needs to be high frequency and elastic to customer demands.

I have just read another great post From Agile to Elastic by @ralfwen is the continuation of his previous post about which spurred me to yesterday. I’m going to go in depth on this one as it matches very closely with my current understanding of how software development I’m involved with should be done.

Since the beginning of 2013 I’m the internal customer, the Product Owner, for all products at ApexSQL. I write all the specifications and unlike the typical customer I actually know how to implement everything I specify. But even so I sometimes mistake the apparent clarity of my thoughts to whatever it is that can actually be implemented or is useful to be implemented. I’m fully aware of this while I’m actually writing the specifications so I take great care but there are still things that pass me by. Everything I write here I write both as a PO and as a developer.

• Customers hardly know, what they want. Any specification is inherently fuzzy and incomplete. What fits the customer’s needs can only be determined by actually trying it out. The customer can only recognize a running piece of software as acceptable.

This resonates even when I’m the one writing the specifications.

The most important role in a software project is the Acceptor. The Acceptor should ask for working software as often as possible. The Acceptor is the driving, no, pulling force behind a software endeavor. The Acceptor’s interest is to keep the software as close as possible on target. Any deviation from a straight line to the goal of a fitting software is costing money. In Lean speak deviations are waste.

Since the goal is not clearly known – see above – the frequency with which to check working software is crucial. The higher the better.

I not only write the specifications and act as the final arbiter on functional and technical decisions, I’m also the one that, at the end of the sprints, accepts or rejects the deliverables. Ralf is right when he says that sprinting time (4 weeks in our case) is too much. Sometimes teams are perfectly on the target at the beginning of the sprint and yet miss it by a significant margin at the end. To counter this we have added a mid-sprint deliverables where I get to see the current state of the project. I’m thinking of increasing this to once a week, with each team having a specific day of the week to submit their semi-deliverables and get immediate feedback.

Scrum and XP come from the world of the waterfall. They were born from frustration with the waterfall. It’s only natural they still contain traces from their predecessor process. This trace is the long iteration. It might not be long compared to waterfall milestones measured in months or years. But it’s still long with regard to how much can go wrong during the several weeks of an iteration.

I think that this is obviously so but it doesn’t get said enough. Sprint is a small waterfall. We might as we call it a cascade.

A truly software oriented process would need to embrace the idiosyncracies of software development.

I like Scrum and it has served us well but I agree with the sentiment that we need a software development process, first and foremost. Even though I’m guilty of bad analogies when it comes to software development, I still know that these are only analogies, hopefully useful for illustrating some similar aspects, but otherwise not really applicable to software development process.

Let me phrase that in the manifesto manner we’ve come to love. It’s my “Elastic Manifesto” for today:

• Acceptance over specification
• Progress over completion
• Reactivity over commitment

This is incredibly useful conceptualization of what makes the software development process actually flow, at least in my experience. There are bound to be bugs in the specification itself and we have to discover them and fix them during the development (acceptance over specification). We stick to the timing of the development plan, cutting whatever can be cut to make it (progress over completion). Circumstances will change, new knowledge will be acquired, more mature ideas will occur to us and we have to be able to deal with them as they are presented (reactivity over commitment).

Customers are interested in just one thing: working software, which means: value generating software. So whatever helps to satisfy this interested, we should do.

As a developer I fully sympathize with the complexities of software development and how hard it is to remain sane in the face of frequently changing requirements. As a customer I try to be transparent, opportune, specific, thoughtful, deliberate and stable as much as possible. But at the end I’m responsible in front of the business and anything that stands in the way of producing “value generating software” (great phrasing) is a problem to be dealt with. And I think that “my” development teams know all this.

I’m not going to go into more details of Ralf’s post but if you are connected to software development in any way, then please do yourself a favor and read it. For the kind of software development in which I’m involved, it really resonates with my experience.

Last modified on 2013-05-26