Found a good thread about supporting a product build with agile development:
Question:
Two of the functions our company provides our customers are:
Our Development team recently switched to Scrum for their development methodology, and while I support this change, I worry that our Support team is going to have more trouble in the future. With a quicker release cycle, our customers will have features and products in production which Support isn't even aware of until the customer calls. We've never been particularly good at getting documentation and information from Development to Support, but I fear Scrum will just exacerbate the problem.
- Our Development team of ~10 employees creates software products for businesses in a particular industry. The software is used on hundreds of our customers' computers. Although the product is, for most customers, off-the-shell, larger customers drive its development, so it's somewhere between shrinkwrap software and custom software.
- Our Support team of ~25 employees provides technical support for both our own software and a few other software products for which we are the vendor.
What are good references on how companies reconcile Development's desire to release frequently with Support's desire to have full documentation and support information before customers see the product? How should a company structure their release and change management when using agile methods?
EDIT: What I'm interested are specifics on how companies structure themselves to deal with these issues. Does the scrum team push releases to customers? Does the software have to go through a release/change management team who will not deploy until Support has been given documentation and brought up to speed? How do you get releases to customers quickly yet still keep everyone informed of changes and new features?
Answer:
First thing to know is that at the end of the iteration, you don't have to release. The objective is to have a potentially shippable increment of the software, not necessarily to release it. Product owner should decide when to release.
Increase Collaboration
When you decide to release, it is quite obvious that the support is being informed and/or trained with the new changes. The support should be involved in the process. They should also be informed which bug has been fixed so they can inform the customers in the support ticket.
Depending on your situation it may be a good idea to invite one or more support team member to the spring planning meeting. It's also a good idea to invite them to the sprint review meeting as well. Try it to see if it works for you.
Write a Definition of Done
Each feature your developers build should comply to a Definition of Done you write and maintain that matches your organization & product specificities. Here is an example of DoD:
- Code build, committed in the repos
- Unit test coverage 80%
- Technical documentation completed (just enough)
- End user documentation completed (just enough)
- Reviewed & approved by another developer
- Fully tested
The concept of Definition of Done alone is a strong company anti-procrastination technique. It forces you to advance, ... to ship.
- What's new file updated
Once a feature is "done", you have everything to release it already. Including what is needed by your support team.
Support Is Useful For Developers
I personally love support. It's the best source of strategic information for your software. It is better than any market study. This is why I think having developers in the support helps you to build on quality. Remember the expression Throw it over the wall?
I also think the product owner should be involved.
