Program Management practices into Scaling Agile

Today I am facilitating Scaled Agile deployment for a large agile team.

When I look back at my Program Management days. I found many similarities what we are doing today at scaling Agile deployment same as during my Program management role.But there are some changes.

Otherwise also , I could able to apply my some wisdom acquired from those days as a program manager.

Wikipedia says Program management or programme management is the process of managing several related projects, often with the intention of improving an organization’s performance. In practice and in its aims it is often closely related to systems engineering, industrial engineering, change management, and business transformation.

As a Program manager, we used prepare program charter, where we used to mention

Background. The background section describe the current situation or need for new benefits. Here, we want to have the justification for the program clearly explained.the big WHY

Scope. The scope covers what is included and not included in the program. This is where the future state of the business is described. What is the vision of the future of the business, and how will it be achieved by this program?

Results. What are the results that we plan to achieve with this program?

Benefit strategy. What are the benefits that will be achieved with this program?

Concerns, constraints, and assumptions. It is important to list all concerns, constraints, and assumptions at this point in the program. Later, a program manager will take these items and analyze the risk each presents and determine how to manage these risks.

Elements. Are there any projects or other program elements that must be included for planning purposes for this program?

Risks. What are the high-level risks or issues with this program? What are the dependencies among each projects?

Time. A high-level timescale and major milestones are presented.

Resources. What resources are needed for the program?

Budget. What is the cost plan for the program?

Stakeholders. Who are the key stakeholders?

Governance. How will this program be managed, structured, and controlled?

This is a high-level description of how the program will function in later phases. The time line was more than 1 year and less than 5 years.

During Program execution we used to do :

A governance process was created to monitor and control activities and deliverable.

• Projects are initiated to meet program deliverable.
• Iterative work continues, where the program plan is managed and updated according to changes in the environment or any other factors that could affect the program.
• Analyze metrics. Benefits are identified, measured, analyzed, and reported to the appropriate stakeholders.
• Review and approve change requests when appropriate.
• Communicate with and manage stakeholders.
• Work with the program governance board and other appropriate executive stakeholders to provide them an update on the program status and receive guidance on strategy or direction changes.
• Provide guidance to the managers/leaders throughout the execution.
• Benefits realization analysis. The benefits of the program and its progress are reviewed against what was planned for the program. A number of areas are addressed in this analysis
• Value delivery. Is this program still delivering the value it was to provide in the fashion it was to provide it?
• Resource management. Are the appropriate resources assigned to the program, and are they being utilized appropriately? Can we see the progress through some tools?
• Performance measurement. Since programs tend to be long in duration, is it still meeting the required level of performance that was planned?
• Strategic alignment. Is the program still strategically aligned with the organization’s goals? If there were changes to the strategy, could the program be redirected to meet the new benefit requirements?
• Risk management. Are the risks of the program outweighing the benefits that it will return?
• Stage gate signal, GO or NO-GO after that integration tests.

After every milestone we used to

Lessons learned. The project manager was responsible for documenting lessons learned in a special database of information updated by the project management team. Documented information includes:

• Unique lessons from this project
• Avoidable mistakes and failures
• Communication problems
• Organizational issues
• Technology information

======================================================

Same applies in scaling agile deployment. Time only compressed, shorter time scale. More empowered team, More collaboration, less command and controlled,daily inspect and adapt,more visible dashboard thanks to advance tools,excellent deployment pipeline and visibility.

It is not water fall way of delivery but Minimal viable way delivering.

Tools we had used : Project plan : Microsoft Project server 2007, Microsoft Project Plan 2007

Dependency, Issue, Risk tracker — Share Point 2007

Code repository : SVN

Weekly sync up call worldwide, 3 months integration. We were 50 team members from Australia,Bejing,Shangai,Germany,USA,India.We had PMO to centralize all the best practices! It was in the year of 2008.

Do you find something like above happening while deploying Scaling Agile? Are those questions still valid today? Of-course we have prescriptive framework to guide us or answer our questions.