If you're scanning my blog for "Phase 1", you will do so in vain! Phase 2 is a reference to the infamous "Underpants Gnomes" from South Park:
In the case of an Agile transformation, Phase 1 is the good old pilot project. If all we coaches ever did was to assist with pilot projects, we'd be rock stars! Pilot projects are by definition set up for success. Mountains are moved in order to ensure that the team is populated with as many of the organization's best people as possible. A team room is created despite a facilities policy of cube farms. Executives remove red tape and silo issues on a regular basis, because everyone wants to ensure the pilot project succeeds.
Like the underpants gnomes stealing from our dresser drawers and laundry baskets, Phase 1 is relatively easy. Senior management is pleased and wants more... much more of what they saw. They want as much of Phase 3 as they can get!
Just like the gnome in the video, there's that poor, ignored little detail called Phase 2. Follow-on projects don't have the ability to say, "Give us a team room!", and have it happen. They can't say, "We want a cross-functional team!", and expect any more than the standard "resource allocation" from which the existing matrix management policies handle the demand for skills. Mountains won't be moved. Roads won't be straightened. In some cases I've seen, the organization's immune system will actively seek out and attack this infection called Agile.
The typical manifestation of these problems is that the next group to attempt to use an agile approach on a project will run face first into the reality of, "Well, I'm allocated to this project for 40% of my time", or, "I will join this project in a few weeks after project XYZ finishes", which of course doesn't finish in a few weeks. This is very simply an issue of an IT organization not understanding its real capacity for work. They have been using the same approach for years or even decades, and systems do indeed ship. However, even the most jaded people recognize that yet another Death March isn't terribly interesting to them. I have never seen an IT group that had too little work to do, and yet so many of them take on far more work than they should and have too much in progress at any given time.
Once a portfolio has been brought under control or at least made completely visible to all those concerned, then the effects of decisions can be tracked. If teams continue to use the same approach to delivering those projects, you at the very least have a baseline from which to track any changes. Suppose the organization starts an experiment of using teams that are fully dedicated to a project for its duration. You can see the effect of that on the portfolio as a whole. Similarly, if teams start using automated testing approaches where they hadn't done so before, that should be visible in the progression of projects through their lifecycle.
Finally, an initiative as large and disruptive to an organization as an Agile transformation truly needs a rational, value & capacity-driven portfolio in order to create an environment for success. If that doesn't happen, the transformation will be challenged at best. After much time, effort and money is spent, the people who "sign the cheques" will wonder what value they've received for their money. If all of the projects are thrashing because they're fighting over getting QA people or waiting for a DBA to do the database work because no one on the team is either able or allowed to do so, then the organization won't see anywhere near the type of improvements that can be achieved by using Agile approaches.
So, in short, if you're in the middle of an Agile pilot project and are wondering what the next step should be - what the question mark is in Phase 2 - then you need to grab a copy (or 10!) of Managing Your Project Portfolio and start determining what work your organization really should be doing at that moment.
Don't be the Underpants Gnomes and end up with a giant pile of underwear and no one to wear them!