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
  • 2
  • 8
  • 1
    The real conflict here seems to be between what the new customers want vs. what the old customers want. You're either going to have to prefer one over the other, or work out a way to manage multiple deployments. – vaughandroid Jun 27 '12 at 09:14

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
  • 198,589
  • 55
  • 464
  • 673
  • But then... the customer doesn't validate the output of the sprint until perhaps 2 months later. Right? – Cheeso Jun 26 '12 at 17:12
  • 2
    Right you are. That's a consequence of their conservatism. If problems are discovered, add them to the next sprint. – Robert Harvey Jun 26 '12 at 17:14
  • 3
    The customer should be participating in User Acceptance Testing in a non-production environment. You need them to do that within the confines of your sprint, but you don't have to actually release what they've tested until they're ready for it. – Matthew Flynn Jun 26 '12 at 17:23
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
    +1 but note that a Deliverable needs to have been seen and tested by the customer to be considered done. – Matthew Flynn Jun 26 '12 at 17:25
  • 1
    Note the SaaS requirement, this implies **multiple** customers that will all be on different lifecycles. There is no single customer in this scenario, so the Product Owner would be the deciding factor. –  Jun 26 '12 at 17:26
  • True. In this case you need some sort of representation/sampling from the customers to do UAT, with the caveat that those who do not participate may be unhappy with the results. Exposing a beta version of the service might also mitigate this. – Matthew Flynn Jun 26 '12 at 17:30
  • The point of a sprint may be a deliverable, but the point of a deliverable is customer feedback. Without feedback you won't benefit from iteration at all. (You can substitute a test team for the customer, of course.) – Andomar Jun 26 '12 at 19:36
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.

yoozer8
  • 693
  • 1
  • 8
  • 20
  • 1
    Somehow, I have the feeling that sprints don't work that way. You can't change it to a marathon and still call it a sprint. – Robert Harvey Jun 26 '12 at 17:18
  • I'm not saying still call it a sprint. I'm saying that sprinting is not the right choice if it doesn't match up at all with the customer's needs. – yoozer8 Jun 26 '12 at 17:19
  • 2
    Perhaps I was a bit obtuse: in a very real sense, it's no longer scrum. – Robert Harvey Jun 26 '12 at 17:21
  • 1
    A Sprint is for the development team, **not** the customer. Sprints are about commitments to deliverables, **not** about deployment. –  Jun 26 '12 at 17:23
  • 1
    @RobertHarvey Perhaps I was unclear. I'm saying that in this situation, scrum might not be the right/best development method. – yoozer8 Jun 26 '12 at 17:55
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,330
  • 24
  • 52
  • 1
    `set them up a public facing demo server and do your end of sprint deploy/review there.` -- That only works if it is a web application and not a desktop application, unless you are advocating some sort of remoting scenario. – Robert Harvey Jun 26 '12 at 17:23
  • quite true, he mentioned services, but if you had stand-alone software beta installs or downloadable VMs would be more appropriate – Bill Jun 26 '12 at 17:26
-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
  • 536
  • 2
  • 6
  • 2
    the question is specifically about a SaaS environment where there is not a single customer, but many on many different adoption points in the life cycle. –  Jun 26 '12 at 21:27
  • 1
    @JarrodRoberson: You can have each customer on a beta version that's their "next" adaption point. The point is to enable feedback by allowing a subset of users on a different version. (This requires backward compatibility in the database, which at least for us is fairly easy to do.) – Andomar Jun 27 '12 at 09:42