Many agile transitions start off with a pilot project or two. There are early successes and some momentum starts to build. There is excitement, energy, a promise of a better way. Then it is time for the annual corporate game known as "budgeting", where each department must submit a budget with details explaining how the money they are requesting is to be spent and what return the company likely will get for having allocated the money to the line item in the budget. Typically in engineering or IT, the process involves doing long term portfolio planning (at least 12 months but often 18 months) to create the line items on the department budget. This often involves creating project plans (albeit at a high level) for all these projects.
All this is reasonable as a goal; however, rather than a high level assessment of where the company wants to go to get to an investment level and allow the empirical process of agile to guide the actual delivery of value throughout the year, many companies turn it into a list of committed features with estimates that are now locked in! There are companies that allocate people to all these projects in the budget, including the hypothetical "TBH" people. Any deviation to this plan needs to be justified each month or quarter. Once these projects are on the portfolio, the project's sponsors want to see progress each month. That forces IT management to spread out the staff so that all projects are started. Large WIP, partial people on projects, committed dates and features. Doesn't sound very agile.
This impediment is a killer. I have seen a few agile initiatives die from this process. Managers exhibit a large amount of micro-management to drive the developers to show progress on everything and stay in their committed budget, time, and features. The "iron triangle" is forged and hardened during this process.
Organizations need to find an alternative to this mindset. Budgeting should be about making investment decisions, how to best invest the company assets to create and deliver value to the marketplace which in turn delivers more assets (cash) to the organization. Since the world is changing very quickly, this process needs to be flexible so as to maximize the return by cancelling projects/features that are discovered to be no longer needed or cannot be delivered and diverting the investment to more lucrative projects. This is agile portfolio management. Johanna Rothman wrote Manage Your Project Portfolio to help organizations with this problem.
Essentially, the elements of this approach is to create a list of all your projects with a very high level assessment of value and cost. Use the corporate strategic goals, "ROI" information, and risk data to order or prioritize the projects. Then for each project ask if we should continue to fund it and at what level, should we transform the project into something of a higher value, or cancel it and use the funds elsewhere. Once you have the committed list of projects in priority order, it is time to staff them properly from top to bottom. One way is to have predefined agile teams that can deliver a complete feature. When one team is available, they "pull" the highest priority project and execute it. If the feature requires more that one team, split the project so that one team can do it. Repeat the entire portfolio review process at least quarterly.
Doing this allows organizations to plan their investments for the year and provide a mechanism to allow adjustments throughout the year. It is empirical, incremental, i.e. agile! With complete teams on projects/features they get done faster with limited waste due to multitasking. The organization gets a flow of value from idea to delivery.
One company I worked with had a situation where a competitor delivered a new release with four features that allowed them to win more deals. This threatened the company's market share. Having a more agile portfolio process in place, they were able to add these new features to their portfolio at the top. The next teams pulled the features in and delivered. The annual release shipped on time with these new features (other features from the annual plan were no longer on the list). The company recaptured their leadership position in the market, invested no more money than planned, just allocated differently to maximize the value.
Agile transition is a transformation. A change from traditional approaches and predictive methods to one of experimentation, empiricism, and empowerment. What we are talking about is culture. Structures and procedures support culture and in turn structures and procedures reinforce that culture. To make the agile transition sustainable, structures and procedures also have to change. Portfolio Management is one of the key procedures to address.