Talking Agile without regular delivery ?
Using Scrum but only within the teams. Releases every 6 months. Management won't change.
Should the org stop saying they are Agile?
Should the Scrum masters leave?
Nothing in Scrum says that you have to release frequently. It just advocates that the sooner you can get increments in front of the stakeholders, the sooner you can inspect and adapt. The manifesto for agile software development states this principal:
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
But there is nothing that says delivering every 6 months is wrong. Being agile has nothing to do with delivering fast, it is about being able to adapt to change quickly. As long as you are still doing Scrum Events to take advantage of the ability to inspect you can still have agility.
Should the org stop saying they are Agile?
Not if they are capable of adapting to changes in needs and environments. However, if adaption only occurs in 6 month increments, I'd question their agility.
Should the Scrum masters leave?
That is a career decision that each of them have to make on their own. I'm not going to give an opinion on that question. (I know. Shock that I'm withholding an opinion but it happens sometimes.)
If Scrum was being used in the teams, I'd imagine they'd be releasing more often than every 6 months. Chances are they are doing something else and they at least ought to be transparent about this.
There's no mention of a pain-point however, so presumably the organization is innovative enough to survive and thrive in its present business context.
- If so, one might congratulate everyone on their good fortune and move on to a challenge in which Scrum is more urgently needed.
- If not, a Scrum Master might find some things to wonder about, so truths are revealed and a new train of thought is developed.
Daniel is right - nothing in the Scrum Guide talks about release cadence. Even backing up, nothing in the Manifesto for Agile Software Development or the principles behind the Agile Manifesto is about releasing - it talks about delivery.
The first thing that I would do is define what it means to "release" or "deliver" your product. For me, "release" is what you do to be able to deploy to a live environment and "delivery" doesn't necessarily have to be to your live, production environment. It's conceivable, to me anyway, that you could deliver a product that hasn't been released yet.
Agility is about feedback. When an organization says that they are agile, they are saying that they recognize that they cannot make and execute on long-term plans. Instead, they need to plan on a short timescale, on the order of weeks at most. Then, they need to obtain feedback and plan the next step. Maybe you're doing timeboxed iterations like Scrum. Maybe you're doing continuous planning and execution in a flow approach like Kanban. Maybe you're doing something else. As long as you have a team that is capable of working together to deliver a high-quality, valuable product to stakeholders quickly (and often regularly), obtain feedback on the product and processes, and make changes to the product and processes, you can say that you are agile.
How often is the organization getting feedback? How quickly can they take that feedback, make changes, and get feedback? How long does it take for a key stakeholder to raise a concern and have it addressed with the other (appropriate) key stakeholders? Can the pace of work be maintained indefinitely? These are the questions to ask to determine if you are agile or not.
For the questions:
Should the scrum master leave? It sounds like this is a job for the scrum master to try to fix - management doesn't understand the agile benefits. Transparency into what the team is getting out of agile can help, but the scrum master has to try to show this.
Should the org stop saying they are Agile? Well, they probably won't stop saying they are agile if the leaders don't want to change. At the end of the day, they can call themselves whatever they want. This might be a job for the scrum master to show that agile isn't a destination but a journey. Kind of like "you're saying your agile, but can you be more agile and get the goodness out of it?"