Hi,
Straight away, you can take some good practices out of both.
Daily scrum meetings are very effective. Have the whole team meet daily near a whiteboard, not a room, for a 15 minutes stand up. Everybody has to answer three questions:
- What have you done yesterday
- What will you do today
- Is anything standing in your way
This has a direct benefit of making everybody feel part of a team, and letting problems emerge.
Dividing your project into iterations is also very useful. Choose an iteration length, either two weeks or one month.
- Have a half day meeting on the first day of the iteration where the team chooses and commits on what to do in the iteration. Write this down and refer to it during the daily meetings. Monitor that you are progressing towards the objective.
- Have another half day meeting on the last day of the iteration to do two things. First you want the demo the current state-of-the-art to Business Owners (or Stakeholders). This focuses the team on having something that can be demoed, and keeps pressure off the team by showing constant progress. Second, you want to have a retrospective meeting in which you write down what went wrong, what went right and any exceptional events happened.
Sometimes we use pair programming to build team spirit and to focus on particularly complex issues. Give one item to solve to two people using only one computer.
Speaking of team focus, have the whole team work in the same dedicated room if possible. This is quite important.
Continuous integration, decent source control and unit testing are technical tools that allow your team to be more agile. Set them up!
I also found useful in the past to circulate (and hang a large print-out of) the agile manifesto.
In order to become even more agile, you need your Business Owner to "buy-in" to the methodology. They need to be involved in the planning meetings where the pick and choose which items should be developed in the following iteration. Generally this choice is based on business value: reduce risk by having the most valuable items developed first. If the project runs late you can still close it off early, still having the most important stuff. They also have to accept part of the responsibility of bringing the development to completion. This usually focuses the development on the right things.
I could write a lot more on the full implementation of these methodologies, but as I was saying, your project has already started. In my experience the biggest problem with implementing agile methodologies is that people have difficulty getting what agile means. Some people will tend to act in a non-agile way even during a fully agile development! For this reason I think that you will need some agile training before you can implement a full-blown Scrum, for example.
Hope it helps!