A friend of mine in another department had a problem and came to me with a question that I wasn't sure how to help him with. He recently became promoted to architect and he was put in charge of design and leading a team of developers that are of questionable quality and little to no experience with following a project plan. This team got in the habit of starting development as soon as possible before business needs were even evaluated, and then hacking the software to pieces when requirements finally became clear near the end of the deadline. Because of this they have tried formulating design standards in the past but never bothered following them later in the project when the heat was turned up.
He aims to change this and asked me about the best way to handle these challenges. My perspective is that the project is doomed before they start because management sets a tight deadline before the requirements are clearly known or understood. Dithering from the client exacerbates the problem further. I told him that Agile was MADE for these kinds of problems, formulate user stories based on the customer requirements as you are aware of them now, and then as more user stories or as they change just add to the backlog and readjust your sprint plan accordingly.
But then I got thinking about what really is the best way to handle this? The client has no way of knowing exactly what they want from the software now, but they know they want it and are willing to pay for it and they want at least some kind of working release by a specific date. They are given a quote with a breakdown of what will be delivered (it is a guess for both vendor and client), price is agreed upon.
When formulating the quote a deadline of some kind must exist even though it is soft at this point. User stories aren't even known and certainly not tasks and the ability to provide a reasonable estimation either. How do you approach this challenge?
When this quote is taken and agreed upon is it normal to use the rough deliverables as outlined in the quote as a basis for formulating your user stories?
Further do you have any advice on how to "keep the design patterns and documents alive" throughout the project as requirements change drastically?
EDIT: It seems many people assume that the client involved should be the one to provide the user stories as if it were a given. I don't have any personal experience with a client willing to put this kind of effort into being involved with the development process. Due to this, it seems to make sense that because of their lack of input into the development process, they are not a very good stakeholder for the project itself. The stakeholders at this point become the business analysts and application managers who are supposed to squeeze whatever trickle of information they can get from the client and turn it into usable information for the developers. This is clearly not working though so perhaps the ONLY way that Agile or Kanban can work is to have direct client involvement in user stories or else the project is doomed to failure?