We didn’t build it because the business didn’t prioritise it

Agile software development is inherently democratic.  Choice over Prescription could be included in the Agile manifesto.  We give the customer the choice, the choice to decide what is most important to them, what will deliver the greatest value and build that first.  We do not prescribe that they must build a complex framework first- the software will evolve, You ain’t gonna need it (Yagni) until you need it.

The problem with this democracy, with this unleashed choice is that, if you don’t have the right mix of stakeholders, the (agile project) customer doesn’t always know what is best.  They are not always the best people to choose.

There is a difference between domain knowledge and what I’ll call ‘experience’ knowledge.  A banker may know the banking domain inside and out, they can tell you the difference between all the different types of balance and how (and where) they are calculated; closing balance, running balance, etc.  But unless they have done any research with customers, unless they have ‘experience knowledge’, when it comes to  a question such as which balance to provide as an SMS alert, their ‘domain’ knowledge is as good as your common-sense.

Imagine software were a supermarket store.  IT are responsible for the construction of the store, the basic layout, the signage, the checkout, the peripherals.  The business are responsible for what goes into the store, the merchanising, the planogram.  The business imperative is to fill the shelves and shift the product.  They want to spend their money to this goal, anything that does not directly support this will be of lower priority.  That is their domain and they will prioritise that over anything else.  If they could fill the store with nothing but shelves they’d probably be happy.

Now imagine visiting the store.  There’s no carpark, there are no shopping trolleys, there’s no emergency exits.  There’s no ramp for disabled customers.  The shelves rise to eight foot high (with no steps to reach the heights), the aisles are difficult to negotiate because of promotional displays between the shelves.  The business is happy, but what about the customer?

In the agile world, nobody is going to pay attention to this stuff unless it is prioritised.  “Sorry, we didn’t build any shopping trolleys because you prioritised building more shelf space over them”.

This sort of thing happens all the time; functional domain requirements trump experience requirements. Why? Because no-one brings experience knowledge into prioritization and planning sessions.

When stating their choice, your stakeholder wears a commercial hat, they are thinking about their targets and those are based upon shifting product.  They are living in thier operational business domain.  But cold commercials are not what shifts product.  It is the experience that does.  Now go back to the democracy of choice on an agile project.  Who is the ‘business’ specifiying requirements? Is it a balanced team? Is their an experience champion with an equal voice?  Is the voice of the customer recgognised?  If not, isn’t about time you got an customer experience champion onto the team.

What is your business

Should “the business” care about IT? Should an investment bank trader know anything about XML, or a marketer know anything about SQL? Probably not. Even less so should they be talking to their IT colleagues of their requirements in these terms. The business should speak to IT in a language of value driven requirements rather than implementation detail. What is the outcome you need or want, not how you think IT should deliver or implement it.

Yet in many organisations (especially where IT has historically had a track record of failure), the business has taken a greater interest in IT delivery. They start talking the language of the techie. When this starts to happen business operations no longer see the clarity of their business. They see systems. In an investment bank setting: the trade is booked in Zeus, settlements are handled by Minotaur, payments by Socrates. Corporate actions are handled in Hades. Depending upon the geographic region, client management might be handled by Tomsys, Dicksys or Harrysys. You ask a business person what do they do and they talk in terms of systems. Getting down to the underlying requirements of what they actually want to do is hard. Innovation and creative thinking are hard because they always return to what the limitations of the current systems are. They focus upon the requirement for a Reconciliation System rather than asking why there needs to be any reconciliation in the first place.

So here’s a suggestion. Act dumb. Forget everything you know about the way you do things and go back to first principles. How would things be if we were starting from scratch? How would you describe your business intent (not the what you do now, rather what outcomes you really want to achieve) in simple terms to a complete novice. I doubt the word “system” would come into the description.