Agile in the manufacturing industry

Agile is a project management framework originated from the software industry. Nevertheless, values and principles that define the methodology are highly relevant and applicable within the IIoT context.

Jeremy Theocharis

Background - project obstacles

While working in an IIoT project, there are several circumstances that can delay and diminish the impact in the production shop floor.

Not enough budget for all the desired hardware and management is desperately looking for fast ROI
Team doesn’t have a 100% clear idea of how to solve the problem e.g., quality deviations, machine stoppages or process performance to mention a few
Clients such as the production department want to increase their KPI’s as soon as possible.

Project management tools as waterfall and agile are used to fight back these circumstances. The first one is more known in the OT sphere, while the second one in the IT one.

Waterfall

Waterfall or stage-gate process is a methodology of project management used to develop, produce, and bring to market products. In a nutshell, the project has defined phases and the team members which are composed of different areas of the company collaborate. From one phase to another there is a checklist, or also referred to gate, created with inputs and experiences from all the team members from previous projects. This tool states the requirements needed in the product in order to advance for the next phase.

Waterfall proposes a sequential and structured approach. Passing the different gates, assures the fulfilment of standards, tests and maturity of the product or process for entering a new phase. Also promotes an efficient collaboration between colleagues from different departments in an organization, e.g., pulling colleagues to the project when they are most needed.

Nonetheless, this methodology has some weak points. With new type of products for the organization, it is complicated to have an efficient checklist that revises the necessary elements and doesn’t add irrelevant work packages. The method adds distance between the project team and the client, since the requirements of the client changes, bringing less value when the product is finally ready. These flaws are easier to be identified in a pure software product such as a website. That is when a group of IT developers gathered and defined the values and principles of agile.

Agile

Agile methodology started in the software industry. Developers were having problems to define the gates for totally new products (particularly the intangible aspect). Asking the client wasn’t an option neither because they were not familiarized with this. The agile methodology is very well described within the “Manifesto for Agile Software Development”:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

In order to diminish the uncertainty, agile proposes shorter development cycles, by establishing and prioritizing requirements. Once these requirements are fulfilled, the client tries the product. The client in a conscious or unconscious way will give feedback to the team, this being the inputs for defining a new round of requirements. It is important to add that this is done in a diverse team from different areas rather than a particular department.

“Speeds always wins” is a common phrase within the agile methodology. Agile is all about decreasing the uncertainty of a new product and by constantly bringing, testing and receiving feedback from the final client, this is achieved. Nevertheless, it is highly relevant to always include crucial requirements, more precisely the ones that are related to safety for the end user. This can’t be never skipped or depreciated.

Unfortunately, agile has also some disadvantages. For products that the organization has much knowledge, the team can fall in the trap of “re-inventing the wheel”, instead of leveraging existing know-how and resources. Other issue can be within this mindset of getting things done as fast as possible, can create pressure in the team and forget of essential requirements such as regulations even safety for the user.

Agile in the manufacturing shop floor

Within this phenomenon of the merge of the IT and OT in the manufacturing shop floor, the United Manufacturing Hub recommends applying the best of both worlds in the development and delivery of IIoT projects in the shop floor.

Context: An IoT engineer is developing a project in a production area where several machines, workstations and operators are collaborating. Production, quality and infrastructure department are struggling with their KPI’s.

Pitfall	Description	Agile recommended tool
IoT engineer Vs the world	Each department demanding many and complicated requirements, not supporting activities nor sharing knowledge to the project	cross-functional team, empowering the developer as well sharing the responsibility with the final user and client
Infinite To-do list	Tasks are opened by the team members and written down by the IoT engineer in an excel file.	Kanban board - visual manner to organize tasks, responsibility and the status of it. Helpful to the team to support each other
In search of the “perfect” project	Team works to bring the perfect project, with very sophisticated (and expensive) sensors and/or highly complex data extraction and contextualization in order to solve all the possible problems. Project budget on the roof and the project is delivered with many delays. At the end, half of the sensors do not bring significant correlation to the problems.	MVP - define together most important variables. Test fast and validate hypothesis. Improve to MVP2, while MVP1 is already bringing savings in the production shop floor

Conclusion

Depending on your background and the role of your organization, try to take the best of each part of the IT/OT world to your team and your IIoT projects to develop. There is much to learn, but don’t feel overwhelmed. Leverage this opportunity (and your colleagues) to learn from each other in order to become a more holistic engineer.