Menu
E80 Group, formerly Elettric80 S.p.A., is a company specializing in the implementation of automated logistics solutions equipped with robotic systems for consumer goods manufacturing companies in the beverage, food, tissue and diversified fields.
The company, headquartered in Viano, in the province of Reggio Emilia, with branches on all continents, employs about 1100 people.
New product development within customer orders showed obvious limitations in terms of the length of the process and the inability to fine-tune the product in a short period of time.
The company’s management, which was very clear about the need to give a stronger impetus to new product development.
The project in E80 Group began with an experiment in February 2021, in cooperation with Maxwell Consulting, at the initiative of the company management.
Together with Daniela Rinaldi, mindful of previous experiences, we involve function heads directly or indirectly interested in new product development, preparing a short training course designed for them. Without this crucial step, we would not have started.
The interest shown prompted management, despite our misgivings, to carry out an experiment on two product development projects already underway.
The 2 projects involve two dynamic and experienced product managers in the company, Gianluca Clementini and Alberto Lodini, who quickly stepped into the role of Product Owner. With the help of technical director Marco Casarini, a historical figure in the company and sponsor of the experiment, we identify in Francesco Monica and Juan José Contreras González, who work in R&D, the ideal people to ask for support for this agile transition test, promoting them in the field to the role of Scrum Master.
After a quick training of the operations teams, we immediately got into the thick of the projects, specifically starting with a review of the rationale for each project and identifying the unique value proposition with the Lean Canvas.
Although it was a revisit, the initiative was highly appreciated because it had people from the sales area and technicians cooperating in defining requirements that were already defined in a preliminary form but further refined in the meantime. This allowed business needs that had not been sufficiently clarified to be allowed to emerge, and mechanical, electrical, and software designers to work together with material procurers and production people in a way that traditional waterfall approaches had never done before.
Some operational methodologies were then introduced, such as:
Both in-person and remote cooperation was experimented with, in a hybrid mode befitting the distribution within a radius of several tens of kilometers of the E80 Group’s production units, which we might describe as a “diffuse company.”
Retrospectives were introduced, enabling small process improvements and increasing team motivation. The latter became passionate about such a way of working, openly expressing a desire for it to become their permanent mode of work.
Although the projects were already underway, the results from the perspective of participant feedback were very good: mechanics, electronics, materials management, and SW developers were working together listening to each other and beginning to understand each other’s needs.
Indeed, the teams began to cooperate, quickly achieving a team spirit that surprised both Daniela and me, indicative of a corporate culture that still remembers the artisan spirit of its origins.
“It is our fears that limit our successes. Not mistakes” is one of the slogans you find when you enter the company.
This approach also highlighted weaknesses in E80 Group Product Development that are typical of most companies I have met, such as the difficulty in managing the development of prototypes of new products within the production flow of materials for customer orders.
The critical issue of having a materials management process that, for the reason just given, is not yet integrated with the design process also emerged.
The important opportunity for the agile process to also take place on the factory floor was quickly understood, and there was a need for Purchasing people to be dedicated to the project.
The two POs who are very operational in the business field and called to this role of project leadership experienced the experiment as reported here in their own words.
Gianluca Clementini:
At the time when I started this experience together with Claudio, the most difficult thing was to be able to convince people that a different way of approaching the development of a new project could give added value and efficiency.
What worked and was the turning point in the application of the agile process was the moment of the creation of the working team, the periodic meetings to share the status of the project, the meetings to present the status of the work to the Stakeholders: in these phases I saw a great involvement of all participants, probably due to the empowerment of each one to carry out a certain number of tasks and share the results with the rest of the team.
I can say that the value added was the continuous alignment of all departments on what was being carried out and the empowerment of everyone to achieve the final goal.
As in all new experiences, there are also the moments of difficulty; in the particular case, they occurred from the moment of the end of design to the physical realization of the prototype. Here issues arose regarding delays on material procurement that delayed the project by a couple of months, making the team’s work very hard. The pressure from outside became more and more intense, and here I noticed that the teamwork was greatly weakened and only the difficulties of the individual understood as department, provider, etc., emerged…
The “Lesson Learned” from all of this is that it is necessary to have the strength to act in the same way both when things are going well and when critical issues emerge, and at all times the end goal, which is that of the team and not the individual, must be clear.
This can all happen with time and the involvement of the right people at the right times.
Alberto Lodini:
I have a very vivid memory of my first approach to Agile
–
also because it was definitely traumatic
–
which occurred precisely with Claudio and Daniela when they began their training of a small number of people in E80, of which, of course, I was part.
Their enthusiasm and attempts to build trust, both in them and in the agile methodology, continually clashed with my vision, which was mainly based on previous experiences too far removed from what they recounted.
The glossary used, mostly unfamiliar to me, did not help, and even the Case Studies brought punctually as examples failed to open my eyes and minds because they were deemed too far from my “world.” In such a climate of extreme skepticism, more by the will of others than by me, we nevertheless began the first real agile journey by tackling the Easy Store Girona project. It involved developing a new autonomous vehicle, called Satellite (or, for those close to it, “piggyback”), employed in integration with a fleet of LGVs (Laser Guided Vehicles), also of our own manufacture, in the implementation of automated warehouses for multi-depth pallet storage. The real difficulty was related to the fact that the project had to be directly developed on a sales order having significant penalties on delivery delays and relating to a strategic client for the company: in practice, it was not possible to fail. Further extending my doubts was the fact that the project in question had already begun, albeit not long ago, with the typical waterfall approach, and many decisions in the design area had already been made. I knew inside that I was not the only one within the Core Team. –
composed of about ten technicians from different business departments
–
to have doubts, but at that time my role required me to externalize confidence to create momentum and motivation at such a delicate stage, and so of course I did.
Also defining the roles that would later prove to be of paramount importance
–
such as Product Owner, Scrum Master, Core Team, Shell Team and Stakeholder
– had been done by pandering to the ideas and expertise of Daniela and Claudio, rather than out of any real understanding of what was happening. Understanding that, personally, only began at the end of the session where we all went together to address the Lean Canvas.
It was certainly not, once again, the terminology used that helped me, but rather the input given by a part of the company that until recently I had always considered hostile to the construction of a real project because it was often unskilled, marked by constant demands without adequate justification and little respect for the work done within Operations. Well, yes: the eye-opener for me was the input given by the business side, which, included in the initial sharing of defining the project rationale, with lucidity and punctuality of argumentation made a fundamental contribution to the compilation of what, as it was filled in, I realized was the most extraordinary technical specification document I had ever seen before: at a single, simple glance, everything our project had to contain or not contain, why it had to contain it, and what would be its key priorities and objectives were listed with disarming conciseness. All with the endorsement or even the complacency of the commercial: I couldn’t believe it….
Shortly thereafter, Sprints began with the participation of the work team. With the exception of a few rare occasions of Brainstorming at the beginning of a project, I had never been at a table with so many technical entities present at the same time, and the curiosity was strong: how would the Softwarista or production man not get bored during meetings that would involve only mechanics and electrical for several weeks? It really took only a few meetings for me to realize how far I was from the agile reality: not only did Softwarista and production not get bored, but they provided interesting insights into most topics, giving unprecedented insights for those who had always thought in waterfall, thus thinking that projects started with mechanical construction, then electrical, etc.
The participation and interest on the part of the entire team immediately proved so high that it seemed almost unreal; I was reminded of images from long ago when, after years of team practice, we would take the field together with the desire to play all united to win. So the project “team” began to play the game, Sprint after Sprint, obviously creating their own product, but also creating a strong sharing environment where choices are made together and where mutual training also comes naturally as everyone always teaches the others something.
In the end, the most surprising result was not the creation of the new product itself, the Satellite, which moreover took place satisfactorily and on schedule, but also and above all the creation of a group of people who continued to learn and grow through the exchange of mutual skills, including those from the commercial area, and who will certainly have today more awareness and additional tools to better face future work challenges.
After about 8 months of testing, the findings were so positive that management took two important steps:
For Hardware projects, 4 Product Owners were identified, with 3 Scrum Masters supporting the teams.
To make the high pace of events of these teams and the integrations between the different groups sustainable, the projects were divided into 2 macro-groups staggered by one week. The iterations have a duration of 2 weeks.
The expected Outcome of the project is an agile transition of the new product development process that brings out the new operating standards so that this becomes part of the corporate culture.
This will lead to the structuring of a portfolio of new product development, an adjustment of teams according to what emerges, and the adoption of dedicated spaces, including the “Agile Mini-Factory.”
