Can Scrum be used in non-development activities?

Question

Our company has recently implemented Scrum in the development process, and it seems to be somewhat successful. They are now suggesting that we carry it over to other activities within the company such as software implementation where many of the activities are totally outside of our control, i.e. the customer does not provide information on the schedule you set. Is Scrum really applicable here?

Answer 1

In order to accomplish Scrum, the following conditions must be met:

• There must be buy-in from upper management (based on your question, you already have this)
• There must be buy-in from the Team
• There must be a Scrummaster who understands Scrum and is empowered to be its evangelist
• There must be a Product Owner who is authorized and empowered to make decisions on behalf of the customer (it sounds like this may be your sticking point)
• The work must be such that a potentially shippable product can be produced with each iteration
• The work must be estimable (difficult-to-estimate work is fine, but if the nature of the work is such that it cannot be estimated, then you cannot do Scrum)
• The team must be cross-functional (note that this is not a team where every member can do everything. Rather, it is a team that is capable of doing everything)

While most commonly used for software development, there's nothing inherent to Scrum that makes it bound solely to software development. If you can fulfill the above requirements, then you should be able to implement Scrum successfully. If you cannot fulfill the above requirements, then it's time to re-assess.

Answer 2

Non-Software Scrum Exists, But...

Scrum can be used for projects (as opposed to ongoing activities) outside of software development. However, in my experience adapting Scrum to administrative or other non-software projects requires a great deal more maturity and adaptability than your organization probably has if your current Scrum implementation is only "somewhat successful."

Aside from the fact that you don't consider your current implementation to be fully successful, another red flag is that you talk about the customer not providing information (of whatever sort) on a set schedule. This seems like legacy, top-down command-and-control rather than either agile collaboration or Scrum time-boxing.

Some Simple Considerations for Success

Here are five additional points you should keep in mind in order to implement customer-facing Scrum well:

1. Decide whether you have a project or an ongoing business activity.
2. Make sure you have the organizational experience with Scrum to make it successful where it's already been applied before attempting to extend it into other domains.
3. Plan how you will interact with customers in iterative delivery cycles.
4. Modify your processes to integrate ongoing customer collaboration rather than tail-end feedback.
5. Define communications plans for broken feedback loops, or feedback loops that that exceed your iteration time-boxes.

This isn't dramatically different from Scrum for software development, or Scrum implementations where the "customer" is internal to the business. In any Scrum implementation, communication, transparency, and continuous collaboration are always essential elements. These elements just take on a little more urgency when you are dealing directly with customer-facing delivery.