My belief is that:
* Agile should be used for creative development
* Waterfall should be used for highly repeatable/known implementation
For example I would strongly recommend an Agile methodology like Scrum be used for creation of a brand new product, feature, extension, use of technology, bug fix, etc. because there is a lot of thinking, discovery, and experimentation that goes into figuring out what needs to be built and how. However, if I had a team that needed to take a product and deploy/configure it for a Client I would want to create a project schedule template (and other artifacts) that would allow people to simply 'do' the work to stand up that implementation for the new Client.
I was thinking more about my reply last night and realized that I didn't explicitly answer the question.
Yes I think is is okay and the correct thing for a single team to use both an agile and a waterfall methodology, provided they are using the right methodology for the job (i.e. my previous response). If a team is both creating a product and implementing it then they should use both, but if a team is only creating new product features then I believe they should only use an Agile method.
Andre, are the projects types very different?
Alan what percentage of work is "highly repeatable/known implementation" Even with this couldn't you structure it with most of the elements of Agile.
Andre, I wonder if a small array of methodology types Pure agile at one end and hybrid Agile/waterfall at the other would work. Then continually look at how the hybrid model could be brought closer to a pure Agile.
Even in the waterfall days we all had different methods depending upon the type and size of the project.
Agree you could definitely use a lot of the same tools techniques for an implementation. For instance you could have a backlog of stories that are very well defined and already estimated, and run these in Sprints until they are completed. With that you could probably use all the same tools that you use to run other projects.
I'm not certain I would advocate a % known as much as rely on your experience of running and managing projects. If it is a set of work that has already been done by you and your team before and it is a matter of using different configuration parameters, that to me is really well known. If you are going to build a new feature that has not been built before, then there is a level of unknown and I would lean toward using an agile method like Scrum.
I agree with Don: there seems to be an assumption here that there are only two choices: (1) Agile, and (2) Waterfall. In my experience there are many more, and most fall in between.
I agree there are certainly many many flavors of agile methodologies to choose from: scrum, unified, extreme, evolutionary, spiral, etc. I'm sure there are equally as many flavors of waterfall, but I'm not nearly as familiar with those methods. Picking the right one and making your own tweaks to it is definitely a personal choice. I personally like Scrum for a multitude of reasons, one of which is for its strong community.
I would respond by asking the client, to "tell me more about that". From what little information we have, it sounds like the client ("our team") is providing some code or service to multiple groups and those groups use different processes. The client is probably really be asking, "how do we best address the needs of these groups?" Once the real question is on the table, we can move forward with evaluating their needs.