Archive for the ‘Agile Methodology’ Category
Saturday, April 3rd, 2021
A growing number of companies are relying on agile approaches when developing their PLM systems to enable faster reactions to new market requirements. At the same time, they often want to outsource development activities to offshore partners for financial reasons. Two new white papers explain how PROSTEP supports customers when it comes to using agile methods and introducing agile methods in context of near- and offshoring.
Companies in the manufacturing industry must be ready to quickly respond to changing market and customer requirements. Therefore, they need PLM solutions that support this, for example by making the growing dependencies between software and electronics in connected systems more transparent or ensuring traceability for safety-critical functions. New approaches such as model-based systems engineering (MBSE) or virtual validation of system functionalities by means of co-simulations are needed. The entire PLM architecture must be geared towards change.
IT organizations must also adapt to reduce the time between new requirements and working-functionality implemented in the PLM-Systems. Waterfall or V-model are typically not appropriate to fulfill the dynamics required here. Too much time passes between the definition of requirements and their implementation; time during which the developers do not receive any feedback. They run the risk of developing software that fails to meet the needs of the users. Specifications are often cluttered with requirements and are difficult to change. Then, their implementation is based on the contracts and not on the actual benefits. These and other factors lead to extremely long project runtimes, which can delay the introduction of innovations into productive PLM operations by months and sometimes even years.
A growing number of companies have identified the weaknesses in their existing software development processes and have started introducing agile approaches or are planning to do so. When implementing agile methods, they not only have to decide on a suitable agile model but also find development partners who are able to go along with their agile approach. Furthermore, they have to challenge existing contract models, because in agile approaches, project scope is typically only fuzzily defined at the start of the project.
PROSTEP has been using agile approaches to develop its own software solutions for many years, and as a partner and supplier also brings this experience to bear on customer projects. We are currently involved in agile projects with numerous major customers in the automotive, shipbuilding, and other industries. In many cases, we assume overall responsibility for these projects as general contractor and coordinate subcontractors, be it on site at the customer’s premises or at an offshore partner.
“Our teams combine PLM expertise and hands-on experience with using agile methods. They know the strengths and weaknesses of Scrum, SAFe and other process models from experience gained in the field and can therefore actively help to shape agile transformation at the customer’s site and drive it forward,” says PLM manager Frank Brandstetter. He is the author of PROSTEP’s new white paper, which provides more detailed information about the challenges posed by agile PLM development. (English version available soon.)
The white paper on agile PLM development is complemented by a second white paper in which Rainer Zeifang, Chief Technology Officer Daimler Projects at PROSTEP, reports on his experience with the use of agile methods in nearshoring and offshoring projects. The main driver for the outsourcing development activities is the increasing cost pressure to which we and our customers are subjected.
PROSTEP has been working together with selected nearshore and offshore partners on both the development of its own software products and on customer projects for some time now. We also make use of nearshoring internally. For the past year, we have been maintaining a subsidiary in Wrocław, Poland, which uses agile Scrum teams to provide the development team in PROSTEP’s Berlin office with support in the context of software development projects for major automotive customers.
Agile approaches are compatible with nearshoring and offshoring, but they also amplify some of the challenges involved. The partners have to create a common understanding of the customer project and exchange know-how that is generally in the heads of the developers. They need to establish a uniform approach to ensure that the software being developed is consistent and enables a coherent user experience despite distributed teams and long distances. And they must break down obstacles to communication or find new forms of communication that are compatible with agile approaches.
As Zeifang explains, personal contact and interaction are crucial for project success. “At the start of the project in particular, it is important that the key players get to know each other personally in order to exchange know-how but also to understand what makes their counterparts tick, what is important to them, and how they work.” In the new white paper, he answers questions like: What advantages and disadvantages do time differences offer when it comes to agile software development? How should the distributed agile teams be structured? Does nearshoring and offshoring work with all agile process models?
Download the white paper here.
By Joachim Christ
No Comments »
Thursday, December 3rd, 2020
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.
Different architectures
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.
By Frank Brandstetter
No Comments »
Friday, February 1st, 2019
In today’s world, agile methods are the state-of-the-art when it comes to IT project management. Corporations also use them in large-scale IT projects that they implement together with service companies. The most common agile process model is Scrum, which has to a great extent replaced the conventional waterfall model and its variants. It does, however, require a redefinition of customer/supplier relationships.
In the past, large-scale IT projects involving external service providers were usually executed on the basis of service contracts and billed at a fixed rate. This model is incompatible with agile methods in that there is no longer a clearly defined scope of delivery that could be the subject of formal acceptance and billing at the start of the project. Instead there is a rough target (product vision), a timeframe and a team. This means that the customer’s management must make an investment decision without a detailed cost estimate, rather like a declaration of intent: We will invest the sum of x euros within a defined period of time in order to achieve a specific objective without knowing the detailed results in advance and without having a contractual basis for demanding the result should this become necessary.
This not only requires a change in thinking when it comes to project controlling but also has a direct impact on the remuneration arrangement as measurable criteria for evaluating supplier performance need to be identified. There are basically two variants: billing for the number of hours worked (time and materials) or for deliverables (agile fixed price). The time-and-materials model is easier to implement from an organizational perspective, but it shifts all the project risk to the client. The deliverables-based model is in principle a fixed-price model with very small billing units (user stories), whose constraints are regulated by a framework agreement. It requires significantly more organizational effort when it comes to acceptance and billing but results in greater transparency and a more even distribution of risks.
Conflicts can become problematic when assessing the overhead of user stories because the parties involved are more or less at an impasse. If the supplier estimates the overhead for a user story to be significantly higher than the client is willing to accept, neither side can force the other to accept their view of the situation. This means that assessment conflicts must be resolved constructively within the framework of the collaboration. A general feature of agile collaboration models becomes particularly apparent here: They require a high level of mutual trust and great willingness to resolve conflicts constructively. Proponents of agile principles will counter that this applies to the successful implementation of IT projects in general and that agile process models such as Scrum merely demonstrate a methodical way of dealing with them professionally and in a results-oriented fashion.
Scrum is in itself only designed for teams of up to nine people. Software relevant to industry such as PLM systems, however, require much larger development teams, thus giving rise to the question of how collaboration between a more or less large number of Scrum teams can be organized efficiently.
The approaches proposed in the literature, such as LeSS and SAFe, are typically based on a multi-level model, with operational work taking place on the lower level and coordination on the upper levels. LeSS, for example, aims to minimize overhead. Here, the operational teams send representatives to the upper level teams and the Scrum process is only modified slightly. SAFe, which is currently the most widely used approach, introduces a total of three levels and numerous new roles and events.
There are differing views on how well Scrum can actually be scaled in practice. There is no simple solution to the main problems that arise when coordinating creative work in large organizations. It is, however, becoming evident that, as the size of the project teams increases, binding content-related and technical definitions that are valid for all actors and a deep, shared understanding of the overall objective become critical success factors. Conveying them is more important than finding the supposedly perfect scaling method.
Using an agile process model poses certain risks if more comprehensive digitalization measures are to be implemented in a company’s extensive IT landscape. It could be tempting to launch larger projects without sufficiently clarifying the objectives and constraints and hope that it will be possible to clarify these points during the course of the project. This often leads to expensive dead ends. Unfortunately, the methodology does not provide any clear recommendations as to what should be clarified and defined in advance and with what level of detail. The project participants must therefore make this decision based on their own experience and strike a balance between creative chaos and over-specification à la the waterfall model.
Experience shows that a lack of process knowledge and inadequate analysis of the data model in particular can result in expensive abortive developments, which could be avoided or at least reduced with a little more conceptual preparatory work. It can therefore be concluded that sufficient attention also has to be paid to the process and data model description when using an agile approach in order to ensure that a solid conceptual basis for implementing the desired functionality is available at an early stage. This information should then be communicated to all project participants so that the creative scope that an agile approach creates can also be exploited in the context of the overall objective.
By Norbert Lotter, PROSTEP
No Comments »
|
