TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Whatever development method you use there are tradeoffs between
features and deadlines. You want more features, it will take longer.
You want it sooner, which features can you do without? Sure, we can
add X, but the ship date's going to slip. Switching from waterfall to
agile doesn't change that.
The ranked backlog approach in most agile methods gives stakeholders
more control over engineering priorities and helps them understand the
tradeoffs necessary to reach short- and long-term goals. Short
iterations make it clear how much progress is being made and help
stakeholders make more realistic decisions about tradeoffs.
It's definitely a cultural change, but it's for the better, and in the
long run the developers are more efficient.
On Mon, Sep 16, 2013 at 1:11 AM, David Farbey <dfarbey -at- yahoo -dot- co -dot- uk> wrote:
> ... Most
> companies expect their R&D departments to commit to a set of features and a
> delivery date. In "Agile", the company needs to accept that R&D can commit
> to either a set of features or a delivery date, but not both (or at least,
> to embrace the fact that there's a negotiation between the two).
>
> For many companies and many individuals that "either/or" aspect of "Agile"
> is completely incomprehensible.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
New! Doc-to-Help 2013 features the industry's first HTML5 editor for authoring.
