Process Structure
The PCP R&D processes consist of master, functional, supporting, and program processes:
Master Processes
The master processes focus on the lean-agile planning and execution of streams and teams. The processes create a continuous flow of activities to deploy and deliver a release. The master processes are benchmarked with Scaled Agile Framework (SAFe), where more information about values, lean-agile mindset, leadership, planning, and execution is available. The System Stream corresponds to the Large Solution in SAFe, and the Development Stream and Development Team correspond to the "Essential" in the framework.
While SAFe is a framework to understand lean-agile execution, SAFe lacks details on how to perform activities, e.g., for SW and HW development. These are the additional details we need to explain in the functional and supporting processes.
Functional Processes
The functional processes explain in more detail how to perform an activity. The activities consist of sub-activities (steps). Additional guidelines describe how to do an activity, with references to templates and checklists. One or several roles are assigned to the activity as well.
The functional processes are groups of activities that are related to each other. E.g., the "Requirements" process captures all activities related to how to specify and accept a system epic.
Supporting Processes
Support processes cover activities that support product development and maintenance. For example, CM interacts with all other processes to provide infrastructure and tool support. The "build" activity found in "SW Development" is enabled by CM.
Program Processes
The program processes describe the Synchronized Program Increments (SPI) cadence and the alignment of the organizational functions (e.g., PPM, R&D, manufacturing, marketing, and sales) for a market launch of a release.
Process Overview Map
The process map shows each process area, the activities, artifacts, and how they are related. Click on the picture and zoom (CRTL + mouse wheel) or pan (drag the picture) to look at details.
Why do the processes look waterfall?
When the processes are simplified to show the logical dependencies between the activities, you may get the impression of a waterfall model. It is a challenge to show the iterative and incremental way of working, with all the details on how to do requirements, SW development, tests, and other activities in the same picture. Agile development frameworks often focus on high-level planning activities and how they are planned and executed in iterations and increments - but seldom show how to perform specific development activities.
It is up to the streams and teams to figure out how to slice a release into pieces, which are efficient to develop. The architects guide the agile teams to build products and systems in iterations and increments.
The functional processes need to support the identification and development of small slices. A team can work on many slices in parallel. When they have developed enough customer value, it can trigger a demo or release.