torsdag 17. september 2009

Documentation is not Waste

Many agile projects focus merely on producing running code, and leave out documentation on how to use, implement and maintain it in an IT-services organization. Thus losing great value potential for its stakeholders.

One thing is if this is extremely user friendly software, or standard out of the box-products. Another thing entirely is if this is software tailor made for the customer, making changes in the way people will work while using it:

· Change of processes and workflow for end users and IT-services
· Change of quality of the end users’ work
· Change of skills needed in order to use the software correctly
· Change of the management’s way of following up on their employees
· Change of results/output (financial value)
· Change of results on SLA’s (IT availability, HR, etc.)
· Etc.

Even small changes in these and other factors in the customer’s organization need planning. And this is why Scrum and other practices can be very efficient. Good dialogue between customer and developers lead to good software. And documentation showing value potential and possible negative effects for each user story – produced as a natural part of every sprint – gives the customer time to prepare for what’s coming.














See http://almostasfunny.blogspot.com/2009/08/using-wiki-for-agile-user-stories.html for a good tip on how to arrange documentation along the way.

The Product Owner

Unfortunately there are large variations in how Product Owners perceive their roles. There are also many obstacles to managing the stakeholders and Scrum teams in a good way:

  • The Product Owner looses his daily contact with his line organisation, thus being rejected as a good manager of its needs.
  • The Product Owner stops being interested in what happens within each sprint, causing trouble for the Scrum teams when it comes to clarifying their needs.
  • The Project Manager interferes with what the Product Owner can order (scope handling).