> "Build as much as you can by x" makes more sense than "How long will it take to build all of Y?".
As a developer this makes total sense and I love it.
The problem is when the rest of the company that exists outside of the development world (i.e. creating new things), like sales and marketing, is that they would rather the whole company align under the "build all of Y" type of scenario because it makes their jobs fantastically easier. At the expense of the devs, of course.
As "agile" development practices continue to spread, I am hopeful that this re-framing of development around short development iterations and continuous delivery begins to transform the processes of the "clients" of development teams as well.
In my experience, when sales and marketing hear 'agile' they think it means you can deliver everything in a week. They don't hear 'iterations' or 'a certain amount of functionality' they hear 'completely done, faster'.
You're absolutely right and I have no idea how to best solve this communication problem. The rest of the world is simply trained to scope box. They probably don't even know what their technique is called.
I've found time boxing works much better the deeper in the bowels of an organization you work in.
If you have a receptive customer, try and start with a regular release cycle as part of the overall project management. "During development, we'll do regular releases every x-number of weeks. We'll meet every 2 release cycles to see where we are with respect to overall scope vs. the last release(s), spot bottlenecks or readjust scope and requirements as needed". This gives them lots of input into the process without getting too involved in the day-to-day and let's you timebox. They get regular insight and feedback as the product progresses, and you can emphasize or deemphasize requirements as things go on.
As a developer this makes total sense and I love it.
The problem is when the rest of the company that exists outside of the development world (i.e. creating new things), like sales and marketing, is that they would rather the whole company align under the "build all of Y" type of scenario because it makes their jobs fantastically easier. At the expense of the devs, of course.
As "agile" development practices continue to spread, I am hopeful that this re-framing of development around short development iterations and continuous delivery begins to transform the processes of the "clients" of development teams as well.