During my career as an MES consultant, I worked in projects where we applied different project management methodologies. The most common one was the Waterfall model. This model was developed in 1970’s. More recently, at the beginning of this millennium, the Agile methodology was introduced. Here I explain how I adopted it in an MES project.
Waterfall methodology is a sequential process where the outcome should be known from the beginning. The project moves on to the next step only when the previous step is complete. Once a step has been completed, there is no going back to a previous one (not without changing the original plan). In general, this model works well. However, there are some limitations:
The initial requirements must be very detailed and should not change during the course of the project. In reality, it is not uncommon that the initial ideas become obsolete in the middle of the project. In consequence, any changes to the scope will impact the project timeline and budget. And if a decision is made to omit the changes, the solution will not meet the customers’ expectations.
The solution should be tested as a whole at the end of the project. If significant problems are discovered at this stage, they are typically resolved by applying “shortcuts” instead of proper fixes so that the delivery date is not impacted. That makes future changes more difficult and prone to errors.
Project needs to be executed in a sequence, so there is no possibility to make changes in the previously executed steps. In consequence, projects often end up having designs or test scenarios that deviate from the actual solution developed. Particularly in MES projects where changes are a commonplace, this leads to issues with code control, maintenance, and support.
Agile methodology was introduced to “remedy” to all the disadvantages of the waterfall. The main difference is that it follows an incremental approach instead of sequential design process. All the phases of the Agile project are executed in short cycles – 2 to 4 weeks. These cycles are called “Sprints.” During every sprint, a small set of features is worked on. At the end of the sprint, the outcome is presented to the customer. That allows for collecting feedback and introducing changes to the initial plan. In Agile approach, changes are expected. In the waterfall model, changes are considered to be “evil”.
Both methodologies have their strengths and weaknesses. Deciding which is right depends on the context of project and clarity of the requirements. In one of the projects that I took part in, we followed the Agile model and chose the SCRUM implementation. The remainder of the blog explains the SCRUM framework.
The MES project, where we used the Agile approach, was delivered for an automotive company. Here are some reasons why the Agile model was used:
Customer was familiar with this approach as they used it in other software projects
Customer wanted to enhance the existing implementation of the current MES system
Business goals were defined, but not all details could be specified when the project started. The business goals were:
Develop a Visual Defect Tracking system that can be used by inspection and repair teams
Improve shop floor visibility by connecting and collecting data from the automation layer
As every SCRUM project, our implementation was divided into several Sprints. Sprint is a period of 2-3 weeks that takes one full cycle from design to review. In every Sprint, we had a couple of meetings, and the full cycle looked as presented below.
At the beginning of every sprint, we had a meeting where we went through all of the user stories and tried to estimate the time it would take to implement these features. This seem to be easy, but quite on the contrary it was not. The first challenge that we encountered was that we couldn’t just take 100% of our available time and split it into delivery tasks. In our case, we ended up using a 0.5 ratio. We used half of the available time on delivery tasks. The rest of the time was allocated to non-productive items like meetings, knowledge sharing and other projects that required our immediate attention. We have calculated all the available time, and we had estimated and prioritized the required work… Easy sailing after this, right? Not exactly!
After the first Sprint, we realized that we had some people whose time was not efficiently utilized because of their specific competencies. We had two profiles: developers and automation specialists. Teaching developers automation and the other way round was not an option in the given timeframe. That is why we grouped people and tasks into two separate pools and prioritized requirements separately. Additionally, unlike in a standard Scrum approach, the external dependencies had to be taken into account when consuming backlog.
The Sprint Planning Meeting was also a perfect place to split bigger User Stories into smaller chunks. However, to be able to do that, you need to make sure that your User Stories are well defined. That is the responsibility of the Product Owner. Having well-defined User Stories allowed us to split them into smaller tasks and not waste time on unneeded clarifications.
Every day at 8:45 in the morning we had a 15-minute meetings. During these meetings, the team members could share what they were doing yesterday, what they are planning to do today and if there are any impediments. In the beginning, we had a problem finishing our meetings in 15 minutes, but this improved with every sprint. Daily Scrum meeting is a summary meeting. If there is a need for a detailed discussion, that discussion should be handled separately. That way you don’t waste time of the team members that are not affected by the problem.
At the end of the sprint, we met to present the results of the previous two weeks. These meetings were very important as they allowed us to gather feedback from business users. In our case, we were quite surprised by how involved and engaged our customer was in these meetings. We had to present our solution in front of 30-40 people, and most of them had direct involvement in the project. It was a great experience because you could immediately see if the project is going in the right direction or if the key users are not happy with what they are seeing.
After demo to the business users, the whole team gathered to share their thoughts about previous sprint. Every member wrote down positives and negatives that he/she thought were important. Then we compiled the feedback and worked on putting some actions in place to improve the most common ‘negatives’ in the next sprint.
Near the end of the sprint, Product Owner plus selected team members met to go through Product Backlog to see if any changes in priorities are required. Most of the time, there were some adjustments needed. Some of that was due to issues encountered during development or changes to requirements. Remember, Scrum is all about expecting changes and not avoiding them. Backlog Refinement meeting is a perfect example of that.
The Scrum project that I took part in was a great experience. It offered a fresh approach and proved that Agile can work in MES implementations. We applied some modifications to the methodology, but in general the concept was the same. Most importantly, you need business to be actively and continuously involved in the project. Not only the people that will use the solution, but also higher level execs must know how the Agile approach works. Every demo day requires a time commitment of at least one hour from key business users for the feedback process to work. Once adopted, Agile approach is perfect to handle future change requests that are frequent in MES implementations.