Welcome to the Treehouse Community
Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.
Start your free trial
Adiv Abramson
6,919 PointsWhy would customers want a half baked, frequently updated product delivered quickly instead of a full app later on?
Seems like customers wouldn't be happy with an incomplete, raw product delivered to them to use by the development team. It makes the end users into beta testers, which I doubt they want to be. Why would customers want an app that's updated frequently? Wouldn't that frustrate and confuse them?
Just speaking for myself and no one else, I prefer to do things right rather than fast. Agile seems to be all about speed at the expense of quality and completeness. How is that even a viable development strategy? I may be old school but I feel a slower, more deliberate approach to application development is vastly superior to pumping out code just in order to show that work is being done.
2 Answers
Dan Johnson
40,532 PointsAgile methodologies are more about communication than speed. The issue you can run into with long development cycles with static requirements is that of no adaptation. Changes in the requirements of your clients or misinterpretations of their needs by the developers won't be accounted for until it's too late.
With the smaller iterations and more rapid deployment you can have stakeholders report their issues with the product sooner, and you have a less complex system to change because of that. Features that weren't thought of at the start can start to appear as they become more relevant/apparent.
The (hopeful) end result is that you'll be building something they actually wanted, instead of something they thought they wanted.
Craig Dennis
Treehouse TeacherHi Adiv!
We have a Scrum Basics course coming out very soon and it works through this very clearly. The concept here is to deliver working software so that prioritization can change. Sometimes after seeing the final product it's too late, this iterative approach makes sure everyone is talking about the same thing.
Looking forward to this course! It's great!
Adiv Abramson
6,919 PointsThank you. I will have to check this course out. But shouldn't the current iteration of the software product be pushed to QA first instead of the end users? If they receive each iteration directly, they become beta testers in essence, in my opinion.
Are product updates pushed out to all end users simultaneously or is a subset designated to try out the latest version, so that if disaster strikes it is restricted to a limited number of end users? Thank you.
Craig Dennis
Treehouse TeacherYeah typically QA is considered part of the sprint. Most Agile practices lean heavily on unit testing and Test Driven Development.
Adiv Abramson
6,919 PointsAdiv Abramson
6,919 PointsThank you for your reply. All of your points are valid, for sure. But user requirements always change and whether iterations are few or frequent, change is inevitable. If anything, the unfinished product should be pushed not to end users but to QA staff who understand the requirements for the project. They, not the end users, should find the bugs, missing features, incorrectly implemented features and advise the development team of such. That way, the end user gets a product which is battle tested and polished. Further refinements will of course still be needed, as provided by the end users. But at least they aren't handed a different version of the product every other day. I cannot see how that makes for a pleasant end user experience. Thank you