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?

  • Does your support team have any representation in the development team's scrum? Commented Nov 26, 2010 at 1:09
  • No. I'm looking to change this, but since the support team is a chicken, its needs aren't going to be properly considered by the project owners. Commented Nov 26, 2010 at 1:12
  • Some people of the support team could take part in the sprint review meeting. It would allow them to know and understand the last added features.
    – David
    Commented Nov 26, 2010 at 8:52

5 Answers 5


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.

  • Hrm, this is a really good perspective to take, especially with the DoD. Getting the DoD to include what's necessary for support is probably the direction I need to go. Commented Nov 27, 2010 at 1:47

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.

  • How do you keep a staff of 25 up to date with changes that are being pushed to customers? Support is 24x7 so different techs work at all hours of the day, and while technicians are smart people, they aren't necessarily developers so they cannot infer as much about the software without documentation on new features. Commented Nov 26, 2010 at 2:34
  • @Stephen Jennings: A wiki might help here, maintained by the development team. Commented Nov 26, 2010 at 3:55
  • This is at least as much the support's problem as it is a dev problem. A smart manager of support would try to organize things well.
    – Job
    Commented Nov 26, 2010 at 4:09
  • @Job I agree, but how to go about doing that is my question. It's not a trivial problem getting two departments who think they have opposing interests to play nice. Commented Nov 26, 2010 at 4:20
  • 1
    If the dev team are doing scrum correctly, at the start of an iteration they will have a list of features to be implemented and how well they will be implemented. That's most of the info you need. The rest you can get from the dev team during the iteration. This gives you the same amount of time to produce your outputs as the dev team.
    – Henry
    Commented Nov 26, 2010 at 6:52

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 :)


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.


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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.