6

Agile promotes the use of giving your software to users as soon as possible so they can provide feedback and so we overcome the Waterfall problem of making an app no one wants.

But recently, I ran into this issue where giving it earlier would not work since the users of my app would be dissuaded due to it not being as user friendly as possible etc. EVEN THOUGH it is in Beta. The end users want a 'fully working' version as opposed to what I have.

I've also heard horror stories of where games/software is given harsh reviews even though over time after releasing their app they were able to improve useability/features.

What's the tradeoff here?

Molten Ice
  • 163
  • 3

4 Answers4

5

The key is to put your energy into defining a solid MVP.

http://en.wikipedia.org/wiki/Minimum_viable_product

Cut back on features, not on quality. It should always be as bug free and user friendly as possible. Quality is non-negotiatiable but scope is flexible.

As soon as your MVP is ready ship it. Ship it early, measure it, build another iteration.

rdjs
  • 298
  • 2
  • 8
2

Potentially-Shippable Increments

Agile frameworks don't require that the software be delivered to end-users before it's ready. The goal of iterative development is to product a potentially shippable increment at the end of each iteration.

Stakeholder Feedback Loops

The feedback loop must eventually involve stakeholders to be effective, but acceptance testing is generally driven by the Definition of Done. Acceptance testing can also involve the Product Owner, business analysts, QA resources, or other stakeholders as proxies when appropriate.

The important thing is that stakeholders are actively engaged in Sprint Reviews so that they can see progress and provide feedback to the project. Providing them with actual software (as opposed to a demonstration of new functionality during the review) is not a fixed requirement of the Scrum framework.

Todd A. Jacobs
  • 50,264
  • 7
  • 59
  • 177
0

Continuos shipping doesnt mean delivering to end client.

You should set a milestones with your client to review the product and provide feedback when a specific milestone has been achieved.

But internally you may run multiple sprints to achieve a milestone and with each sprint you are shipping a feature to your internal teams. (QA, other teams etc)

Ajit Singh
  • 1
0

An option to consider when planning releases is to work based on Minimum Marketable Features. Each adds something of value to the product, something the user might want to pay for.

Alexandr Kurilin
  • 101