Agile in Industry

Many industrial companies are implementing agile methodology. In practice it is not always straight forward how to make the change. We have seen three major issues that need to be considered.

When we are meeting customers and discussing project activities, we increasingly come across the subject area "agile". Sometimes it's about agile methods and tools and sometimes it's about the need to be agile in the market. Agile in the sense of being able to adapt quickly to completely new conditions and requirements. Big, rapid changes seem to be the new normality. A good example of how being agile can mean different things came on last year's Passion for Projects in Malmö. One of the main speakers was Klaus Steen Mortensen, CEO of Vestas. He told us that much of Vestas successes came from their agile project activities. We were many in the audience who expected a description of how they organized themselves in teams, about backlogs, features and sprints. Instead, it was Vestas's business model for running order to delivery projects and the modular composition of the Vestas windmills that was agile. By utilizing local resources for more than 90% of the work in the projects, Vestas became flexible and agile. Capacity-wise and time-wise Vestas could absorb variations in the market by changing the percentage of their own involvement in the projects. Also on the cost side Vestas became more agile as more of the cost was in local currency.

For many software companies, the business "agility" described above comes directly from the agile ways of working. By developing incrementally, with small functional additions that may be demonstrated to the customer it is assured that the products will match the customer needs. Also, the companies own employees benefit from the work environment as the agile teams enjoy freedom and influence over how to best satisfy the customer needs. In the SW business areas like music streaming, app development, gaming, social media, online finance there are many examples of companies being agile both in ways of working and in the product and business model.

In the sense of constantly trying to understand and meet the customer's needs and wishes, successful industrial companies are already agile. Many have also organized their products into modules to speed up development and customization.

Being able to handle more and more projects simultaneously and, above all, getting more projects to deliver faster becomes an increasingly important competitive factor. Are the agile ways of working the solution for managing the challenges? How should industrial companies adopt the agile working methods? Can they copy software companies straight off or do they need customization and changes? The questions are many and the answers are essential. We see three areas where industrial companies often differ from software companies and where the difference is such that it can affect how well the agile methods will work.

With industrial companies, we mean companies that manufacture physical products. Industrial companies can also use software but usually as one of several components of the product. With our definition of industrial companies, we want to distinguish these from service companies and pure software companies. We see three important differences. It is about organization, it is about having more projects with fixed delivery date and fixed content and more projects with need for internal synchronization.

In another article, available on our website, we highlight the difference between complex and complicated projects and how complex projects are well suited for agile ways of working, while complicated or simple projects are more suitable for a more goal-oriented approach.

If we start with organization, an industrial company comprises a more complicated product life cycle that, in addition to development, marketing and sales, also involves resources in production, logistics and purchasing. The difference continues in development, where the need for skills for a single company can span widely different areas, such as mechanics, electronics, biomedicine, software and materials technology. Organizing such a company in a permanent cross-functional team organization may not be impossible, but it would be much more expensive and difficult to duplicate all specialists that would be needed in many of the teams. To maintain important support functions for respective skills such as laboratories, prototyping workshops etc., the traditional functional organization is preferred.

The next difference is about how constrained the projects are in terms of delivery time and content. For software products, an experimental and gradual agreement of what to deliver is valuable for both the customer and the supplier. In industrial projects, it is more likely a business to business relationship where the customer has many sub suppliers and may not have the capacity to engage in any gradual agreement of content. On time delivery with an agreed content is the probable scenario for most of the sub supplier relationships. For industrial projects, it is therefore likely that concepts such as 100% delivery precision and short quoted lead times are and remain central.

The third difference is about the need for synchronization. In an agile environment, the project's (the product to be delivered) purpose and goals are captured as a sorted backlog of desired features or product capabilities. The teams who will design, test and deliver the product will start with the backlog items generating the highest value to ensure that the product achieves maximum customer benefit. In a project (product value stream) where several disciplines will create common customer benefits, it may be necessary to find sync points where the various disciplines, such as mechanics and electronics, synchronize their function growth so that the overall result can be used for the continued work within the respective discipline. Such synchronization means that the teams cannot choose only by customer value. They need to plan the work so that they can hold commitments to the incremental needs of the other disciplines.

It seems unnecessary to describe the benefits of the agile ways of working. There are already a lot of articles, presentations, seminars where they are presented and celebrated. There is also a large amount of case stories and other testimonials where representatives from well-known and respected companies report the successful embracing of the agile. We can also say that we have good experiences ourselves and that we use backlogs, sprints, task boards, retrospectives, stand ups, burn ups, minimum viable products, etc., both in our own development projects as well as at our customers sites. It is important that we are not carried away and that we lose judgment and give uncritical tribute to the universal excellency of the agile workplace.

We would therefore like to draw attention to and invite discussion about how the industrial companies should apply the agile ways of working and specially draw attention to areas where the agile practices are insufficient and sometimes not appropriate.

The first area is the management of critical skills. In an industrial company's more complex needs of different skills, there is a likely capacity bottleneck of the company. It is likely that there is at least one competence whose accessibility is slowing down the number of projects that can be delivered. We call such competence for the project system's capacity bottleneck. A capacity bottleneck limits the throughput of an organization. If improvements are made outside the bottleneck. If the flow is accelerated and improved both upstream and downstream of the bottleneck, there will still be no more project results delivered than the capability of the bottleneck. Being able to view and manage their resource bottlenecks is of utmost importance for organizations that have capacity bottlenecks that take time to resolve. (In SW companies a constraining competence capacity can often be resolved with cross training or other means.)

In a project portfolio consisting of projects with clear requirements and contracted delivery dates, there will be different priority conflicts. At present, it is unclear how the agile methods work under such circumstances. Prioritizing customer values ​​in backlogs is not enough. There should be a follow-up of how deliveries are against promised dates, information on how much work remains on the respective delivery chain and information about available capacity to put in place countermeasures in time and in the right place.

The third challenge for the agile is about the ability to synchronize project events so that different parts of the project cannot stop and wait for partial results. A trivial example is that continued work with electrical power cards requires that some dimensional mechanics decisions be taken. The inability to handle the necessary synchronization leads to shift of work and thus to loss of time.

It is important to note that the three problems described are not created by the agile approach. The three problems exist as an inherent challenge for industrial companies. To deliver projects on time, to handle bottlenecks and to handle handovers just in time. The problem with the agile approach is that they do not address the three problems.

At VMG, we are deeply committed to solving the above problems and today we have a solution that is well-tested for conventional project portfolios. It is called Velocity and has over 3000 daily users in industrial companies. After some time, in close cooperation with our customers, we have expanded Velocity to include agile ways of working.

With Velocity, we offer leaders in multi-project operations a unique opportunity to identify and utilize capacity bottlenecks in ways that provide the best project flow for the entire project portfolio. The flow through the bottleneck is the Takt or Puls of the system. Similarly, we handle all delivery commitments and we identify early delay risks and appropriate countermeasures. Uncomplicated and easy-to-handle handover and synchronization.

Velocity is based on the idea of ​​flow optimization of project flow. With smart methodology and signaling, we make it easy for everyone to work in the sequence that is most beneficial to the project flow. It is transparent to everyone in what sequence work should be done. Incorporating an agile approach in this has proven to be very simple and straightforward. For the agile team it means that it is clear what work should be pulled first from the backlogs, and stay focused on the work until demonstrated and approved by the customer when new work is pulled. This is completely in line with the standard Velocity work method.

With Velocity and Velocity SprintMaster we can handle both agile projects, mixed projects, conventional complicated projects, simple projects, requirement areas, agile teams, virtual competencies, individuals, project portfolios, programs in a single transparent common tool. We can detect and use the bottlenecks, detect and fix risks for delay before they occur and ensure smooth handovers.

Read more