PROSTEP has been providing car manufacturer Daimler with support for the maintenance and further development of its central PDM system for several years. The established project structures, which had evolved over time, reduced transparency and made coordination more difficult. To help address this issue, PROSTEP and Daimler introduced an integrative, agile approach based on the Scaled Agile Framework.
Around 70 developers from PROSTEP and sub-suppliers have been working for several years in a number of small teams at Daimler on maintaining and further developing Daimler’s central PDM system. The tasks they perform also include developing innovative new PLM functions, creating a completely new, state-of-the-art PDM architecture and migrating existing functionality to the new architecture.
In the past, development was carried out within the framework of multiple smaller and larger projects, and the team structure was more technically oriented. Developers often worked on several projects in parallel, which led to resource conflicts and made it difficult to perform forward-looking resource planning. In addition, specialist knowledge was often concentrated in a small number of people, which led to bottlenecks and a considerable risk of losing know-how.
Most of the projects were organized differently when it came to working methods, collaboration with customers, billing models, release cycles, infrastructure, etc. Some teams maintained very close contact with the customer, with no close internal coordination, others used Scrum and worked with the customer’s product owners, and still others worked to a large extent independently. Billing was based on either time and materials or on an agile fixed price. Story points were defined differently for the different commissions, which resulted in different criteria being used for estimates and for billing. These different working models significantly increased the time and effort required for coordination and meant that developers had to adapt to new circumstances every time they took on a new task. Ultimately, they prevented synergies from being exploited and made it difficult to respond to new challenges in a flexible manner.
Agile project based on SAFe
We launched the “PDM goes SAFe” initiative together with Daimler with the aim of simplifying and standardizing development activities in the field of PDM development. Instead of multiple projects with different billing and process models, the objective was to have a single agile project that used as uniform an approach as possible. This new project is based on the Scaled Agile Framework (SAFe). SAFe is the leading scaling framework and is used, among other things, to coordinate the work being performed by multiple Scrum teams.
We started off with eight cross-functional teams. However, it soon became apparent that the consistent use of cross-functional teams led to the creation of too many interfaces between the teams. This is why we have in the meantime switched to feature teams, which, unlike fully cross-functional teams, combine within the team the skills needed to implement specific features. A cross-team alignment meeting is used to coordinate the teams. Each team sends one or more delegates to this meeting. The delegates present the concerns of their team and coordinate them with the other delegates.
We have introduced so-called “communities of practice” to promote the transfer of knowledge between the teams. Communities of practice are interest groups in which people with common interests can exchange information on experience already gained and seek advice. Because knowledge transfer is essential, it is promoted within the framework of the project by providing a budget reserved specifically for this purpose.
A large number of developers and product owners needed training to learn how to use the new agile model. Although some of them had previous experience with Scrum, SAFe was entirely new to everyone.
The two different software architectures pose a particular challenge in the PDM project. The legacy system needs to be kept alive while the new architecture is being built and stabilized. In the past, the two architectures were supported by different teams. The challenge now is to shuffle the members of the teams around in such a way that the knowledge of the different architectures is consolidated without breaking up the teams completely. This is why we have distributed people familiar with the individual technologies across the various new feature teams to the extent that this is possible, while at the same time ensuring that features can, if possible, be implemented by a single team. The aim was to find a reasonable compromise between a focus on features with as few interfaces as possible and the desired transfer of knowledge.
Together with Daimler, we have also introduced a uniform, SAFe-based requirements process. The previous, project-specific individual backlogs were consolidated in a joint program backlog. The product owners define and prioritize the requirements in this backlog on the basis of the available budget. The program backlog is then used to derive the team backlogs.
Another challenge faced in the context of the end-to-end implementation of agile methods was standardization of the different billing models. We had to adapt the estimation criteria and convert the fixed prices into story points in such a way that customers ultimately receive the same service for their budget as before. This would not have been possible without Daimler’s active support and cooperation.
Switch to an agile approach completed
Transformation to the new project structure was performed over a period of four months. The kick-off was followed by a two-month preparation phase, which was carried out in the old project structure. The new project was officially launched at the beginning of this year, followed by an approximately two-month-long familiarization phase. In the meantime, the switch to an agile approach has been completed and initial benefits are already being reaped.
We have taken a major step forward when it comes to development processes, requirements processes, billing models and backlogs. Project structure, roles and communication channels are clearly defined and ensure greater transparency. We have also become much more flexible. There is still room for improvement in the flow of information on the customer side and in the transfer of knowledge. And not all the teams have fully understood and embraced the agile approach. SAFe has however proved to be a good guideline for the new, harmonized PDM project as it is compatible with the customer’s specific needs and we will continue to use it for guidance in the future.
Original article by Frank Brandstetter