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.
As a lone writer for a development team that adopted SCRUM two years
ago, I can state that this methodology does not solve everyone's
problems. However, it has solved many problems for us. In my experience,
the SCRUM process has made my job easier, in part by:
-- increasing the interaction with the customers, so that business
requirement changes and UI modifications are dealt with at least monthly
(I am currently on a 2-week Sprint project), instead of at the end of
the product development. This increases somewhat the instances of
rework, but greatly decreases the total scope of rework.
-- making the documentation structuring simpler, because the business
needs (in the form of User Stories) are identified at the very
beginning, with all "acceptance criteria" included. I can easily
structure the user documentation from that, and get customer approval
early in the process.
-- In addition, since development is done incrementally, one User Story
at a time, I can fully document each feature as it is developed and
tested, so that the customer can review the documentation as they test
the feature. In those cases where development leaves me no time for
documentation, I simply move the documentation task to the next Sprint
and complete it while the developers are building the next feature.
Additional benefits for the team in general include:
-- limiting the number of interruptions made by the stakeholders by
making them go through the Product Owner. The developers do not have to
deal with constant interruptions, complaints, change requests, etc.
-- ensuring that only the highest priority items are in development by
having the Product Owner verify the priorities of all remaining items at
the end of each Sprint. Developers are not required to guess which
feature to develop, and developers are not writing only the "cool"
features.
-- reinforcing the team concept by having daily (and VERY short) status
meetings where each member is held accountable for each task they took
responsibility for. If one member has a problem from outside the team,
the Scrum Master deals with it. If it is inside the team, the team deals
with it.
That has been my experience. YMMV.
--Darrell
-----Original Message-----
From: techwr-l-bounces+dzuerche=tva -dot- gov -at- lists -dot- techwr-l -dot- com
[mailto:techwr-l-bounces+dzuerche=tva -dot- gov -at- lists -dot- techwr-l -dot- com] On Behalf
Of Ed
Sent: Wednesday, December 02, 2009 3:13 PM
To: 'Marguerite Krupp'; 'TECHWR-L Writing'; 'Robert Lauriston'
Subject: RE: I'm now blogging about Agile & TW
I actually agree with Robert on this one. From the bit I read on
Wikipedia,
it sounds like a buzzword-filled methodology forced on a group of people
that doesn't solve most people's problems.
Kind of like DITA.
How does anything get done in four weeks when there's "extensive
planning"?
And how extensive can planning be when it doesn't look long-term? Isn't
that
a bit dangerous?
Also, a "manifesto" that's centered and laid out like a poem kind of
frightens me.
Are you looking for one documentation tool that does it all? Author,
build, test, and publish your Help files with just one easy-to-use tool.
Try the latest Doc-To-Help 2009 v3 risk-free for 30-days at: http://www.doctohelp.com/
Help & Manual 5: The all-in-one help authoring tool. True single- sourcing --
generate 8 different formats and as many different versions as you need
from just one project. Fast and intuitive. http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
