Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

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

Last post 06:29 am May 14, 2016 by Olivier Ledru
10 replies
05:41 pm May 10, 2016

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."

It's an uphill, coaching challenge for me as SM and Agile Coach. My activities thus far have not shifted this organization mindset.

I'm a developer, SM and believer in people working effectively in this way. I've seen it work. How would you counsel me to go about demonstrating that they actually should want to practice Scrum?


06:04 pm May 10, 2016

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.


11:24 pm May 10, 2016

> 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.


07:29 am May 11, 2016

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?


07:31 am May 11, 2016

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


09:42 am May 11, 2016

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.


02:18 pm May 11, 2016

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.


02:22 pm May 11, 2016

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.


02:24 pm May 11, 2016

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.


03:16 am May 12, 2016

> 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.


06:29 am May 14, 2016

+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...


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.