Agile and not Agile Teams in a project

The first thing to do is to challenge why one project "requires" an agile approach, while you "need" to support waterfall development also.

The delivery needs shouldn't come from either the project or from you, but rather from the business. How quickly does it need to innovate? What are the risks and opportunities of market disruption?

Sascha,

You wrote " I have a project that requires content do a agliles". Come with whoever gave this statement to common definition of Agile, which might not be what we advocate about Agile. I recommend that you document the process to be used in the project which is transparent to your management, team and users. Let not characterize this process as Scrum or Waterfall, let say this what your company is ready for. Build the process documentation on addressing risks which could allow you to convince your management with some Scrum concepts , for example frequent feedback from the business. Understand your project constraints and objectives, your company overall process and the needs of other groups while drafting that process. At least you can have process visibility and transparency on what the team is doing.

Hi Sascha,
It is quite common in real-life that you such mixed situations. A lot of people are doing nowadays a hybrid approach for software project management because there are sometimes good reasons not to go fully agile - same as not going fully waterfall. In a lot of bigger companies the organizational culture is simply to rigid to move quickly into agile and they may never do - especially if software is not the core business.
Assuming you have challenged the decision to do waterfall + agile already here are some recommendations on a hybrid-process:
1. Define early and frequent synchronisation points between the team; break the waterfallish part into multiple phases if possible
2. Your risk rises due to the dependencies that are more complex to manage. Stay on top, e.g. with metrics and regular formal risk assessments plus listening, talking and walking around
3. Plan for 3-4 explicit "synchronisation-sprints" to bring it all together and not only one at the end
4. Share the project plan with all teams, so they can see what's going on at the other side of the fence (..you'll probably want to have a milestone plan and also an WBS for the waterfall-part)
5. Let the waterfall team take part in some scrum meetings, at least the sprint reviews/demos, so they get to learn and see how agile teams work and may find some inspiration :-)
6. Make use of the underlying principles of agile wherever it is sensible: Interactions over processes, customer collaboration over contract negotiation etc.

I always find it hard to mix Scrum teams and non-Scrum teams because Waterfall teams tend to be 'static' and Scrum teams tend to be more dynamic as changes may emerge throughout the project. For example: If there are changes for the Scrum teams and if that changes affect the Waterfall teams then either the Waterfall teams become a Scrum teams or if the Waterfall teams do not become a Scrum team, the product developed by the Waterfall teams may become unusable.