Agile and the Breton Case

When I arrived at the company in the fall of 2010, the president-who was very active in product development with constant suggestions to the teams-asked me to propose a different organizational mode that would make the company capable of continuing without slowing down even when he was no longer able to provide the necessary impetus. It was a very enlightened and forward-looking request, and I remember him placing two conditions on it, which he agreed to and adhered to in the years that followed and which I personally vouched for:

• The best idea wins, even if it comes from the person with the lowest hierarchical position.
• Developing very innovative things requires taking risks, and therefore one must accept failure, which is bound to happen.

The rationale I gave for pushing the company’s management to embark on a new mode of product development, which was absolutely revolutionary for the company’s context, was an assessment of the cost of delay that the company was unknowingly incurring.

Fortunately, I was not starting from scratch, and when I arrived in Breton I brought with me the still-experimental experiences made since 2008 with the agile approach. Starting in 2013, I began to carry out with my teams the first experiments in iterative and incremental approaches. In 2014 I realized I needed help, and I involved Stefano Leli of Agile Reloaded; together with him and my teams we worked to set up a sustainable process of developing physical products in agile mode.

First, I strengthened the engineering department to support sales, with the goal of having people who could delve into the needs of the market through their continuous interaction with customers. These people later became the first Product Owners, whom we brought in to lead product evaluation meetings sometimes employing Vision Canvas and much more frequently Lean Canvas.

In a technical company like this, the marketing of new products is governed mainly by the two brothers who own the company. Such an active role of the OPs leading the team development of the Canvas in the presence of the two brothers, the managers and the function heads concerned was greatly appreciated.

This greatly shifted the focus of development from a very technical perspective to a value-oriented perspective brought to the customer.

The OPs also proved to be very effective in product-related promotional activities, dealing with the four dimensions of the Marketing Mix and cooperating with the Marketing Department in creating promoted content in magazines, on the Web and at trade shows.

The role of the Product Owners was fully understood by management, so much so that two of them-among the most experienced in their respective lines of business-were given the role of Business Developers.

Il ruolo dei Product Owner ne risultò pienamente compreso da parte della direzione aziendale, tanto che a due di loro – fra i più esperti nelle rispettive linee di business – fu conferito il ruolo di Business Developer.

A group of people delegated only to new product development was deliberately not formed, so that participation in development teams would be open to all and in this sense very meritocratic and challenging.

All of us, for personal or physical or other reasons, may not always be able to cope with the challenges of developing a new product, and that is why I think it may be worthwhile to opt for rotational work. In fact, sometimes one needs to be able to stay in the “rear” to be able to regenerate, as the “continuous challenge” is likely to wear one down.

Once the development phase was over, the return of the people who made up the development teams to order fulfillment allowed for a better understanding of the real behavior of the products, while at the same time bringing into the order fulfillment process of often customized machines additional skills gained during new product development.

To make the work more efficient and sustainable, we divided the cross-functional development teams into Core and Shell.

• A “Core Team” composed of full-time committed people.
• A “Shell Team” composed of people committed part-time according to well-defined rules of engagement.

People from both teams should work together when necessary, attending meetings in each iteration (Sprint).

Parallel to the “internal” role of the PO, it was necessary to introduce the role of Scrum Master, initially held by consultant Daniela Rinaldi. It was necessary to wait until 2019 to hire Giovanni Melis as Senior Scrum Master. Daniela and John then brought out other Scrum Masters, in this case part time, who made this new mode of development sustainable. With the arrival of first Daniela and then John, we began to reduce the presence of counseling, until we proceeded completely independently with John.

In the first phase we focused on design (Agile for Design), because it was believed that this activity was the weak link in the whole process, but we soon realized that design was only part of the problem.

The results obtained were satisfactory for design, but the overall development time was affected by construction and procurement, which were carried out in the same manner as order fulfillment.

The issue really lay in the physical development of the product, so I convinced the management to set up a dedicated department–a kind of fully agile mini-factory–with a dedicated acquirer and dedicated planners to handle the materials directly. In 2019 this new way of working became operational, and this proved successful because the time was further reduced. The most relevant aspect was the possibility of having a staff of assembly and testing technicians more involved in the project. This improved the quality of industrialization, effectively enabling Design for X.

The Agile Factory draws on what technology makes available today, such as 3D printers or the accelerated build modes enabled by specific suppliers; it also draws on virtualization (think Digital Twins) that allows physical construction to be postponed, making more iterative development possible.

Digital Transformation was driven by the needs of the Agile Factory and had a positive impact on Web management of job planning, production, and project document distribution, leading to the development of a lightweight PLM that allowed widespread reference of 3D documents and drawings.

This was also enabled by the Modular Architecture adopted for all new products, which allowed in several cases for the separate development of specific machine modules, or the development of cross-cutting and innovative technical solutions that we called “Technology Bricks.”

The Agile Factory has brought about a paradigm shift on the meaning of prototype.

As long as one remains in the office, one is inclined to think of the product as being closer to the final product and tends to focus verification of design assumptions at the time of prototype availability.

The Agile Factory has also led to a revolutionary approach to the validation of design solutions.a Designers, given the high speed of component construction allowed, are naturally driven to validate the developed solutions as soon as possible by building real prototype forerunners, i.e., “Pretotypes.”

In particular, I remember the case of the development of a granite grinding and polishing head: during the design with 3D CAD-accompanied by structural finite element verifications-we were left with doubts about the mountability of some solutions and the actual possibility of passage of cables and hoses. These verifications could only be experimental. The two main elements were made of light alloy shell castings. Mold making and initial sampling would have taken about four months.

The team together with the OP decided to develop the light alloy case with Additive Manufacturing (by means of special 3D printer the mold inside which the alloy is cast is produced). Within a month it was possible to get the two components cast and machined, ready for assembly checks. This turned out to be providential, as assembly checks revealed the need to change the geometries of the cast components. The drawings were thus modified in time so that the mold construction order would not be delayed and remade. The cost of the prototype in 3D prints was about 18 times the cost of the component cast in shell, but it allowed the machine with more than 20 spindles to be completed five months later without error. Certainly the extra cost was largely offset by the sharp advance in product release.

The absolute most significant aspect revealed I think is the Outcome, that is, the result achieved on people and the organization.

I am referring to the human aspects of change and the impact that the application of the Agile Factory has had on the people involved.

Through working in cross-functional teams, the people involved acquired new skills, not only technical but also relational. This has led to greater mutual recognition of roles and functions.

People are really at the center of the development process, and this is evidenced by several cases in which I have been able to verify the first principle of the Agile Manifesto: people and interactions more than processes and tools.

Their resourcefulness has made and is making a difference, and seeing teams acting on their own gives great satisfaction.

There would be many citeable episodes, among which I like to recall a case related to the development of a machine that during testing broke the product it was supposed to process. The event occurs in the morning, and together with the team, we identify the possible cause and decide what to do. A team worker recalls that in the warehouse, covered in dust, there is a particular sheet material from which it would be possible to make the parts we need. A designer draws outlines of the parts to be cut on squared paper, and another worker applies to cut them on a cutting machine with pressurized water the same evening. The same worker the next morning, with other colleagues from the first shift, cleaned all the pieces from the water-cutting residue and took them to the machine. Together the whole team installs these new components and puts the car in a condition to start again. By noon the machine starts, and this time the process is perfect.

This all happened by the team’s decision, and without any pressure from us managers present. In fact, the only thing we did was to call our colleague who ran the department with the necessary machine and ask him to make it available immediately.

It is really exciting to see these things happen, and it makes you realize how far people can go when they feel motivated. The agile approach for all intents and purposes promotes the self-organization of people in cross-functional teams.

Also very important was the collection of feedback through the Retrospectives: true moments of reflection that allowed for improvements in working methods. The Scrum Masters played a delicate and crucial role by leading these meetings restricted to the development team only, reporting a summary of them to me, and always maintaining the necessary confidentiality about what people were saying.

The agile transition was not a walk in the park; we faced several difficulties.

For this specific topic, my greatest personal effort was devoted to convincing and motivating the design group leaders (the Middle Management) who, in this new organization, were faced with the request to step back. I was asking them to select their best people, to have them participate in the development projects led by the OPs, and to step into a role much closer to mine: of mentor, of advisor in support of the teams.

At each Sprint Review, group leaders are at my side and at the side of management in evaluating the solutions developed. At the same time, they are the internal customers of the products that they will then have to handle within the customer orders.

It is humanly understandable, putting oneself in their shoes, that it was not easy to internalize that the transition from less of a player’s role and more of a coach’s role could have provided as much satisfaction.

They soon discovered that this role allowed them to implement very strong innovations, through the initiatives taken by the people on the teams, and that in many cases they themselves in their previous role would not have implemented them themselves because it was too risky for their reputation.

In this way very bright young contributors could make extremely innovative proposals and take risks that “group leaders” would not easily take.

And this allowed for an unprecedented flourishing of ideas.

Equally important has been the response of the people involved in the agile teams once they are brought back to the client orders, precisely to encourage the dissemination of knowledge that would otherwise remain elitist.

Well, this generated aspirations from others to participate in such development teams, however more competitive and challenging, because the products often represented the progenitors of new product families.

There was a chance for a great many of them to make themselves known to the management that previously knew mainly the “group leaders,” and this meant that even the youngest became protagonists, within teams where strong challenges require intergenerational cooperation.

People are really at the center of the development process. This is evidenced by several cases in which I was able to verify firsthand the first principle of the Agile Manifesto: people and interactions more than processes and tools.

Their resourcefulness has made and is making a difference, and seeing teams acting on their own gives great satisfaction. At the end of the project, people embedded within the customer order fulfillment process soon ask to return to new product development, a testament to the fact that people like to work in “agile” mode.