Agile teams generally do acceptance tests, unit tests with every sprint but what about usability tests ? The myriad test frameworks allow continuous feedback for the functionality or 'user acceptance' tests, but the user experience tests are sadly missing or delegated to the specialist designer.
What has been your experience ? Can you build user experience (UEX) focus in your agile sprints from the beginning?
Today the agile teams are mostly generalists and quality infected, but as we find that the user experience is not always a top priority. From my experience the user experience discussion in agile projects today usually happens POST the sprint demo. The product owner and the specialist UEX designer reviews the sprint demo against an intial user interface specification and provides feedback to the team. This may sometimes result in major changes or complete redo of the functionality, not a good sign (smells ?) But it is indeed possible in my view to use the available tools to engage in discussion and do rapid prototyping and reduce the feedback cycle time.
Here's my list of popular tools which can be used for agile user experience discussions with your UEX designers and Product Owner
Ideally the agile communication for user experience discussions could range from simple paper drawings to using the quick dirty tools (see the popular tool set above), based on the user story maps (or themes and epics). The extreme user experience oriented step would be to setup a Usability lab fitted with cameras et al. as the NASA example demonstrates.
So what is your best bet ? what discussions do you have with the product owner \ UEX designer so that your agile team becomes usability infected also?
Monday, November 23, 2009
Thursday, November 5, 2009
Does continuous deployment help your product development strategy?
Can you deploy your software 50 times as day ? (yeah FIFTY) !! The folks at IMVU are doing it already..! But the more important question is if you can ripple this deployment model achievement into your overall product development strategy for achieving product differentiation in the marketplace?
The naysayers will resist and say that the product strategy is long term buddy and who cares about these minor deployment details...
But for emerging industries, where we have major technological and strategic uncertainties, and everyone is struggling to get the right business model or there is no product standardization, this deployment model also becomes one of the key links in the path to glory and market share.
To illustrate, let us imagine the IDEAL world of delivering a 'differentiated' product:
a) Product owners get 'new' requests from the customers FIFTY times a day
b) Product owners receive competitors/external environment reports FIFTY times a day
c) Project engineers can develop these 'prioritized' requests FIFTY times a day
d) Underlying platforms are available with 'features' for deployment FIFTY times a day
e) Project testers can test and deploy at customer sites the integrated product with 'new' requests FIFTY times a day
f) Of course if all the above happens then surely your 'threat from substitutes' is reduced by a factor of FIFTY if not more..
Imagine the customer *delight* when they receive their 'new' requests implemented in a single day !! WOW !!
Is this realistically possible / a necessity or just a dream? What do you think?
The folks at IMVU have certainly demonstrated the Deployment part of this linkage !!
The naysayers will resist and say that the product strategy is long term buddy and who cares about these minor deployment details...
But for emerging industries, where we have major technological and strategic uncertainties, and everyone is struggling to get the right business model or there is no product standardization, this deployment model also becomes one of the key links in the path to glory and market share.
To illustrate, let us imagine the IDEAL world of delivering a 'differentiated' product:
a) Product owners get 'new' requests from the customers FIFTY times a day
b) Product owners receive competitors/external environment reports FIFTY times a day
c) Project engineers can develop these 'prioritized' requests FIFTY times a day
d) Underlying platforms are available with 'features' for deployment FIFTY times a day
e) Project testers can test and deploy at customer sites the integrated product with 'new' requests FIFTY times a day
f) Of course if all the above happens then surely your 'threat from substitutes' is reduced by a factor of FIFTY if not more..
Imagine the customer *delight* when they receive their 'new' requests implemented in a single day !! WOW !!
Is this realistically possible / a necessity or just a dream? What do you think?
The folks at IMVU have certainly demonstrated the Deployment part of this linkage !!
Subscribe to:
Posts (Atom)