Initial Situation

A large German automotive manufacturer with 120,000 employees and 16 production sites does not yet manage its manufacturing and operating resources as well as production equipment via a PLM system and is therefore only able to trace requirements determination, development, commissioning, utilization and recycling with great effort and in an incomplete manner. Processes and applications differ not only between manufacturing plants, but also between departments within a manufacturing plant. Much of the information is bound up in emails, PDFs, Word documents and Excel lists locally on employees’ workstations or in their heads. Data and information are lost in the event of internal and external fluctuation. Approvals are given via meetings and are not fully traceable. For this reason, it is difficult to find and eliminate the causes of errors.

An overview of the overall process is a prerequisite for using new simulation solutions, e.g. for the virtual launch of mechatronic systems in production lines, which should reduce expensive delays in the launch. For efficient handling, simulations are to be managed via simulation lifecycle management (SLM). In addition, the majority of manual activities are to be automated or made automatable as far as possible, redundant information and data with different version statuses are to be resolved, and the functionality of a large number of different inventory applications is to be integrated into the PLM solution. This also includes the automation of work processes in the CAM area. The company expects additional cost savings from the resulting tool consolidation.

The introduction of transparent release and change management is a prerequisite for faster and more reliable production startups and should also provide all levels with an insight into the current status of target achievement in order to be able to counteract undesirable developments in good time. Production start-ups and changes are to be implemented faster, more smoothly and with less effort.

The solution to be implemented should avoid customization as much as possible, because the company knows about the high follow-up costs and almost insurmountable hurdles in maintenance and updating within large interlinked IT structures due to in-house developments and highly customized applications.

The company attaches great importance to good usability and a future-proof technology platform as well as seamless integration into the existing IT system architecture. In a follow-up step, the solution will be integrated into the fully automated CI/CD environment and support a variety of automated test types. The company already has a team of specialists for operating the standard application to be implemented with several existing environments into which the solution is to fit.

The budget and time frame are tight. For this reason, the company would like to provide as many services as possible itself. This also includes the determination of requirements. The project is to be organized in an agile manner, but will be commissioned on a fixed-price basis with defined work packages and milestones.

  • How can the required usability be provided, if this is only made available by the strongly functionally reduced web client and not by the powerful main application?
  • Which solution will be implemented at the company if there are 2 solution approaches from different product lines within the supplier, where the long-term oriented approach is not yet ready for use and the approach that can be expanded in the short term could probably be discontinued in the long term?
  • How can the company’s requirements be implemented with a standard solution that does not yet exist in the scope of requirements even in the approach that can be expanded in the short term?
  • How can the company define qualitatively usable requirements without deep product knowledge about the standard application and without MVP?
  • How can process automation in the CAM area be implemented against resistance from the specialist departments?
  • Derived from this: how can the existing CAM application at the company be replaced as unobtrusively as possible by the company’s own CAM application?
  • How to maximize the reduction of expenses for implementation, because it is a strategic investment that will never cover the costs?
  • And how can this project be used to lay a foundation for replacing the existing PDM environment with a new PLM environment?

The PLM system provider accepts the negotiation result that does not cover costs, but for its part sets strict conditions for implementation in the SOW in order to limit the loss. This includes a particularly strict definition of the readiness criteria of requirements, a black box concept for the solution team that prevents access to specialists, and separate ALM environments for the company and the solution partner so that no unauthorized knowledge can reach the company.

The solution team receives a crash course in Scrum with tightened XP components to maximize efficiency. In addition, a Scrum coach is available to the solution team, the company’s steering team and specialist teams.

The feature-reduced web client is to be extended based on the company’s requirements, setting the OOTB standard for other customers. The added value achieved justifies the strategic project costing and at the same time fulfills a key customer requirement. The basic implementation is prepared using the old client and implemented in the new client when the necessary functionality is available.

The company must provide requirements for any functionality including basic functionality with the specified readiness criteria. A proxy PO provides support to the company’s product owner and interfaces with the solution team.


The requirements promised at the start of the project were not yet available due to a lack of product knowledge about the standard solution to be introduced. For this reason, the PLM system provider supported the company in the initial steps outside the agreed scope of services in a limited timeframe and scope. The result was that the solution team did not receive any implementable requirements at the start of the project and consequently incurred costs for over 3 months without adding any value.

After support was discontinued, once again no implementation-ready requirements were delivered in accordance with defined readiness criteria, so that the need for a business analyst with product experience became obvious. However, the necessary resource adjustment could not be accommodated either in the company’s budget or in the contract. The result was another delay where the solution team incurred costs with no added value. The company has rejected payments with reference to fixed prices per delivered work packages.

In response to the delays and lack of payments, the PLM system supplier significantly reduced services and, due to the Covid19 situation, in consultation with the company, froze the project indefinitely. 1.5 years later, the project was resumed on a reduced scale. This reduced scope was shortened by the PLM vendor’s strategic goals. Meanwhile, other projects of the PLM system provider at the company were outsourced to other service providers.

Project Method

The solution team was to work according to Scrum in order to generate as few costs as possible with maximum efficiency due to underbudgeting. The use of hardcore Scrum was problematic, however, because there were no experienced Scrum users on the team and the special character traits and efficiency-driven humility required for this were only available to a limited extent. The consequence was the open refusal of the proxy PO and half of the team members in the form of an open revolution, who simply rejected Scrum processes and did not practice them.

In response, the Agile Coach stopped working, the team had already been cut in half before the project freeze, and Agile leadership components were no longer provided.


There were many unsolved challenges in this project that could very well have been solved with a little good will, openness, experience, flexibility and courage.

The first challenge was certainly the order format, which was unsuitable for the project method. Fixed prices do not allow for agility and flexibility in service delivery, which is essential in a solution without a foreseeable solution path. Unfortunately, there has been no adaptation to demand from the customer side. The Scrum Master should have frozen the project already on the first project day in order to adjust the framework conditions so that a realistic solution development becomes possible.

Another challenge was under-budgeting and the associated lack of an experienced business analyst or consultant to help the client define their requirements efficiently and completely. A good practice is to have a business analyst on the solution team who gathers independent requirements in the right order and delivers them to the product owner well prepared and ready to be refined, so that the solution team is always well utilized. The Scrum Master should have frozen the project immediately after kick-off and Scrum training because it was known that there were no requirements for an existing solution team to implement. The Scrum Master is responsible for the resource budget and the sprint goal achievement! Meanwhile, the resources could have been used in other projects to add value. The project budget would not have melted without service delivery if the correct course of action had been taken.

How is a partnership supposed to develop when one partner wants to screw the other over from the start? Openness and transparency are fundamental principles of agility, but in this project they were excluded from the beginning. How does a black box concept fit with agility? How do project tools separated by company and solution team fit with agility? How does a proxy PO fit with agile that denies the product owner access to the team? Other than excessive pressure and the choice of words, there was nothing agile about this project. The agile designated ceremonies were filled with activities of a planning organization. The teams and the project were managed by planning organizations. The Scrum Master should never have accepted this configuration because it has nothing to do with agility.

The specialists from management levels integrated in the project team completely refused agile teamwork, did not share knowledge or did not add value. The tasks belonging to the roles were not performed and corresponding services were not provided. Missing work results have created insurmountable challenges for other team members. The Scrum Master with his sprint goal responsibility would have had to reassign the team when the shortfall became known and therefore freeze it until the circumstances were resolved.

My regular reference to the necessary project freeze and the associated correction of the boundary conditions has not been taken into account by any of the contracting parties. The appointed Scrum Master had no previous project experience and therefore did not draw the necessary consequence. In the end, the Scrum Master failed because he did not meet his sprint goals and wasted the budget.

Project Information

Project Duration: 6 months until project freeze

Project Team: 1 Proxy PO, 1 Scrum Master, 8 Team Members

Project Budget: unknown


An Agile/Scrum Master who does not fulfill his role will cause a project to fail. For a Scrum Master there is no shifting of blame: he alone is responsible for sprint goal achievement and therefore also needs the corresponding competencies such as team staffing and partial budget responsibility. Without these competencies, the Agile/Scrum Master is not an Agile/Scrum Master, but a toothless tiger. This is even more true when the Agile/Scrum Master is controlled by a planning organization and has no authority.

When two large planning organizations collide and then call themselves agile, there is not much agility to be expected. Agile transformation is primarily a matter of mindset. Agile transformation requires agile restructuring of the organization. And agile transformation is neither a short-term affair, nor can it be implemented in islands. Agile transformation grows from the top down through the company and must take the entire breadth with it, because almost unsolvable problems have to be mastered at the interfaces between the planning organization and the agile organization. From top to bottom also because superior levels are authorized to give instructions downwards, but not in the opposite direction. And because the good example from above encourages people to follow suit, while ignoring superior levels leads to neglect and rejection.

My solution until agility penetrates the team level is therefore: large companies should stick to the waterfall method until then to avoid inevitable areas of tension and friction. Large companies are unable to resolve conflicts flexibly due to their rigid hierarchy and rules.

My Employer

PLM implementation partner of the PLM system provider on whose subcontract my employer is working at the company.

My Role

I supported the project setup as a PLM Consultant, assisted the company as a Business Analyst in the initial steps of requirements determination, reviewed existing requirements for readiness and fed back deficiencies to the Proxy PO, assisted the Proxy PO in prioritizing independent requirements, supported refinement, and assisted the Scrum Master in his initial project experience. In addition to the external Scrum Coach, I supported the business teams and the steering team of the company as well as the solution team with my agile experience in developing solutions for challenges. In addition, I set up, configured, and administered the solution team’s ALM system, documented the team’s internal processes in the wiki, trained the team members, and supported them during the course of the project. In individual cases, I also performed small implementation tasks as well as created the necessary review videos.