Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

I've always tried to be informed about (and use... when possible) the latest software, kind of an early adapter.

Then, in the latest years I've noticed a decrease in the quality of all the products I could put my hands on (new apps most of it), I wont name any apps in particular but I think it could be due to the adoption of the "Agile Development Process".

So, I've started to skip minor updates in all the apps I use, and to try only "mature" and stable software, becoming more of a "lagger".

Could it be posible that the agile development process is spoiling the UX of early adopters, while aiming to bring software to the market as quickly as posible with as many iterations in the development process as needed? i.e. flooding the market with buggy applications and an endless stream of small updates.

share|improve this question

closed as primarily opinion-based by DA01, greenforest, Benny Skogberg MCSA, Erics, ChrisF Nov 10 '13 at 19:26

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

    
down voters, could you please explain the reason for the vote down? –  rraallvv Nov 3 '13 at 16:35
1  
I'm not convinced the amount of bugs are germane to a particular development methodology. More than likely it's a marketing issue. Anyways, this question can't really be answered in any definitive way. –  DA01 Nov 4 '13 at 5:55
1  
Maybe you're just getting older and value your time differently now? ;-) –  edeverett Nov 4 '13 at 16:43

4 Answers 4

In order for an agile process to work, the testing process should be efficient. Companies can deploy 4 times a day and have a low number of bugs if developers are following best practices like BDD (Behavior-driven development). Companies like github and many others follow this approach.

The problem is that the code is not tested properly before deploying or testing is not given the right importance. Read about behavior driven development, it basically means that developers write test driven code.

share|improve this answer
    
I'm glad you mentioned BDD, I didn't know about that process. –  rraallvv Nov 4 '13 at 18:16

How you work can shape your service and update cycle. I will try to explain you that frequent updates and agile development are not always harming the overall product. From end-user perception, having too many updates can be perceived as not mature software. However,as said, it is perception and it can be also an advantage if it is designed wisely with following these two rules.

  • not using all your bullets at a time
  • sharing your feature and version map with your customer in an honest way.

not using all your bullets at a time: When there is an update, there should be an element that will has potential to increase the overall experience (ex: Avatars, shortcut...)

sharing your feature and version map with your customer in an honest way. One great example is Grafio, a diagram app. When they launched their product, they shared their 0 iteration with what is next? as a FTE. In each update, you can also see new features that they deployed and what are they coming next.

share|improve this answer

Agile is a development methodology. The way in which developers work is a separate concern than the experience of the user.

Reframed as a question about UX I think it's most likely the concept of MVP — Minimum Viable Product — combined with rapid iterations that are causing the problems you perceive.

There has been a reasonable amount written about the problems of using MVP as a strategy (although it works well in some cases).

http://www.andybudd.com/archives/2011/12/the_tyranny_of_the_minimum_viable_produc/

http://pandodaily.com/2013/02/04/three-reasons-not-to-build-a-minimum-viable-product/

share|improve this answer
    
So the agile approach is a tool used to bring to markets a Minimum Viable Product, but the problem is when the the MVP is not defined in the right way. –  rraallvv Nov 4 '13 at 18:10
    
MVP isn't necessarily tied directly to Agile, though. Agile is more about a process for developing the software while MVP is more of a marketing/research process. Both can certainly work together, of course. –  DA01 Nov 4 '13 at 19:42

Yes, it can!

But businesses are in the business of making a profit, not shipping perfection. If users will still buy apps that are of lower quality--indeed, come to expect problems that will quickly be fixed in a few days in the next release--then from the business perspective the rapid-release strategy is working correctly.

Then our struggle as UXers is to provide feedback in an agile fashion: improving product usability while avoiding such a detriment to product schedule that the fast feedback loop with customers is broken. On the flip side, the constant feedback from customers is a gold mine of data for UX improvements.

Perhaps your perception is what needs adjusting; I know mine does. These days we all expect to see a somewhat ragged release--iOS7 comes to mind, with a thousand minor imperfections--with a rapid X.0.1 release afterward to fix the worst of these.

share|improve this answer
    
Maybe the early adopters could be used to test the viability of such strategy. I, for one, am tired to try incomplete products, but then it could be matter of a change in perception as you mentioned. –  rraallvv Nov 4 '13 at 18:07
    
That's what app store reviews are for these days. ;) –  Alex Feinman Nov 4 '13 at 18:07

Not the answer you're looking for? Browse other questions tagged or ask your own question.