Can Agile Methodology Work for PLM Implementation?


Agile Methodology

In this blog, I am analyzing the usefulness of Agile methodology in PLM implementation. Working for xLM Solutions, a company with extensive PLM implementation experience working with large implementations as well as a software background both on a company and individual level, I thought it would make sense to start this discussion in the PLM community.

Agile Methodology in a Nutshell

For those not familiar with Agile methodology, it originated in the software development industry and applies to all traditional software engineering aspects. “Agile is a set of methods and methodologies that help your team to think more effectively, work more efficiently, and make better decisions. […] Agile is also a mindset, because the right mindset can make a big difference in how effectively a team uses the practices” (Learning Agile: Understanding Scrum, XP, Lean and Kanban, Andrew Stellman, Jennifer Green).

Agile has the following 12 characteristics as described in the Agile Manifesto:

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Working software is the primary measure of progress.
  • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity–the art of maximizing the amount of work not done–is essential.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Agile is driven by “user stories” which are very specific, short, user needs/scenarios that can be described in only a few lines with a brief discussion. One of the first and more well-known Agile methodologies is “scrum” in which a product owner creates the product backlog, which is a list of requirements to be developed. The team then runs time-limited sprints which normally last for 2-4-week cycles – the team picks a 2-4 week’s-long list of needs the team thinks it can develop within the limited sprint cycle. A daily status meeting (10-20 minutes) is held to review the previous day’s work and any issues. The scrum master guides the team through the process.  Upon the sprint completion and review, the changes are deployed into the environment.

Agile vs. Traditional Waterfall

There are multiple implementation methodologies out there, but the one that is likely the most common is the traditional “Waterfall,” where there is an amount of time up front to develop all the specifications and behaviors, a long development time, testing and then roll out (for more detail, see the Waterfall definition). It is often compared to Agile methodology mainly in the software development world. I will compare the two in the context of PLM and point out some similarities.

Everything in the Waterfall methodology is dependent on extensive documentation and contracts between user and implementer. Everything needs to be defined and documented before the commencement of the implementation of the next phase and every phase in the implementation needs to be completed for the most part, before moving on to the next phase. As a result, this system does not have the agility to easily change requirements during the implementation process, which is something that often happens in PLM as the project evolves.   As in many cases, decisions made at the beginning of the project change as the stakeholders become familiar with the PLM system and/or changes with company direction and priorities of the PLM system. Being able to easily handle these changes without having to re-do a contract, change a project plan, etc., is crucial.

This system is also based on the participants’ ability to establish strong communication processes and is based on trust, openness and team solidarity. Agile, by definition, is geared toward constant changes and less formal communication processes. This is useful for evolving projects where requirements keep changing, whether it is simply a UI change, functionality change, or additional reporting, etc. Since most PLM users can’t predict and fully define all requirements, especially when dealing with new systems or processes, this can be of great value.

On the other hand, Agile may have its own pitfalls when dealing with PLM, particularly in implementation. In many PLM projects, there are multiple teams from different disciplines plus third party software vendors and consulting parties. It is often hard to build the necessary trust among them to fully adhere to the Agile mindset as one team. In addition, when dealing with third parties, there are usually legal contracts which normally require more documentation for risk mitigation and legal reasons. This is not well aligned with the Agile approach where openness for change is key. In addition, when dealing with steering committees and stakeholders – like engineering or manufacturing VP or CFOs (finance and numbers oriented) – the concept of continuous change and semi/undefined long-term scope is not always a very attractive thing in the manufacturing world, and so Agile has a great disadvantage.  In many cases, management wants to see a concrete project plan with deadlines being met.

If It Is Not 100% Agile, Is It Still Agile?

Most die hard Agile followers would say that if you do not follow the Agile methodology principles 100 percent, then you are not really Agile. Although technically it is a correct statement, others (including myself) claim that even by executing only a subset of the Agile methodology’s principles, it is still better than Waterfall or not having any other formal process at all. In fact, I think that for PLM specifically, with its special circumstances, having a partial (or “informal”) Agile process is the best of both worlds and would provide a better solution for PLM implementation with all its restrictions and hurdles.

My Version: “Informal Agile”

This section of the blog is likely a subject for a separate blog on its own, but I will try to summarize a few of my thoughts about what I refer to as “Informal Agile” methodology for PLM implementation even if it is considered an oxymoron to the software developers in the audience. This is also the area where any software Agile advocate may disagree with my statements (I am open for comments and feedback).

The foundation is easy to define, but as always, implementation is not as easy. In my version of “Informal Agile” (some may say “partial Agile”), I have put emphasis on the following main points:

  • Work toward a more traditional Waterfall delivery plan, but execute it using the builds and change mentality in Agile. Prioritize the changes to avoid possible delays.
    • Work toward initial dates in the road map (do not share possible extensions with non-steering committee stakeholders)
    • Make sure key stakeholders are on board. The Agile approach may be a better fit for PLM as a journey approach, however it is critical that management is on board and fully understands this approach vs. simply looking at an open-ended project
  • Document as much as possible early in the process but focus on changes “on the fly” using frequent project meetings and less documentation once the project has started.
  • Have team cadence meetings twice a week for enough time to make sure all participants are aware of what has been done, changes, issues, etc. (vs. the Agile daily standing brief meeting).
  • Aim toward formal delivery gates/phases, but break it down to more Agile-like build and sprints. Execute a Waterfall roadmap with an Agile approach. This is basically going bottom up (Agile) vs. top down (Waterfall) but maintaining the bigger scope organizational Waterfall roadmap.
  • Like in Agile, implementers and developers should take the next task for next sprint period, but as in older Waterfall, also take into consideration priorities and pre-planned communicated drops/builds to avoid delays in deliveries of key milestones.
  • Unlike Agile, do not deliver until the quality is there. Avoid the somewhat “crappy” quick agile delivery with later improvements and use minimum sprints to achieve the priority one list or requirements and acceptable quality by the users. And just to clarify, by crappy, I do not mean Agile is crappy. It means not doing it right or fully embracing Agile, which may end in a less than 100 percent delivery. The team is not tracking/recognizing the technical debt properly. Proper Agile methodology recognizes technical debt and dedicates appropriate resources each sprint to address it, so it doesn’t get out of hand – just like bug fixes. However, I do not believe that in most cases PLM can nurture the right condition and environment for pure Agile and as result can result in harm and “crappy delivery” and so I am trying to provide a compromise which is better suited for PLM.
  • What is “crappy” is setting requirements and deadlines with no understanding of what is involved in meeting such deadlines and being able to negotiate changes.
  • Have real end users involved in this process if possible, not just the product owner to achieve this goal.
  • Have an hourly base contract with third party consultants which would be aligned with less documentation. Do not base contracts over specific documented scope which requires a heavy dependency on documentation and less flexibility due to legal reasons. This, of course, requires a highly trusted third party that is experienced in such an approach and has references to prove it, as is the case of xLM Solutions. I know this may sound alarming to some people, but from my experience it ends up being significantly more efficient and productive.
  • The Agile role of product owner and tech lead should be maintained. It is okay if in smaller companies it is a single person. Scrum master or the project manager should continue the same roles as in an Agile methodology, though keeping in mind the more formal phased approach which was communicated to the steering committee.
  • A robust framework for maintaining communication, documentation, custom deliverables, planning, should be in place. This can be in one or more systems like MS Teams, Jira, GitHub etc. Obviously if you have an in house PLM system which can handle all that in one place, such as in Dassault Systèmes It is better using such a system.

As I said earlier, I may elaborate on this with more examples and reasons in a follow up blog, but this merger of methodologies is combining the steps in an Agile process while maintaining the bigger picture/Waterfall phased road map. It acknowledges that it is sometimes easier said than done, but this is where experience and lessons learned become useful.

In Summary

Finding the implementation approach that is best for your PLM implementation will depend on the culture of your organization and how it operates, any third-party vendors you work with and the scope and depth of your project. There may not be one size that fits all. xLM has found very good success at a more of an informed Agile implementation combining some of the strong points of both Waterfall and Agile.

At xLM Solutions, we are looking for you, the implementers and industry experts out there who are interested in sharing and working together, to develop PLM implementation standards. Share your comments below or contact us.