Question
Is it valid and possible to cope fixed unmovable deadlines into Scrum?
I guess it is just confusing to me because I thought one of the core principles of Project Management is to help identify realistic estimates of a completion date based on limited information. Is there a branch of Project Management, specifically Agile or Scrum Project Management that concerns the opposite, starting at the completion date and working backwards to figure creative ways to fit everything in?
Context
I am trying to understand the methodology and strategy of project management in my current company. It is a large financial institution and there are hundreds of projects ongoing at any given time. There is a large Program Management office that is collecting status information on many different ongoing work threads for communication of status up to executive level. The Project Managers maintain project plans and coordinate project status information from project resources to the Program Managers.
The odd thing I can't figure out is that when a project is in conception, there is no real technical effort to determine estimates of effort or time on the project milestones. At this phase it seems to be completely unimportant, because every project deadline are set by IT executives or by the LOB, sight unseen.
After we are told what the date will be we are then told to do formal estimation of effort (story points) rather than time because the organization has an executive mandate to be Agile and Scrum. The weird thing is that after we identify all of the Epics and T-Shirt size everything, the Project Manager is still required to figure out how to fit all of this into the pre-determined deadline. To do this we split and do a detailed story point estimation of a single Epic, usually a Small size, then the total story points of that are used comparatively to figure out total assumed story points. From there the Project Manager determines velocity and proves whether all of the project milestones are achievable by the deadline.
The concept of Minimum Viable Product is non existant. The PM has to show how many people are needed for this deadline to be possible and if it is too expensive then the project might be cancelled before it even starts.
The thing is that for the past several years nearly every project could be considered a failure because they almost never hit these deadlines regardless. What I don't understand is that despite failure after failure, nothing substantial seems to change. It certainly doesn't seem that being late on the project really matters in the long run. When the project runs late then status meetings increase and general anxiety seems to increase, but just about everybody keeps working ahead as they typically do.
Other people who have been at the company for a long time have told me that their are actually two dates. The formal deadline that goes on paper, and the date that executives actually anticipate when the project will be done in reality. When I asked why not just make the deadline reality, they almost universally agree that executive leadership feels that when projects run late on paper then people "work harder".
I don't see this working for a number of reasons. Veterans at the company don't feel the pressure because they believe there is an attempt to manipulate them into working harder. Newer people get demoralized and stop trying. Everybody spends more time in status meetings with anxious program managers rather than focusing on project work, and finally the nature of the work is more knowledge based and managing external dependencies than hard core work with rows of people furiously typing at keyboards until 2am. Most everybody works a solid 40 and goes home regardless of pressure because often staying late wont get real roadblocks done any sooner.
