< back

Agile MES

February 27, 2014

Agile MES

The habitat in which modern manufacturing organizations exist is rife with changes. These changes appear in the way markets are evolving, products are being manufactured and customer preferences are changing. The changes in manufacturing processes, in almost every industry segment, are occurring at a much faster pace than before. Technology, both in manufacturing and information, is evolving rapidly and changing the way in which manufacturers design and deploy products and satisfy customers.

The hottest topic of discussion in the board-rooms of most manufacturers revolves around developing more agile more collaborative value chain based operations, which are pro-change and proactive in the way they anticipate and respond to change/contingencies. Major contributors to this much desired agility are the various software applications such as the MES, ERP, MRP, SCM etc., and the way in which they accommodate changes to improve their own effectiveness and thereby the efficiency of their user groups and value chains.

Software applications such as the MES which model production processes, cannot afford to remain stringent in their functionality, they need to become enablers of positive change and process improvement. In our blog posts "The MES selection process", we had highlighted the importance of a project approach required for successful deployment of MES applications. The project approach implies involvement of major process stakeholders with the software development team on a constant basis, which allows formation of an incrementally clear definition and constant improvement of the resulting solution, as the project moves forward. Today, we will try and establish why agile deployment techniques trump traditional software development techniques such as the waterfall method in MES software development and subsequent deployment.

Let’s begin with trying to understand the difference between agile and traditional software deployment processes. Traditional methods like the waterfall, relied on a phased approach for development, which flow from the initial phase to the last, as the name suggests. The waterfall technique involves 6-7 phases, beginning with- 1) Requirement specification, 2) Design of Software architecture, 3) Coding, 4) Integration, 5) Testing and Debugging, 6) Installation and 7) Maintenance. In this approach each stage or phase proceeds only when the previous stage is complete in entirety. Once a phase is completed no changes can be made to it whatsoever.

So a typical waterfall deployment works like this: the customers provide their requirements upfront, which should be detailed and precise as to the functionality required. Upon receipt of specifications the design team, which in this approach is generally different from the coding team, then prepares an elaborate and generally time consuming design of the software. Heavy and constant documentation is common in this phase. Then the coding team develops the final application, again documenting precisely the coding performed for future reference and formation of the source code. Then the almost final product is tested and any bugs detected are removed at this juncture. After this exercise ends, the final product is now deployed.

This traditional approach is highly disciplined and lays heavy emphasis on initial planning and design, where all possible changes are made up-front in the earlier part of the process and no major changes are accommodated in the later stages. The exercise of developing applications using the waterfall techniques or other similar ones is highly time-taking and leads to the development of a well-documented but highly inflexible application. Such an approach requires customers to know up-front all their requirements, which is almost never the case in fast-changing modern manufacturing environment.

The discipline which is mandatory in such techniques, often leads to creation of information silos and gaps which cause delay and make the process too stringent and unaccommodating. These approaches rely on excessive planning and thereby pose a threat of rolling-out a very reactive system, which has functionality that is no longer valued by the customer. Legacy systems which were developed using such techniques have now become a major challenge for their users and employers alike. These systems can’t accommodate any changes and lack the ability to interface with other applications, thereby rendering them useless from a collaboration perspective. Traditional methods are generally very expensive as the amount spent from idea to conception is longer than modern agile practices. Also the way in which such applications are developed, makes them highly customized and thus each time a new change is required, the entire process needs to be repeated.

In contrast to the traditional methods, agile methods are much more iterative and incremental in nature, where development of software is an ongoing continuous activity, which involves visiting all/most stages of traditional techniques simultaneously. The emphasis in this approach has shifted from excessive documentation to presenting actual and functional code to the customer. It mandates participation of self-organizing, cross-functional teams, which perform adaptive planning and work towards evolutionary development. The time-boxed iterative nature of this method makes it faster and more agile, and thereby more effective for environmental conditions characterized by constant change.

Agile techniques advocate the importance of individuals and their interactions with each other and the importance of providing a working software to the stakeholders of the project rather than documents and responding to changes which occur during the course of the project. Agile iterative methods exist on an exactly opposite end of the software development continuum, where the continuum ranges from highly planned to highly iterative development techniques. There are many hybrid techniques, which use features of both extreme techniques and thereby find their place somewhere in the middle of the software development continuum.

Rather than discussing all agile techniques in detail, let’s focus on one of the most popular techniques called- SCRUM. The word Scrum is derived from the game rugby, which refers to the way in which the game restarts after a minor infraction. This technique follows the agile deployment philosophy of continuous, face-to-face communication, incremental iterations to develop and test the product simultaneously and a focus on delivering quality to customer, with changes made constantly based on regular feedback. In the Scrum process the project team has well-defined roles, the three major roles are- 1) Product Owner, 2) Development Team and 3) Scrum Master. The product owner represents the voice of the customer and provides the requirements and their priorities. This role can be played by the project manager of the deployment team; it is a key role in the Scrum process and requires the person involved to constantly interact with the development team and the scrum master.

The development team develops a potentially usable product- the ‘Sprint Goal’ at the end of every ‘sprint’- which is the name given to every iteration performed during the Scrum process. Each sprint is time-bound and at the end of every sprint the development team provides an integrated, tested, documented and finished product, which is then modified in the subsequent sprints; until the customer finally approves it for deployment.

The third role in the process is that of a Scrum Master, who is responsible of facilitating the practice of scrum, chair meetings, maintain flow, ensure collaboration and most importantly removes impediments in the way of delivering the final product. The Scrum Master is different from a project manager as the sole objective of the Scrum Master is enforcing the rules of Scrum and ensuring deliverables and deadlines are met, through constant collaboration and making incremental and educated changes.

The Scrum process involves various sprints. In each sprint there are three types of meetings, which are- Sprint planning meeting, Daily Scrum Meeting and End Meetings. Basically the objective of these meetings is to determine what has to be done, then go ahead and do what is planned and finally review what was done. At the end of the final sprint the ideal product would be deployed, as it is now perfectly refined through the series of iterations or sprints performed. A typical sprint cycle can range from one to four weeks; generally a two week sprint cycle is common.

What makes Scrum so effective is the way in which stakeholders are constantly involved in the deployment process. This enables generating a product which is needed rather than what was planned years ago, and leads to higher value being generated from the teams combined efforts. Scrum involves development of a ‘Product Backlog’, which is a list of high level requirements from the application being developed, as process proceeds. This document becomes more specific and more functionality oriented and provides basis for ‘Sprint-Backlog’, which documents tasks to be performed during the sprint. This methodology is not only fast, but also allows an evolutionary approach to software deployment, where modular applications can be customized to specific requirements.

Earlier we emphasized the risk of developing MES applications using traditional methods like the water-fall and how modern manufacturing environment is plagued with change. However, agile methodologies such as the Scrum are ideal for developing MES applications as they rely incorporating required changes and don’t force customers to provide specific requirements right at the beginning of the process, once and for all.

Moreover, even in the case where the MES product is available, an MES project involves the modeling, the configurations, the integrations and even the extensions on the base product, necessary to fulfill the customer requirements. It needs requirements, development, testing and deployment and can dramatically benefit from the adoption of Scrum methodologies, like the ones used in pure development projects.

This very feature of incorporating flexibility in the process itself is what makes these agile techniques more desirable and more sensible. MES applications are practically useless if they are unable to model the ever-changing flows of manufacturing plants. Both the applications and the deployment projects need to be agile, collaborative and faster than ever before. Both should be set up to enable and entertain change, which will make the manufacturing operation more proactive and more AGILE.

< back


IIoT Has a "Thing" for MES. Why IoT Platforms Won’t Replace MES for Industry 4.0
by Iyno Advisors and Critical Manufacturing