Applying Agile for Developing Industrial Machinery

We want to tell you the story of what we have experienced in recent years in this Italian company in the north-east, located about 60 km west of Venice.

We produce industrial machinery and we needed to renew many of our products, but in a much shorter time than in the past.

We will try to explain why, for the development of new products, we have come to choose a flexible methodology, mainly agile, versus other more traditional methods.

We will tell you about the journey we have made moving from a classic organization for competence groups working in silos, to an organization with cross-functional teams.

In all this, the most important element has been and still is the people, from the new roles of product owner and scrum master, adapted to our industrial context, to the development teams that are learning self-organization, and finally to the stakeholders involved in supporting the teams.

The surprising results, together with the impulses given by the retrospectives never experienced before, are leading us to continue extending agile methodologies to the entire development process.

This company culture, typical of the manufacturing industry, is still stressed by the ongoing lean and agile transition, since these new paradigms have not yet been fully assimilated.

Why we decided to apply agile for developing industrial machinery

The industrial machinery that Breton develops is an integration of mechanics, electronics, software and industrial processes, and therefore it presents an incredible level of complexity.
Breton has three business lines: machines for the processing of natural stone, industrial plants for the production of agglomerated stone slabs, and 5-axis numerical control machine tools to process metal and carbon fibre resin.

We have analyzed the most effective methodologies for managing the development of such complex products.

In order to reduce the time needed to develop new hardware products, even with the classic stage, gate and waterfall methods normally used, the practice since many years has been to overlap the different stages of development. 

In other words, the components with the longest construction and supply time (lead time) are launched into production before the entire design phase has been completed, and assembly begins before all the components have been built. 

This type of approach is called concurrent-engineering.

The advantages are however limited, because waterfall logic remains prevalent. 

I used this methodology for a long time, all the while knowing its partial results; so 15 years ago I was able to experience the logic of lean product development.

Even with lean methodologies, the results are partial because they are applicable to simple or predictable projects, but give modest results in the case of complex projects.

In those years (2006), I was involved in the development of a web software for document management, and our chief developer introduced me to the agile methodology. 

I became passionate about methodology and became aware of the complexity of the process of developing new products.

It was natural for me to consider that even hardware products could be developed in an agile way.

In this way, the overlapping of the phases becomes even more complete because they are broken down into micro phases. 

In 2008 I began to try out agile methodologies in the development of hardware products.

Today I do not know of any other methodology that allows for a sustainable overlap of phases, as the agile one does.

Faced with the challenge of squeezing development time, in 2012 we began the first experiments applying agile methodologies to the development of our complex products at Breton. 

How we combine agile, lean, and traditional methods

We adopted a flexible development process that integrates the best methodologies applicable to the different stages of development.

The vision, lean and product canvas and the subsequent breakdown of the backlog with the User Story Mapping were found to be very effective. 
3D CAD design and digital twins available today allow for effective virtualization, and make the early stages of development of a hardware product very similar to those of a software product.

Once the product concept including cost analysis has been completed, the phases of construction or purchase of physical components begin using conventional methodologies such as Material Resource Planning (MRP) of modern ERP systems, which is in fact a waterfall methodology.

This makes the physical construction asynchronous, as compared to the 15-day sprints, which continue to develop in an iterative and incremental way. 
The assembly is done in an iterative and incremental way with a User Story Mapping modified for Assembly and its Kanban Assembly Board. 
The testing and validation proceed in an agile way, as during the assembly.
Wherever possible, we also use lean methodologies for the visual management of materials and assembly area.
The process is hybrid because it integrates agile, waterfall and lean in a synergic way.
Thanks to a custom-made web planning software that integrates waterfall, lean and agile, we can allow eight product development teams, involving about 100 people, to self-organize, manage the backlog, and at the same time provide the management with a Milestone Plan.

The roles of the product owner and scrum master

The design department previously consisted of several "component teams", divided either by competence or by type of machine they managed. The teams were led by a team leader who also coordinated the development phases of new products that directly affected him. Production and purchasing were separate and independent.

The component teams worked continuously, multitasking between order development and new product development.

The calculation of the cost of product development delay also motivated the recruitment of new developers, in order to make it possible to develop new products without damaging orders.

We continued to maintain component teams for customer order development of standard and custom machines, and at the same time we created several “cross functional teams” including mechanical, electrical and software designers, estimators, buyers, and production and assembly people (our functional team).

At the end of development, the "functional team", coordinated by a PO and an SM, breaks up and its members return to their component teams.

For each new project, a team is created by selecting the most appropriate people.

Product owners have been selected from among the sales engineers who support salespeople in proposing our solutions to customers.

These people have a deep knowledge of the market, they represent the interests of customers and shareholders, and at the same time they have such a knowledge of the product so to be able to guide its development.

The team leaders of the "component teams" have become stakeholders, like the product development director, the president and the general manager; this role allowing much more opportunity to help the development team as opposed to the PO, who cannot simply discuss technical solutions. Fabiano Gazzola (co-host at the ABD2018) is the PO of one of the business lines at Breton.

The role of scrum master was the most difficult to introduce into the organisation, as there had never been a coach role in the company.

We started in 2015 with the support of Daniela Rinaldi (also co-host at the ABD2018). As an external consultant, she helped us to discover the role of scrum master, with all the advantages and disadvantages of being outside the company, and as a woman supporting development teams composed almost exclusively of men.

She helped the teams to deal with the breakdown of the project and to develop the product in an iterative and incremental way, which represented a real revolution.

After a year, the need to have several internal scrum masters emerged, so we recruited new young engineers with a project management scholastic background and with a personality predisposed to the role. This decision proved to be successful, as it allowed us to make agile development sustainable.

In the beginning, the scrum masters played an important role as facilitators and organizers of the time boxed meetings.

While watching the teams at work, there were several surprises. People who seemed initially reluctant opened up and made themselves available to help others. During the daily stand up meetings at the assembly, it was a real surprise to see the production men at the service of the team and facilitating the meeting.

Learning from retrospectives

The retrospectives were the biggest new element in a manufacturing company with a strong male presence, typical of our region.

Cross functional teams include people who may have an age difference greater than that between father and son; it’s not easy for them to bring up the difficulties encountered.

Not everyone had the courage to open up during the meetings, leading Daniale to develop a sort of face-to-face post-retrospective with the most difficult people.

In other words, she gave some people the opportunity, in a very maternal way, to express their difficulties confidentially.

The teams are many, but the scrum masters are still too few so we still do few retrospectives.

The new young scrum masters, recently introduced, are the facilitators of the ceremonies of the sprint meetings but are not yet experienced enough to lead a retrospective.

Generally, we do not retrospect every sprint, even if this remains our goal, but we focus on important moments of the project, as the end of the project.

The main feedback from the retrospectives was as follows.

A PO engaged in multiple development projects in parallel is not supporting the team as much as necessary. Thanks to this feedback, we are now converging towards a PO for each individual project.

The development teams required a project room or at least a corner that they could use throughout the development period.
When the product starts to become physical, the team requested dedicated mounting areas similar to the corner of the project room.

Not all skills are needed for the entire duration of the project. The development team is therefore composed partially of people who are always present (core team), and partially of people present only in some micro phases of the development, or on demand (shell team). In this way the meetings are less crowded, and the team will work with less than 10 people present at the same time.

People who previously loved multitasking have come to understand the need to focus only on the project; and when this is not possible, they do not want to have a daily multitasking, but rather one distributed over multiple days.

With the retrospectives we also collected feedback from the team leaders of the components teams who had difficulty in moving from their previous multirole of developer, partial project manager and order manager, to a stakeholder, only supporting the development team.

Some component team leaders have experienced the role of PO. but quickly realized that they were more useful to the team as stakeholders and as external support to the team itself, rather than focusing on the value to be given to the customer for which they were not so well prepared.

The benefits agile and lean has brought to Breton

We believe that the flexible and agile development of new smart products is now a competitive advantage for Breton, compared to our competitors that use all conventional development methodologies.

Thanks to the flexible, mainly Agile development, we have reduced development times by up to 25% in some cases. 

In all cases, for the first time in the company, the product cost objectives have been better (less cost with respect to the target) in some cases, while in many cases the cost objectives have been fully achieved and only in some cases the cost objectives have been only partially achieved.

The first experiments applied to a smart machine included a PO for the development of the software part of a machine and a PO for the hardware part. Problems of coordination between the two teams and of knowledge transfer emerged, as can be expected. It was therefore decided in future projects there would only be one PO, and we are supporting them together with the development team, in writing software and process stories.

It has become clear to all of us that the bottleneck in the development process is due to the use of standard construction processes and classic materials management (MRP) methods.

This motivated us to launch an internal "Factory inside Factory" project to halve the development time, thanks to dedicated spaces, permanent functional cross teams, new channels and new construction methods. 

In some cases we are able to build relatively simple components within a sprint, and one of the goals of the "Factory inside Factory" project is to get as close as possible to building hardware components within an iteration, thanks to new methods such as additive manufacturing, or dedicated machines and departments. 

This will be applicable only to the very first prototypes because these new methodologies are generally more expensive than the traditional ones for a series production.

The "Factory inside Factory" project is managed in agile mode and also intends to improve all the phases of product development that are already agile today.

The main goal of this factory is to release new validated products ready for serial production as quickly as possible.

How our culture changed

The cultural change is still underway because we only started the change extensively from 2014-2015.
Agile is effective because it produces knowledge and increases creativity and productivity, thanks to the cross-functional working team.

The relationship between production and designers is much better because each one is aware of the work of the other.

There have been some cases where during the assembly phases it has been necessary to create a new component, which has been thought and designed by the team in the afternoon, built in the evening, completed in the morning after and installed in the machine by noon.

This did not happen due to pressure from the management, but was the team’s decision and as managers we gave only support by providing access to other manufacturing resources.

People who previously systematically finished their work at 5.30 p.m. continued to work spontaneously until 8 p.m. if needed.

Mutual assistance between team members made the role of the scrum master less necessary in some cases.

Moving from traditional task management to deliverable management with user stories greatly motivates team members.

Sprint reviews look more and more like "time boxed design review".

Top management always wants to be involved in the writing of the canvas board and participates with interest in the sprint reviews to which they are invited.

Cooperation between sales stakeholders and development teams is greatly improved.

The personal and professional and human growth of the people involved from the beginning to the end in the development of a new product is evident to all.

Concluding thoughts

The calculation of the cost of delaying the introduction of a new product to the market has forced us to consider faster development methods versus traditional ones, even if the first prototype products may be more expensive.

The most important aspect of the agile transition in the development of new products is the human aspect.

Better results and better products are achieved thanks to more motivated and proactive people who get involved.

Agile is an effective methodology that promotes social learning and therefore produces shared knowledge, thanks to people with various skills working together. One of the agile principles "Individuals and interactions over processes and tools" really works by fostering creativity and productivity.  The team climate has improved dramatically.

All Development Teams really appreciate working together and without multitasking with other projects.

The results obtained together with what emerged from the retrospectives allowed us to start the organizational project "Factory inside Factory" that will extend the agile modalities to all the product phases, where possible.

One of the most important challenges will be the extension of agility to the construction of machine components, which are currently built with classical methodologies, and the extension of agile logic to other business processes outside of product development.

It's of utmost importance that all of management share the agile methodology.

Today, the pressure from top management to develop more and more products in agile mode is a great motivator, but this requires caution until we have consolidated these new methods.
Still, we have a long way to go to make the whole product development process agile, which today integrates agile, lean, and waterfall methodologies together with the use of digital technologies.

About the Author

Claudio Saurin is passionate about Organizational Innovation. He is the director of product development at Breton s.p.a., a company with about 900 employees that produces industrial machinery near Treviso. He has been implementing new product development in a more flexible way, integrating agile, lean and waterfall in a synergic way, together with strong digitization of development processes. Claudio coordinates a company project, financed by MISE (the Italian Ministry of Economic Development), on Digital Transformation, which involves the integration of 18 IT platforms to digitalize office and factory work. He also coordinates another company project, also financed by MISE, for the development of "Smart Machine Tools" enabling the Industry 4.0.