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.
Interesting point about missing the user perspective. I feel some people go overboard in internal SW development with the whole idea of it being bad to build anything the customer didn’t ask for. This is often a problem if the customer is management and they build a system that is literally painful for their employees who are, for example, forced to put up with a literal implementation of processing rules they weren’t following tot he letter before that result in situations where documents can’t be processed if someone that is the official approver isn’t the office that day.
Steve Blank’s Customer Development model is one approach to this, but the basic concept is that you have to experiment. Building something for customers outside of your organization puts the assumption that the scrum product owner or XP customer has all the answers into even more questionable territory.
Hmmm.. but do the product owners or end users always know ? As Henry Ford said ” If I had asked my customers what they want, they would have asked for faster horses”.
Democracy will always draw upon the least common denominator not the insight.
Democracy != populism like Agile != blindly do whatever the customer asks you to do
Agile != blindly do whatever the customer asks you to do
That is a problem. What tools exactly does Agile have to understand and appreciate future innovation when the benefits are not immediately quantifiable ? More often than not, the pushback/ argument for not doing something is based on old world thinking about business value.
It requires a leap of faith to follow the insights of someone with vision. I dont think either Lean or Agile philosophies explicitly value that. Twitter or Apple Ipod or Youtube would never have been born with that mindset.
Oh and having lived in UK and Indian democracy, its a tough job convincing me that Democracy != populism. Democracy ultimately degenerates into one because it treats all voters as equals.