Home Blog
Dan LeFebvre's Blog
Agile Transition: Portfolio Management PDF Print E-mail
Written by Dan LeFebvre   
Thursday, 01 March 2012 17:03

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.


Last Updated on Thursday, 01 March 2012 18:36
My Scrum Alliance BoD Endorsement PDF Print E-mail
Written by Dan LeFebvre   
Monday, 05 December 2011 14:34

I formally endorse Daniel Mezick for the members' representative on the Scrum Alliance Board of Directors. I have had the pleasure of getting to know Dan over the last few years while working with him at the Agile Boston User Group. Dan's focus as a coach and leader is to serve, increase transparency, and enable learning. His coaching practice has helped many clients achieve greater agility and improvements in employee satisfaction. Dan has opened the debate on Agile Coaching Ethics focused on serving clients by reducing the dependence on the coach and helping them achieve free standing agility.

Last Updated on Thursday, 01 March 2012 18:37
Sustaining an Agile Transition PDF Print E-mail
Written by Dan LeFebvre   
Monday, 27 September 2010 21:00

Transitioning to agile is hard. It involves learning new techniques, thinking in a different way, and stepping out of your comfort zone. Many organizations have been designed with traditional product development models in mind. Functional silos are put in place to handle the different aspects of the software development lifecycle with people who spent their careers becoming experts in a particular silo. Senior managers have spent many years developing rules of thumb, instincts, crisis management models, and metrics that have made them successful in this way of working. So successful that they've actually become senior managers in their company. This situation creates a lot of forces that act against a successful agile transition and pulls a company back into the traditional lifecycle.

Last Updated on Friday, 08 April 2011 21:42
Agile Transition: Internal Coaching PDF Print E-mail
Written by Dan LeFebvre   
Friday, 08 April 2011 21:35

Last time, I talked about the first mechanism for sustaining an agile transition, impediments escalation and removal mechanism. This time, let’s look at internal coaching.

Anytime you learn a new skill, there are times it feels awkward. You are not quite sure you are doing it right or improving. Feedback and coaching is the key here. It is great to start with an external coach to get the ball rolling, but to truly create an agile workplace, a capacity for internal coaching must be developed.

Last Updated on Tuesday, 06 December 2011 23:55
The Power of Self-Organization PDF Print E-mail
Written by Dan LeFebvre   
Friday, 03 September 2010 18:47

One of my clients started a new project. This was a very important project yet it was staffed by asking all managers to donate one person to the team. Each manager selected a fairly junior persons so their project would not be impacted. To mitigate the risk of the junior members, they assigned a senior person as their ScrumMaster to help them.

Being the senior person, the ScrumMaster drove the project and very little team self-organization was happening. The product owner was very dissatisfied by the results. The team had the CEO's attention for the wrong reasons.

Last Updated on Monday, 27 September 2010 21:14
More Articles...

Copyright © 2018 DCL Agility, LLC. All Rights Reserved.
Schedule a meeting