Many agile transitions start off with a pilot project or two. Companies experience some early successes and momentum starts to build. Excitement and energy are in the air with a promise of a better way to work. Then the annual corporate game known as “budgeting” begins, where each department must submit a detailed budget explaining how the money they are requesting is to be spent and what return the company will likely 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. This involves a lot of work from various people who happen to be delivering value on this year’s projects.
All this seems reasonable as a goal. How can a company invest millions of dollars without having some idea of how it is going to be spent and what return that spending may yield? A curious thing happens to that budget. It becomes a committed plan. What should be a high level assessment of the areas in which the company is willing to invest with a focus on the next few months becomes a locked in allocation of resources required to delivery a set of features for a twelve month window. Instead of executing on the first few months and allowing the empirical process of agile to guide the actual delivery of value throughout the year, 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. This forces IT management to spread out the staff so that all projects are started leading to large WIP, long lead times, partial people on projects with lots of multitasking, committed dates and features that lead to long hours and burnout. Doesn’t sound very agile to me.
This organizational impediment is a killer. I have seen many 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 by this process.
Organizations need to find an alternative to this mindset. Budgeting should be about making investment decisions, how to best use 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 which included four features that allowed them to beat us on several deals. This threatened the company’s market share. Having a more agile portfolio process in place, we were able to add these new features to our 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, it was simply allocated differently to maximize 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.
Comments are closed.