Use SCRUM with 2TUP

Question

After taking a look to SCRUM it doesn't same to me "enough" to lead a project since it isn't disucssing the technical side of it, so my questions are:
1-is it possible/recommanded to combine SCRUM with some unified process or any other software development process ? How to make specifications in this case?
2-What about planing the project : Divide the project into sprints and use the Y method in each
Thank you

Answer 1

You're right that Scrum doesn't discuss a lot of details. But that's OK because it's a process framework.

For example, Scrum says that the Product Owner is responsible for adding to, removing from, and prioritizing the Product Backlog but doesn't say how the Product Owner does this. That's because everyone who implements Scrum may have a different process. Scrum in a more regulated environment would likely need to implement a more rigorous change control process to change the backlog, while other situations may not require artifacts to produce. It leaves it up to the organization to define how the Product Owner (and possible supporting people) go and figure out what requirements to write, how to write them, and how to prioritize them for the development team.

Another example is the daily work that teams do. Usually, teams implementing Scrum will write automated unit tests because they can be run automatically by developers and automated build tools to get rapid, incremental feedback on work. However, Scrum does not mandate this. Scrum simply says that at the end of the Sprint, you should have an Increment that meets the Definition of Done and is usable. How you ensure that you have an Increment is up to the organization and team.

Scrum defines what its creators see as the minimum amount of roles (Product Owner, Development Team, Scrum Master), events (Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective), and artifacts (Product Backlog, Sprint, and Increment). In your organization, you may choose to have other roles.

For example, a lot of critical software requires independent verification of work. In this type of environment, you may choose to have an Independent Verification Team that operates alongside the Development Team, but with the appropriate independence from the creation of the software and associated deliverables.

Officially, tailoring Scrum makes it not-Scrum (from the Scrum Guide):

Scrum is free and offered in this Guide. Scrum's roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

I don't consider this to be realistic as it doesn't recognize the variety of environments in which software is developed. I wouldn't recommend combining Scrum with something else, but instead using Scrum as a starting point and then tailoring to your environment within that framework. If Scrum is so wildly unsuitable for you, perhaps a different process framework should be considered as a starting point for tailoring. If Scrum isn't right, there are alternatives - Disciplined Agile Delivery, for example, builds on ideas from Scrum, Kanban, Extreme Programming, Lean, and the Unified Process (in particular Rational and Agile). The Crystal methodologies that Alistair Cockburn described may also be a good starting point.