The post a few days ago by Ahmet Alp Balkan, about mediocrity in his team at Microsoft, produced a small storm of response, of all perspectives. Among these was Tim Anderson reflecting the mediocrity of Microsoft as an outsider. He mentioned the Surface purchase experience and Windows 8 as two clear failings: “This is not how you beat the iPad.”

He also said this, which particularly caught my eye:

Apps like Mail, Calendar and Contacts on the Metro-style side have the look of waterfall development (though I have no inside knowledge of this). They look like what you would get from having a series of meetings about what the apps should do, and handing the specification over to a development team. They just about do the job, but without flair, without the benefit of an iterative cycle of improvements based on real user experience.

For me, the fascinating thing about this is the association of agile and well-designed applications. Sadly, it’s mistaken: agile development does not, unfortunately, entail coherent, beautiful applications with well-designed user interfaces.

Agile development gives you the opportunity to deliver frequently and to continuously reprioritise your work. It will also give you code with fewer bugs.

However, the development process itself does not tell you how you should prioritise or reprioritise your work, and if those responsible choose to prioritise an incoherent bag of unrelated features, if they are satisfied with an unremarkable interface, and if they choose to ignore user feedback (either collecting it or responding to it) then so be it. The agile development process enables that to happen. Frequently, and sustainably.

Agile development has risen around roughly the same time as the disciplines of digital product management and user experience design. Many teams are practising all of these together, so it can be hard to distinguish the benefits of each.

And just as agile development can produce poor software, so waterfall development can probably produce great software. Admittedly you’d have to be flexible on the deadline, but if you conceive a beautiful product in its entirety, build it in one go from bottom to top, and can spend time fixing all the gaps you inevitably missed, then you will have a beautiful product. (That it’s difficult to continue developing the product is something we’ll skip over.)

In the end agile development is an engineering approach. It still needs good governance to be successful, especially at scale, and it needs to be working on the right thing in the first place. Without those the benefits are confined to the software team.