the application of Agile practices is usually limited to developers, business analyst, quality assurance and project/iteration managers. From the outside this team acts as a black box, accepting “business” direction (requirements and prioritization) – and via the voodoo and strange practices of agile return working software for approval.
While this black box is very good at delivering software and eliminating the usual waste and lack of ownership that waterfall development tends to encourage, none of its moving parts are focused on improving the actual usefulness or usability of the service developed.
the black box accepts requirements and delivers on them…. but sometimes that’s not enough. the black box assumes that the business know exactly what it wants, and can effectively feed the requirements hungry team of efficiency that is the agile team. agile is a hungry beast, and sometime the business just isn’t up to feeding it properly (both in terms of quantity and quality) – this is especially the case in customer facing websites competition is fierce and the competitive landscape is constantly changing and introducing new threats and challenges.
while agile practices are specifically designed to work with and around business uncertainty, and inception methods attempts to illicit clear and prioritized requirements in a short and collaborative manner – there is neither the time or resources available to really tackle questions of innovation, service vision and customer experience.
companies want both a clear and viable vision for their future, AND the ability to execute on this vision in a timely and efficient manner.
the principals of agile are universal – so can Agile UX help feed the beast?
developers understand interfaces, and agile has an interface – Its the business. Integration with this interface can be difficult, and the role of UX is to make this integration less painful and more inspirational. It does not replace the roll of the business analyst, it complements it…
UX looks out, and reaches towards the business – synthesizing often contradictory ideas into an inspiring and cohesive vision in order to better clarifying their needs, while i would argue BA’s often look in – breaking down requirements into stories and acceptance criteria – a more palatable and usable form for the information hungry development team.
So if you were to redraw the boundary around agile to include UX, how does that change the way we work….. its simple.
< i had planned on finishing this post, but after viewing Jeff Pattons talk on Lean Product Development i have decided that im far better off just discecting his presentation…. he captures what i was trying to say in this post in a more conscious and eloquent way than my silly hungry monster metaphore… so read take a look at the post above this one>