Agile methodology is a “fashionable” paradigm widely used in Software Development. Its numerous benefits on project definition, scope determination and delivery make it a powerful and efficient method. Based on our experience, we believe that – despite its simplicity and straightforwardness – Agile is a very useful method for complex and pluri-disciplinary projects such as PLM implementation. But how Agile methodology could be used to implement a sophisticated transverse program such as PLM or SPDM? What are the challenges and hampering points to overcome and what are the best practices? In this document, we propose to share insights and answers coming from our experience.

Agile at a glance

Agile methodology is a proper way to manage a project by improving the interactions between different roles and providing a constant and tangible project delivery.

Most important characteristics of this method are:

  • Project team includes all Business & IT actors from the beginning, all collaborating and sharing the same future product vision;
  • Project scope (Product Backlog) is defined through elementary “User Stories”, allowing changes under a controlled process;
  • Fast rhythm of detailed design/development/test/delivery, incorporated by Sprints of 1-4 weeks (usually 2-3), based on a “time boxing” and “effort boxing” paradigm (content should be the adjustment variable).

How Agile can be used in PLM projects?

  • Agile methodologies have been initially designed to handle simple software development projects. The PLM context is different mainly because it supports large business processes across the enterprise, and it implements rich “Out Of The Box” software with advanced configuration features and few software development activities.
  • In order to adapt properly Agile to PLM implementation context, we identified a list of specific topics:

Project planning

In our approach, three different concepts are introduced to plan the PLM project:

  • Roadmap & Solution Design: The PLM implementation project starts with this phase. It is allocated to set up the global solution design and could last 1.5 to 3 months. During this phase, global architecture of the system, macro data-model, modules and capabilities of future PLM are discussed with business/IT and project members, and one converged solution is formed. All Fundamental decisions should be taken at the end of this phase together with a preliminary backlog of User Stories and a Release Plan.
  • Release. Each Release corresponds to a deployment phase of the PLM. It implements a part of the global User Stories backlog, it contains several sprints and an overall acceptance tests activity. In parallel, it should accost with the data migration activity related to the content of the Release. A complete project may consist of several releases deployed independently.
  • Sprint. The Sprint is a founding element of agile methodology, for a PLM project we advise to setup a fixed duration of 3 weeks. Each sprint implements a part of the Release User Stories backlog. It’s important to notice that 3 sprints are considered in parallel at any time:

Sprint N: The development of this sprint’s content is undergoing.

Sprint N-1: The delivery of this sprint is under acceptance test.

Sprint N+1: The content of this sprint is defined, and its backlog is established.

User Story and acceptance

Cornerstone of Agile, the User Story is used to specify an elementary user feature in the PLM application. It must be understandable for both business and IT representative and should be formulated like: “As a <Role>, I want to <Action> so that <Goal>”. A PLM User Story can be implemented either with “Out Of The Box” PLM features (methodology, use case), PLM configuration or specific development.

For each type of User Story the “Definition of Done” should be specified from the beginning, as it will be used as acceptance of the solution.

Acceptance is performed continuously sprint after sprint, so that the final release acceptance before deployment can be short and efficient.

Roles & organization

Standard Agile roles are used in PLM projects (Scrum Master, Product Owner), 2 more profiles should be considered in addition:

From a Company / Customer point of view:

  • The Product Owner is accountable of the business and application scope (Product Backlog), he is the main point of contact of the Agile implementation team;
  • The Process Owners are representative of the different business processes: They will work closely with the Product Owner who will consolidate User Stories from all processes.

From a System Integrator point of view:

  • The Scrum Master is the operational Agile team manager, he sets the rhythm and try to remove any factor hampering team velocity.
  • The Solution Architect will ensure all along the project a consistent and optimal use of the “Out Of The Box” PLM software.

In case of large PLM project, we can consider spreading the teams across several Agile streams who will work in parallel on part of the User Stories Backlog. For instance, we could consider an Application Stream and an Interfaces Stream. Overall governance should map the principles of SAFe (scaled agile) methodology.

Continuous integration

Continuous integration is the technical process to check individual deliveries and integrate them into a common environment on a frequent basis. In Agile approach, the fast rhythm implies to automatize this process as much as possible, which can be hampered in the PLM context by the parallel integration of software code and configuration/administrative data managed in the database. Despite its complexity, PLM continuous integration must be implemented to deliver the expected value of Agile approach.

Data Migration and Deployment

In Agile PLM context, Data Migration and Deployment streams are managed at Release level and must accost with the Application stream. Data migration chain development should start once the data model is ready (usually at sprint 2 or 3), then at every sprint the Data Migration stream should push test data to the Application stream. At the end of last sprint, the Application is ready for Acceptance, then for Acceptance with real data, then for deployment. The Application stream can then start on the next release and keep the rhythm…

Velocity/ Content adjustment

As we have seen in different PLM projects, requirements could change throughout the PLM implementation (because of business evolution or due to the maturity of PLM concepts and technology). These adaptions/evolutions of project’s content should be possible as part of Agile principles. The “velocity” of the team will measure the speed of User Stories “consumption”, so that after a few sprints it is possible to determine what is the available flexibility to change. However, these changes must be controlled using a mechanism of balance depending on the available team effort. Velocity is typically monitored thanks to burndown charts showing graphically the completion of stories sprint after sprint.

What are the advantages?

Is it judicious to use Agile method on PLM projects? Based on our experience, Agile methodology is more efficient to manage a PLM project, and the results are more reliable. The project could be adapted to the new or reformulated needs and the risk of divergence between software solution and business requirements is reduced.

Below are the advantages of implementing a PLM project through Agile Methodology:

  • Scope definition: The small and controlled scope of each PLM delivery guarantees a fast and presentable result of the project. It’s essential as it decreases the risk of scope extension to non-feasible dimensions regarding the enterprise efforts capacity or process maturity.
  • Users Engagement: One of the most important success factor of a PLM project is the engagement of future key-users and users to the project. They should get a good feeling of the project and the useful results of their efforts. Tangible and progressive results could become sources of motivation along the project. In other word, users express and debate their needs during a sprint and in the following one, they start to evaluate the solution in a very short lap of time.
  • Resource Management and Planning: As each sprint has a stable roles & resources plan, participants can precisely anticipate and manage their participation to the project. Business consultants, Key-users, developers, testers and other roles are involved continuously during the project.
  • Change Management and Training: Moreover, this early collaboration and implication of Key-users facilitate change management and secure adoption in the deployment phase. Key-users participation during implementation reduces rejection risk and improves new competencies acquisition. Training can be done along the project, with a constant and affordable workload.
  • Tunnel Effect: As the System is delivered with a constant rhythm, all stakeholders are aware of its content and capabilities. Eventual problems could be detected and resolved during design and the result is easily predictable. These conditions prevent one of the most probable dysfunction of PLM projects: Tunnel Effect.
  • OOTB Promotion: Our experiences show that Agile methodology facilitates adoption of standard capabilities (OOTB features) versus customization. Key-users’ involvement in solution definition and development from the beginning provides a re-thinking framework on enterprise process and encourages reengineering.
  • Design Effort: There is no need to have detailed specification before starting the development. As there is a concatenation of small phases of design/development, detailed specification of a component is needed just during its corresponding sprint. This “lean” mode saves time, especially as it avoids lots of rework due to early detailed design.
  • Shared understandings: Continuous collaboration between different team members brings common understanding of all challenges and requirements during the project. In Agile it is called “Shared Vision”.

Lesson learned

We have described our approach to PLM Agile methodology and the benefits that it provides for projects. However, I’d like to share a few attention points and lessons learned to make it happen:

  • Tight Governance: PLM project is critical as it impacts all Enterprise processes from design, development, production to maintenance. Governance is more challenging if the project is managed via Agile methodology, when the team engagement is stronger, and the planning shortened compared to other management methods. Scrum master should be very attentive to governance risks and decisions should be made fast and with authority.
  • Scope Management: Control of the scope is critical in Agile approach. The list of expected capabilities and associated OOTB features should be established very clearly from the beginning and changes must remain under control. It’s important to set for each feature some indicators such as: Business priority, OOTB status, efforts (development or configuration), interdependences between features, etc. For each deviation from OOTB, the gain (ROI) as well as the cost for customization must be evaluated and based on this information, the adaption is decided and implemented.
  • Team Composition & Availability: The team availability according to sprint rhythm should be guaranteed both for Business & IT representatives, it’s up to the project sponsor. By learning Agile method and collaborating with other team members, the performance of project members and the whole team will increase sprint after sprint. In any way, it’s recommended to avoid unnecessary changes to the team structure.
  • Testing: Testing approach in Agile methodology can be an issue compared to conventional projects. Unit and functional tests occur during each sprint and the acceptance tests for related capabilities will happen in the following sprint and will be executed by key-users. Tests plan consist of user-story based test (tests based on the nominal scenarios). It is critical for key users to understand this paradigm of sprint content to provide efficient testing.
  • Data Migration: The migration strategy and project should be aligned with the Agile implementation project. Data preparation should be started from the beginning of each Release and its related requirement should be escalated and discussed during sprints, in order to avoid any non-compatibility, especially issues related to Data Model. The meeting points between migration and application delivery sprints as well as the content of migration (which is related to the delivery content and readiness of Data Model) is decided from the beginning and all modification should be controlled and shared mutually.

In conclusion

According to our experience, Agile methodology is of course not magic, but is a powerful approach to manage PLM implementation project. Its frequent and verifiable deliveries clearly reduce risks of OOTB deviation and rejection, and it offers a better overall budget control. Future users are continuously involved on specification, test and deployment phases, which accelerates acceptance and improves overall satisfaction. Regardless of the size of your enterprise and the complexity of its organization, Agile could provide lots of benefits to transverse PLM or SPDM projects, considering good practices presented above.

 

Author: Hamedreza Izadpanah, Inensia PLM Consultant 

 

 

About Polina Todorova