To start of with a cliche: The team and you must own the project! All the nitty gritty details!
In an agile world we often tend to avoid having clearly defined gates we must pass, but we still need to make the project a success.
One of the best way to set people up to success it by creating ownership. Ownership, is the most important factor in an agile project.
If the team feels ownership of the project they are likely to go that extra mile if the project needs it to reach the iteration goal.
How to Create Ownership
One of the things I have seen being used successfully is involvement in the entire process from inception all the way to retirement. For a development team it is really demotivating just getting a specifiction that says you need to do this with no way of influencing the product or the interfaces.
You must show the team trust and involve them in the process of creating the new product. They are probably going to add valueable insights with respect to what technologies could be used, what tools exists already etc. Believe me when I say that most development teams, if not all, will grow with the responsibility. I might even go so far and say if the team doesn't take on the challenge, then the team is not a team and it should be disbanded.
Tools That Have Shown Useful
There are some tools I have used and that worked for me. Give them a try, and if they don't add any value for you then don't use them (Agile-mindset-style, you know ;-)).
Things like project rooms where you can always get an updated view of the project is often quite motivating, but can be a but of a hazzle to get a dedicated room. But the Project Room can also double as a dedicated meeting room for the team, stand up space, etc... Really REALLY useful!
Wallboards with the current sprint are also really nice and adds some gamification to the project. In the recent years I think virtual boards like those that software like JIRA offers are a valid substitute.
Burn up charts! I really like burn up charts! The issue with burn down charts are they don't show scope creep. Of course scope creep shouldnot happen, but from my experience that is rarely the case.
In a burn down chart scope creep will either show as a flat line giving the team the impression they did not add any value at all in that period of time or by actually moving the line upwards which will give the impression that the team did minus work. That can be really demotivating. Instead I prefer burn up charts.
Lets look at an example.
Here the yellow line shows the scope of the sprint and we can see that during the sprint work were added to the sprint but we still see that the team actually did work and should get motivated by that. From my point of view these chart a superior to burn down charts.
For the team it is also much easier to argue why they missed the iteration goal due to scope creep.
End to End Involvement
As I already mentioned end to end involvement is paramount to securing that the team feels ownership.
It is super motivating to get a loose project breif and then fill out all the blanks: Making architecture, discussing testing strategies, how should we implement it etc.
The team will grow with the assignment!
Ownership is Paramount
From all the projects I worked one, from the failures to the successes, ownership was either strong or missing.
One project failed because nobody really knew what direction the project was heading and nobody really felt like it was their project. It was just work. Nothing more than that.
Another project failed because nobody from the business really pushed for the project the team and I did not really feel the importance of the project hence we did not go the extra mile when needed. The end result were OK, especially when you took the lacking business involvement into account.
Sometimes ownership can grow in the strangest projects. We had one project were the business involvement was minimal but we were involvement in the entire flow of the project and we really felt invested in the project and the end result exceeded the expectations. That was a really nice experience that really showed me the importance of ownership.
Own the Ship
I can not stress enough how important ownership is! The project stands and falls with the ownership inside the team!