Agile, SCRUM and Technical Writing

[Gene Kim-Eng]

All document projects have a certain element of "just in time," 
especially where software that does not require CDs and retail
packaging to go to market is concerned.  Even in the best of
development efforts, there is always some last-minute eruption
of Murphy's law.

As for the studies, I can see how having "detailed requirements
documents early in a project," and "change management 
procedures" can seem like "a leading cause of failure."  When
requirements are documented it is much easier for a customer 
or the development team's management to recognize that the  
product has failed to meet them.  

Likewise, if the product development process is a poorly managed,
"make it up as we go" variety of chaos.whose end result hardly 
ever conforms to its design models, then those models do indeed 
become irrelevant to the success of the product.

One of the reasons why the people involved in poorly managed 
development environments are often resistant to attempts to 
document their requirements, processes, workflows, etc., is that 
not documenting these things makes it easier to gloss over the 
fact that they don't have any that make any sense in the first place.

Gene Kim-Eng


----- Original Message ----- 
From: "Gillespie, Terilyn" <Terilyn.Gillespie at ddiworld.com>

I have read a few articles that promote the "just in time" documentation
philosophy, going as far to say that comprehensive requirements and
functional specification are over kill, and that creating and
maintaining these documents can overburden a software development
project.  Scott Ambler, from www.agilemodeling.com tells us: "One study
found that the creation of detailed requirements documents early in a
project and the change management procedures associated with doing so is
the leading cause of failure on IT projects.  Another study found that
the creation of detailed design models had no effect on the success of a
software development."