I've worked across a spectrum of projects of differing sizes comprising teams small and large, often spanning multiple contracting companies. The short answer i

I've worked across a spectrum of projects of differing sizes comprising teams small and large, often spanning multiple contracting companies. The short answer is: adjust your approach to suit the project conditions, but you need to start with a clearly articulated objective. Agile, in it's many flavours (scrum, kanban etc), is at it's heart simply trying to minimise Work in Progress (WIP). This view gives the direct link back to the Lean Manufacturing movement and the Toyota approach to Lean processes and Continuous Improvement. Any WIP inherently accrues risk - the risk you are building the wrong thing, or the right thing with the wrong quality. Hence minimising WIP is about trying to identify the smallest amount of work and drive it through to the finish so you can identify if it is indeed the right thing. So Agile in a SAAS context is about shipping the feature into production and using direct customer feedback to retire the risk that you may have built the wrong thing. All good but it doesn't scale to a large contract where you have pages of requirements written by the customer. That's why in the "waterfall" world you have design reviews aimed at creating a representation of the design that can be reviewed, critiqued and revised before cutting any code. Similarly as the team size increases you have to expend more effort documenting the design such that you can apportion work to sub-teams and be confident they will create the component you want. If you view Project Management as Risk Management you can't go far wrong. Just list out all of the assumptions you are making and turn those into your risks. Then work through them in priority order.