handling a fixed scope with a fixed deadline
I know the iron triangle and how to handle it in 'normal' situations, but I already faced in my career several projects with governments where there is a fixed set of regulations starting with a fix date.
Obviously my approach was to start the project as early as possible to handle it.
But if I do not have any time buffer, what would you use as an approach to do it in any way?
* Talking with the government about the deadline to break out of the iron triangle would be the best option, but there is a risk that they do not agree.
* Add manpower is an option with the risk that I cannot add unlimited resources and resources might not be available within time
* Reduce quality by accepting technical depts and fix them after the deadline . Additionally breaking up the zero bug strategy and postpone technical depts if possible could also help to focus on the project.
Any other ideas? What measures have you taken in such situations? (And yes, being at this situation needs to be analyzed)
Who is accountable to stakeholders for the value of this "fixed scope" initiative, and are they prepared to take the leap-of-faith needed until delivery happens on that "fixed date"? Are they happy to fund whatever change requests and quality fixes may prove necessary? If not, why not?
it is about government regulation based on some laws or directives. So the scope for e.g. APIs is a fix set.
My personal guess is, is that the government will not handle it themself in time, but that mitgate my issue.
The stakeholders within the company will probably accept it.
It doesn't sound like there's much of a case for implementing Scrum at all, at least in so far as there is no sense of urgency for it. The consequences of a failure to change -- and to achieve valuable agile outcomes -- apparently aren't there to be suffered. Peeps can just roll on regardless. So, who actually wants Scrum in this organization, and why?
I'd agree with Ian's comment, if both the scope and deadline are truly fixed. However, there are cases where you think the scope is fixed, but it isn't. There could be any number of reasons for this, from changes being made outside of the product or service being delivered from Scrum to accommodate the needs to a lack of understanding or clarity on what is truly needed to support the new requirements. Whenever someone tells me that both scope and time are fixed, I want to dig deeper to understand what that truly means, because it very well could not be the case.
What measures have you taken in such situations?
The belief that time, scope and budget can all somehow be "fixed" is a conceit used to try and conjure certainty out of an uncertain world. Something typically has to give, and when faced with that so-called "iron triangle", the only thing available to compromise on is quality.
In Scrum, quality is committed to via a Definition of Done. The imperative is to establish empirical process control via increments that are Done and usable...even if this means cutting scope when unforeseen things happen. That's where the contingency lies.
In other words the Scrum framework is a means of managing uncertainty, as opposed to the usual corporate practice of faking certainty up. So the key "measure" I would take is to be quite clear about what it is I'm selling.
I did not say, that budget is set, as manpower is limited at all in all companies around, but the hope to get somebody external is not high. But there are chances to get somebody inhouse so the triangle can be broken.
Back to the requirements, if e.g. the government decide that from e.g. 1.5.2022 a new api for a software has to be used, then the scope (API) and the date (1.5.2022) is fixed. I know, the power of Scrum is limited in that case, thanksfully we do not have these requirements all the time, so we have a lot of value what we can deliver with the full power of Scrum.
dig deeper to understand what that truly means
This was already into my mind to ask what do we really need of the scope in time or if there are some parts more important than other to get a prioritization.