Monday, October 22, 2012

A Cautionary Tale

Heard an interesting story recently, from a software developer advocating Scrum. I shall omit the names of the companies and individuals, and I may get a few of the details wrong, to avoid embarrassing anyone.

Our hero was working for a mobile device company, responsible for defining software requirements. At one point in this job, he was sent to negotiate an interface with a social networking company. The programmers at the social networking company were very keen that the social networking application (app) should be zero-rated - in other words, the users should not have to pay network charges for using the app - so our hero dutifully recorded this as a requirement and built it into the app.

When our hero returned to his company's offices, he discovered to his dismay that the sales and marketing people were very cross with this arrangement. They felt that this damaged the interests of the device company and their network partners (who usually want to generate network revenue from the use of such apps).

Our hero felt bad. Clearly he had let his company down, by failing to consult all the stakeholders before agreeing to this arrangement.

For my part, I thought our hero was being too hard upon himself. After all, the device company was operating in a highly competitive multi-sided market, and deciding how to balance the interests of different stakeholders was therefore a delicate strategic judgement. Our hero was sent off to perform this delicate task without any proper briefing or guidance or policy. Or architecture. I thought it significant that it was the sales and marketing department that got cross, because this implied the absence or abdication of any strategic planning or architectural function who, if they were doing their job properly, should have anticipated this difficulty. How was our hero supposed to know who all the possible stakeholders were, if he didn't have a decent model of the ecosystem?

So this is also a story about the proper balance between agile development (with all its potential advantages) and architecture (with its attention to strategic risk). A proper architecture will look at the business and its ecosystem from several viewpoints including the Motivation View, which highlights value conflicts and differences of interest between different partners.

In response to @allankellynet who commented "Scrum/Agile irrelevant, guy was not briefed, had not spoken to stakeholders. Could happen on any method", I should make clear that I'm not blaming Scrum as such, I'm bemoaning the lack of effective architecture. There is a great deal of guidance about combining Scrum/Agile with architecture - for example, see this Linked-In discussion Does Agile/Scrum negatively impact software architecture?

@brwalsh, Monetization: Money for Nothing (Cisco Communities, June 2011)

@mutlu82, Facebook Does A Deal With Mobile Operators To Produce New Mobile Site With Zero Data Charges! (Mobile Inc, May 2010) 

updated October 23rd 2012

No comments: