How to support a product built with agile development?

Question

Two of the functions our company provides our customers are:

• 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.

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.

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 1

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
• What's new file updated

The concept of Definition of Done alone is a strong company anti-procrastination technique. It forces you to advance, ... to ship.

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 personnaly 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.

Answer 2

Your support guys need to be involved in the iteration and release planning stage so that they know what's going into a release as early as possible. So while the developers are building the software the support guys can be preparing for it. One good thing about Scrum is that once an iteration starts you can be sure of what will come out at the other end.

Answer 3

You may already have the data available to help communicate to your support team.

If you have a ticketing system to track bugs and feature requests, you can easily provide automated reports when tickets are resolved.

Likewise your source control system can used to deliver a changelog for each release with each atomic checkin ("ie: Bug #12345 fixed").

If you don't have any of the systems above, you've got other problems waiting to happen.

During your product testing phase (after code is changed, before it is released), this is the ideal time to produce changelogs and communicate with support staff. During this time don't bombard them with huge lists, just give them an itemised list of features and bugs that have been addressed - and provide links to the appropriate systems.

If you don't have dedicated testers - I'd consider pulling one of your longer-term support guys into such a role - they'll help you release less-buggy code and can make sure someone is responsible for putting together documentation for the support team.

Just a few thoughts :)

Answer 4

If you run a demonstration of stories completed in your sprint, get your Support crew into these sessions. The more interactive the demonstration, the better.

Answer 5

Involve Support team representative in weekly client calls (i.e when giving a walk through to your client ) by that even your support team rep will get to know the product better before releasing to client