What techniques do you use to establish scope in agile

Question

More than communications skills, lean techniques to discard useless features with no value, more than ask "what do you want?" or "is there anything else?" to the customer.

Reading the book Agile Project Management of James A. Crowder, it says: "Organizations must strive to provide an environment where budget is not centered on time and motion, but must be centered on the perceived values of the objectives of the project.... In classical EV change is bad and uncertainty is worse".

From the book Brilliant Agile Project Management of Rob Colle & Edward Scotcher: "Agile embraces change and even encourages it. Change is not seen as the enemy, it's seen as an important part of the evolution of any good idea."

In an agile approach everything is speculative and scope never is closed until customer is satisfied.

It looks like to me that these statements are for internal projects in software companies like Facebook, Uber, Airbnb, or even in in-house projects where there is an initiative to improve processes continously.

In a context that you handle projects with external customers and projects with ad-hoc development, we are limited by the triple constraint all the time. What are the techniques you use to set up scope and minimize the number of iterations if we are in time-restricted contract?

Edit

*Triple constraint is the name that PMI uses to describe restrictions on any project in Time + Cost + Scope (+ Quality in 6th version of the PMBOK) Any change on any of this restrictions will affect the other. A change in time, it will affect your cost, any change in scope affects time and cost and so on.

This is so restrictive, fixed and old in terms of agile. Once you have your baseline, you cannot change it, but through a formal change process. With external projects based on classic perspective, you manage contracts to deliver a product or service in a specific time and in a budget.

That's why in classic approach change is bad. If you change your baseline (time or cost or scope) it will drive you into a rework or reschedule. Nevertheless in agile, change is accepted all the time. Kind of 2 philosophies conflicting each other in change management, but we need to limit changes in a way to fulfill with deadlines.

Answer 1

If I understand your Question correctly, you're asking how best to approach agile development in a situation where there is a hard cap on time?

The obvious answer is to constrain the scope. And a good technique to do that is to first develop towards a minimum viable product (MVP).

You start out by getting from the customer a list of the absolutely must have requirements. The requirements such that, if the product is otherwise 100% complete except that one requirement, and there's no way to add it - then the only option is to throw the product out. The collection of those requirements is your MVP.

You then estimate how long you think it will take to develop that MVP - you now have your minimum schedule. At that point, you add padding to the schedule. The padding serves two purposes. First, a safety net for if you underestimated. Second, room to iterate improvements - the more padding you have, the more 'should have' and 'could have' requirements you can fit in.

Importantly, though, once you've completed the MVP, show it to the customer. Requirements practically always change once customers have a working product in front of them. At this point, you can renegotiate any of the 'padding requirements' you added before, in exchange for adding new requirements. Either remove some of the old ones, or increase the time/cost of the project.

The goal is collaboration. As per the manifesto, 'Customer collaboration over contract negotiation'.

Answer 2

In our company we face this situation every time we take Fixed Price contract. Please, look into our approach description here.