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).
Ingen kommentarer:
Legg inn en kommentar