Project Manager and Agile?

I watched the “Does the PM have a role in agile” at the PMI Agile Community of Practice. It was nice, nothing provocative. I’ve read the Gartner Enterprise Wide and Enterprise Class agile report as well. What struck me was what has always struck me:

Good project management does most of the management processes found in agile:

1. The processes that are dedicated to actually writing code in agile are unique to agile.
2. The “management” wrappers in agile that look after these development process are just good project management, see below.

The Gartner report has a list that is simply good PM and logical for any successful project:

1. Customer-Centric – the customer on site is not always necessary, but at some periodic point the customer has to give feedback. In our domain that is monthly for programmatics and monthly or on planned boundaries for Technical Interchange Meetings (TIM)
2. Collaborative and Cooperative – yep if it is adversarial it’s going to fail.
3. Constant Feedback – you’ve got to answer the question how long are you willing to wait before you find out your late?
4. Heterogeneous Environment – one size doesn’t fit all. Never did. Fools thought it did. But they’re fools.
5. Throughout the Software Life Cycle – Measures of Effectiveness (MoE), Measures of Performance (MoP), Technical Performance Measures (TPM) are embedded in all System Engineering Management Plans (SEMP). When are enterprises IT folks going to figure this out. Enterprise development is Systems Engineering.
6. Continuous Delivery – how long are you willing to wait before you find out you’re late? Answer that and have tangible evidence of physical percent complete at points no longer than half way through the cycle. Otherwise when you find out it’s not going the way you want, it’s too late to take corrective action (that’s a code word for MANAGEMENT) and you’re going to be late, over budget, and probably the thing you’re building won’t work as desired.
7. Adaptive Solutions – the SEMP defines the processes to be used, methods to be applied, technologies that enable to success of the development process. It’s Systems Engineering all over again.

So here we are again, with "bad management" as the starting point for applying agile processes.

Instead I'd conjecture if we looked at how large complex systems (not too large or too complex because they have problems) are done, then we'd see it starts with a Systems Engineering point of view. And the Systems Engineering Management Plan (SEMP). Go look at DID-81024 for starting guidance.

As well these large and complex programs are guided by MOSA (Modular Open Systems Approach). Here Systems Engineering is also dominant.

In this system management paradigm, there are core "management" processes that must be in place. [from Systems Engineering Guide for System of Systems, Director of Systems Engineering, Office of the Director, Defense Research and Engineering] These are outside the development of software.

1. Data Management - addresses the handling of information necessary for or associated with product development and sustainment.
2. Interface Management - ensures interface definition and compliance among the elements that compose the system, as well as with other systems with which the system or system elements must interoperate.
3. Configuration Management - is the application of sound business practices to establish and maintain consistency of a product’s attributes with its requirements and product configuration information.
4. Requirements Management - provides traceability back to user-defined capabilities as documented through the Joint Capabilities Integration and Development System. In evolutionary acquisition, the management of requirements definition and changes to requirements takes on an added dimension of complexity.
5. Risk Management - ensure program cost, schedule, and performance objectives are achieved at every stage in the life cycle and to communicate to all stakeholders the process for uncovering, determining the scope of, and managing program uncertainties.
6. Technical Planning - ensures that the systems engineering processes are applied properly throughout a system’s life cycle. Technical planning, as opposed to program planning, addresses the scope of the technical effort required to develop the system. A mandated tool for this activity is the Systems Engineering Plan. Each of the technical processes requires technical planning. Technical planning for Implementation, Integration, Verification, Validation, and Transition processes and their accompanying systems can reveal constraints and interfaces that will result in derived technical requirement.
7. Decision Analysis - provides the basis for evaluating and selecting alternatives when decisions need to be made. Decision Analysis involves selecting the criteria for the decision and the methods to be used in conducting the analysis. For example, during system design, analysis must be conducted to help choose among alternatives to achieve a balanced, supportable, robust, and cost effective system design.

When it is suggested Agile be applied in the Scrum-of-Scrum manner, it might be useful to confirm if any of these 7 activities are applicable, add value, or may be necessary for the success of the project. And if they are who is the role that is going to be to manage their perform?