5

I'd prefer to have sprints that last 3-4 weeks, but customers don't want to adopt new feature/function every 3-4 weeks. Existing customers are conservative and, once we meet their minimum bar for features and capabilities, they like to remain on a stable release for much longer than 4 weeks. Even a 3-month cycle would be pushing it for them.

On the other hand, newer customers tend to have more feature requests, and are willing to follow sprints. But this willingness dissipates after we've met their bar.

How do you balance the need for rapid sprints with the customer's conservative view of application change?

I'm particularly interested in SaaS scenarios.

Cheeso
  • 353

5 Answers5

9

Keep your short releases in-house, until the customer is ready. Then, release to the customer on one of your four-week cycles.

If possible, have the customer participate in software reviews between their release dates, so that you can keep your sprints on track.

Robert Harvey
  • 200,592
7

Sprints aren't about deployment

Sprints are for the developers, they are about commitments to deliverables, not about deployments by customers.

The goal of a Sprint is to have a Deliverable. There is no requirement to actually deliver it much less deploy it.

Every team I have been on produces many more deliverable builds than the operations team could possibly deploy and promote to production.

Software as a Service

SaaS is a specific circumstance, you deliver what you want when you want to, but don't break backwards compatibility without a lot of notice, if ever. Nothing stops you from deploying new API features alongside old ones, and marking the old ones deprecated.

Have a very public end of life/support policy so everyone knows what to expect and when to expect support to end.

1

How do you balance the need for rapid sprints with the customer's conservative view of application change?

The way I see it, if the customer doesn't need/want another delivery in 3-4 weeks, there is no need for a rapid sprint.

The balance here would be to change your development cycle to match their expectations.

Cloudy
  • 703
0

If all you are saying is that they do not want to deploy live frequently then set them up a public facing demo server and do your end of sprint deploy/review there.

If you are saying they really just do not want to spend that much time dealing with the product anymore then you either lighten the workload or continue with the rework risk.

Many times in the latter situations the PM or the sales person ends up filling the role of the customer anyway, regardless if sprint duration because the customer is just not interested in participating. It is unfortunate, and leads to larger rework but it is true.

Bill
  • 8,380
-3

It's essential that you get the customer to participate. The entire point of iteration is to get customer feedback. The feedback will allow you to adjust your course.

How do you balance the speed of Sprints with the customer's conservative adoption schedule?

SCRUM's benefit is not developing faster, it's about having better direction. That means you'll get to your goal much quicker. But you can't adjust your direction without customer feedback.

We've had success getting the customer to step in by adding a "beta" version. It's basically a second production version. It operations on the production database, but is updated every day from source control. It's incredibly helpful to get feedback on items you worked on yesterday. And the conservative people can stay on the regular production release.

Here's a good article on Boyd's Law of Iteration. The quickly iterating fighter pilot wouldn't win without feedback.

Andomar
  • 526
  • 2
  • 6