Legacy project

Sometimes projects are inherited from other teams by completely new teams, or even 'waterfall' projects are moving on to Scrum carrying along some background that, given the case, might result harder to cope with for the scrum team during the first sprints probably endangering the sprint goal proposed amongst other things.

Scrum is intended for complex problems where uncertainty can be brought under empirical control. It is less applicable to a chaotic environment where the ability to frame and meet Sprint Goals would be compromised.

If you were to use Scrum in your situation, how would you set about ensuring that Sprint Goals are achievable, and that your team produces "Done" work of release quality? Can enough stability be found to do that? For example, can a Sprint be made short enough to largely avoid becoming endangered by events? If so, could a useful and usable increment be developed and delivered in that time-frame?

I work for a company where we moved all of our legacy systems into Scrum.  It was not easy.  All of @Ian's questions were asked many times but we pushed forward and worked through them slowly.  Scrum can be used in the situation you mentioned.  In fact the transparency, inspect, adapt loops really helped us to focus on doing the right things instead of just doing things.  However, we are still working through some of it after almost a year of effort. 

It can be done but not without a lot of effort, trial-and-error, inspection, adaption. And you will have to be able to influence changes in the organization outside of the part that uses Scrum.  

From my experience in this situation (which is not vast; hence my inquiry) I’d be curious about the following:

In the case of a project transformation from old methodologies like waterfall to agile I’d test  the root cause of the (sudden) change:

1. Why has it been decided that the transformation is needed this time? What are the reasons for deciding that the project is to be continued using the framework of Scrum?
2. Has it enough complexity in which empiricism is to be used to reduce risk and deliver continuous business value to stakeholders?
3. Is there anything that was not working before that now is expected to be solved using Scrum?
4. Why do you think Scrum is the solution now?

And any other similar questions aimed to surface the true/false assumptions of the owner of the project. Reflection may lead to new considerations not fully transparent previously and other casuistics, like whether the transformation was imposed, how ready is the project,  future consequences, etc. Also they might help to identify problems at an organization level and the need of influencing them as Daniel suggested.

In the case of a product that has been developed using Scrum and eventually showing high technical debt, long term refactoring, untested work… I’d be curious about what are the real causes for having so much undone work. Some actions like performing a technical analysis, reviewing the DoD, testing, code review etc can make technical problems transparent. But I’d be also curious about how the scrum process were carried out. What failed? Why? Did the scrum team learn from their failures? Where the sprint goals achieved? When not? Why is so much technical debt and how it’s been handled (if it’s ever been handled at all)?

In my company we detected a scrum product where high technical debt was accumulating progressively and the root cause for it was the rate of dev team members rotation between projects plus the partial percentages of time dedication assigned to them by management (something seriously disastrous I dare to say).

If you were to use Scrum in your situation, how would you set about ensuring that Sprint Goals are achievable, and that your team produces "Done" work of release quality?

I think that is the question. If there are so much undone work inherited then it yields no much room for delivering as much value as it would be desirable, or said in other words, the time employed on fixing previous work sucks up the time for transforming product backlog items into value and keeps us from fulfilling our sprint goal. A balance on both things is to be set, letting the development team decide how much of both things can they accomplish during a sprint and crafting a reasonable sprint goal that still could be achieved within the agreed time frame. The PO (and the stakeholders) should be aware of the technical situation of the product and that the reduction of value delivered is at some point justified. It should be noticed that, with time, the delivery of value is to be increased and improved.

Nevertheless, the situation is quite challenging for everyone. As Daniel says it won’t happen overnight since effort and time is required to it.