Scrum's nice but, we don't value producing releasable software each Sprint

This situation is quite common and it's absolutely ok to not release into production after every sprint. What we have to strive for is to have "potentially shippable and usable" increment at the end of each sprint. Release into production can be planned by the PO based on the agreements he has with the customers/stakeholders.

> I work for a company that does not currently
> value delivery of working "Done" software in
> more than a 3 month horizon. The reason I
> hear most is, "Our customers are not
> (currently) willing to accept updates more frequently."

That's 3 months of risk. It's 3 months of work founded on assumptions which may not have been validated. It's 3 months of wasted opportunities to elicit feedback and to build a better product.

If the risk and the waste is low enough to be acceptable then the company doesn't need Scrum. That might be the case with simple products, but it is rarely true with complex ones.

As per the previous reply it builds up the risk so maybe you could build a case around mitigating the big panic to test and fix at the end of 3 months by doing a done drop into UAT every sprint even if the production drop is only done every three months? At least it'll all be 'done' code

I could be wrong but it sounds like there isn't regular engagement with a customer representative in this project?

Oh yeah, and kudos for your response to Definition of Done in the other forum! Liked the way you phrased it and if OK may borrow some of that wording sometime :-)

Jason,

What you can do in your situation (which is not uncommon) is to try and make visible the risk and "negatives" with their approach. Ask pointed and powerful questions that can stimulate discussion and reflection.

Why is a 3-month customer feedback loop preferable to a more frequent one?

Why is accumulating code changes in 3-month batches preferable to releasing code more frequently?

What are the main reasons for customers unwilling to accept more frequent releases?

How frequent are the customer interactions?

What are some ways to reduce time and effort managing code versioning (with the current 3-month release cycle)?


Good luck.

Thanks for the reply Ranjith. I totally get it; the goal is potentially releasable. We don't currently to even that. The impetus to change isn't there, and I'll have to expose the dysfunction of our current ways of working to reveal the improvements that are possible with this aspect of Scrum.

We definitely have a complex product and we definitely need to mitigate risk by more frequent inspection of releasable software.

The challenge is convincing, cajoling, or persuading the organization (mainly management) to build cross-functional teams and get work done completely each sprint rather than relying on a "search for defects" phase a.k.a. regression testing. This is the choice to build quality in at the start rather than inspect for defects later.

This is the crux: we have too many managers, and the org likes to manage from top down. This is why being the SM in an orge with 40+ devs is hard right now.

I completely agree, that added risk mitigation could be a primary driver for this change. Additionally, truly cross-functional teams that are allowed to self-organize would increase productivity greatly and greatly improve developer satisfaction and drive. These are things I'm preparing in short order to bring to management in a concerted effort to change things. I feel this is my professional duty in order to ensure Scrum is both understood and enacted.

> The impetus to change isn't there, and I'll have
> to expose the dysfunction of our current ways
> of working to reveal the improvements that
> are possible with this aspect of Scrum.

Correct. The first step in an agile transformation is often to build transparency. If people can't see problems, such as the waste that is being incurred, then they will perceive no reason to suffer the inconvenience of change. Typically, the next step is to see who cares enough about the evidence to want to improve.

+1
It remind me one day I explained Scrum to a team ion my company. I explained the goal of having potentially shippable product each Sprint. Because of that, they quickly understand they will have a LOT of work to refund their technical debt, because of their very low testing-practices.

But they were not able to see any reason to change for Scrum, because they feel "it's kind good by now" !
And then I asked how many time they spend each month for expedite items because of bug in production ; if the customers are satisfy ; if the rythm is sustainable for everyone...